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

[WipeOut]

Sont en mode panique.
Quand on voit qu'ils étaient prêts à tricher pour les nouveaux i9 via un tiers, honte à eux. Moi je switch sur AMD next year

[otto87]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

[radamanthys]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

ce qui fait "paniquer" (le mot est un peu fort) c'est plutôt de ne plus être maintenant systématiquement en tête, pas de l'avoir été durant des années.
et que lorsque on est encore devant dans les perfs c'est avec un ratio performance prix assez mauvais.
il y a un mouvement de fond au niveau de différents test dans la presse qui ont de plus en plus tendance a ne plus recommander le dernier né d’Intel a cause de ce ratio perf/prix.
les premiers a réagir sont les acheteurs au détail, qui montent eux même leurs machines, mais la tendance pourrait s'étendre.

https://www.cowcotland.com/news/64787/amd-s...-allemagne.html

Ce message a été modifié par radamanthys - 6 Nov 2018, 11:38.

[Twisell]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

ce qui fait "paniquer" (le mot est un peu fort) c'est plutôt de ne plus être maintenant systématiquement en tête, pas de l'avoir été durant des années.
et que lorsque on est encore devant dans les perfs c'est avec un ratio performance prix assez mauvais.
il y a un mouvement de fond au niveau de différents test dans la presse qui ont de plus en plus tendance a ne plus recommander le dernier né d’Intel a cause de ce ratio perf/prix.
les premiers a réagir sont les acheteurs au détail, qui montent eux même leurs machines, mais la tendance pourrait s'étendre.

https://www.cowcotland.com/news/64787/amd-s...-allemagne.html

Voir les benchs du nouvel iPad pro, en terme de puissance de calcul l'A12X rattrape la plupart des Intel milieu de gamme.
Certes c'est une autre architecture ce qui reste un frein important à un switch, mais oui il y a de quoi paniquer.

[otto87]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

ce qui fait "paniquer" (le mot est un peu fort) c'est plutôt de ne plus être maintenant systématiquement en tête, pas de l'avoir été durant des années.
et que lorsque on est encore devant dans les perfs c'est avec un ratio performance prix assez mauvais.
il y a un mouvement de fond au niveau de différents test dans la presse qui ont de plus en plus tendance a ne plus recommander le dernier né d’Intel a cause de ce ratio perf/prix.
les premiers a réagir sont les acheteurs au détail, qui montent eux même leurs machines, mais la tendance pourrait s'étendre.

https://www.cowcotland.com/news/64787/amd-s...-allemagne.html

Intel fait comme NVIDIA, faute de concurrence réelle, les prix sont élevés

Voir les benchs du nouvel iPad pro, en terme de puissance de calcul l'A12X rattrape la plupart des Intel milieu de gamme.
Certes c'est une autre architecture ce qui reste un frein important à un switch, mais oui il y a de quoi paniquer.

C'est un faux problème pour intel puisqu'Apple gardera jalousement ses puces vendu dans des machines a prix d'or, ce qui cantonnera Apple toujours dans une cage de quelques pourcents... et que le reste des puces ARM est pour l'instant en retrait...L'A12 est très bon, mais reste à voir ce que ça donne dans une vrai machine, avec plus de 6Go de ram et de quoi gérer autre chose qu'un simple port USB C...

[Sethy]

ARM étant issu d'un monde différent avait du "retard" sur Intel. Retard qu'ils rattrapent à pas de géants, aidé en cela parce qu'Intel fait du sur place.

En gros un i3 actuel égale un i7 d'il y a 7 ans et comme les perfs d'un i7 actuel sont le double de celles de l'i3 actuel, la puissance est doublée en 7 ans, soit une augmentation de 10,4% par an. L'i7 d'il y a 7 ans est gravé en 32nm et l'i3 actuel en 14 ...

Mais imaginer (performance pure) qu'une fois qu'ARM aurait rattrapé Intel, ils vont le dépasser en le laissant sur place, ça c'est une erreur. Ils seront confrontés aux mêmes problèmes. OK, il seront peut être 2x plus rapides car débarrassé de la compatibilité x86 qu'Intel doit trainer. Mais pas plus.

Par contre en performance/Watts, la avec les coeurs dédiés, etc, oui il y a de la marge de progression. Mais la on parle autonomie et mobilité, pas performance.

Ce message a été modifié par Sethy - 6 Nov 2018, 12:00.

[iAPX]

Le monde des serveurs, ou les mondes car le HPC n'est pas du Cloud pour du Web par exemple, sont quasi totalement disjoint des usages et valeurs qu'on trouve dans le grand-public.
De la même façon d'ailleurs que si Ferrari fait des bons moteurs, je les verrais mal équiper des semi-remorques ou des tracteurs, il y a des spécialistes pour ça...
(oui je sais comme pour Porsche, pour ceux qui savent vous avez compris l'idée quand-même)

Le grand-public est mal éduqué concernant ses ordinateurs, notamment à cause de Windows dans les années 90 où on a remplacé du hardware spécialisé par du logiciel via des interfaces générique, offrant la possibilité de faire supporter moults choses comme le son par la CPU principale puisque leurs performances grimpaient à une vitesse exponentielle d'année en année, ce qui a amené une culture de la performance brute de la CPU comme premier facteur à considérer. C'est maintenant culturel.

On en revient sur les PC ou même les Mac et c'est une bonne chose, même si Apple ne nous sert pas très bien en se focalisant sur les CPU.
Pour des raisons de ratio perf/Watt, les plateformes mobiles sont autrement plus complexes et riches que les PC grand public (ou la plupart de nos Mac), puisqu'on multiplie les petites unités dédiées parfaitement adapté à leur tâche pour décharger les cœurs de traitement du SoC autant que possible. Une conception bien plus avancée que la plupart des Mac et PC grand-public!

Les serveurs ont des rôles divers et sont hyper-spécialisés, où là aussi il n'y a pas un organe central (certes vital) chargé de tout, mais c'est d'abord et avant tout une synergie entre le logiciel et le matériel qui permet d'optimiser le ratio performance/coût, où le logiciel est la seule chose qui importe et le matériel agencé pour le servir au mieux, expliquant la multiplicité de l'offre d'Intel dans ces marchés.
Les gens qui conçoivent des serveurs ne se focalisent pas sur la CPU, mais sur les débits et/ou la latence des opérations, et font en sorte d'éliminer tout ralentissement en équilibrant au mieux les composants matériels et leurs capacités de communication.

On n'augmente pas les performances d'un serveur en upgradant sa CPU, sauf rares exceptions, on en monte un autre taillé très différemment avec une nouvelle CPU à la place et des composants adaptés pour en optimiser l'usage.
Je ne suis pas inquiet pour Intel dans le monde des serveurs à moyen-terme, même si AMD grâce justement à des capacités d'IO de ses CPU prend des places de marché sur certains équipement et ARM aussi.

Ce message a été modifié par iAPX - 6 Nov 2018, 12:56.

[PetitGreg]

ça sera intéressant de savoir comment les 2 puces 24 cœurs seront interconnectées entre elles.
Intel avait fait un gros travail de sape contre AMD en critiquant ouvertement leur architecture d'interconnexion entre cœurs. L'architecture d'AMD étant moins performante sur le papier, mais finalement beaucoup souple et facile à mettre en œuvre et en production.
A voir, si Intel a fait du "bricolage" comme AMD ^^

[iAPX]

ça sera intéressant de savoir comment les 2 puces 24 cœurs seront interconnectées entre elles.
Intel avait fait un gros travail de sape contre AMD en critiquant ouvertement leur architecture d'interconnexion entre cœurs. L'architecture d'AMD étant moins performante sur le papier, mais finalement beaucoup souple et facile à mettre en œuvre et en production.
A voir, si Intel a fait du "bricolage" comme AMD ^^

Le bricolage du 2990wx se voit dans les benchmarks, il est totalement étouffé par sa bande-passante mémoire (et celle du cache L3 orienté mémoire) et marginalement plus rapide que le très intéressant 2950x pourtant équipé de 2X moins de cœurs!

Les capacité de communication réelles sont souvent essentielles, plus que la puissance brute.

Ce message a été modifié par iAPX - 6 Nov 2018, 13:02.

[Lionel]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

ce qui fait "paniquer" (le mot est un peu fort) c'est plutôt de ne plus être maintenant systématiquement en tête, pas de l'avoir été durant des années.
et que lorsque on est encore devant dans les perfs c'est avec un ratio performance prix assez mauvais.
il y a un mouvement de fond au niveau de différents test dans la presse qui ont de plus en plus tendance a ne plus recommander le dernier né d’Intel a cause de ce ratio perf/prix.
les premiers a réagir sont les acheteurs au détail, qui montent eux même leurs machines, mais la tendance pourrait s'étendre.

https://www.cowcotland.com/news/64787/amd-s...-allemagne.html

Voir les benchs du nouvel iPad pro, en terme de puissance de calcul l'A12X rattrape la plupart des Intel milieu de gamme.
Certes c'est une autre architecture ce qui reste un frein important à un switch, mais oui il y a de quoi paniquer.

ARM étant issu d'un monde différent avait du "retard" sur Intel. Retard qu'ils rattrapent à pas de géants, aidé en cela parce qu'Intel fait du sur place.

En gros un i3 actuel égale un i7 d'il y a 7 ans et comme les perfs d'un i7 actuel sont le double de celles de l'i3 actuel, la puissance est doublée en 7 ans, soit une augmentation de 10,4% par an. L'i7 d'il y a 7 ans est gravé en 32nm et l'i3 actuel en 14 ...

Mais imaginer (performance pure) qu'une fois qu'ARM aurait rattrapé Intel, ils vont le dépasser en le laissant sur place, ça c'est une erreur. Ils seront confrontés aux mêmes problèmes. OK, il seront peut être 2x plus rapides car débarrassé de la compatibilité x86 qu'Intel doit trainer. Mais pas plus.

Par contre en performance/Watts, la avec les coeurs dédiés, etc, oui il y a de la marge de progression. Mais la on parle autonomie et mobilité, pas performance.

ARM a du bol en effet actuellement, et avec lui Apple et les autres. Intel est bloqué à 14nm ce qui permet en gravant en 10, et 7 nm d'augmenter les performances facilement (il n'y a pas que ça). Maintenant, de toute façon la barrière quantique est proche et ce gain va se réduire d'ici deux ou trois ans. On verra alors si ARM arrive à faire des puces au design très performant pour des machines de bureau. Là l'avantage de l'économie d'énergie est moindre.
Je rappelle quand même qu'ARM s'est vautré sur le marché des serveurs.

[ericb2]

@Lionel : ça peut se discuter. Dans une "boutique", j'ai fait remplacer des tours par des brix et autres NUC (selon l'usage client/serveur), et il n'y a pas photo : consommation, chauffage poussière encombrement, bruit moindres, pour une utilisation confortable. Et si ARM continue, je pense que le choix entre les deux architectures deviendra possible.

[iAPX]

...
Je rappelle quand même qu'ARM s'est vautré sur le marché des serveurs.

Je n'irais pas l'écrire comme cela...

Le monde ARM est en train de s'imposer dans des serveurs spécialisés, que ce soit en réseautique (ce qu'on appelle des routeurs ou switch) ou le stockage, sans compter le nombre de puces à jeu d'instruction ARM présente même dans des serveurs plus génériques, sans pour l'instant être concurrentiel coté CPU principale pour des charges de travail plus génériques.

Il y a du chemin à faire et comme Apple le démontre coté performances et performances/watt il est possible de faire bien mieux que les autres acteurs du monde ARM, dont les core sont orienté efficacité (sans l'atteindre) au détriment des performances, que ça soit les IP d'ARM ou les réalisations des uns ou des autres (souvent basée sur la première).

En même temps, coté serveur on est plutôt agnostic sur le jeu d'instruction utilisé, seul compte l'efficacité (débit et/ou latence) rapportée au coût sur les logiciels choisi.
Et pour l'instant Intel est incontournable pour cela, sur le moyen-terme ça devrait tenir encore longtemps même si AMD et les CPU à jeu d'instruction ARM vont progressivement gagner des parts de marché.

Ce message a été modifié par iAPX - 6 Nov 2018, 13:18.

[Lionel]

Je n'ai pas dit que l'échec était définitif, mais ARM a reculé sur le marché dominé par Intel après avoir tenté des incursions.

[kwak-kwak]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

ce qui fait "paniquer" (le mot est un peu fort) c'est plutôt de ne plus être maintenant systématiquement en tête, pas de l'avoir été durant des années.
et que lorsque on est encore devant dans les perfs c'est avec un ratio performance prix assez mauvais.
il y a un mouvement de fond au niveau de différents test dans la presse qui ont de plus en plus tendance a ne plus recommander le dernier né d’Intel a cause de ce ratio perf/prix.
les premiers a réagir sont les acheteurs au détail, qui montent eux même leurs machines, mais la tendance pourrait s'étendre.

https://www.cowcotland.com/news/64787/amd-s...-allemagne.html

La panique vient du bas, milieu, et désormais haut de gamme sur le marché grand public.
Quand on voit qu'un AMD Ryzen 5 2600 à 190€ (soit le prix d'un Intel Core i3 8100), dépasse allègrement les performances d'un Intel Core i5 8600 à 340€, il y a en effet de quoi paniquer. C'est tout le secteur grand public que Intel est en train de perdre.

Du coté des serveurs c'est effectivement souvent l'ultra haut de gamme qui importe, ce qui donne parfois un léger avantage à Intel (meilleurs en performances brute par puce et en performances par watts consommés sur ces puces, mais pour un tarif complètement rédhibitoire (8700$ pour du 28 coeurs / 56 threads) qui ne sera pas compensé par la facture d'électricité). Par ailleurs, vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (le ratio de performances par Watt consommé devrait entrer en faveur d'ARM, et les perfs en mono thread sont corrects (Ca facilite de développement en évitant d'avoir à ultra-paralléliser les tâches)).

Ce message a été modifié par kwak-kwak - 6 Nov 2018, 14:20.

[iAPX]

...
Et vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (les perfs par Watt consommé devrait entrer en faveur d'ARM).

Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien.

Les autres acteurs utilisant le jeu d'instruction ARM sont à 2ans ou 3ans d'avoir des CPU comparable à celles des Mac actuels, et entre-temps la cible ce sera déplacée, peut-être énormément si Intel arrive à sortir du 7nm comme prévu à ce moment.

Mais je partage quand-même l'avis que sur le long-terme Intel a perdu le marché grand-public.

[Sethy]

@Lionel : ça peut se discuter. Dans une "boutique", j'ai fait remplacer des tours par des brix et autres NUC (selon l'usage client/serveur), et il n'y a pas photo : consommation, chauffage poussière encombrement, bruit moindres, pour une utilisation confortable. Et si ARM continue, je pense que le choix entre les deux architectures deviendra possible.

Je trouve que la comparaison que je fais relative l'importance de la finesse de gravure pour les performances pures.

Passer de 32nm à 14nm, n'a multiplié la puissance que par 2 (ou un chouia plus si on discute sur le fait que l'i3 a 4 coeurs comme l'i7 de référence mais qui lui a l'HT).

[Ambroise]

Sont en mode panique.

En effet être systématiquement en tête des benchs depuis des années, ça donne envie de paniquer

ce qui fait "paniquer" (le mot est un peu fort) c'est plutôt de ne plus être maintenant systématiquement en tête, pas de l'avoir été durant des années.

Je ne suis sûr que ce processeur soit une réponse à AMD.
Il me fait plutôt penser à une réponse aux nombreux processeurs ARM qui percent actuellement sur les serveurs : ils ont tous une caractéristique commune, c'est d'avoir beaucoup de canaux de DDR. Nettement plus de canaux de DDR que les Xéons.

Du coup, ils n'essaient pas de se mesurer à la puissance brute des Xéons, mais plutôt à des usages plus légers pour lesquels la bande passante de la mémoire est prépondérante.

Ces nouveaux Xéon AP multi-dies offrent cela : probablement une puissance par cœur sensiblement inférieure (si jamais ils mettent 2 fois plus de cœurs dans la même enveloppe thermique, ça va devoir tourner à faible fréquence), mais deux fois plus de canaux DDR et donc de bande passante. Le choix du multi-die n'est pas forcément une façon simple d'augmenter le nombre de coeur, mais plutôt une façon simple d'augmenter le nombre de canaux DDR.

Le positionnement tarifaire va être complexe en revanche : ils vont faire des CPU à 10000$ face à des concurrent à 800$ ?

[otto87]

On en revient sur les PC ou même les Mac et c'est une bonne chose, même si Apple ne nous sert pas très bien en se focalisant sur les CPU.
Pour des raisons de ratio perf/Watt, les plateformes mobiles sont autrement plus complexes et riches que les PC grand public (ou la plupart de nos Mac), puisqu'on multiplie les petites unités dédiées parfaitement adapté à leur tâche pour décharger les cœurs de traitement du SoC autant que possible. Une conception bien plus avancée que la plupart des Mac et PC grand-public!

L'informatique est un éternel recommencement, le coprocesseur arithmétique! La problématique est juste celle des capacités de communication, ce n'est pas pour rien que ce coprocesseur de l'époque a fusionné avec le CPU, c'est plus efficace!

Ce message a été modifié par otto87 - 6 Nov 2018, 16:48.

[Lionel]

On en revient sur les PC ou même les Mac et c'est une bonne chose, même si Apple ne nous sert pas très bien en se focalisant sur les CPU.
Pour des raisons de ratio perf/Watt, les plateformes mobiles sont autrement plus complexes et riches que les PC grand public (ou la plupart de nos Mac), puisqu'on multiplie les petites unités dédiées parfaitement adapté à leur tâche pour décharger les cœurs de traitement du SoC autant que possible. Une conception bien plus avancée que la plupart des Mac et PC grand-public!

L'informatique est un éternel recommencement, le coprocesseur arithmétique! La problématique est juste celle des capacités de communication, ce n'est pas pour rien que ce coprocesseur de l'époque a fusionné avec le CPU, c'est plus efficace!

On y reviendra aux coeurs hétérogènes, spécialisés, que l'on peut allumer ou éteindre au besoin.

[otto87]

On y reviendra aux coeurs hétérogènes, spécialisés, que l'on peut allumer ou éteindre au besoin.

C'est déjà plus ou moins le cas avec les switch GPU/GPU intégré!

[Lionel]

On y reviendra aux coeurs hétérogènes, spécialisés, que l'on peut allumer ou éteindre au besoin.

C'est déjà plus ou moins le cas avec les switch GPU/GPU intégré!

Oui, et avec des GPU qui font de plus en plus de choses différentes que d'afficher des images.

[iAPX]

On y reviendra aux coeurs hétérogènes, spécialisés, que l'on peut allumer ou éteindre au besoin.

C'est déjà plus ou moins le cas avec les switch GPU/GPU intégré!

C'est le cas avec la NPU sur un SoC A12 ou A11, l'encodeur ou décodeur vidéo hardware (iGPU et dGPU), aussi avec les unités AVX et AVX2 des CPU Intel récentes, et la spécialisation est l'avenir car le silicium ne coûte rien alors qu'on a du mal a augmenter les IPC des architectures complexes qui ont de toute façon un coût énergétique incroyablement élevé pour des traitements spécialisés.

[otto87]

On y reviendra aux coeurs hétérogènes, spécialisés, que l'on peut allumer ou éteindre au besoin.

C'est déjà plus ou moins le cas avec les switch GPU/GPU intégré!

C'est le cas avec la NPU sur un SoC A12 ou A11, l'encodeur ou décodeur vidéo hardware (iGPU et dGPU), aussi avec les unités AVX et AVX2 des CPU Intel récentes, et la spécialisation est l'avenir car le silicium ne coûte rien alors qu'on a du mal a augmenter les IPC des architectures complexes qui ont de toute façon un coût énergétique incroyablement élevé pour des traitements spécialisés.

D’où l'avantages du SIMD (l'essentiel des gains de perf ces dernières années avec les GPU/NPU), même si ça oblige à pas mal de gymnastique pour en tirer le meilleurs! Vivement que la quantité de registres disponibles augmente!!!!

Ce message a été modifié par otto87 - 6 Nov 2018, 21:07.

[Sethy]

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

[otto87]

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

à raison!
Quand on compare l'assembleur 6800 au i386, y a de quoi pleurer!

Ce message a été modifié par otto87 - 6 Nov 2018, 21:38.

[Sethy]

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

à raison!
Quand on compare l'assembleur 6800 au i386, y a de quoi pleurer!

Oui, mais déjà à l'époque, les pragmatiques ont gagné contre les dogmatiques ...

Et je pense que la même chose est en train de se passer ...

[iAPX]

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

Aucun rapport, déjà que je ne vois pas ce qu'on pourrait qualifier de RISC ou de CISC aujourd'hui, toutes les CPU modernes (hors IoT et encore) ont des unités SIMD intégrées.

Mais encore faut-il utiliser le SIMD à bon escient, ce que les compilateurs C/C++ ne savent vraiment pas faire hors parallélisme évident (je n'ose parler des autres langages presque tous basés sur du C ou C++!)
Par exemple pour charger une structure alignée de 512bits ou proche, aucun n'a l'idée de déclencher une lecture dans un registre AVX2 pour après balancer les données dans les registres généraux, résultats plein de cycles perdus avec des lectures partielles depuis la ligne dans le cache L1.
Et on perd au passage le bénéfice atomicité de l'architecture Intel lors de l'écriture, obligeant à mettre des clôtures autour (fence) et/ou d'utiliser un sémaphore, ça rend le truc 10X plus lent à la fin!

Les smartphone qui sont -pour moi- des merveilles de technologies intégrant au gros minimum 3 CPU (centrale, communication, stockage), mais souvent bien plus, et des unités spécialisées en veux-tu en voilà (SIMD évidemment, traitement d'image pour la photo/vidéo, Enclave de sécurité, traitement du son, NPU pour le ML, traitement d'empreinte, etc.).

Rien à voir avec un PC ou un Mac de base, et bien plus proche des serveurs spécialisés qui s'appuient sur des unités très efficaces dans un domaine précis et sont architecturés pour des résultats optimaux.
Et c'est là que la CPU n'est pas l'essentiel du serveur mais si elle en est le chef d'orchestre, et que rarement ses performances pures conditionnent celles du serveur, mais l'équilibre de l'ensemble pour les tâches à effectuer au meilleur rapport performance (latence et/ou débit) pour le coût.
Et Intel a un catalogue très fourni pour avoir la bonne CPU à offrir dans chaque contexte, c'est une force.

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

Ce message a été modifié par iAPX - 6 Nov 2018, 22:16.

[Sethy]

On parlait de l'esprit, pas de la lettre

Ah le 6502 du C-64

[iAPX]

On parlait de l'esprit, pas de la lettre

Ah le 6502 du C-64

Eh bien justement le 6502 avait la simplicité des jeux d'instructions du RISC de l'époque, mais avec à la fois du load/store intégré aux instructions donc du CISC, et des modes d'accès à la mémoire extrêmement avancé (son arme fatale) qu'on a trouvé que bien plus tard dans le CISC (M6809 notamment, quoique différemment) mais qui ne fait évidemment pas parti des fondements du RISC (on fait les calculs d'adresse séparément des load-store et évidemment séparément des opérations elle-même).

Comme quoi tout n'est pas binaire

Ce message a été modifié par iAPX - 6 Nov 2018, 22:41.

[otto87]

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

C'est sans doute que tu n'a pas pratiqué l'assembleur su x86, c'est une véritable plaie Et oui les compilos sont des tanches j'ai fais une formation HPC y a 2 semaine, c'est affolant ce que même le compilos d'intel n'est pas capable de trouver tout seul, en mettant à la main les bonnes directives sur des valeur a garder dans les registres, on peut faire du X10 sur des trucs qui se rapprochent de stupides produits de convolution...
Mais bon c'est pareil sur GPU, j'arrive a du X 50 avec du code tweaké à la main alors que pourtant la compilation repose sur LLVM qui est censé être au top!

Sethy : il est plus question de philosophie de code


Ce message a été modifié par otto87 - 6 Nov 2018, 22:42.

[iAPX]

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

C'est sans doute que tu n'a pas pratique l'assembleur su x86, c'est une véritable plaie Et oui les compilos sont des tanches j'ai fais une formation HPC y a 2 semaine, c'est affolant ce que même le compilos d'intel n'est pas capable de trouver tout seul, en mettant à la main les bonne directive sur des valeur a garder dans les registres, on peut faire du X10 sur des trucs qui se rapprochent de stupides produits de convolution...
Mais bon c'est pareil sur GPU, j'arrive a du X 50 avec du code tweaké à la main alors que pourtant la compilation repose sur LLVM qui est censé être au top!

Sethy : il est plus question de philosophie de code

J'ai vendu mon travail avec de l'assembleur au début, notablement sur du Z80, M6809, M68000, 8088, puis 80286, 386, etc. et aujourd'hui je continue avec AVX et AVX2 (non je n'utilise pas les Intrinsic, on m'a déjà posé la question!). je connaisssais évidemment avant le 8080 et le M6800 (en fait M6802 chez SMT Goupil).

À l'époque du 8088, je préférais évidemment le M68000 (ceux qui s'y sont essayé me comprennent), mais c'était déjà tellement au-dessus du 8-bits mis à part le M6809 (pour les modes d'adressages autrement plus avancées) rare et cher, et le Z80 quand on utilise les instructions cachées sur IX et IY (les mêmes que pour HL mais avec un prefix) mais c'est venu un peu tard et pas nécessairement compatible avec un "compatible" NSC-800 (Canon X-07) qui avait aussi des bugs sur les répétitions d'opérations (pour ça que le Basic Microsoft intégré n'en utilisait aucune, je le sais car je l'ai désassemblé et commenté!)

Ce message a été modifié par iAPX - 6 Nov 2018, 22:48.

[marc_os]

...
Et vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (les perfs par Watt consommé devrait entrer en faveur d'ARM).

Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien.

Hein ?
Pourrais-tu préciser stp quelles sont ces tâches interactives, "ton quotidien", qui nécessitent surtout des traitements mono-thread efficaces et ne profitent pas des autres cœurs ?

Sur Mac, le multi-threading via GCD permet par exemple (en simplifiant) à une application d'effectuer un traitement lourd dans un thread dédié, le thread principal s'occupant essentiellement de l'interface utilisateur. Ainsi, l'interface reste toujours fluide et réactive, quelque soit la ou les tâches lourdes tournant "à côté". Tes « tâches interactives » donc ne fonctionnent pas comme ça ?

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

à raison!
Quand on compare l'assembleur 6800 au i386, y a de quoi pleurer!

Euh... Ne s'agit-il pas là de deux processeurs CISC ?
A ma connaissance, le premier processeur RISC sur Mac fut le PPC, une coproduction IBM/Motorola/Apple introduit il me semble avec les PowerMac.

Ce message a été modifié par marc_os - 7 Nov 2018, 15:02.

[iAPX]

...
Et vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (les perfs par Watt consommé devrait entrer en faveur d'ARM).

Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien.

Hein ?
Pourrais-tu préciser stp quelles sont ces tâches interactives, "ton quotidien", qui nécessitent surtout des traitements mono-thread efficaces et ne profitent pas des autres cœurs ?

Sur Mac, le multi-threading via GCD permet par exemple (en simplifiant) à une application d'effectuer un traitement lourd dans un thread dédié, le thread principal s'occupant essentiellement de l'interface utilisateur. Ainsi, l'interface reste toujours fluide et réactive, quelque soit la ou les tâches lourdes tournant "à côté". Tes « tâches interactives » donc ne fonctionnent pas comme ça ?

Mail, Chrome, Safari, Office, éditeurs de code divers et variés, VM pour le web (même quand il y en a 3 ou 4 simultanées pour des tâches dédiées c'est essentiellement monothread à cause des dépendances) : le quotidien de la plupart des gens
Ce qui caractérise d'ailleurs les tâches interactives est la chaîne de dépendance se terminant justement par l'UI qui ne peut être rafraichie/modifiée qu'une fois les traitements faits, et pour lesquelles avoir des tâches séparées est un non-sense.

Pour le reste j'aime cette vision très fantasmagorique du multithread, mais juste comparer un 4-cœur à 2Ghz au quoditien face à un 2-cœur à 4Ghz (du même niveau d'IPC), vous pleureriez sauf pour des tâches spécialisées

Ce message a été modifié par iAPX - 7 Nov 2018, 15:25.

[Hebus]

??? IAPX tu t’égares là...

Safari multi threading, ok, avec la puissance de nos becane ça se voit à peine...

Compilation multi thread, Xcode ou IDEA

Une image docker qui compile me bouffe 6 coeurs sur 12 (j’imagine mon réglage de docker)

Par contre grep et find dans le terminal sont toujours monothread... pas glop !

Edit: oui j’ai réglé Docker à 6 CPU et 8GB

Ce message a été modifié par Hebus - 7 Nov 2018, 15:39.

[otto87]

??? IAPX tu t’égares là...

Safari multi threading, ok, avec la puissance de nos becane ça se voit à peine...

Compilation multi thread, Xcode ou IDEA

Une image docker qui compile me bouffe 6 coeurs sur 12 (j’imagine mon réglage de docker)

Par contre grep et find dans le terminal sont toujours monothread... pas glop !

Edit: oui j’ai réglé Docker à 6 CPU et 8GB

Ce qui compte c'est la réactivité, il est désagréable de faire une action et de constater des latences. Quand je dois me taper la compilation d'OpenCV avec tout les modules, même avec 48 core, la meilleurs chose a faire c'est d'aller boire un grand grand café

[iAPX]

??? IAPX tu t’égares là...
...

"Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien." - iAPX

Le sujet était de possibilité de remplacement de CPU Intel dans nos ordinateurs, utilisés au quotidien, par des CPU à jeu d'instruction ARM, et moi expliquant que seul Apple fourni des performances mono-thread capable d'amener une réactivité similaire sur du mono-thread, car les tâches interactives sont essentiellement caractérisées par leur chaîne de dépendance (Input -> Processing -> Output) mais aussi par leur demande en terme de latence et non de débit.

Quand je dis "notre quotidien" c'est celui de la plupart des gens utilisant un ordinateur individuel, et je ne m'égare absolument pas

C'est d'ailleurs aussi le mien où je suis très content d'un dual-core pour mon travail, très réactif dans les tâches interactives, et donc non-remplaçable par une CPU peut-être aussi rapide en multi-thread mais 2X plus lente en mono-thread (latences sur les interactions), et donc non remplaçable par autre chose qu'une puce sur jeu d'instruction ARM conçue par Apple aujourd'hui, les autres basées sur le même jeu d'instruction étant encore totalement largués.

PS: je sais que je vais encore avoir les remarques de ceux avec une config à 2351 core, 28.3 To de RAM, 17 GPU, ou utilisant tel ou tel logiciel Pro, mais c'est pas le sujet. Mme Michu s'en fout de vos machines (moi aussi d'ailleurs, car mis à part @otto87 et un ou deux autres, j'ai plus puissant)

Ce message a été modifié par iAPX - 7 Nov 2018, 21:30.

[Sethy]

Avant, j'avais une machine pour tout.

Depuis le duo iMac / Hack, je trouve ça finalement bien mieux d'avoir 2 machines distinctes.

Et c'est pour ça que j'hésite à remplacer l'iMac 2011 avec le gros CPU et le gros GPU de l'époque par le Mini à 899.

[Gallows Pole]

Salut,

Réaction à la MAJ : Intel annonce que ses puces à 48 coeurs seront 1,5 fois plus rapide que les EPYC d'AMD avec 32 coeurs...
Oula, une puce à 48 coeurs, 1,5 plus rapide qu'une puce à 32 coeurs ?
Elle est vachement efficace !

Et ils annoncent que cela peut aller jusqu'à 3,6 fois plus rapide...
J'imagine que là ils prennent leur 48 coeurs en mode "turbo" et qu'ils comparent à 32 coeurs à la vistesse de base ?
Voire, peut-être qu'ils parlent d'une carte mère bi-processeurs comparée à une carte mère EPYC mono processeur ?

Et comment est-ce qu'ils se positionnent par rapport à la EPYC à 64 coeurs ?

Franchement... ce genre d'argument est risible. D'où qu'il vienne !

[radamanthys]

Sur l'image, intel indique 1.3x et 3.4x
https://images.anandtech.com/doci/13535/IntelSlide.png

[WipeOut]

Sur l'image, intel indique 1.3x et 3.4x
https://images.anandtech.com/doci/13535/IntelSlide.png

Je me méfie maintenant avec Intel, ils avaient aussi fait faire des tests pour leurs nouveaux CPU. Les tests étaient mal faits pour donner un gros avantage contre les Ryzen.
Pire encore, le fameux TDP de 95W du i9-9900K qui n'est jamais respecté par les constructeurs de carte de mère et Intel le sait très bien.
Quand on force cette limite de 95W les performances sont pas aussi bon. Certes il reste un peu meilleurs que le Ryzen 2700X, mais question prix, l'avantage est en faveur de AMD.

Différence de performance ici --> Intel Core i9-9900K Re-Review [95-watt TDP Results] Very Ryzen 7 2700X Like!

les fameux TDP bidon de Intel --> Intel TDP Investigation: Violating Turbo Duration (Z390)

[Bunios]

ARM a du bol en effet actuellement, et avec lui Apple et les autres. Intel est bloqué à 14nm ce qui permet en gravant en 10, et 7 nm d'augmenter les performances facilement (il n'y a pas que ça). Maintenant, de toute façon la barrière quantique est proche et ce gain va se réduire d'ici deux ou trois ans. On verra alors si ARM arrive à faire des puces au design très performant pour des machines de bureau. Là l'avantage de l'économie d'énergie est moindre.
Je rappelle quand même qu'ARM s'est vautré sur le marché des serveurs.

Je serai curieux de savoir effectivement si ARM arrivera à faire encore mieux d'ici 1-2 ans. Apple améliore par son savoir faire les designs de base des processeurs ARM mais qu'en sera t'il d'ici 2 ans ? On annonce (enfin Ming CHi Kuo annonce des Mac en ARM en 2020-2021 (gravure en 5 nm)) ces nouvelles machines en ARM en 2020-2021. J'imagine que l'on arrivera aussi à la limite physique du côté des processeurs ARM. Mise à part l'optimisation, le gain sera marginal d'ici peu aussi.

Donc je partage ton analyse Lionel. ARM a le vent en poupe ces dernières années mais d'ici 2-3 ans qu'en sera t'il vraiment ?


A+

[Ze Clubbeur]

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

C'est sans doute que tu n'a pas pratiqué l'assembleur su x86, c'est une véritable plaie Et oui les compilos sont des tanches j'ai fais une formation HPC y a 2 semaine, c'est affolant ce que même le compilos d'intel n'est pas capable de trouver tout seul, en mettant à la main les bonnes directives sur des valeur a garder dans les registres, on peut faire du X10 sur des trucs qui se rapprochent de stupides produits de convolution...
Mais bon c'est pareil sur GPU, j'arrive a du X 50 avec du code tweaké à la main alors que pourtant la compilation repose sur LLVM qui est censé être au top!

Sethy : il est plus question de philosophie de code

Ça me rappelle mes cours de programmation d'il y a jadis... En assembleur, on nous avait fait faire un exercice comparatif... Un truc simple en assembleur et le même programme compilé à partir de C...
Comment dire...

Donc oui, un compilateur est, comme son nom l'indique : con. Il fait bêtement ce qu'on lui demande, sans aucun sens critique et d'optimisation...

[marc_os]

...
Et vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (les perfs par Watt consommé devrait entrer en faveur d'ARM).

Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien.

Hein ?
Pourrais-tu préciser stp quelles sont ces tâches interactives, "ton quotidien", qui nécessitent surtout des traitements mono-thread efficaces et ne profitent pas des autres cœurs ?

Sur Mac, le multi-threading via GCD permet par exemple (en simplifiant) à une application d'effectuer un traitement lourd dans un thread dédié, le thread principal s'occupant essentiellement de l'interface utilisateur. Ainsi, l'interface reste toujours fluide et réactive, quelque soit la ou les tâches lourdes tournant "à côté". Tes « tâches interactives » donc ne fonctionnent pas comme ça ?

Mail, Chrome, Safari, Office, éditeurs de code divers et variés, VM pour le web (même quand il y en a 3 ou 4 simultanées pour des tâches dédiées c'est essentiellement monothread à cause des dépendances) : le quotidien de la plupart des gens
Ce qui caractérise d'ailleurs les tâches interactives est la chaîne de dépendance se terminant justement par l'UI qui ne peut être rafraichie/modifiée qu'une fois les traitements faits, et pour lesquelles avoir des tâches séparées est un non-sense.

Pour le reste j'aime cette vision très fantasmagorique du multithread, mais juste comparer un 4-cœur à 2Ghz au quoditien face à un 2-cœur à 4Ghz (du même niveau d'IPC), vous pleureriez sauf pour des tâches spécialisées

Bon ok, tu n'as visiblement jamais programmé une application sous macOS ou même probablement dans l'absolu ou alors c'était sous Windows 3.1 ou le Système 6 (sinon rappelle moi de ne jamais t'embaucher comme dev), pas la peine de discuter tes à prioris.
Sache par exemple qu'on peut avoir plusieurs threads tournant sur un CPU mono cœur.
Mais bon ok, t'as raison, Mail, Chrome, Safari, Office sont mono thread, c'est ça.

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

[Ze Clubbeur]

...
Et vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (les perfs par Watt consommé devrait entrer en faveur d'ARM).

Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien.

Hein ?
Pourrais-tu préciser stp quelles sont ces tâches interactives, "ton quotidien", qui nécessitent surtout des traitements mono-thread efficaces et ne profitent pas des autres cœurs ?

Sur Mac, le multi-threading via GCD permet par exemple (en simplifiant) à une application d'effectuer un traitement lourd dans un thread dédié, le thread principal s'occupant essentiellement de l'interface utilisateur. Ainsi, l'interface reste toujours fluide et réactive, quelque soit la ou les tâches lourdes tournant "à côté". Tes « tâches interactives » donc ne fonctionnent pas comme ça ?

Mail, Chrome, Safari, Office, éditeurs de code divers et variés, VM pour le web (même quand il y en a 3 ou 4 simultanées pour des tâches dédiées c'est essentiellement monothread à cause des dépendances) : le quotidien de la plupart des gens
Ce qui caractérise d'ailleurs les tâches interactives est la chaîne de dépendance se terminant justement par l'UI qui ne peut être rafraichie/modifiée qu'une fois les traitements faits, et pour lesquelles avoir des tâches séparées est un non-sense.

Pour le reste j'aime cette vision très fantasmagorique du multithread, mais juste comparer un 4-cœur à 2Ghz au quoditien face à un 2-cœur à 4Ghz (du même niveau d'IPC), vous pleureriez sauf pour des tâches spécialisées

Bon ok, tu n'as visiblement jamais programmé une application sous macOS ou même probablement dans l'absolu ou alors c'était sous Windows 3.1 ou le Système 6 (sinon rappelle moi de ne jamais t'embaucher comme dev), pas la peine de discuter tes à prioris.
Sache par exemple qu'on peut avoir plusieurs threads tournant sur un CPU mono cœur.
Mais bon ok, t'as raison, Mail, Chrome, Safari, Office sont mono thread, c'est ça.

+1
Et heureusement !! Imagine Mojave limité au nombre de cœurs du processeur Ce serait comique, sur un MBA de 2018 lol

[iAPX]

...
Et vu les perfs de l'A12X, il semble que ARM soit aussi sur le point de bouffer Intel du coté du marché des serveurs (les perfs par Watt consommé devrait entrer en faveur d'ARM).

Non c'est juste Apple, les autres sont 2X plus lents actuellement en mono-thread essentiel pour la réactivité sur des tâches interactive, notre quotidien.

Hein ?
Pourrais-tu préciser stp quelles sont ces tâches interactives, "ton quotidien", qui nécessitent surtout des traitements mono-thread efficaces et ne profitent pas des autres cœurs ?

Sur Mac, le multi-threading via GCD permet par exemple (en simplifiant) à une application d'effectuer un traitement lourd dans un thread dédié, le thread principal s'occupant essentiellement de l'interface utilisateur. Ainsi, l'interface reste toujours fluide et réactive, quelque soit la ou les tâches lourdes tournant "à côté". Tes « tâches interactives » donc ne fonctionnent pas comme ça ?

Mail, Chrome, Safari, Office, éditeurs de code divers et variés, VM pour le web (même quand il y en a 3 ou 4 simultanées pour des tâches dédiées c'est essentiellement monothread à cause des dépendances) : le quotidien de la plupart des gens
Ce qui caractérise d'ailleurs les tâches interactives est la chaîne de dépendance se terminant justement par l'UI qui ne peut être rafraichie/modifiée qu'une fois les traitements faits, et pour lesquelles avoir des tâches séparées est un non-sense.

Pour le reste j'aime cette vision très fantasmagorique du multithread, mais juste comparer un 4-cœur à 2Ghz au quoditien face à un 2-cœur à 4Ghz (du même niveau d'IPC), vous pleureriez sauf pour des tâches spécialisées

Bon ok, tu n'as visiblement jamais programmé une application sous macOS ou même probablement dans l'absolu ou alors c'était sous Windows 3.1 ou le Système 6 (sinon rappelle moi de ne jamais t'embaucher comme dev), pas la peine de discuter tes à prioris.
Sache par exemple qu'on peut avoir plusieurs threads tournant sur un CPU mono cœur.
Mais bon ok, t'as raison, Mail, Chrome, Safari, Office sont mono thread, c'est ça.

C'est le principe des tâches interactives en soit qui limite énormément la concurrence des exécutions et non le nombre de threads lancés ou de cœurs/fils disponibles.

D'un autre côté, en ingénierie logiciel il y a ce qui s'appelle le budget, et tant que pour un type de logiciel la réactivité est suffisante, personne ne dépense du budget à rendre le programme plus complexe, donc avec plus de bugs et plus coûteux en maintenance pour le plaisir de gagner en performance, même quand c'est possible.
Ce second point explique largement le niveau de "performance" de nombre d'outils bureautiques actuels...

Merci pour tes a-priori et surtout les jolis commentaires associés, c'est extrêmement flatteur pour moi

Ce message a été modifié par iAPX - 12 Nov 2018, 13:30.

[yponomeute]

D'un autre côté, en ingénierie logiciel il y a ce qui s'appelle le budget

Tu oublies le petit copain du budget qui s'appelle deadline Ils se promènent toujours par deux.

Ce message a été modifié par yponomeute - 12 Nov 2018, 13:38.

[iAPX]

D'un autre côté, en ingénierie logiciel il y a ce qui s'appelle le budget

Tu oublies le petit copain du budget qui s'appelle deadline Ils se promènent toujours par deux.

Oui mais elle n'existe que dans le monde parallèle où vivent les chef de projets

[otto87]

@ marc_osLa volée de bois vert que tu vas recevoir J'veux pas médire, mais les connaissances et les problématiques du dev, sont *très très très très très* inférieurs à celle de iAPX. On croirait entendre parler un commercial ou un pur fan boys après la présentation de "grand central" du genre " pf la gestion des cores c'est 3 lignes de code et l'API magique d'Apple fait le reste".Mais non ce n'est pas comme ça que ça marche.Tout ne se parallélise pas ou pas efficacement.Et à moins de passer toutes sa journée de boulot sur du calcul intensif, il y a fort à parier que seuls quelques % de ton CPU soient utiles réellement, on en revient donc à la problématique de la réactivité qui elle dépend de la fréquence de ton core plus que du nombre.

[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

[Hebus]

Ho, je n’avais pas vu iAPX, non, GCD est utilisé dans les applications d’aujourd’hui, très fréquemment, en fait on s’en sert obligatoirement, dès qu’il y a un quelconque call back qui doit tracer dans la thread principale... genre un callback généré par un load du web, qui plus est en Swift sous ubuntu c’est le modele de concurrence utilisé puisque Foundation n’est pas dispo... si tu fais du server avec Vapor tu utilise GCD à tous les coups, mais la dernière version a définit sa propre abstraction de Future ... qui utilise GCD en dessous, comme je m’y attendais

Sous iOS ou macOS c’est utilisé, soit directement par les APIs en C soit indirectement par les classes de Foundation : OperationQueue, et je peux dire que j’avais aidé sur un projet y a un bail, il bossait en freelance, utilisait dès le début massivement ces abstractions pour ses application iOS...

Bref, Marc_OS a raison, vous ne connaissez pas du tout le dev sous OSX / macOS / iOS

Pourtant je ne gagne pas ma croute avec...

[iAPX]

...
Bref, Marc_OS a raison, vous ne connaissez pas du tout le dev sous OSX / macOS / iOS

Pourtant je ne gagne pas ma croute avec...

Je ne connais pas tout le dev sous macOS ou iOS, mais ce n'est pas ce que @marc_os a écrit

J'avais écrit un gros historique, je l'enlève et je vais au plus court: ce qui importe c'est de comprendre le matériel pour ne pas être freiné par des fuites d'abstraction extrêmement coûteuses car n'importe qui peut massivement paralléliser une tâche "embarrassingly parallel", mais quand on a besoin de communication entre threads et/ou process (oui en NUMA la distinction a vraiment du sens, plus encore en réparti), avec des temps de traitements pouvant être très différents, c'est une autre paire de manche...

Le problème n'est pas de faire appel à GrandCentral ou n'importe quel autre outil pour paralléliser une tâche simple (du lambda pour simplifier), déterministe et peu communicante, mais quand toutes ces conditions ne sont pas remplies

Le maître-mot est la communication, et ça inclus les différents niveaux de cache, le bus interne (relié à la mémoire avec le bus L3 en intermédiaire), et les façons de ne pas créer de problèmes dans toute cette organisation. En bref, d'isoler en comprenant les dépendances.

Ce message a été modifié par iAPX - 13 Nov 2018, 04:34.