Intel va proposer des Xeon à 48 cœurs, Réactions à la publication du 06/11/2018

[Lionel]

En plus de ses problèmes à graver sous les 14nm, Intel fait face à une concurrence devenue conséquente d'AMD qui propose des puces dotées de très nombreux coeurs.
Pour lutter contre ce concurrent, Intel a annoncé la sortie prochaine de Xeon dotés de 48 coeurs.
Dans la pratique, chaque processeur sera en fait doté de deux puces de 24 coeurs interconnectées au sein du même package.
Il sera de plus possible d'utiliser ces processeurs sur des cartes mères dotées de deux sockets, pour avoir des machines qui auront au total 96 coeurs.

Intel est resté chiche au niveau des spécifications de ces puces, que ce soit le TDP ou encore le nombre de lignes PCI-Express ainsi surtout que leur tarif.

[MàJ] Intel en a dit un peu plus sur ses puces. Elles seraient selon des tests effectués par la société entre 1,5 et 3,4 fois plus véloces qu'un processeur AMD EPYC 7601. Ce processeur a 32 coeurs (64 fils) à 2,2 GHz (turbo entre 2,7 et 3,2 GHz).

Lien vers le billet original

[Hebus]

Quand même grand central offre une manière interessante de faire du //isme en imposant l’organisation du travail en file d’attente séquentielles ou //

En laissant le noyeau arbitrer la distribution des resources, pour les closures sensées réaliser le travail.

Ça ne résout pas tout, ça reste d’assez bas niveau, obligeant à gérer avec beaucoup d’attention les files d’attente.

Et pour ce qui est des browsers ils sont massivement multithreadé ... je me souviens particulièrement d’Omniweb sous NeXTStep

Par contre oui, à cette époque et encore aujourd’hui l’affichage se fait dans la thread principale... quoique maintenant avec Métal qui permet de faire du multithreading massivement, on devrait pouvoir bricoler certains trucs pour les surfaces d’affichage de MetalKit...

Ce message a été modifié par Hebus - 12 Nov 2018, 13:57.

[iAPX]

Quand même grand central offre une manière interessante de faire du //isme en imposant l’organisation du travail en file d’attente séquentielles ou //

En laissant le noyeau arbitrer la distribution des resources, pour les closures sensées réaliser le travail.

Ça ne résout pas tout, ça reste d’assez bas niveau, obligeant à gérer avec beaucoup d’attention les files d’attente.
...

C'est l'inverse, GrandCentral est une abstraction de haut-niveau sans les outils de bas-niveau indispensables pour exploiter efficacement du parallélisme, idéal pour faire une démo, un prototype, mais qui ne doit guère être utilisé dans les applications réelles

Pour le reste entre le budget et son petit copain deadline, sans parler d'Amdahl qui fait la loi, faut pas trop rêver en couleur sur ce que l'avenir nous apportera sur les tâches interactives, puisque si on a pas su ou voulu le faire en quelques décennies de micro-ordinateur à plusieurs cœurs (initialement via des CPU mono-cœur interconnectées), je ne vois pas pourquoi ça arriverait magiquement demain!

Ce message a été modifié par iAPX - 12 Nov 2018, 14:07.

[Hebus]

Quand même grand central offre une manière interessante de faire du //isme en imposant l’organisation du travail en file d’attente séquentielles ou //

En laissant le noyeau arbitrer la distribution des resources, pour les closures sensées réaliser le travail.

Ça ne résout pas tout, ça reste d’assez bas niveau, obligeant à gérer avec beaucoup d’attention les files d’attente.
...

C'est l'inverse, GrandCentral est une abstraction de haut-niveau sans les outils de bas-niveau indispensables pour exploiter efficacement du parallélisme, idéal pour faire une démo, un prototype, mais qui ne doit guère être utilisé dans les applications réelles

Pour le reste entre le budget et son petit copain deadline, sans parler d'Amdahl qui fait la loi, faut pas trop rêver en couleur sur ce que l'avenir nous apportera sur les tâches interactives, puisque si on a pas su ou voulu le faire en quelques décennies de micro-ordinateur à plusieurs cœurs (initialement via des CPU mono-cœur interconnectées), je ne vois pas pourquoi ça arriverait magiquement demain!

Non bas niveau par rapport à des abstractions du type Future que l’on trouve dans Netty/Scala ... autres et bientôt Swift. Je m’en suis servi intensivement cette année...

Je ne sais pas où en est la discussion autour de cet ajout à Swift mais les dernières info que j’avais, ils considéraient utiliser GCD en dessous... comme sous Scala, les Future utilsent les files de threads gérées par Java, comme contexte d’execution et on a accès aux différentes stratégies associées à chaque files.

Bien sur que GCD est de plus haut niveau que les primitive de base ... je ne suis pas un expert en multi threading mais la première fois que je m’en suis servis c’était en 93 pour un plug-in à une application 3D sous NeXTStep écrite par un ami, pour déporter du calcul de forme géometriques au kernel de Mathematica