existe-t-il un compilateur C/C++ produisant du code optimisé 3dnow ?

non, et à ma connaissance aucun compilateur ne génère du code SIMD (3dnow!, SSE, MMX), ou alors uniquement les instructions scalaires.

j'ai cru lire que ça existait pour SSE mais je suis sur de rien.

wave > As-tu fini d'optimiser ton moteur 3D en 3dnow! ??

VectorC que je sais plus trop qui. J'avais la version beta (gratuite), maintenant ca doit etre payant.
 
Sinon Visual Studio version pro supporte le 3DNow!, mais en macro seulement...

zop non j'ai pas commencé. Après une journée de programmation PS2 la vue d'un PC me donne des boutons.

 
Au fait comme t'es directement impliqué dans la programmation de la PS2 j'aimerais avoir ton avis (d'expert) sur la complexité de la programmation de la PS2. J'ai lu un peu partout qu'elle a sûrement un énorme potentiel mais qu'il est très difficile à exploiter ??? Ton avis de programmeur ???

exactement: elle est puissante, peut afficher beaucoup de polygones mais c'est une vraie merde à programmer, les librairies sont mal foutues ou bugguées et quelquefois documentées en japonais uniquement. Rien que de créer un CD bootable à partir d'une démo qui tourne sur le kit de développement ça demande du boulot!

une autre question à wave : les Japonais lorsqu'ils conçoivent leur console, est-ce qu'ils vous contactent pour avoir votre avis sur des choix conceptuels ou pas du tout ? Ou alors c'est une fois qu'ils sont en phase terminale de la conception de leur future machine qu'ils viennent vous voir avec une doc ou un kit de développemnt ?

ils doivent bien consulter quelques développeurs (quoique j'en sais rien) mais s'ils me montrent les caractéristiques sur papier je dirai que la PS2 est excellente, alors qu'en pratique je suis pressé de ne plus y toucher.

En effet il y a VectorC qui génère du code SIMD.(http://www.codeplay.com/)
 
Pour obtenir les performances optimales y'a qques guidelines à respecter... quitte à faire un effort, autant programmer directement en macros (enfin c'est mon avis).

bien-sur mais si ça permet déjà de gagner en vitesse sur des gros fichiers sources qu'on n'a pas envie de retoucher ça m'intéresse. Surtout sur mon K6-3.

bon...
 
j'ai lu rapidos sur le site d'AMD que :
 
1) Toutes les nouvelles versions de compilateurs de tout langage sont compatible SSE/3DNow/MMX sans problème (le code généré supporte les 3 types d'instruction), car Intel et AMD leur ont fournit tout ce qui était nécessaire pour implémenter.
 
2) Les instructions 3DNow! et 3DNow! Etendues sont suffisament bien gérées pour le le proco les utilise même si ce n'est pas stipulé dans le code assembleur...
En effet, son architecture RISC de Digital lui permet d'analyser les instructions x86, les réinterprêter et les optimiser avant de les exécuter. C'est un système propriétaire de Digital, existant depuis plus de 5 ans dans le monde Unix.
 
Car chacun sait ici j'espère que l'Athlon est un proco RISC avec un interpréteur x86... (le PIII suis la même voie, mais plus en recul)

hum...
L'athlon est un proc CISC car il utilise un jeu d'instruction CISC. Qu'il utilise des méthodes empruntées au RISC, c'est son problème, il execute quand-meme un code CISC.
Ensuite, 3dnow c'est un ensemble d'instructions asm et comme toute instruction asm, le proc ne l'exécute que si on le lui demande explicitement. La plupartssdes compilos n'utilisent PAS ces instructions et en sont incapables. Dans ce cas (ex: visual c++) on peut utiliser des macros en assembleur mais ça ne permet pas d'écrire du code C/C++ générique qui utilisera 3dnow. Ce que tu dis est vrai pour les micros-instructions internes au processeur (rien à voir avec 3dnow), absolument pas pour les instructions que le programmeur donne au cpu.
 
En gros, c'est faux d'un bout à l'autre.

wave > Non non non non !
 
Athlon (Et PIII) utilise en effet des instructions CISC.
 
Mais le core du proc n'est pas CISC mais RISC.
 
Il y a un intermréteur d'instruction CISC -> RISC au niveau du chipset et du processeur.
 
Ensuite, là où l'Athlon est meilleur par rapport au PIII, c'est qu'il "comprends" les instructions qu'on lui passe et refait sa sauce afin d'utiliser toutes ses capacités...
 
A mon argumentation s'ajoute ce fichier (3 Mo) qui vient du site d'AMD :
 
http://www.amd.com/products/cpg/at [...] /22007.pdf
 

Traduction : L'athlon est capable d'éxécuter en parallèle plusieurs instruction x86, grâce à son architecture.
 

Optimiser le code x86 pour l'athlon permet de meilleurs perfs (sans avoir à utiliser les instruction MMX ou 3DNow!)
 

Grace à son pipeline plus flexible la plupart des optimisations spécifiques aux pentium n'est plus nécessaire.
 
Maintenant, en C : (optimiser le code C permet de générer un code assembleur apte à être optimisé par l'ahtlon)
 

 
... etc.

Bon, désolé, le code passe pas bien à l'écran... Tu verras mieu dans le PDF.

le processeur lit des instructions cisc avec tous les inconvénients que ça comporte:longueur d'un opcode variable et instruction + complexe à décoder (entre autres). Qu'il réorganise l'ordre des micro-instructions c'est très bien mais c'est pas ça qui va faire aller la fpu 32/64 bits à la vitesse d'une instruction 3dnow (32 bits avec précision inférieure pour les inverses et racines carrées), pour la bonne raison que le boulot exécuté n'est PAS LE MEME.
optimiser pour athlon permet d'avoir de meilleures perfs: bien-sur mais optimiser ET utiliser les instructions 3dnow permet d'aller encore + vite!
L'athlon est capable d'éxécuter en parallèle plusieurs instruction x86, grâce à son architecture: oui, heureusement car le pentium aussi.
L'athlon est excellent mais c'est pas la peine de dire que 3dnow ne sert à rien, ni qu'il s'utilise tout seul, ni que tous les compilos l'utilisent (loin de là). C'est tout ce que je voulais dire.

ya un petit util pour utiliser les instructions 3dnow dans delphi que j'avais utilisé au début de mes études...
c'est ici:
http://www.yks.ne.jp/~hori/program-e.html
( ça permet aussi d'utiliser les instructions:ss
MMXss
Streaming SIMD Extensionsss
CPUID (486)ss
RDTSC (Pentium)ss
CMOVxx (Pentium Pro)ss
3DNow!! )
 
c'est l'auteur de delphix ( les composants DirectX pour delphi )
wave a raison, d'ailleurs ya des articles sympas à ce sujet et sur les architectures des proc sur http://www.arstechnica.com
 
Yop yop

up!

Voilà qques jours que je cherche qques infos sur le sujet, et en effet il semblerait que le compilo Intel génère du code SIMD, ou du moins qu'il y ait une étape de vectorisation :
 
"Vectorization detects patterns of sequential data accesses by the same instruction, and transforms the code for Single-Instruction Multiple-Data (SIMD) execution."
 
Le lien d'origine
http://developer.intel.com/softwar [...] zation.htm

il parait effectivement que le compilo d'intel le fait mais pour SSE, pas 3dnow évidemment.

Ca semble être une nouveauté de la version 5.
J'avais utilisé la version 4 de ce compilo, et c'était la catastrophe niveau optimisation, enfin en tout cas largement en dessous de Visual 6.
Si j'ai l'occasion de tester la version 5 je vous tiendrai au courant.
 
Sinon rien de tel dans le SDK d'AMD. Juste des librairies optimisées fournies...

pour compléter ce débat CISC/[RISC+interprétationCISC], précisont l'arrivée d'un nouveau venu, qui a faillit se terminer en vaporware, mais bon... Je pense qu'il est important de préciser son existance, car peut de personnes en parlent.
Mon regard seras critique, avant tout sur la technologie dite "papier", puis sur le bébé en lui même, et je parlerais de son avenir juste après. Donc, ce fameu proco, le Crusoe de Transmetta est né...ssTransmetta est une boite, créée par le N° de chez M$, et qui embauche Linus Torvalds (vous savez, le mome qui a fait Linux...)... Déjas, ca commence mal Mais bon...
Sur le cahier des charges, le Crusoé est décrit comme étant destinné aux portables, et à tout ce qui peut se raprocher de l'embarqué. Cela impliquait une faible consomation d'énergie, et un faible dégagement de chaleur (comme dirait Joule, l'un entraine l'autre ). Le but étant aussi de garder un proco compatible x86 (rha caca ), pour pouvoir s'implanter aisément dans le marché.
Transmetta c'est acharné à répondre à ses critères durant la création du Crusoe, mais en conservant quand même des performances honnorables. Cela, ils l'ont réalisés en utilisant une technique plutot étrange, mais qui, a prioris porte ses fruits : le but est d'obtenir un processeur CISC (processeur à jeu d'instruction complexe, c'est à dire qui comprends beaucoup d'instructions, qui exécute des instructions complexes en peut de cycles, mais qui consomme comme une voiture haut de gamme, et qui chauffe comme un grille pain!) qui est le x86, mais en ayant les avantages d'un processeur RISC (processeur à jeu d'instruction réduit, c'est à dire qui comprends un petit nombre d'instructions, qui les exécutes super rapidement, mais vraiement super rapidement, et qui consome peut, et qui dégage très peut de chaleur). Intel et AMD ont choisis de construire un processeur autour d'un core RISC (comme le dit Magic Buzz), puis qui ajoutent une partie qui rends ce RISC compatible avec le set d'instruction CISC propres à nos x86, en transformant ces instructions complexes en instructions RISC, en adaptant le code en même temps (optimisation, exécution parallèle, prédiction de branche, ...), mais tout cela de facon matérielle (en grande partie tout du moins). Ces choix (l'implémentation d'AMD étant tout de même techniquement supérieure à celle d'Intel, notement grace à certaines technologies tirées des Alphas, procos supers puissants, et novateurs...) ont entrainés des processeurs encores plus volumineux (mais c'est compensé heureusement en partie grace aux nouvelles techniques de gravage, et heureusement, car quand on voit la taille d'un P3, et qu'on se dit que ca aurait pus etre pire...), encore plus gourmands en énergie, et donc (encore une fois merci à Mr Joules) encore plus calorifiques (ce qui entraine des systèmes de refroidissement plus conséquents, donc plus d'énergie, donc plus de dégagement... bref, le phénomème met du temps à s'auto amortir...). Donc les nouveaux procos sont super vachement plus puissants, mais ils sont énormes, consoment un max, et chauffent beaucoup (qui à dit énormément? ). L'iddée de Transmetta est justement de ne pas faire les mêmes erreurs... en implémentant la compatibilité x86 de facon logicielle... C'est le "Code-Morphing", technologie déposée par Transmetta, et qui permet de garder tous les avantages du RISC (perfs, taille, conso, faible dégagement de chaleur, ...), les instructions CISC, les avantages des nouveaux procos de chez AMD et Intel (Performances, optimisation, ...) sans les inconvéniants qu'amennent l'implémentation hardware (taille, conso, chaleur, ...). De plus, cela comporte d'autres avantages, comme celui de rendre ce processeur compatible avec d'autres familles de processeurs (architectures), par simple modification logicielle. Et imaginez un processeur sur lequel on pourait coriger les bugs qui existeraient dans la partie logicielle (LE RISC est facile à dessiner, donc super vachement moins de chance d'y foutre des erreurs que dans un CISC...)!
Pour les impératifs en terme de conso et de chaleur, ce comparatif à été effectué : un Crusoé TM5400 700 MHz, contre un Athlon 700 MHz tous deux gravés à 0.18 microns. Les chiffres parlent d'eux même : athlon = 100°C et 34W, Crusoé = 40 °C et 1W... alors, c'est t'y pas beau? Et, en plus, comme cado Bonux, le Crusoé adapte sa fréquence en foction de la charge qu'on lui soumet... en gros, le TM5400 (700MHz) n'est à 700MHz que quand il a une forte charge...
 
Mais point de vue performances, que dire? Et bien, je connait deux heureux possesseurs de Sony Vaio Ultraportables équipés du TM5400 en question... mais pour l'instant, leur bébé est sous win Meuh, et ils ne font essenciellement que du Word/mail/net/... donc pas très évocateur en termes de perfs (wow, Word 2000 se charge en moins d'une minute, c'est moyen!). Je vais donc voir avec eux si je peut effectuer des benchs, voire même me rendre compte par moi même, parcequ'il y en a un qui m'as l'air motivé par l'iddée d'installer un nunux 2.4.x (le zoli noyeau qui gère le code morphing, au lieu de se contenter de la x86 compat...), je pourait donc vous dire...
Sinon, il faut voir aussi que le crusoé vise principalement les machines nomades et l'embarqué. Malgrès les avantages qu'il avance, Transmetta parviendra-t'il quand même à s'inssérer dans le marché? Tout dépendras de leur politique commercial, et des réactions du public face à ce proco. Sony fournit déjas des Crusoés, mais d'autres constructeurs/assembleurs le suivront'ils?
... affaire à suivre!
 

--Message édité par PinG--

Juste une précision : le Crusoë repose sur une architecture interne VLIW (Very Long Instruction Word). La partie code-morphing du proc transforme les instructionx x86 en instructions VLIW ...

vala... en fait, c'est ce qui lui permet d'exécuter plusieurs instructions en parallèle, entre autres. C'est très souvent utilisé quand on transforme un CISC en RISC (encore une fois, pour beaucoup d'avantages), mais le Crusoé gère ca très bien, disont le, et comme le core RISC du crusoé est superscalaire (comme beaucoup), bien concu et performant, le crusoé devrait surpasser ses concurents.
pour plus d'infos sur le VLIW : http://www.research.ibm.com/vliw/basic.html
 

--Message édité par PinG--

up!

Avec visual C++ 6.0 c'est possible mais en assembleur.
 
Sur le Site AMD tu recupéré le SDK Athlon et chez microsoft le SP4 pour Visual C++ 6.0 ainsi que le processor pack pour compiler en assembleur specifique AMD avec Visual.
 
J'ai fait un algo de produit de convolution en 3Dnow, c'est cool tu peux faire 2 multiplications en virgule flottante simple précision en meme temps combiné avec 2 additons en flottant simple précision, du fait que l'unité d'addition et de multiplication sont distincte.

wave tu fais bien de nous réveiller de temps en temps avec un p'tit up
j'ai recompilé qques programmes avec la version 5 du compilo Intel (limitée à 30 jours), en particulier en activant les flags qui vont bien, à savoir génération de code SSE (-QxK)
Et en effet il utilise des instructions SSE, mais dans le code que j'ai recompilé il n'a généré que des instructions scalaires...
Au niveau des performances, j'ai gagné 2 ou 3% sur une décompression mpeg (qui, à priori, se prête bien à ce genre d'optimisation vectorielle).
Rien de bien transcendant, disons que ça a le mérite de ne demander aucun effort d'optimisation manuelle. Par contre après il faut se prendre un peu le chou parce qu'évidemment ce code ne se fonctionne qu'en présence de SSE ...
 
Je n'ai pas mené des tests approfondis, et je suis certainement passé à côté de qques subtilités. Si d'autres ont essayé ce compilo je veux bien leur avis.

Allez un p'tit UP !
Chacun son tour, wave doit en avoir marre d'upperss