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.

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.

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 ?


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.

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.

??? 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.

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é

"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.

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.

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 !

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)

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+

Ç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...

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.

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

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.

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.

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

@ 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.

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.

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.

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

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...

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.