puissants les G5?

En fait la premiere fois il a utlisé les résultats de la compilation que tu as mis dans le zip.

Parceque la j'arrive plus à compiler... Même aprés avoir changer le compilo par défaut à gcc 3.1 ???

Il m'indique une erreur sur le fichier main sans me donner son intitulé, ni sa localisation...

Donc je ne peux rien faire... (j'ai redézippé graphes.zip et j'ai forcé cette fois une recompilation propre en effacant les fichiers intermédiaires, et ca m'a fait le même erreur)
 
OK j'ai créé un nouveau projet dans XCode (de type outil C++) et j'ai inclus tes fichiers...

Apres une modif : #include <iostream> transformé en #include <iostream.h> , la comiplation a fonctionné.

Donc voici les résultats de la console avec n=150:


[COLOR=666666]<font class="small">Code:[/COLOR]<hr /><pre>capacite maximale : 696

test Graphe has exited with status 0.</pre><hr /></font>

obtenu en moins de 1 sec.
 
cool, t'as trouvé mon erreur avec GCC3.3! comment as tu eu l'idée de changer ça???

sinon ton n=150 en moins de 1sec est impressionnant... (là mon powermac mettait plus de 5 sec, à l'exécution)

essaye avec 200 pour voir!
 
Une dernière chose : est-ce que ta variable 'n' est le nombre de variables dont tu parles plus haut ?

Parce que dans ce cas, ne devrais-je pas obtenir un calcul beaucoup plus long pour n=150 que pour n=120 ?

Quand je teste avec n=160, j'obtiens effectivement quelquechose de plus long : 23 sec. . La console indique:

[COLOR=666666]<font class="small">Code:[/COLOR]<hr /><pre> capacite maximale : 742 </pre><hr /></font>
Mais avec n=150 c'est irrémédiablement plus court
confused.gif
 
decoris a dit:
cool, t'as trouvé mon erreur avec GCC3.3! comment as tu eu l'idée de changer ça???
Cliquez pour agrandir...

bein je développe moi même, et j'ai deja été confronté au pb
smile.gif


avec n=200 : 76 sec.

et la console : [COLOR=666666] <font class="small">Code:[/COLOR]<hr /><pre> capacite maximale : 857 </pre><hr /> </font>
 
avec n=300 : 7 mns 34 sec.

console : [COLOR=666666]<font class="small">Code:[/COLOR]<hr /><pre> capacite maximale : 1290 </pre><hr /></font>
 
en fait il génère n(n-1)/2 variables. donc c'est normal qu'il y ait un saut à un moment ou un autre... moi c'est entre n=120 et n=150 sur mon PM, et à n=75 sur mon ibook...

en tous cas c'est excellent que tu ais pu le faire avec n=300!!! ça représente un graphe avec 44800 arcs!!!

je vais bien prendre note des résultats, je les mettrai dans mon rapport... je pourrai faire le malin :
L'algorithme s'exécute sur un graphe dirigé composé de plus de 40 000 arcs en un peu moins de 8 min, patata...


n = 300 ça représente plus de 100 000 000 d'opérations!
 
si on n'a plus de nouvelles de klog, c'est qu'il teste avec n=1000... comme le temps a été multiplié par plus de 16 pour passer de 160 à 300, je n'ose pas imaginer le temps nécéssaire...
wink.gif


je vais essayer de voir s'il y a une complexité temporelle bien établie pour pouvoir faire des prévisions sur plus de variables...
wink.gif



edit : pour faire mes calculs, j'ai besoin de plus de tests... tu pourrais encore en faire deux, par exemple avec n=240 et n=280 (ou plus si tu veux....
wink.gif
)
merci bcp en tous cas!
 
decoris a dit:
si on n'a plus de nouvelles de klog, c'est qu'il teste avec n=1000... comme le temps a été multiplié par plus de 16 pour passer de 160 à 300, je n'ose pas imaginer le temps nécéssaire...
wink.gif
Cliquez pour agrandir...

non
smile.gif
je me suis arreté à 300... par contre je viens de désactiver un proc, si les résultats t'intérressent ?
 
En fait il n'y a pas beaucoup de différence :

<ul type="square">
[*]n=120 : entre 7 et 8 sec.
[*]n=150 : environ 1.5 sec.
[*]n=200 : 82 sec.
[/list]

Compte tenu des variations dont tu nous as parlé, et conformément à ce qu'on pouvait attendre, le nombre de procs ne semble pas influencer tes résultats.

En toute logique, il faudrait pour cela que tu fasses du multi-thread.
Si tu as besoin de résultats pour d'autre valeurs de n (&lt;à 300
laugh.gif
) fais moi signe.
 
Pour l'optimisation bipro, ça doit pas être compliqué, il faut juste que tu répartisses tes calculs sur 2 threads ou deux processus.

Donc soit tu regardes du coté des pthreads, soit du coté du fork().
 
me revoila!

j'ai amélioré mon algorithme (en fait il devrait etre plus lent, j'ai supprimé toutes les variations qui pourraient se présenter dues à la génération aléatoire des variables), et j'ai ajouté une fonction qui compte le temps d'exécution tout seul!

le résultat affiché sera maintenant, par exemple :

nombre de noeuds : 100
nombre de variables : 4950
exécution...
calcul terminé :
capacite maximale : 537
temps écoulé : 48 secondes


y-a-t-il d'autres volontaires pour tester?


edit : je viens de tester 300 noeuds sur mon Powermac 1GHz :

nombre de noeuds : 300
nombre de variables : 44850
exécution...
calcul terminé :
capacite maximale : 1589
temps écoulé : 830 secondes

Graphes has exited with status 0.

un peu moins de 14 min... grosso modo, je suis à peine deux fois moins rapide qu'un Bi 1,8GHz!
up.gif
 
Test géant :

nombre de noeuds : 450
nombre de variables : 101025
exécution...
calcul terminé :
capacite maximale : 2430
temps écoulé : 5281 secondes

nombre approximatif d'opération : 275 000 000!!!!

ps : ça me parait vraiment un bon test de la puissance pure d'un processeur : cet algorithme est basé sur un ensemble d'opération très simples, qu'il faut exécuter un très grand nombre de fois. Il n'est optimisé pour aucune machine, et donc on peut aussi bien le tester sur un Mac que sur un PC...
je vais essayer de faire des tests sur des PC pour comparer...


PS : existe t il un fonction C ou C++ qui teste le nombre exact d'opération d'un algorithme?
 

Sujets similaires

R
Conseil Achat PowerMac G5
Réponses
6
Affichages
1K
Classic Mac
Webmr
Webmr
M
G4+, Athlon, Motorola, AMD...
Réponses
6
Affichages
4K
Classic Mac
Ariioehau
A
Haut Bas
Back