Je propose un nouveau petit concours du code le plus rapide. Plus simple que le précédent pour que tout le monde puisse y participer.
Ce topic est posté dans les zones : C, C++ et ASM.
D'ailleurs, pendant que j'y pense, ce serait bien d'avoir une sous-catégorie Concours !
Y a-t-il un modo dans la salle ?
 
ça m'aurait permis d'éviter de flooder en zone C et ASM. Désolé.
 
 
On dispose d'un générateur de nombre aléatoire générant une suite de 5.000.000 valeurs entières (positives) allant de 0 à 2^31-1 suivant :

Il s'agit de comptabiliser l'occurence des chiffres composants les nombres. Attention, on ne comptera pas le zéro précédent la valeur !
 
Un exemple pour 3 nombres : 484230, 6232, 89054620

 
Limitation dans le programme
- Tout est possible, la mesure de temps doit se faire entre le début du main et juste avant l'affichage des résultats.
Pour les résultats, un tableau de 10 entiers (de longueur 4 ou 8 octets) doit être rempli.
 
Limitation en mémoire
- Mémoire occupée limitée à 64Mo.
 
Limitation pour le langage
1 - Uniquement en C ou C++ sans aucune optimisation de la part du compilateur.
2 - Uniquement en C ou C++ avec les optimisations maximales du compilateur.
3 - Pour ceux qui veulent faire de l'assembleur (avec ou sans C/C++ mélangé), il faudra également fournir un code en C ou C++ (voir 1 ou 2). Donc sortir au moins 2 programmes (ASM et C/C++).
 
La cible
- Pour ma part, j'ai a ma disposition deux AthlonXP (Un Thoroughbred à 180MHz*12 avec 512Mo et un Barton à 180MHz*12 avec 1Go) sous Windows XP et un Pentium III-600 (133MHz*4 avec 128Mo).
- Il est possible de tester sur d'autres configurations.
- J'ai a ma disposition Visual C++ Service Pack 6 + Processor Pack 2 et DJGPP 2.01 (uniquement sous Windows 98SE).
 
Les performances
- Je ferais un récap pour les 3 cibles pour ceux qui sortirons en C/C++ sans optimisation et avec.
- Pour les programmes en assembleur, j'essayerais de les faire tourner sur les 3 plate-formes.
 
A vos cerveaux !

t'as oublié un 0!

skeye> Bien vue ! T'as été plus rapide que moi pour la relecture.

«  Uniquement en C ou C++ sans aucune optimisation de la part du compilateur. » c'est complètement bidon ton truc ... si tu désactives l'inlining, c'est même pas là peine de faire quoi que ce soit, sans parler des noop que rajoute les compilos dans tous les sens en mode debug

Taz> On a tous des compilateurs différents. Cela montrera les performance de l'analyse et pas forcément du code.
Pour l'optimisation, il reste l'assembleur !

 
non, pas assez de topic à ce sujet

 
Cela n'a aucun sens de parler d'assembleur tout en désactivant les optimisations du compilo pour le C ou le C++.

ça montrera rien du tout. c'est bidon ton truc

quand même

C'est ouvert à tout le monde... Et je n'oblige personne a participer. Si cela ne t'interresse pas, libre à toi de faire ton choix.
Mais tu peux toujours nous sortir un code avec les optimisations si cela peut te faire plaisir.
 
Rien que pour vous faire plaisir, j'élargi la cible.

Pour les résultats, un tableau de 8 entiers doit être rempli.
 
8 entiers ? pas 10 ?

ce que tu comprends pas c'est que ton histoire bidon de désactiver les optimisations est pire : certains compilateurs ne considère pas certaine choses comme des optimisations, donc si tu laisses pas sa chance à chaque compilateur de faire son mieux, tu accrois encore plus les différences. à jamais

BlackGoddess> Bien lu ! Corrigé, merci. Je m'étais trompé, Désolé.

Taz> Sors-nous un programme et on verra la différence entre o0 et o3 sous DJGPP et entre Od et O2 sous Visual C++.

Bizarre, j'ai l'impression d'avoir déjà vu ça qq part...
 
http://forum.hardware.fr/forum2.ph [...] =0&subcat=
 
edit : j'avais pas vu qu'on ne compte que les chiffres. L'algo est trivial, donc ça n'a aucun intérêt.

 
taz utilise GCC

 
d'ailleurs, à cause de taz, gcc de faire du C++

el muchaco> Il ne marche pas le lien...
Mais si c'est à quoi je pense, j'ai repris l'idée du générateur de Knutz et j'ai fais un problème plus simple. Peut-être trop simple puisque dans le problème, ce qui va causer la lenteur ne sera pas forcément l'analyse, mais la bande passante... Cela dit, l'algo doit quand même être bien fait.
 
Sous VC++ 6.0 SP5 avec un Barton à 180x12 et WinAmp en tâche de fond : (4 essais et j'ai pris le temps le plus court)
- Debug = 7047ms (/Od)
- Release = 5781ms (/O2)
 
Up> Le code est très simple, mais sans aucune analyse.

 
  le niveau vient de grimper d'un coup là !

(jme suis juste permis de mettre une windowserie pour mesurer le temps.)
 
compilé sous vc++7.1, p4 2.4 :
 

 
résultats :  
 
debug :
 
temps ÚcoulÚ : 3421 ms
0 : 4454792 occurences
1 : 6919549 occurences
2 : 4821073 occurences
3 : 4474832 occurences
4 : 4473815 occurences
5 : 4457929 occurences
6 : 4454968 occurences
7 : 4451157 occurences
8 : 4450771 occurences
9 : 4455972 occurences
 
release :
 
temps ÚcoulÚ : 1109 ms
0 : 4454792 occurences
1 : 6919549 occurences
2 : 4821073 occurences
3 : 4474832 occurences
4 : 4473815 occurences
5 : 4457929 occurences
6 : 4454968 occurences
7 : 4451157 occurences
8 : 4450771 occurences
9 : 4455972 occurences

C'est bien partie...
Je repasserai plus tard. Je crois que tout le monde a compris; BlackGoddess en a fait la preuve.

Tu ne trouves pas que la ressemblance est frappante ?
http://forum.hardware.fr/forum2.ph [...] =0&subcat=
 
(lien corrigé)

et comment tu fais pour valider que les resultats sont corrects si tes 5000000 valeurs de départ sont aléatoires? ^^

el muchacho> Le problème est quand même différent puisque l'on ne compte pas l'occurence des nombres, mais des chiffres.
J'en avais un autre dans l'idée, mais je voulais faire simple et proche de ce qui avait déjà été fait. Au prochain, je poserais mon idée. Simple mais avec un très fort potentiel d'analyse.
 
the real moins moins> La valeur de départ est de 0 (lValue=0 dans le for).

J'pige pas en quoi la valeur va être aléatoire, perso
Elle est 0 au début. OK. Tout ce que tu fais ensuite c'est des opérations dessus, donc tu finiras avec des constantes fixes et pas aléatoires, non ?
(ce que je veux dire c'est : pourquoi pas faire un bête rand() ?)

Cela permet à tous d'avoir la même série de nombres et une bonne rapidité de fabrication du nombre aléatoire.
Le travail d'analyse peut également inclure la fabrication même de ce nombre aléatoire...

ouais enfin en bref ton input est pas aléatoire du tout

Bon alors comme chu con et que j'voulais absolument de l'aléatoire, voici mes résultats :

Utilisation de la JVM IBM 1.3.0 sur Windows 2000, avec un P4 2.4 GHz (y a plein de progs qui tournent en tâche de fond, j'vais pas vous faire la liste mais entre autres y a un clien DB2 et un serveur WebSphere).
Vala

Os          : Linux Debian testing
Processeur  : Intel(R) Pentium(R) 4 CPU 1.70GHz
Compilateur :  gcc 3.3.4
 
Compilation sans paramètre (taille 12650 octets) :

 
Compilation avec le paramètre "-O3" (taille 12482 octets) :

the real moins moins> C'est le générateur congruentiel de Knutz. Tu trouveras via google plein d'infos sur l'aléatoire. Mais ce n'est pas le sujet ici.
Taiche> Peux-tu ajouter le code du générateur, sinon je ne pourrais pas le prendre en compte. Egalement, c'est 5 millions de répétitions.

 
comment il parle à

Oui mais tu ne l'as pas faut sur une série de 5 000 000 valeurs variant entre 0 et (2^31)-1 ?

on ne teste que la compilation

Ba côté algo, j'vois pas trop c'qu'il y a de si marquant... non ?

Or donc, après un copier/coller d'un code foireux, voici la version "faussement aléatoire" :

Compilation avec jikes 1.21 et l'option -target 1.3.
 
Résultats :

Désolé pour le faux résultat précédent qui était dû à un code foireux

Différence entre mon premier algo et le dernier :
Le source est en C pur sans aucune ligne en assembleur.
 

 
Cible : AthlonXP Barton 12*180/1Go/nForce2 et WindowsXP avec WinAmp en tâche de fond.