( lol pour les communistes)

En fait, le principe c´est que les sovietiques n´ont pas de sous ( si en fait mais bon).
Donc ils n´ont pas les moyens de se payer des machines puissantes.
Donc s´ils peuvent économiser UN octect ou UN cycle processeur ils le font!!!

En l´occurence, on avait codé sovietique sur notre projet de simulation. On devait simuler des files d´attentes bizarres pour en tirer des valeures de moyennes, ecart-types, machin, truc, bidules.

Notre programme avais une méthode d´arrêt un peu spéciale, puisqu´il s´arretait quand les valeurs que l´on calculait convergait.
et elle convergait... lentement.... tres lentement... ( entre 100 millions et 1 millaird d´itérations)
donc gagner 100 cycles processeurs par itération, ca nous faisait 10 milliard d´operation. Sur une machine a 300 Mhz, ca fait... 30 secondes.

Sachant que notre probleme avait 3 parametres... ca faisait beaucoup de simulation a faire!

bon pour la petite histoire... Quand on a plus eu de recours algorithmique, une simulation faisait pres d´une heure, a la fin... 3 minutes!

FAITES COMME MOI: CODER SOVIETIQUE!!

notez bien qu´on s´est bien cassés la tête pour ca!!

Mais ca donne lieu a des truc marrant: au début tu fais une optimisation bidons et tu gagnes 2-3 minute, dès fois 10 minutes.
A la fin,tu es la: ouais, j´ai gagné 2 secondes!

moi j´appelle ca coder tout court :-? meme si c´est encore plus vrai sur console cela dit...

M´en parles pas.
apres je vais me rappeler de mon moteur 3D sur GBA et..
Ca y est je suis de mauvaise humeur!!

Nan serieusement, je m´en fout la plupart du temps es perf de mon appli tant que ca repond en temps réel.
la c´est du calcul scientifique et j´avais une deadline a mon projet.
Apres que mon grep réponde en 10 millisecondes ou en 5 millisecondes je m´en fout complètement!

En plus a la fin notre code était imbittable par partie ( mais il était très commenté donc ca allait).

Mais bon, on avait un REEL besoin de perf, ce qui n´est pas toujours le cas.

LGV tu pourrait m´expliquer ( sommairement) comment on fait au niveau asm ( bon c´est un peu hs) pour accélérer les calcul sur des float plutot que des double :

parce que quand on utilise FMUL & Cie rien ne lui dit qu´on veut moins de précision si tout est déjà dans la pile du FPU. Et si l´un es opérande n´y est pas est-ce qu´il limite la précision à celle de l´opérande que tu charge en mémoire ? ou pas si de toute manière il stoque ça en extended double après ( 80 bits donc encore mieux que les double pour ceux qui lise ça).

Enfin ça m´interesserait de savoir car je suis assez décu par ce que je code en asm au niveau des perf donc il y a peut-être un truc qui m´a échapé.

merci.

le code assembleur que tu ecriras sera presque toujours plus lent que du code écrit par le compilateur.

En effet, tu ne peux pas connaitre et prevoir le fonctionnement du pipeline du processeur aussi bien que le compilateur.

Ton code risque de generer du fait des bulles dans le pipeline ou des choses comme cela.
L´ordonnancement de tâches avec delai est un problème suffisament compliqué pour laisser un compilateur faire sa tambouille!

Si tu es vraiment curieux
apres tu peux toujours regarder la tete du code pondu par gcc ( ou visual) en assembleur quand tu le met en max d´optimisation.
( option -S dans gcc)

ça dépend, sur des morceaux de code assez cour j´ai réussi à battre Visual C++ avec toute ces optimisations.

L´astuce c´est que pour une simple exponentiation, le code généré par VC++ fait es dizaines de ligne de vérification diverse même avec les optimisation réglé au maximum, alors que moi je me contente de faire le calcul. Le problème est que VC++ triche et que par exemple il n´y a pas d´appel de fonction quand tu écrit x=pow(a,b); donc je ne peut pas battre le compilo si moi j´écrit une fonction à laquel il faut passer des arguments donc il faut écrire directement l´asm inline dans le code.
Je pense que ce gain pourrait être plus important sur des grosse fonction mathématique justement parce que je ne sais pas coment marche le pipeline, mais par contre je sais bien mieux compter que VC++ et donc je peut mieux optimiser le calcul en lui même.
Mais dès que je dépasse une certaine quantité de code je me met à perdre énormément de performance.

Entre autre j´ai l´impression que c´est plus long de faire les calcul directement dans la pile de processeur genre FMUL; avec 2 opérande de 80 bits que avec un opérande de 64 bit qui vient de la mémoire, alors que le chargement dans la pile du FPU est quand même extrémement long.

bah non il ne triche pas maios ca c´est la deuxieme raison pour lequel le compilo est plus rapide.
comme il ne sait pas quel registre tu va modifier, il est obliger de faire une savegarde/restauration de contexte quand tu mets de l´assembleur...

pour quand meme repondre a la question, quand tu fais des operations sur le fpu via des fxx et que les mnemoniques demandent des donnees adressees en argument, tu peux preciser le type d´addressage, a grand coup de " dword ptr" pour du 32 bits par exemple. De memoire il me semble qu´on peut activer des flags pour specifier le format par defaut, mais je ne saurais le garantir.

je viens de trouver un petit exemple qui montre comment proceder : http://www.immersive.com/marc/dft80x87.html

sinon, je suis du meme avis que godrik, sauf dans qq cas TRES particuliers, mieux vaut laisser faire le compilo. Il est bon de connaitre un minimum l´asm, pour savoir comment ca se passe " derriere", ou pour certaines phases de debuggage, mais avec la complexite des archi actuelles, les compilo font un bien meilleur boulot ( et c´est " evolutif"). On reserve donc l´ASM pour des specificites materielles bien precises ou on n´a pas d´autre choix ( ou alors quand l´archi est connue precisement, comme les fameux vertex units de la PS2 ou les codeurs specialises la-dedans n´hesitent pas a pondre du code au petit oignons)

disont qu´en théorie vous avez tout les deux raison ( juste godrik quand je disait qu´il triche, c´était une tournure de style) mais ce qui m´amuse disont c´est justement d´écrire moi même le calcul qu´il fait au plus bas niveau possible. je ne le fait pas vraiment pour le calcul, mais pour écrire le calcul, ensuite bien sur j´essaye de l´écrire le mieux possible.

LGV : en utilisant le programme que tu m´a passé là, j´ai fait un test en calculant le dft d´une série de 50 000 points.

Et bien que j´utilise des double ou des float l´exécution mets exactement ( à moins d´un dixième de seconde près pour un temps d´exécution de 400 seconde) le même temps.

Pour information le code que j´ai utilisé est là :
http://rafb.net/paste/results/x9V8BM70.html

http://perso.wanadoo.fr/sectionpc/wall/dft.cpp
pour la postérité, si jamais quelqu´un tombe la dessus un jour.

J´auré aimé savoir si on pouvait desactivé la croix en haut a droite de l´ecran pour ne pas pouvoir fermer le programme tan qu´il n´est pas fini

tu active la fonctionalité:

no_little_cross_in_top_right_corner=true;

quoi tu n´a pas cette fonctionnalité ?
mais il faudrait nous dire ce que tu utilise alors...

bon, si tu es en mode console basic ( juste stdio ou iostream), c´est pas faisable je pense.

Mais de toute manière tu ne peut pas empêcher un utilisateur de fermer un programme, si ton programme refuse de quitter l´utilisateur peut toujours tuer le processus, ce n´est pas la bonne méthode.
Il vaut mieux prévenir : dire à l´utilisateur de ne pas quitter quand l´en empêcher, sachant que s´il a avant de quitter il doit pouvoir le faire.

Avec ma lib :
http://perso.wanadoo.fr/secionpc/lib
qui dispose de fonctionnalité d´entrées/sorties dans la console assez puissante tu peut facilement intercepter la fermeture de la console et même si tu ne peut pas empêcher que la console ne se ferme, tu peut comme ça être prévenu qu´elle se ferme et exécuté le code necéssaire à la bonne fermeture de ton programme ( voir relancer un nouveau processus d´un nouveau programme qui reprend le travail là où tu l´avait arrété, mais c´est vraiment pas propre comme manière de faire).

il convient de comparer ce qui est comparable. Les instructions FPU utilisées datent des premieres generations de pentium. Si tu executes ton code sur un PII par ex. tu verras une ENORME difference entre les float et les double.
Avec un compilo moderne qui tire parti des archis modernes, la différence s´amenuise : l´archi rattrape la faiblesse du double mais atteint ses limites avec le float qui ne gagne que peu au changement, en qq sorte. Donc pour du code " naif" c´est tout bon !
Par contre, là où ça devient interessant, c´est de faire une comparaison moderne, avec les techniques modernes.

je viens de pondre un petit truc dans ce sens : http://rafb.net/paste/results/HNfLU357.html

une bete comparaison de 1/sqrt ( le choix n´est pas innocent...), l´un naif en double, l´autre moderne en float-SSE1
Sur mon P4C la version float est plus de 4 fois plus rapide que la version double ; la version double naive se rapprochant elle meme de ce qu´on obtient avec de l´asm fpu " à la main".

( au passage, avec un CPU supportant le SSE3 on pourrait écrire la version double vectorisée, deux fois plus rapide que la version naive, ramenant alors le rapport de perf double/float pour une techno identique à la valeur " logique" de 2)

ki pourrai me dire ( pour ce qui sont réveillé) ou peut on télécharG le c++ ! !! en non payant ! ( je c po si c´est payant ou pas ! ! parce que rpg maker sans conétre le ruby c=sa a ses limites !

lemoutoon: sur www.microsoft.com
cherche a VC toolkit.

pour repondre a toute cette digretion ( c´est peut etre avec deux s, je ne asis plus)
il ne faut pas oublier que les compilos ont aussi un flag plateforme cible.
Et comme je disais plus haut, quand on voit le bordel que c´est de faire de l´ordo avec temps de latence sur plusieurs " processeur" ( puisqu´au final, le proc est divisible en partie independante), je n´ai vraiemnt aucun doute qu´il sera fort difficile d´écrire du meilleur code que le compilo MS ou que gcc
( sans compter que ce flag permet de fasser facilement d´une architecture materielle a une autre et que tu as l´air bien con d´avoir active les super option de la mort qui tue quand il n´y a que 3 processeurs das le monde qui savent s´en servir! )

LGV : mais le SSE et Cie tune peut t´en servir que lorsque tu a une grosse quantité de donnée sur lesquel tu doit faire le même traitement non ?

entre autre est-ce que ça peut te permettre si tu veux tracer une fonction assez complexe de calculer " en même temps" plusieurs point de la courbe ?

enf ait a ce que j´ai cru comprendre c´est un genre de SIMD ( Snigle instruction stream, multiple data stream).
donc si tu fais exactement le meme calcul sur deux float. ca doit pouvoir le paralleliser.