Discussion :

[RyzenOC]

Un iphone6 ne coute que 250€ a la production.

Les 500€ c'est la marge pour amortir l'investissement dans "l'innovation" et dans l'os (qui est censé etre gratuit).

ton iphone vaut super cher

Je n'ai pas d'Iphone.

Ah moi et les autres appareil électronique, ça fait deux, il n'y a que le PC

Je remarque que les PC fixe ne tombent jamais en panne (en dehors d'une barrette mémoire ou d'un disque dur), j'ai encore un de mes vieux PC datant de 25ans !, et a part le disque dur tous le reste est d'origine.
L'explication:
Composant plus gros donc plus solide (soudure plus résistante),
Appareil bien ventilé (évite la chaleur).

[Aiekick]

pas besoin d'avoir plusieurs cores il suffit juste d'être bien dans le sien

[Saverok]

Ce sujet est un peu en contradiction avec un autre topic actuel : http://www.developpez.net/forums/d14...nelle-t-futur/

La programmation fonctionnelle tire justement parti du traitement parallèle.
Si ce type de programme monte en force, et cela semble être le cas, les processeurs multi-coeurs sont tout indiqués pour cela

[hn2k5]

En quoi M. Torvald est il qualifié pour émettre ce genre de jugement ?

Il a pondu un OS répandu dans le monde entier, puis il a bossé chez Transmeta (qui a coulé en 2009 - dur de lutter contre les 2/3 mastodontes du secteur), une boîte qui fabriquait des processeurs à faible consommation électrique.
:-)

[Ryu2000]

En lisant le titre je me suis dit qu'il trollais, mais en lisant l'article j'ai vu qu'il avait totalement raison.

En gros il dit qu'en ce qui concerne les processeurs il vaut mieux 4 gros cœurs que 8 petits cœurs et c'est totalement vrai.

[Null4Ever]

Comme d'habitude, les posts de Linus sont toujours sujets à contre-verse dans la mesure où ils sont très (trop) souvent sortis de leurs contextes.

Dans le cas présent, il est évident qu'avoir 16 coeurs pour faire du traitement de texte n'améliorera ni ma vitesse de saisie, ni ne corrigera mes fautes d'orthographe ou de grammaire.

En revanche, avoir 256 coeurs (et même bien plus) et de bon gros caches sera idéal pour une application de type serveur d'application web à gros trafic à condition qu'elle soit écrite justement en programmation massivement parallèle par de vrais codeurs professionnels (ce que je ne suis malheureusement pas).

Un excellent exemple ici : www.gwan.ch qui est un outil qui tire automatiquement la quintessence du nombre de coeurs de n'importe quelle machine, des tests ayant été faits dans un labo de Zurich sur une machine avec 1024 coeurs !

Bonne et heureuse année à tous en ce jour de deuil national.
Je suis Charlie.

PS: Je suis tout à fait d'accord sur le fait que certains n'apprécient pas mon (ou mes) post(s), mais il me semble qu'il serait intéressant que celui (ou ceux) qui vote(nt) négativement (pouce vers le bas) donne(nt) une raison valable à leur appréciation négative. Et ceci est valable pour tous les posts de tout le monde. Sinon, ce genre de position arbitraire (et surtout anonyme, c'est tellement plus confortable...) est nulle et non avenue et ce forum ferait bien mieux de supprimer cette option alors qu'un débat serein pourrait permettre à chacun de donner son point de vue avec des arguments solides.

Comme disait le regretté Coluche : J'attends !

[Ithildine]

A mon humble avis, un algorithme doit être conçu dès le départ pour être utilisé en environnement parallèle. Ceci fait parti du design initial et ces algorithmes sont souvent plus compliqués qu'on ne le pense à première vue et sont également particulièrement délicats à mettre au point : il y a des bugs de synchronisation pas toujours évidents à analyser.
Ensuite, gérer le parallélisme nécessite aussi des ressources (du CPU, des verrous, des attentes d'autres files d'exécution, de l'éclatement ou de la consolidation de données). Le parallélisme me semble intéressant sur le calcul intensif, genre calcul scientifique ou encodage, mais imaginer accélérer un algorithme non prévu à la base pour être parallélise me semble être une illusion, un dou rêve... J'ai vu dans ma jeunesse ce que donnait les options de parallélisation "automatique" du Fortran... Ca allait vite, ça parallélisait les boucles... mais ça donnait des résultats faux...
Au niveau logiciel, le parallélisme, c'est bien sur le papier, mais c'est complexe (toujours plus qu'on le pense : éclatement et consolidation des données, synchronisation, séquencement, bug non reproductibles) et si l'algorithme n'est pas pensé dès le départ pour être parallélisé, à ce que j'ai vu, cela donne des résultats souvent moins bon qu'espérés. Après, rien n'est ni blanc, ni noir et on trouvera toujours des cas extrêmes, soit dans un sens, soit dans l'autre...

Ensuite, au niveau du processeur, quand on double le nombre de coeurs, on double en apparence la vitesse d'exécution... à condition, me semble-t-il, que tous les nouveaux coeurs se voient affecter un thread qui était en attente de CPU. C'est facile quand on passe de 1 à 2, de 2 à 4, de 4 à 8, et ainsi de suite mais quand tous les threads en attente trouvent déjà un coeur libre, certains des nouveaux coeurs restent inutilisés ou seulement à une fraction de leur temps et le gain apparent en vitesse s'étiole... C'est un peu l'offre et la demande : le business marche très bien tant que le produit trouve preneur mais quand la demande s'effondre le rendement s'effondre. A ceci s'ajoute mécaniquement un rendement à décroissance logarithmique : toujours doubler le nombre de coeur, ce qui devient difficile au delà de quelques dizaines ou centaines de coeurs (ajouter 1, 2, ... 16 coeurs... mais 1024, cela devient exponentiellement difficile techniquement et toujours pour garder le même gain d'un facteur 2 sur la génération précédente), sans être certains que tous ces coeurs trouvent un thread en attente. C'est ainsi que je comprends la remarque de Linus Torvalds, et puis il y a le style "tout en nuance" du monsieur, mais c'est aussi pour cela qu'on l'aime... ou qu'on le déteste !.. ;-)

[behall]

Contrairement a ce que certains semblent avoir compris, l'article de Linus Torvalds critique une vision de l'avenir ou les machines devraient être MASSIVEMENT parallèles.
Effectivement il a des mots durs envers le parallélisme en général, mais c'est bien un avenir Massivement parallèle qu'il critique, relisez, il cite des centaines de cores, on est loin d'une architecture quadri-cores ni même octo-cores, même si une utilisation de machines virtuelles nombreuses n'est pas le besoin de tout le monde.
En y réfléchissant calmement effectivement les besoins de calculs massivement parallèles se limitent à des implémentation d’algorithmes mathématiques et à leurs usages dans différents domaines dont l’algorithmique graphiques (dont les besoins sont plus spécifiques pour les traitements d'images). en dehors de ces domaines la parallèlisation est moins utile (bien qu'elle puisse l'être) et pour utiliser des machines virtuelles ce sont les outils de virtualisation (et les systèmes utilisés) qui ont besoin de paralléliser et plus rarement les programmes les plus courants. En gros la parallélisation à grande échelle est plutôt un domaine de spécialistes et devrait le rester encore un certain temps.

[steel-finger]

Oui, en plus le titre de la news porte a confusion....