Nehalem et innovations

[Childerik]

Dans le contexte de mon post precedent, code pourri = code avec des instructions qui prennent beaucoup de bytes (comme par exemple SSE4.1 et SSE4.2)

Tu veux dire qu'Intel donne le bâton pour se faire battre alors ?

Il lance de nouvelles instructions SIMD qui génèrent beaucoup d'espace, pour finalement s'obliger plus tard à optimiser le front-end avec beaucoup d'efforts parce qu'il se rend compte de la complexité du nouveau set d'instructions, si j'ai bien compris ?

[fefe]

Tu veux dire qu'Intel donne le bâton pour se faire battre alors ?

Il lance de nouvelles instructions SIMD qui génèrent beaucoup d'espace, pour finalement s'obliger plus tard à optimiser le front-end avec beaucoup d'efforts parce qu'il se rend compte de la complexité du nouveau set d'instructions, si j'ai bien compris ?

Oui et non. Meme sans optimisations du frontend ces instructions offrent des benefices important a qui peut les utiliser. Il n'y a pas la place pour les encoder autrement dans le x86, donc elles s'alongent. La generation d'apres, les architectes se rendent compte qu'ils peuvent optimiser le frontend pour accelerer encore plus du code avec ces instructions (de meme que des instructions complexes datant d'il y a 30 ans).

Il n'y a rien de nouveau sous le soleil, combien d'ameliorations d'architectures ont ete ajoutees par AMD et Intel pour accelerer MMX, 3DNow, SSE, SSE2, SSEx... Les loads non alignes que Sam aime tant et si rapides sur Nehalem sont des instructions SSE non, peut on vraiment y appliquer ton raisonnement ?

[newbie06]

Qu'est-ce qui empêche un codeur de soigner son code ? Une contrainte énorme de temps ?

Je note quand même qu'un des arguments de Franck, l'absence de tout ou partie du code, est une réalité industrielle que pas mal défendent : pas de source ; et je comprends fort bien que la société X ou l'individu n'ont pas envie de même recompiler leur code parce qu'Intel a sorti un nouveau jeu d'instructions et comme personne ne peut le faire à leur place, on se retrouve avec un SuperPI x87

A plus haut niveau, l'accélération du code est très coûteuse en temps, du coup ce n'est industriellement pas rentable, voire pas à la portée de certains (oui, les programmeurs ne naissent pas tous égaux et de plus n'ont pas tous la même culture ). Alors on te raconte que tu n'as qu'à upgrader ta machine. Ce discours est bien entendu applicable au code GPU.

Donc quand on développe un nouveau CPU, et ce quel que soit le marché, on essaie d'avoir des benchs standards avec lesquels on tune les compilos (EEMBC, SPEC, etc), des benchs sans source, et surtout des applications existantes et du code "client". Hé bien on voit de sacrées horreur là-dedans et à tous les niveaux (imbécillité du compilo, code aberrant, code d'il y a 15 ans, Java). Et tout ce beau monde ne doit pas perdre en vitesse, sinon ton CPU est mort-né.

Bon je retourne à mon générateur de code x86 qui me rappelle à quel point l'encodage des instructions est une sombre m...e, et je parle même pas d'orthogonalité

[Neo_13]

Hé bien on voit de sacrées horreur là-dedans et à tous les niveaux ([...] Java[...])

[newbie06]

J'assume le mépris que j'ai pour Java et le code performant, et surtout pour ce qu'il fait perdre en compréhension lorsqu'il est utilisé comme unique langage d'apprentissage.

[ylyad]

J'assume le mépris que j'ai pour Java et le code performant, et surtout pour ce qu'il fait perdre en compréhension lorsqu'il est utilisé comme unique langage d'apprentissage.

Ca, je suis entièrement d'accord. Je vois des petits jeunes sortir de l'école d'info (jusqu'à Bac+5) et sorti de Java, ils connaissent que dalle. Du coup,

Spoiler Alert!

ils font du code tout pourri

ils font même pas de code mais du gloubiboulga, et il faut leur apprendre à programmer.

Je note quand même qu'un des arguments de Franck, l'absence de tout ou partie du code, est une réalité industrielle que pas mal défendent : pas de source ; et je comprends fort bien que la société X ou l'individu n'ont pas envie de même recompiler leur code parce qu'Intel a sorti un nouveau jeu d'instructions et comme personne ne peut le faire à leur place, on se retrouve avec un SuperPI x87

Sans rentrer dans le débat open/closed source, je vois suffisamment de cas où le source (sinon ouvert, du moins disponible pour l'équipe) est tout simplement perdu, suite à trois changements de gestionnaire de source, les specs sont aux oubliettes, etc.

[newbie06]

les specs sont aux oubliettes, etc.

Les quoi ?

PS - C'etait mon trollage du matin, je vais essayer de n'en faire qu'un aujourd'hui, mais je ne promets rien...

[Foudge]

Les quoi ?

PS - C'etait mon trollage du matin, je vais essayer de n'en faire qu'un aujourd'hui, mais je ne promets rien...

Nous on a un cahier de post-it pour les specs, et je crois savoir où il est. Je bosse dans une entreprise sérieuse moi !

[Yasko]

Ca, je suis entièrement d'accord. Je vois des petits jeunes sortir de l'école d'info (jusqu'à Bac+5) et sorti de Java, ils connaissent que dalle. Du coup,

Spoiler Alert!

ils font du code tout pourri

ils font même pas de code mais du gloubiboulga, et il faut leur apprendre à programmer.

Bon, ca part en HS, mais j'ai récupéré l'oriflamme de JYS et m'en vais bouter les vils manants que vous êtes hors de vos convictions rétrogrades.
La programmation est un domaine très vaste, on a déjà parlé à l'époque du topic à JYS sur les perfs en Java (qui serait également applicable à tous les langages sur la plateforme .Net de MS). OK, un développeur qui n'a fait que du Java aura de mal a se mettre à un langage de plus bas niveau, mais est-ce que c'est ce qu'on lui demande ?
Si sa formation n'était pas orientée la-dessus, peut-on lui reprocher d'être nul en assembleur, pour coder un driver en C ou un calculateur d'injection si on lui a appris Java/J2EE et ses frameworks divers et variés, l'architecture logicielle, UML, les design patterns, etc ? Est-ce qu'on reprocherait à un plombier de ne pas savoir tirer un cable électrique, plombier et électricien travaillent bien tous les 2 dans le bâtiment ?
Il y a des formations où tous ces pans du dev sont étudiés, et d'autres qui se concentrent sur un type de métier en particulier (temps réel par exemple). Iriez-vous dire qu'un ingé qui ne fait que du temps réel est nul parce qu'il ne sait pas coder en Java ? Alors, on peut débattre du fait de plus on s'éloigne du hard et plus on est un vil développeur, mais bon, l'utilisation de langage de haut niveau est une réalité du marché, alors...
Après, pour ton exemple Ylyad, je ne sais pas, tu es peut-être tombé sur des mauvais développeurs ?

Voila, je vais pouvoir prendre mon café.

[newbie06]

Yasko, je suis d'accord avec toi. Mais je m'en tiendrai a ma position : un mec qui n'aura vu que du Java a peu de chance de savoir ce que sont les problemes de performance bas niveau (genre cache, TLB, scheduling) ; un copain me racontait que la ou il bosse, les mecs ne comprennent meme pas ce que ca implique de passer des tableaux en parametre, et savent encore moins gerer proprement la memoire (ben ouai quoi, "Java fait du garbage collecting, y'a rien a faire hein ? Si ? Ha, je savais pas m'sieur. Au fait, c'est quoi un memory leak ?").

Je schematise, mais c'est en gros ca. Et c'est dans le sujet puisque tout ce code pourri doit fonctionner correctement sur les nouvelles generations de processeur (au travers des JVM, ce qui rend les choses encore plus compliquees a evaluer), ce qui etait la question original de Childerik

Et puis meme s'il y a de bons programmeurs Java (c'est evident) et qu'on peut ecrire du bon code assez efficace en Java, il restera quand meme a s'assurer que les performances des JVM sont bonnes sur la nouvelle generation.

[Yasko]

Je suis d'accord avec toi (on est tous les 2 d'accord alors ), mais ton discours témoigne de ton orientation bas-niveau. J'ai une collègue qui travaille exclusivement sur le test de perf, principalement en Java, et je ne pense pas qu'elle n'ait jamais eu à s'occuper des TLB, etc, et pourtant elle est plutôt technique.
Déjà, les environnements où du Java est présent sont bien souvent distribués (par exemple, un navigateur web, un Tomcat/JBoss/Weblogic/..., et une DB ). Rien qu'à ce niveau, on peut déjà pas mal de problématiques de perfs. Après si on se focalise uniquement sur la partie Java, il y a tellement de couches, de composants, de frameworks différents que faire de l'analyse de perfs revient à essayer d'optimiser toute cette mécanique interne.
Et si on se place vraiment au niveau du code Java, quand on parle d'un code propre, c'est un code performant mais surtout un code maintenable et efficient.
Passer un tableau en paramètre, pourquoi pas (enfin, ca serait plutôt un objet contenant le tableau ou la collection que tu souhaites), la JVM va le transformer en pointeur.
Optimiser une JVM pour une certaine cible hardware, ce n'est clairement plus le boulot d'un développeur "haut-niveau".
Et sinon, c'est quoi un memory leak ?

[fefe]

en Java, et je ne pense pas qu'elle n'ait jamais eu à s'occuper des TLB, etc, et pourtant elle est plutôt technique.
Déjà, les environnements où du Java est présent sont bien souvent distribués (par exemple, un navigateur web, un Tomcat/JBoss/Weblogic/..., et une DB ). Rien qu'à ce niveau, on peut déjà pas mal de problématiques de perfs.

Et bien les TLB c'est le niveau juste apres (entre les 2 il y a peut etre la pagination OS, donc gerer son swap): quand on commence a se preoccuper de comment on a alloue sa memoire. Contrairement a l'impression donnee ici optimiser pour les TLB est une optimisation de haut niveau par opposition aux optimisations pour le cache L1, pour les decodeurs, du scheduling des instructions.
En gros ce n'est pas parce qu'il s'agit d'un TLA horrible et d'un truc que la majorite des programmeurs ne savent pas ce que c'est, ce n'est pas vraiment si "bas niveau" que ca .

[newbie06]

Optimiser sur les TLB se fait en meme temps que l'optim cache en general, non ? Bien sur avec les caches tu peux rajouter quelques details qui ont leur importance (prise en compte des algos hard de prefetching, preload explicites, etc.), mais ca s'applique aussi dans une certaine mesure aux TLB (preload de cache line pour forcer une mise en TLB ), n'est-ce pas ?

PS - Cekoidonc un TLA ?

[fefe]

TLA= three letter acronym

Optimiser pour les TLB c'est aussi choisir la taille de la page, choisir les "large pages" ne fait pas partie des optimisations pour les caches, mais demande une comprehension de haut niveau des patterns d'acces du programme en question.

Bien entendu "blocker" pour les TLB quand on utilise des petites pages peut etre classe dans les optimisations liees aux caches. Pareil pour le prefetching de page en soft (qui permet de balancer le fait que les prefetchers hard ne traversent pas les frontieres entre les pages).

[newbie06]

TLA= three letter acronym

Chuis decu je m'attendais soit a un truc hyper technique, soit a un truc drole

Optimiser pour les TLB c'est aussi choisir la taille de la page, choisir les "large pages" ne fait pas partie des optimisations pour les caches, mais demande une comprehension de haut niveau des patterns d'acces du programme en question.

Les "large pages", c'est a part, souvent bourrin et OS-dependent Tiens, hors-sujet : Windows les supporte ?

Bien entendu "blocker" pour les TLB quand on utilise des petites pages peut etre classe dans les optimisations liees aux caches. Pareil pour le prefetching de page en soft (qui permet de balancer le fait que les prefetchers hard ne traversent pas les frontieres entre les pages).

On va arreter la, on sort vraiment du sujet, mais pourquoi les journees n'ont-elles que 24h

[fefe]

Les "large pages", c'est a part, souvent bourrin et OS-dependent Tiens, hors-sujet : Windows les supporte ?

Flemmard
http://www.google.com/search?q=windo...or+large+pages ==> http://msdn.microsoft.com/en-us/libr...20(VS.85).aspx

[newbie06]

Flemmard
http://www.google.com/search?q=windo...or+large+pages ==> http://msdn.microsoft.com/en-us/library/aa366720(VS.85).aspx

C'est un probleme de religion, je ne peux pas aller sur ce genre de site. Nan mais franchement MS ils assurent plutot avec leurs doc en ligne. Ils parlent meme d'Itanium sur cette page, un gage de qualitay.

[fefe]

Attention, Itanium est un produit de qualite ! Ca fait d'excellentes calles pour les tables de bar bancales, durables et tout (on derive, je le sens).

[newbie06]

Attention, Itanium est un produit de qualite ! Ca fait d'excellentes calles pour les tables de bar bancales, durables et tout (on derive, je le sens).

Itanium et partir a la derive, ca c'est certain.

[Yasko]

Olla keske y s'organise ici ? 2 topics pris par du flood trollesque massif et l'on y retrouve les mêmes troubles-fête ?
Voulez tâter mes nouveaux super pouvoirs ?

Ah... Euh non, rien en fait.

[fefe]

Massif c'est pas ici mais la

[Yasko]

Ah oui, mais c'est légalisé la-bas.
:red light district:

[Yasko]

En tout cas, j'ai bien aimé ces petits diagrammes.


NUMA devient tellement plus simple avec un peu de porn et de DTC.
Si ça c'est pas de la vulgarisation pour canard... Ca viendrait pas de Casque ces commentaires d'ailleurs ?

[Yasko]

le courant est lui aussi régulé par le biais de MOSFET de puissance directement intégré au die ! Le PCU peut ainsi contrôler exactement la tension qui alimente chaque cœur de manière nettement plus rapide et beaucoup plus fine que les régulateurs de la carte-mère. Cette fois, ce sont les fabricants de carte-mères qui en seront pour leurs frais car leurs technologiques d’économie d’énergie à ce niveau perdent quasiment tout de leur intérêt.

De la régulation de tension directement dans le die... Déja que le NB se limitait à sa plus simple expression (et le PCI-E va lui aussi finir dans le CPU), ca va vraiment devenir un SoC...
Par contre, ca ne fait pas trop monter artificiellement le TDP cette VRM directement intégrée au CPU ? On doit perdre à ce niveau tout en gagnant au niveau des cores. Si Intel a fait ce choix, je suppose que c'était bénéfique. Ils ont du mettre leur VRM dans un petit coin au froid...

[fefe]

De la régulation de tension directement dans le die... Déja que le NB se limitait à sa plus simple expression (et le PCI-E va lui aussi finir dans le CPU), ca va vraiment devenir un SoC...
Par contre, ca ne fait pas trop monter artificiellement le TDP cette VRM directement intégrée au CPU ? On doit perdre à ce niveau tout en gagnant au niveau des cores. Si Intel a fait ce choix, je suppose que c'était bénéfique. Ils ont du mettre leur VRM dans un petit coin au froid...

Quand tu commences a avoir des problemes de qualite des VRM, autant mettre le tien non ? Les problemes se posent quand tu veux des transitions rapides et des courants a bas voltage (donc haut I) bien stables et precis. Bien entendu a force d integrer des trucs dans le cpu la densite thermique augmente, tout ce qui etait dissipe par plusieurs radiateurs passe par le meme et ca c'est...

[Yasko]

Question sur l'overclocking suite au petit laïus PCU rulez, est-ce que le fait d'overclocker permet d'augmenter les perfs ?

[newbie06]

Question sur l'overclocking suite au petit laïus PCU rulez, est-ce que le fait d'overclocker permet d'augmenter les perfs ?

Lopocompris Sinon y'a des malades qui ont deja monte un i7 a 4.8 GHz (lien).

[Yasko]

Ben, je me pose la question vu que c'est le PCU qui décide au final, qu'en non OC on est déjà proche de la limite fatidique des 130W, et que si le Doc a tenté l'OC, il n'a pas publié de tests de perf avec un i7 OC.
Izon test les autres ? (Stéphane, Marc, ...)

Edit :
Oui, ça marche, Stéphane a publié une page dessus. Par contre, ca doit dépendre du bench utilisé. Si en stock freq il fait déjà bien chauffer la machinerie, on doit pas pouvoir monter bien plus haut en perfs.

[fefe]

Si ton bench approche du TDP a la frequence stock tu pourras l'verclocker tout ce que tu veux sans gains visibles. Par contre vu que ce ne sera jamais le cas en pratique ca laisse un peu de marge.

En pratique suivant la qualite de la bin d'ou vient ton proc il sera plus ou moins pres de 130W en faisant tourner des programmes intensifs, donc au fur et a mesure que le process est rode et que la qualite augmente les proc bas de gamme se rapprocheront de plus en plus des haut de gamme en terme de frequence max qui donne des benefices.

En pratique ce n'est pas une mauvaise idee d'overclocker meme si les gains sur certains benchmarks sont 0%, en effet tous les programmes a la con qui sont moins intensifs et qui en temps normal seraient a 90W se retrouveront a 130W avec l'overclock + le controle de la PCU. Pour ceux qui etaient a 130W ca ne changera rien.

Au final la PCU est la feature de reve des overclockers, si ils pouvaient changer le TDP/courant pour lequel elle optimise. En effet, tu mets un bon gros ventilo+dissipateur qui peut encaisser 160W, tu dis a la PCU maintenant tu n'optimises plus pour 130 mais 160 et hop roule ma poule.

Le probleme est que c'est un peu plus complique que de juste limiter a n Watts, et que beaucoup de parametres des algos d'adaptation de frequence/voltage doivent etre hardcodes plutot que calcules au vol, ce qui empeche ce que je viens de decrire. Mais le concept de la PCU n'est pas l'ennemi de l'overclocker a mon avis bien au contraire, en effet ca permet d'avoir un overclock dynamique qui ne depasse jamais la capacite de dissipation, mais l'atteint meme sur des programmes assez peu intensifs (donc plus besoin de faire 3h de prime pour tester la stabilite).

[Yasko]

Je m'étais posé la question d'ailleurs des implications de travailler avec le TDP, plutôt que par rapport à la température qui était/est utilisée par le throttling (je crois).
En effet, en OC, on améliore le système de refroidissement, on peut donc pousser la fréquence et le VCore et ca reste profitable tant qu'on maintient une température inférieure au seuil de throttling.
En travaillant avec le TDP, le système de refroidissement ne change rien à la capacité d'OC. Même à 30°C parce que bien refroidi, on pourra toujours pousser un i7, il ne montera pas plus haut en perfs...
Les fabricants de ventirad au kilo risquent de faire la tronche ?