[News] OpenGL

[fennec]

.Net bouffe pas de mémoire, au contraire, il implémente le Garbage Collector qui évite les fuites mémoires non gérées !

Le garbage collector y'en a dans Windows est donc les logiciels dévellopés à la old-school (C,C++) en profite également...

N'importe quoi ! quand tu fais malloc(22); en C ta mémoire se sera jamais libérée tant que ton programme tourne.

.Net implémente un garbage collector car comme java c'est un langage compilé en "micro-code" (enfin pas de l'assembleur) donc le garbage collector de windows ne peut pas s'appliquer...

Windows n'a pas de garbage collector ....

".Net ne boouffe pas de mémoire !!!" : Install les pilotes "Ati .net" reboote fait Ctrl+Alt+Suppr et compte combien de mémoire te prennent les processus CLI.exe :whistle: .Net bouffe forcément plein de mémoire, parceque tu dévellopes un simple "Hello World" ou une suite de bureautique complète, tu charges tout le framework .Net à chaque lancement de ton applis :whistle:

Une instance de VM .NET prends 10Mo ce qui est peut quand on voit tout ce qu'on peut faire avec. Par exemple une instance de VS.NET c'est 11Mo et c'est autrement plus compliqué que ton "helle world"

Oui mais en ce moment je dévellope en Java sous Linux :whistle: donc il risque d'avoir comme un soucis :wink:

il y a mono et #developp

ouais java aussi... néanmoins il prend plein de mémoire.

Quand tu lances une JVM tu lui alloue un espace mémoire initiale 64MO (je crois), en java le garbage-collector n'est appelé que lorsque cet espace mémoire est plein pour réallouer la mémoire dont tu ne te sers plus

Avec la JVM c'est configurable, tu peux démarrer avec 16Mo si tu veux. Tu donne une taille mini (-XMS) et un max (-XMX) et le comportement du GC est configurable aussi (-NEWGC et CONCSwep en SMP). La JVM va libérer la mémoire a la première occasion et pas quand c'est plein, c'est généralement au moment ou tu as besoin de plein de mémoire que t'as pas envie de te faire pourrir tes perfs par de la dés-allocation (assez couteuse en %cpu). Pour info sur nos serveurs on est passé de 100 clients concurent a plus de 400 en tunant la JVM.

Perso j'aime beaucoup coder en Java et en c#. Je trouve que Java permet de coder plus vite mais est plus limité. C# est vraiment très bon aussi, même si c'est beaucoup repompé sur Java, qui lui même avait repomper sur d'autres (comme Smalltalk), on s'en fout, l'intéressant est la finalité. C# permet plus facilement de faire du code bourrin grace au code unmanaged et a la facilité de dev en COM/DCOM. Le JNI de Java est plus aléatoire et moins bien supporté.

Je travaille actuellement dans un environement "Serveur Java" et "Client graphique en C#" et je trouve que c'est le meilleur des deux mondes.

[lechenejb]

.Net bouffe pas de mémoire, au contraire, il implémente le Garbage Collector qui évite les fuites mémoires non gérées !

Le garbage collector y'en a dans Windows est donc les logiciels dévellopés à la old-school (C,C++) en profite également...

N'importe quoi ! quand tu fais malloc(22); en C ta mémoire se sera jamais libérée tant que ton programme tourne.

.Net implémente un garbage collector car comme java c'est un langage compilé en "micro-code" (enfin pas de l'assembleur) donc le garbage collector de windows ne peut pas s'appliquer...

Windows n'a pas de garbage collector ....

".Net ne boouffe pas de mémoire !!!" : Install les pilotes "Ati .net" reboote fait Ctrl+Alt+Suppr et compte combien de mémoire te prennent les processus CLI.exe :whistle: .Net bouffe forcément plein de mémoire, parceque tu dévellopes un simple "Hello World" ou une suite de bureautique complète, tu charges tout le framework .Net à chaque lancement de ton applis :whistle:

Une instance de VM .NET prends 10Mo ce qui est peut quand on voit tout ce qu'on peut faire avec. Par exemple une instance de VS.NET c'est 11Mo et c'est autrement plus compliqué que ton "helle world"

Oui mais en ce moment je dévellope en Java sous Linux :whistle: donc il risque d'avoir comme un soucis :wink:

il y a mono et #developp

ouais java aussi... néanmoins il prend plein de mémoire.

Quand tu lances une JVM tu lui alloue un espace mémoire initiale 64MO (je crois), en java le garbage-collector n'est appelé que lorsque cet espace mémoire est plein pour réallouer la mémoire dont tu ne te sers plus

Avec la JVM c'est configurable, tu peux démarrer avec 16Mo si tu veux. Tu donne une taille mini (-XMS) et un max (-XMX) et le comportement du GC est configurable aussi (-NEWGC et CONCSwep en SMP). La JVM va libérer la mémoire a la première occasion et pas quand c'est plein, c'est généralement au moment ou tu as besoin de plein de mémoire que t'as pas envie de te faire pourrir tes perfs par de la dés-allocation (assez couteuse en %cpu). Pour info sur nos serveurs on est passé de 100 clients concurent a plus de 400 en tunant la JVM.

Perso j'aime beaucoup coder en Java et en c#. Je trouve que Java permet de coder plus vite mais est plus limité. C# est vraiment très bon aussi, même si c'est beaucoup repompé sur Java, qui lui même avait repomper sur d'autres (comme Smalltalk), on s'en fout, l'intéressant est la finalité. C# permet plus facilement de faire du code bourrin grace au code unmanaged et a la facilité de dev en COM/DCOM. Le JNI de Java est plus aléatoire et moins bien supporté.

Je travaille actuellement dans un environement "Serveur Java" et "Client graphique en C#" et je trouve que c'est le meilleur des deux mondes.

alleluia :jap:

[fofo]

.Net bouffe pas de mémoire, au contraire, il implémente le Garbage Collector qui évite les fuites mémoires non gérées !

Le garbage collector y'en a dans Windows est donc les logiciels dévellopés à la old-school (C,C++) en profite également...

N'importe quoi ! quand tu fais malloc(22); en C ta mémoire se sera jamais libérée tant que ton programme tourne.

Heureusement, quand je fais un malloc c'est que j'ai besoin de cette mémoire, quand j'en ai plus besoin je fais un delete ou free

.Net implémente un garbage collector car comme java c'est un langage compilé en "micro-code" (enfin pas de l'assembleur) donc le garbage collector de windows ne peut pas s'appliquer...

Windows n'a pas de garbage collector ....

Ah...:whistle:

".Net ne boouffe pas de mémoire !!!" : Install les pilotes "Ati .net" reboote fait Ctrl+Alt+Suppr et compte combien de mémoire te prennent les processus CLI.exe :whistle: .Net bouffe forcément plein de mémoire, parceque tu dévellopes un simple "Hello World" ou une suite de bureautique complète, tu charges tout le framework .Net à chaque lancement de ton applis :whistle:

Une instance de VM .NET prends 10Mo ce qui est peut quand on voit tout ce qu'on peut faire avec. Par exemple une instance de VS.NET c'est 11Mo et c'est autrement plus compliqué que ton "helle world"

Ouais enfin il prenait combien VS 6 en mémoire .... :sarcastic:

et puis la pluspart des dévellopement en .net sont des petites applications (genre shareware à la con), si chacun commence à pomper 10MO on est franchement mal barrer

Oui mais en ce moment je dévellope en Java sous Linux :whistle: donc il risque d'avoir comme un soucis :wink:

il y a mono et #developp

Si je fais du java, il y'a une raison (sinon j'aurais fait quelque chose de rapide en C(++) ) : c'est la portabilité, et escuse moi du peu mais la portabilité d'un produit microsoft... (je connais mono et #developp mais à ce qu'on en dit c'est pas top non plus - un peu comme wine quoi).

ouais java aussi... néanmoins il prend plein de mémoire.

Quand tu lances une JVM tu lui alloue un espace mémoire initiale 64MO (je crois), en java le garbage-collector n'est appelé que lorsque cet espace mémoire est plein pour réallouer la mémoire dont tu ne te sers plus

Avec la JVM c'est configurable, tu peux démarrer avec 16Mo si tu veux. Tu donne une taille mini (-XMS) et un max (-XMX) et le comportement du GC est configurable aussi (-NEWGC et CONCSwep en SMP).

Merci je connais java --help :jap:

La JVM va libérer la mémoire a la première occasion et pas quand c'est plein, c'est généralement au moment ou tu as besoin de plein de mémoire que t'as pas envie de te faire pourrir tes perfs par de la dés-allocation (assez couteuse en %cpu). Pour info sur nos serveurs on est passé de 100 clients concurent a plus de 400 en tunant la JVM.

Bien possible en effet, je pensais pas qu'on pouvait obtenir de tels gains de perfs rien qu'avec les options de la JVM uch:

Perso j'aime beaucoup coder en Java et en c#. Je trouve que Java permet de coder plus vite mais est plus limité. C# est vraiment très bon aussi, même si c'est beaucoup repompé sur Java, qui lui même avait repomper sur d'autres (comme Smalltalk), on s'en fout, l'intéressant est la finalité. C# permet plus facilement de faire du code bourrin grace au code unmanaged et a la facilité de dev en COM/DCOM. Le JNI de Java est plus aléatoire et moins bien supporté.

Je travaille actuellement dans un environement "Serveur Java" et "Client graphique en C#" et je trouve que c'est le meilleur des deux mondes.

Je vois toujours pas l'intéret de C# :
- java : Applis portable, dévellopement rapide d'application qui n'ont pas besoin de perf ou IHM (encore que pour les IHMs je trouve que c'est lourd pour pas grand chose...)
- C/C++ : Code rapide, chiant à écrire / débugger
- C/C++(+asm) : Code trés rapide, encore plus chiant à écrire / débugger
- C# : IHM???, portabilité ( pda, téléphone krosoft...)

[lechenejb]

bon, alors on revient à la console, c'est portable, sa bouffe pas de ram pour l'interface, et çà tourne très vite ... un détail que j'oublie, les utilisateurs finaux se foute qu'un logiciel calcule un truc en 20ms au lieu de 50ms, par contre, l'interface à la Playshool, il adorre ! J'ai dev une appli en consultant les utilisateurs finaux, et ben je peux te dire que l'IHM a représenté 80% de mon travail ! Et heureusement que j'ai codé dans un IDE Microsoft où suffit de placer les boutons et hop sa marche, tellement j'ai due modifier pour mettre daccord tout le monde :jap:, pour info, derrière c'est du VB 6 et sa tourne très bien sur des PC 486 alors que l'interface est belle et graphique et que je manipule des tas de chiffres :jap:

[fofo]

bon, alors on revient à la console, c'est portable, sa bouffe pas de ram pour l'interface, et çà tourne très vite ... un détail que j'oublie, les utilisateurs finaux se foute qu'un logiciel calcule un truc en 20ms au lieu de 50ms, par contre, l'interface à la Playshool, il adorre ! J'ai dev une appli en consultant les utilisateurs finaux, et ben je peux te dire que l'IHM a représenté 80% de mon travail ! Et heureusement que j'ai codé dans un IDE Microsoft où suffit de placer les boutons et hop sa marche, tellement j'ai due modifier pour mettre daccord tout le monde :jap:, pour info, derrière c'est du VB 6 et sa tourne très bien sur des PC 486 alors que l'interface est belle et graphique et que je manipule des tas de chiffres :jap:

C++ :D , c'est ce que je dis

edit: euh la console VisualC++ est loin d'être portable (ça dépend des méthodes que tu utilises mais un bon tas d'entre elles sont microsoft-specific)

je ne dénigre pas microsoft, je ne vois pas l'intéret du .net qui en essayant de copier java oublie ce qui fait tout son intéret (la portabilité

edit 2 : et pis tu faires (j'ai fais) du c++ portable gcc + glut(ou autre), en disant portable j'entendais sans devoir recompiler pour telle ou telle plateforme

[lechenejb]

ba à la limite, si on avait une implémentation du CLR qui pourrait interprété le CLI sous Linux ou Apple et sa marcherai sans prob, vu que les EXE .Net sont en fait des codes interprétés :jap:

[fofo]

ba à la limite, si on avait une implémentation du CLR qui pourrait interprété le CLI sous Linux ou Apple et sa marcherai sans prob, vu que les EXE .Net sont en fait des codes interprétés :jap:

Ouip mais là on parle d'un produit microsoft :D

edit: et je doute que ms est un queconque intéret à faire une .netvm multiplateforme (faut bien qu'ils vendent des windows)

[lechenejb]

moi je vois pas pourquoi pas, regarde, y'a bien la suite office sous MAc, y'a aussi MSN, ... alors pourquoi pas :jap: et sous Linux, y'a assez de petit malin capable de mettre çà en place ...

[fofo]

moi je vois pas pourquoi pas, regarde, y'a bien la suite office sous MAc, y'a aussi MSN, ... alors pourquoi pas :jap: et sous Linux, y'a assez de petit malin capable de mettre çà en place ...

C'est écris en C++ pas .net, et c'est microsoft qui sort ces versions

Et pis dans le genre on écrit quelque_chose_que_microsoft_nous_file_pas_les_sour ces y'a wine, et c'est quand même pas top wine, ça marchote avec certain soft et sa plante lamentablement avec d'autres. Donc je ne crois pas trop en mono ou #develop ou autre clones, et de toutes manière le java est déjà présent est trés fonctionnel donc je pense pas que les petits malins vont se casser le c*l

[Dandu]

Pour le .net, y a mono qui permet de lancer tout ce qui est console, hein (sous Linux, et, je crois, sous OS X). Pas ce qui est graphique, bien sur.

Pour MSN mac, c'est juste parce que MS a des actions Apple, le client est pas génial du tout.

Office Mac est fait sous codewarrior, qui existera pas sur les MacIntel, et c'est pas les même Devs que Office Windows (Microsoft à une équipe de dev spécifique mac, y a qu'a voir IE5 Mac face à IE5 PC, le gouffre.)

Sinon, ce qui à l'air pas mal, c'est openGL ES pour les mobiles en tout genre (enfin, surtout les PDAs, parce que les GSM c'est souvent du java les applis).

[fennec]

.Net implémente un garbage collector car comme java c'est un langage compilé en "micro-code" (enfin pas de l'assembleur) donc le garbage collector de windows ne peut pas s'appliquer...

Windows n'a pas de garbage collector ....

Ah...:whistle:

non j'aimerais vraiment que tu m'explique !

".Net ne boouffe pas de mémoire !!!" : Install les pilotes "Ati .net" reboote fait Ctrl+Alt+Suppr et compte combien de mémoire te prennent les processus CLI.exe :whistle: .Net bouffe forcément plein de mémoire, parceque tu dévellopes un simple "Hello World" ou une suite de bureautique complète, tu charges tout le framework .Net à chaque lancement de ton applis :whistle:

Une instance de VM .NET prends 10Mo ce qui est peut quand on voit tout ce qu'on peut faire avec. Par exemple une instance de VS.NET c'est 11Mo et c'est autrement plus compliqué que ton "helle world"

Ouais enfin il prenait combien VS 6 en mémoire .... :sarcastic:

12Mo je viens de tester :D

et puis la pluspart des dévellopement en .net sont des petites applications (genre shareware à la con), si chacun commence à pomper 10MO on est franchement mal barrer

on utilise clairement pas les même applis ? tu connais SAP, c'est un "petit shareware" assez utilisé dont pas mal de composant graphique sont en C# ...

Oui mais en ce moment je dévellope en Java sous Linux :whistle: donc il risque d'avoir comme un soucis :wink:

il y a mono et #developp

Si je fais du java, il y'a une raison (sinon j'aurais fait quelque chose de rapide en C(++) ) : c'est la portabilité, et escuse moi du peu mais la portabilité d'un produit microsoft... (je connais mono et #developp mais à ce qu'on en dit c'est pas top non plus - un peu comme wine quoi).

au lieu de répéter ce qu'on t'as dit, fait toi ton opinion par toi même ... j'ai même l'impression que tu n'as jamais essayé le C# !

ouais java aussi... néanmoins il prend plein de mémoire.

Quand tu lances une JVM tu lui alloue un espace mémoire initiale 64MO (je crois), en java le garbage-collector n'est appelé que lorsque cet espace mémoire est plein pour réallouer la mémoire dont tu ne te sers plus

Avec la JVM c'est configurable, tu peux démarrer avec 16Mo si tu veux. Tu donne une taille mini (-XMS) et un max (-XMX) et le comportement du GC est configurable aussi (-NEWGC et CONCSwep en SMP).

Merci je connais java --help :jap:

c'est pas dedans

La JVM va libérer la mémoire a la première occasion et pas quand c'est plein, c'est généralement au moment ou tu as besoin de plein de mémoire que t'as pas envie de te faire pourrir tes perfs par de la dés-allocation (assez couteuse en %cpu). Pour info sur nos serveurs on est passé de 100 clients concurent a plus de 400 en tunant la JVM.

Bien possible en effet, je pensais pas qu'on pouvait obtenir de tels gains de perfs rien qu'avec les options de la JVM uch:

sur un grosse appli la gestion de la mémoire est la première chose a optimiser ... bien avant de penser a l'assembleur ...

Je vois toujours pas l'intéret de C# :
- java : Applis portable, dévellopement rapide d'application qui n'ont pas besoin de perf ou IHM (encore que pour les IHMs je trouve que c'est lourd pour pas grand chose...)

Il ne faut pas croire ... une appli Java peut être beaucoup plus rapide qu'en C++. Il faut oublier les pré-jugés et compter la diffculté de bien coder dans un language donné.

- C/C++ : Code rapide, chiant à écrire / débugger
- C/C++(+asm) : Code trés rapide, encore plus chiant à écrire / débugger
- C# : IHM???, portabilité ( pda, téléphone krosoft...)

En C# c'est un vrai bonheur de faire des IHM, ça va vraiment très vite et on se prends pas la tête.

Pour ce qui est de perf je te mets au défit si tu veux. Pour une même petite application serveur, tu peux la faire en 3 jours en C#/Java, il te faudra au moins 5 jours pour faire la même chose en C++/C/asm ... D'expérience je peut te dire que ton appli C+/C++/asm sera 2 fois moins performante et aura 10x plus de bugs.

[Oxygen3]

pour info, le C# peut tourner aussi vite qu'un programme en C++, donc la perf est là (contrairement à java justement)

[ylyad]

on utilise clairement pas les même applis ? tu connais SAP, c'est un "petit shareware" assez utilisé dont pas mal de composant graphique sont en C# ...

Ceci dit, je savais pas que c'était du C#... Quelles parties? SAP GUI 6.40? Autre chose?

[Neo_13]

un détail que j'oublie, les utilisateurs finaux se foute qu'un logiciel calcule un truc en 20ms au lieu de 50ms, par contre, l'interface à la Playshool, il adorre

moi, je parlais de 6min de calcul sur pentium4 2.53 avec 1Go de ram pour la version java initiale du code... et c'était destiné à tourner sur Pentium3 733 avec 256Mo de ram. on est loin des 20ms...

[lechenejb]

un détail que j'oublie, les utilisateurs finaux se foute qu'un logiciel calcule un truc en 20ms au lieu de 50ms, par contre, l'interface à la Playshool, il adorre

moi, je parlais de 6min de calcul sur pentium4 2.53 avec 1Go de ram pour la version java initiale du code... et c'était destiné à tourner sur Pentium3 733 avec 256Mo de ram. on est loin des 20ms...

ouai, mais là c'est une appli spécifique destinnée à du calcul, mais c'est rarement le cas dans les entreprises de services qui sont les premiers consommateur de solution logicielle adaptée :jap:

[fennec]

on utilise clairement pas les même applis ? tu connais SAP, c'est un "petit shareware" assez utilisé dont pas mal de composant graphique sont en C# ...

Ceci dit, je savais pas que c'était du C#... Quelles parties? SAP GUI 6.40? Autre chose?

En fait on a comme produit un toolkit qui s'intègre dans un framework SAP pour VS.NET. Je crois pas que ça soit un produit "out of the box" mais en tout cas ça tourne avec NetWeaver et il est en C#.

pour info, le C# peut tourner aussi vite qu'un programme en C++, donc la perf est là (contrairement à java justement)

avec hotspot ça peut bien dépoter le Java aussi, j'ai pas encore eu l'occasion de tester avec la JVM 1.5 mais en 1.4 ya de bon gains.

Pour en revenir au sujet initial, il y avait un projet très intéressant nomé Axiom (http://www.axiom3d.org) de moteur 3D en C# multiplateforme (Windows et Linux) et supportant OpenGL et DirectX. Il a été abandonnée puis repris (RealmForge) mais parrait moins actif, il est basé sur Ogre, un moteur 3D (Win/Linux et OpenGL +DirectX aussi). Ca parrait assez prometteur et supporte les deux standards

[fgeo]

A mon avis, le Managed DirectX à un bon avenir, ce n'est pas un simple wrapper autour de la lib native qui est dessous. La libraire est codée avec les guidelines .NET en tête et utilise les types natifs .NET ce qui augmente énormément la productivité.
Et cela a aussi un impact indirecte sur les performances, quand il faut bien moins de temps pour faire la même chose, on peut utiliser ce temps pour améliorer les algorithmes, l'organisation etc... (Ou pour les jeux: l'interface, l'IA et autres choses) ce qui peut avoir énormément d'impacte sur les performances du produit final. Et alors comme pour IronPython on peut être étonné du résultat : http://www.ironpython.com/
Je vous laisse lire la petite histoire sous "Release Announcement". IronPython va surement devenir un langage officiel de Microsoft (dernière release disponible ici).

Et la différence de perf entre du Direct3D native et managé pour le "même" code sont faible, et se réduit au fur et à mesure qu'on utilise des effets 3D compliqué (shaders, tout les trucs HDR etc...) qui pour la plupart se trouve dans tous les jeux actuels. Comme exemple, l'exemple "HDR Cubemap" du SDK DirectX tourne au même nombre de FPS sur mon PC entre la version native et managé, pas de différence de performances.

Contrairement au Java, .NET à la notion de "types valeurs" tels que les structures en C, qui se trouve sur pile et donc n'ont pas besoin d'être gérée par le garbage collector. Et dans une boucle de rendu, les références qui mettent à genou le garbage collector, ca ne pardonne pas.

Au niveau des moteurs 3D en .NET y'en a une douzaine : http://www.thezbuffer.com/categories/engines.aspx
Avec un mix de moteurs OpenGL et Direct3D.

Et un jeu commercial sympa (passé de longues heures sur la démo ) :
http://arenawars.krawall.de/eng/index.html
Fait en .NET/OpenGL

Faire un moteur 3D .NET multiplateforme est tout à fait envisageable, le système d'appel de code natif (P/Invoke de son nom) fait partit des spécifications de la CLI et est prévu à cet effet, exemple (que certains reconnaitront peut-être, j'avais pas de code OpenGL sous la main ) :

[DllImport("user32")]
public static extern IntPtr SendMessage(IntPtr hWnd, int msg, int wParam, int lParam);

Pas d'extension spécifiée, sous Windows la runtime ira chercher user32.dll et sous linux user32.so. Et la librairie native n'a absolument rien de spéciale, c'est une simple libraire native avec les point d'entrés que l'on veut.
Apres les problèmes restant sont exactement les même qu'un jeu natif : gestion des préférences, profiles etc… différent suivant la plateforme (emplacement, base de registre etc...).
Donc si on utilise OpenGL depuis .NET il suffit d'avoir la lib à disposition sur les différentes plateformes, avec les mêmes procédures dedans.


Et du coté des performances d'exécution d'un programme .NET, le MSIL est complètement compilé en code natif au chargement du programme avec toutes les optimisations d'instructions qui vont bien (et vu le compilateur C++ de Microsoft, ils ont les personnes qui s'y connaissent dans ce domaine). Ce n'est pas du tout interprété au fur et à mesure de l'exécution (comme il me semble que c'est en Java, mais que quelqu'un confirme ou me contredise).

En ce qui concerne la taille mémoire de la runtime, il est clair que cela peut paraître un gros handicap à première vue. Mais dans un programme console qui se terminera autant vite qu'il a été lancé, les 10Mo de plus on s'en tape un peu. Et pour les jeux, 10Mo c'est ridicule comparé à ce qu'ils demandent de nos jours comme RAM.

[lechenejb]

j'avais lu un test des langages les plus utilisés sur des trucs simples (boucles, calcul, affectation, ...) résultat C++ Intel en tête et C++ et C# .Net qui suivait derrière, VB .Net et C++ GCC étaient au même niveau il me semble, et en fond de classement y'avais Python, 100 fois moins rapide que du C++ Intel

[fennec]

Et du coté des performances d'exécution d'un programme .NET, le MSIL est complètement compilé en code natif au chargement du programme avec toutes les optimisations d'instructions qui vont bien (et vu le compilateur C++ de Microsoft, ils ont les personnes qui s'y connaissent dans ce domaine). Ce n'est pas du tout interprété au fur et à mesure de l'exécution (comme il me semble que c'est en Java, mais que quelqu'un confirme ou me contredise).

Java peut le faire aussi avec hotspot (1.3) et la JVM serveur (1.4) , quand la JVM détecte un traitement répétitif elle transforme le "byte code" en code natif.

j'avais lu un test des langages les plus utilisés sur des trucs simples (boucles, calcul, affectation, ...) résultat C++ Intel en tête et C++ et C# .Net qui suivait derrière, VB .Net et C++ GCC étaient au même niveau il me semble, et en fond de classement y'avais Python, 100 fois moins rapide que du C++ Intel

Oui sur un petit traitement précis peut être, sur du calcul scientifique surement mais dans tous les autres cas c'est pas donnée. Ca me fait penser aux mecs qui croient encore que coder en assembleur est la meilleur façon d'obtenir les meilleurs perf ou ceux qui décrementaient les variables au lieu d'incrémenter pour gagner en perf ...

[Dandu]

Coder tout en assembleur, non. Optimiser (en ayant les compétences) des petites parties de codes qui sont critiques (eventuellement en SIMD) en assembleur à la main apporte des gains (parfois énormes).

décrémenter au lieu d'incrémenter permet du gain sur des traitements très répétitifs si le code est dans une partie critique, et c'est pas dénué de sens (enfin, c'était un problème de nombre de registre, il me semble, donc moins d'actualité).

Mais globalement, avoir des bonnes perfs, c'est juste bien penser le truc, en général, et pas coder en VB pas .net

[fennec]

Coder tout en assembleur, non. Optimiser (en ayant les compétences) des petites parties de codes qui sont critiques (eventuellement en SIMD) en assembleur à la main apporte des gains (parfois énormes).

éventuellement mais sur une achitechture donnée c'est valable, si c'est du code pour particulier qui va tourner sur des cpu très différents comme un jeu vidéo ça n'a aucun intéret ...

décrémenter au lieu d'incrémenter permet du gain sur des traitements très répétitifs si le code est dans une partie critique, et c'est pas dénué de sens (enfin, c'était un problème de nombre de registre, il me semble, donc moins d'actualité).

Il me semble que c'était valable sur 68000 mais maintenant même si c'était d'actualité ça serait le compilateur qui le ferait tout seul vu que c'est une optimisation très simple.

Mais globalement, avoir des bonnes perfs, c'est juste bien penser le truc, en général, et pas coder en VB pas .net

C'est clair !

[Alice]

éventuellement mais sur une achitechture donnée c'est valable, si c'est du code pour particulier qui va tourner sur des cpu très différents comme un jeu vidéo ça n'a aucun intéret ...

:heink: ... les jeux sont à destination des CPU X86... le SSE/SSE2 peut être considéré comme "standard" sur ce type de CPU et le gain qu'il apporte est plus que notable sur les classes de calcul vectoriel/matriciel...

[fofo]

éventuellement mais sur une achitechture donnée c'est valable, si c'est du code pour particulier qui va tourner sur des cpu très différents comme un jeu vidéo ça n'a aucun intéret ...

:heink: ... les jeux sont à destination des CPU X86... le SSE/SSE2 peut être considéré comme "standard" sur ce type de CPU et le gain qu'il apporte est plus que notable sur les classes de calcul vectoriel/matriciel...

Quand même pas non plus hein les athlons sont un peu plus à la rue la dessus, mais rien n'empèche de mettre plusieurs exe sur le CD jeux.exe, jeux_MMX.exe ,jeux_SSE.exe ... ça déjà été fait et à l'époque des 3DFX c'était obligatoire

[fennec]

éventuellement mais sur une achitechture donnée c'est valable, si c'est du code pour particulier qui va tourner sur des cpu très différents comme un jeu vidéo ça n'a aucun intéret ...

:heink: ... les jeux sont à destination des CPU X86... le SSE/SSE2 peut être considéré comme "standard" sur ce type de CPU et le gain qu'il apporte est plus que notable sur les classes de calcul vectoriel/matriciel...

Optimiser un programme c'est pas remplacer une instruction par une autre, ça un compilateur peut le faire tout seul. J'ai pas le niveau pour te donner un exemple précis mais il s'agit de choisir l'agencement des instructions en fonction de ce qu'on veut faire et de ce que le processeur peut faire. Dans le cas d'archi aussi opposée que celle d'AMD, le P4 et le P-m on peut pour un même code avoir des perfs complètement opposées tout en utilisant les instructions optimale pour chaque archi.

Il ne s'agit pas que de choisir la bonne instruction il faut aussi les utiliser dans le bon ordre pour profiter des perf d'un pipeline long (P4) ou d'une FPU puissante (AMD). D'ailleur on voit bien que pour un même code dans les différents articles ici sur x86 les perfs ne sont pas du tout les mêmes.

[Alice]

Optimiser un programme c'est pas remplacer une instruction par une autre, ça un compilateur peut le faire tout seul

.
...le compilateur il fait plus que soufrir pour générer du code SSE2 là où il faut. En fait il le fait rarement.

J'ai pas le niveau pour te donner un exemple précis mais il s'agit de choisir l'agencement des instructions en fonction de ce qu'on veut faire et de ce que le processeur peut faire

Pour une multiplication matrice/vecteur il y a plusieurs façon de le paralléliser mais pour un même algo optimisé, le code résultant est identique. Que ce soit sur AMD ou Intel paralléliser ce calcul conduira au même code. Après si les perfs sont en faveur du PIV faut pas chercher d'excuses, c'est tout simplement que le SSE2 des Athlons 64 est moins performant (du moins, il y a encore un an).

Dans tous les cas même sur A64 les gains de l'optimisation SSE2 seront quand même significatifs.

Quand même pas non plus hein les athlons sont un peu plus à la rue la dessus"

C'est pas parce qu'une archi est en difficulté sur un jeu d'instruction que celui-ci ne peut pas être considéré comme standard et utilisé. Si c'était le cas, du temps des geforceFX la norme en vigueur aurait été les Pixel Shader 1.1.

rien n'empèche de mettre plusieurs exe sur le CD jeux.exe, jeux_MMX.exe ,jeux_SSE.exe

C'est le cas sur "The Chronicle of Riddick". :wink:

[fefe]

Optimiser un programme c'est pas remplacer une instruction par une autre, ça un compilateur peut le faire tout seul. J'ai pas le niveau pour te donner un exemple précis mais il s'agit de choisir l'agencement des instructions en fonction de ce qu'on veut faire et de ce que le processeur peut faire. Dans le cas d'archi aussi opposée que celle d'AMD, le P4 et le P-m on peut pour un même code avoir des perfs complètement opposées tout en utilisant les instructions optimale pour chaque archi.

Il ne s'agit pas que de choisir la bonne instruction il faut aussi les utiliser dans le bon ordre pour profiter des perf d'un pipeline long (P4) ou d'une FPU puissante (AMD). D'ailleur on voit bien que pour un même code dans les différents articles ici sur x86 les perfs ne sont pas du tout les mêmes.

Optimiser pour packed sse2 ce n'est pas remplace une instruction par une autre, les compilos ne savent vectoriser que les cas simples, et generalement ca necessite une reecriture de l'algorithme et parfois une refonte globale de l'application.

Le scheduling d'instruction n'a pratiquement aucun impact sur Pentium 4 a moins de reordonnancer des blocs d'instructions tres eloignes l'un de l'autre (100+) ce qui revient a modifier ton algorithme, et sur Pentium M tu n'arriveras pas a ordonancer le code a la main mieux que le compilo Intel ne le fait (a moins de vouloir deplacer tres loin ce qui s'ignifie une refonte de ton algo).

Certaines instructions ont une latence catastrophique sur un processeur ou l'autre et peuvent etre remplacees par un equivalent plus rapide sur une archi et moins sur une autre. Par exemple sur P4 ce sera plus long de faire :

movdqa xmm1, xmm2

que

pxor xmm1, xmm1
por xmm1, xmm2

alors que sur pentium M c'est l'inverse. Ca ce sont les problemes d'optimisation "simples", ou tu prends la liste des instructions qui sont connues pour ramer (decallage a droite pour P4, imul pour northwood...) et tu les remplace par un equivalent moins couteux.

Certains compilos y arrivent des fois, mais si il y a ecrit >> dans ton code le compilo a pas le choix il fait un decallage a droite.

Donc remplacer une instruction par une autre, le compilo a beaucoup de mal a le faire surtout si il s'agit de packed SSE2, changer l'ordonnancement il n'a aucun probleme, et ca n'a un impact reel que sur k8 et pM.

Optimiser un programme c'est comprendre son interaction avec l'architecture de la machine, et s'arranger pour minimiser le nombre d'operations couteuses que l'on effectue. Tenter de lister ces operations couteuses me prendrait la soiree et j ai un peu la flemme, mais regarder ce qui se passe au niveau instructions n'est pas le premier truc a faire et de loin (disque->memoire->cache en premier et pas besoin d'asm), et les problemes d'ordonancement d'instructions sont generalement les derniers a regarder sur les micropros que tu as liste.

[fefe]

Optimiser un programme c'est pas remplacer une instruction par une autre, ça un compilateur peut le faire tout seul

.
...le compilateur il fait plus que soufrir pour générer du code SSE2 là où il faut. En fait il le fait rarement.

Oui en packed (en scalar il s'en sort en general)

J'ai pas le niveau pour te donner un exemple précis mais il s'agit de choisir l'agencement des instructions en fonction de ce qu'on veut faire et de ce que le processeur peut faire

Pour une multiplication matrice/vecteur il y a plusieurs façon de le paralléliser mais pour un même algo optimisé, le code résultant est identique. Que ce soit sur AMD ou Intel paralléliser ce calcul conduira au même code. Après si les perfs sont en faveur du PIV faut pas chercher d'excuses, c'est tout simplement que le SSE2 des Athlons 64 est moins performant (du moins, il y a encore un an).

[edit] oups, je parle de dgemm (mat*mat) et tu parles de mat*vect, desole. A priori c'est pas fondamentalement different donc je laisse mon comment.

Non, le dgemm optimal (le meilleur dispo aujourd'hui) sur athlon et P4 et PM ne sont pas les memes. Blocking pour les caches different, latence et bande passante des caches differente, latence de l'adder different donc utilisation d'un nombre different d'accumulateurs. Les techniques employees sont a peu pres les memes, le code final est different. En pratique il existe un code proche de l'optimal qui tourne a peu pres aussi efficacement sur chacun d'entre eux.

Dans tous les cas même sur A64 les gains de l'optimisation SSE2 seront quand même significatifs.

Quand même pas non plus hein les athlons sont un peu plus à la rue la dessus"

C'est pas parce qu'une archi est en difficulté sur un jeu d'instruction que celui-ci ne peut pas être considéré comme standard et utilisé. Si c'était le cas, du temps des geforceFX la norme en vigueur aurait été les Pixel Shader 1.1.

oui, et le code dgemm SSE2 de p4 tourne pas mal sur athlon, il y a juste un peu mieux.

[Alice]

Non, le dgemm optimal (le meilleur dispo aujourd'hui) sur athlon et P4 et PM ne sont pas les memes. Blocking pour les caches different, latence et bande passante des caches differente, latence de l'adder different donc utilisation d'un nombre different d'accumulateurs. Les techniques employees sont a peu pres les memes, le code final est different. En pratique il existe un code proche de l'optimal qui tourne a peu pres aussi efficacement sur chacun d'entre eux.

autant pour moi... merci pour les précisions

[fennec]

Optimiser un programme c'est pas remplacer une instruction par une autre, ça un compilateur peut le faire tout seul

.
...le compilateur il fait plus que soufrir pour générer du code SSE2 là où il faut. En fait il le fait rarement.

ça dépends du compilateur ... c'est ce que fait icc, et il se débrouille pas trop mal quand on voit les gains.

J'ai pas le niveau pour te donner un exemple précis mais il s'agit de choisir l'agencement des instructions en fonction de ce qu'on veut faire et de ce que le processeur peut faire

Pour une multiplication matrice/vecteur il y a plusieurs façon de le paralléliser mais pour un même algo optimisé, le code résultant est identique. Que ce soit sur AMD ou Intel paralléliser ce calcul conduira au même code. Après si les perfs sont en faveur du PIV faut pas chercher d'excuses, c'est tout simplement que le SSE2 des Athlons 64 est moins performant (du moins, il y a encore un an).

Dans tous les cas même sur A64 les gains de l'optimisation SSE2 seront quand même significatifs.

Donc on revient bien à ce que je disait, il faut optimiser spécifiquement le code pour chaque architecture si on veut les meilleures perfs. Le code optimisé SSE2 tournera plus lentement sur un A64 qu'un P4. Pour l'A64 il faudrait optimiser en utilisant du code non SSE2.

fefe> je crois qu'on dit la même chose ?

[fefe]

fefe> je crois qu'on dit la même chose ?

Sur les details, l'inverse j'ai l'impression.
ICC ne reussit pas a vectoriser la majorite des boucles vectorisables par un programmeur a la main (hors SPECFP) par ex. Ca donne dans quelques cas de bons resultats oui.