Team RC5-72 MacBidouille

[popboy]

Je ne pense pas que ce soit le cas, DNETC me semble plutôt frugal,
d'ailleurs je n'ai pas vu le G5 en 512 pour la comparaison ?

[Héron]

et bien mon meilleurs score sur 24H, si on peut parler de score, avec le dernier client DNETC et un G5 Bi 2Ghz à 512 Mo est de 560 contre 700...
(Ce résultat est réalisé en laissant la main constamment au calcul de la clé RC72)

Ce message a été modifié par Héron - 11 Feb 2004, 21:27.

[popboy]

En tous cas maintenant je sais ou est bipro avec 512k
et la différence n'est effectivement pas négligeable, est-ce la mémoire ?
Je suis incapable de répondre, ce qui est sur c'est que sur mon petit G4 le passage de 512k
à 1,5M n'as pas été spectaculaire, avec dnetc j'entends, pour le reste, miam.

[kakace]

Houlà...
La quantité de mémoire n'influe pas sur les résultats de dnetc. Le cruncher tourne en boucle et la taille du cache L1 est largement suffisante. Si influence il y a, elle est à chercher ailleurs (autres applications, kernel, deamons, etc).
Dans tous les cas, un G5 2GHz peine à fournir 15 MKeys/s, ce qui fait au mieux 304 blocs par jour. 608 pour un dual, donc. Et à moins de diminuer la longueur des pipelines ou d'écrire un nouveau cruncher, il ne peut pas aller plus vite. Autrement dit, un résultat de l'ordre de 560-580 blocs par jour (en utilisation) est tout à fait normal.

[Mathiasr]

Bon le client 488b se lance bien sous 10.1.5, je l'ai pas encore mis en prod, plus le courage ce soir.

En revanche il y a un truc que j'ai pas compris, les options du genre :
-test rc5
-bench rc5
ne produisent aucun calcul :

[localhost:~/rc488b] mathias% ./dnetc -bench rc5

distributed.net client for Mac OS X Copyright 1997-2004, distributed.net
RC5-72 PowerPC assembly by Malcolm Howell and Didier Levet
Enhancements for 604e CPUs by Roberto Ragusa
RC5-72 Altivec assembly by Didier Levet
Please visit http://www.distributed.net/ for up-to-date contest information.


dnetc v2.9007-488-CTR-04013121 for Mac OS X (Darwin 5.5).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/
Using email address (distributed.net ID) '[email protected]'

[localhost:~/rc488b] mathias%

Alors qu'avec ogr ça lance bien l'OGR seul, et sans nom de projet en particulier l'ensemble des calculs.

[caraboud]

J'ai pour ma part demarer mon PC du boulot sur le RC5 MacBidouille ... et je suis surpris des resultats (enfin des previsions de resultats) : sur mon P4 2,4 Ghz a 512 Mo de DDR, il va lui falloir pratiquement 9h pour faire les48 blocks .. ca me parait bizarre non ?

On verra concretement demain mais ca me laisse perplexe ca .. pas vous ?

Ca me parait être une vitesse correcte car si on compare avec mon PC à 350Mhz (AMD K6) qui bombarde royalement 9.5 blocks en 24heures et si on rapportait ce nombre de blocks à la cadence de ton P4, ça donnerait 65 blocks en 24h. Tu es au dessus de presque le double, la cadence me parait correcte.

C'est sûr que si on compare avec mon G4 1.25Ghz qui, en vitesse de pointe donne 256 blocks dans la journée, ça parait faible!

Moi tout pareil !
Au boulot, j'ai une nouvelle bécane : P4 2.8Ghz . Il fait à peine moins que 4 millions de clés.
Par contre, ce qui est étrange, c'est que lorsque j'ai lancé dnetc, il a repéré deux processeurs, alors que je suis certain qu'il n'y en a qu'un !!!! (du coup, je l'ai forcé à ne calculer qu'un seul block à la fois)
Elles ne seraient pas un peu pourries les versions clients PC ?
D'autant que j'ai la dernière : v2.9007-486-GTR-03111106 for win 32

[bananas]

Bon j'ai regarde mes blocks sur 48 heures (depart a 20h21 exactement, arrivee idem 48 h plus tard) : environ 650 blocks/jours ...

Moyenne (quoique variable j'ai vu) 29.22 MKeys

Je suis en 10.3.2 et j'utilise DCnet version beta graphique pour G5 (car j'ai jamais rien pu tirer du terminal, j'y suis allergique ...

Sachant que je n'est pas fait de compression video peandant ces 48 heures .. juste reste ouvert : Mail, Safari, Carracho, AppleWorks 6, de temps en temps Graphics converter et quelques bout de Divx le soir .. rien de plus ..

Cela dit maintenant je reprend un peu l'activite sinon ....

[popboy]

Ce ne serait pas l'hyperthreading qui ressemble à un bipro (de loin) ?
Une sombre histoire de double core qu'un brillant spécialiste
vas nous vulgariser avec talent

Bon il n'y a pas vraiment de double core, mais ça parait efficace.
Tu aurais tort de ne pas t'en servir.

Hyperthreading

P.S. il serait intéressant que tu nous livres tes impressions avec et sans.

Ce message a été modifié par popboy - 12 Feb 2004, 12:04.

[rhapsody]

y a t il un proxy disponible pour l equipe macbidouille sur un port facile (pour les firewall genre 80 ou 21) car j ai un bon nombre de machines qui attendent de réussir à sortir leurs résultats. Le problème étant que je n'ai pas la possibilité d'en installer un à domicile.
D'avance merci.

[nektarfl]

Il me semble avoir vu que ce sujet a déjà été traité plus haut (dans l'une des 36 pages précédentes, et il y a une option qui permet d'envoyer au format html pour que le serveur ne bloque pas l'accès (je l'avais mis en mémoire, mais sans l'orinateur qui m'a été volé, je ne l'ai plus!) mais c'est entre septembre et décembre de l'an dernier. Je m'étais promis de faire l'action car mes NeXT ne trouvent pas l'accès au net!

[kakace]

Bon le client 488b se lance bien sous 10.1.5, je l'ai pas encore mis en prod, plus le courage ce soir.

En revanche il y a un truc que j'ai pas compris, les options du genre :
-test rc5
-bench rc5
ne produisent aucun calcul :

Que le client se lance bien sous 10.1.5 est déjà une bonne nouvelle (je n'ai que Panther...). L'option RC5 correspond au RC5-64 qui est désactivé. Il est donc normal que le client ne fasse rien, bien qu'un message d'erreur serait le bienvenu...
"-test rc5-72" ou "-bench rc5-72" devrait donner de meilleurs résultats

[bananas]

Moi etant toujours allergique au terminal (sinon je serais sous DOS ) est ce que je peux copier le fichier de la 488b dans le paquet du progiciel Dnetc G5 beta ? J'ai a y gagner ? ca pose des problemes ?

Ce message a été modifié par bananas - 12 Feb 2004, 18:58.

[Edge@51]

Normalement ça marche. C'est comme ça que je met à jour DnetcX depuis 6 mois et pas de problèmes (mais sous G3). Fais une copie et essaie, tu ne risque rien

[bananas]

Et comment on sait quelles seront les ameliorations ?

[caraboud]

Ce ne serait pas l'hyperthreading qui ressemble à un bipro (de loin) ?
Une sombre histoire de double core qu'un brillant spécialiste
vas nous vulgariser avec talent

Bon il n'y a pas vraiment de double core, mais ça parait efficace.
Tu aurais tort de ne pas t'en servir.

Hyperthreading

P.S. il serait intéressant que tu nous livres tes impressions avec et sans.

Il semble que tu ais raison !
Il me reste 16 blocks à calculer.
Avec l'option un seul processeur, il me donne un temps restant de 2h24
Avec deux processeurs, il me donne 1h00 !
Etonnant non !
(Je surveille ça de près qaund même)

[Héron]

Bon j'ai regarde mes blocks sur 48 heures (depart a 20h21 exactement, arrivee idem 48 h plus tard) : environ 650 blocks/jours ...

Moyenne (quoique variable j'ai vu) 29.22 MKeys

Je suis en 10.3.2 et j'utilise DCnet version beta graphique pour G5 (car j'ai jamais rien pu tirer du terminal, j'y suis allergique ...

Sachant que je n'est pas fait de compression video peandant ces 48 heures .. juste reste ouvert : Mail, Safari, Carracho, AppleWorks 6, de temps en temps Graphics converter et quelques bout de Divx le soir .. rien de plus ..

Cela dit maintenant je reprend un peu l'activite sinon ....

Franchement, je suis étonné car pour ma part sans rien lancer d'autres, mon BiPro G5 2Ghz sous 10.3.2 mais avec "que" 512 Mo de RAM, je fais 560 Blocks/24H...

[bananas]

Voila ca que me dit le client :

[Feb 18 15:15:18 UTC] RC5-72: Completed CA:813B5411:00000000 (1.00 stats units)
0.00:04:49.75 - [14,822,878 keys/s]
[Feb 18 15:15:18 UTC] RC5-72: Loaded CA:813B5414:00000000:1*2^32
[Feb 18 15:15:18 UTC] RC5-72: Summary: 449 packets (449.00 stats units)
0.18:15:09.37 - [29.34 Mkeys/s]
[Feb 18 15:15:18 UTC] RC5-72: 11 packets (11.00 stats units) remain in
buff-in.r72
Projected ideal time to completion: 0.00:26:29.00
[Feb 18 15:15:18 UTC] RC5-72: 37 packets (37.00 stats units) are in
buff-out.r72

[Feb 18 15:15:34 UTC] RC5-72: Completed CA:813B5413:00000000 (1.00 stats units)
0.00:04:50.13 - [14,803,719 keys/s]
[Feb 18 15:15:34 UTC] RC5-72: Loaded CA:813B5415:00000000:1*2^32
[Feb 18 15:15:34 UTC] RC5-72: Summary: 450 packets (450.00 stats units)
0.18:15:25.48 - [29.39 Mkeys/s]
[Feb 18 15:15:34 UTC] RC5-72: 10 packets (10.00 stats units) remain in
buff-in.r72
Projected ideal time to completion: 0.00:24:05.00
[Feb 18 15:15:34 UTC] RC5-72: 38 packets (38.00 stats units) are in
buff-out.r72

[Feb 18 15:20:09 UTC] RC5-72: Completed CA:813B5414:00000000 (1.00 stats units)
0.00:04:50.03 - [14,808,874 keys/s]
[Feb 18 15:20:09 UTC] RC5-72: Loaded CA:813B5417:00000000:1*2^32
[Feb 18 15:20:09 UTC] RC5-72: Summary: 451 packets (451.00 stats units)
0.18:19:59.95 - [29.34 Mkeys/s]
[Feb 18 15:20:09 UTC] RC5-72: 9 packets (9.00 stats units) remain in
buff-in.r72
Projected ideal time to completion: 0.00:21:40.00
[Feb 18 15:20:09 UTC] RC5-72: 39 packets (39.00 stats units) are in
buff-out.r72

[Mathiasr]

[Feb 18 15:15:34 UTC] RC5-72: Completed CA:813B5413:00000000 (1.00 stats units)
                      0.00:04:50.13 - [14,803,719 keys/s]

Formule approximative, pour arriver au nombre d'unités par jour :

nombre de processeurs x clefs par seconde / 49 710

ici :
2 x 14 803 719 / 49 710 = 595,60 unités par jour

un G3 à 480 MHz :
1 x 1 558 703 / 49 710 = 31,35 unités par jour

un P4 à 2,4 GHz :
1 x 3 322 619 / 49 710 = 66,84 unités par jour

Une unité statistique contient 2^32 clefs (ce qui en fait 4 294 967 296), il faut donc environ 290 secondes (4 294 967 296 / 14 803 719) pour faire une unité (4 minutes et 50 secondes, comme l'indique le client).
Dans une journée (86 400 secondes) chaque processeur peut tester un peu moins de 298 unités (86 400 / 290), donc avec deux processeurs on arrive dans les 595 unités par jour (si la machine ne fait rien d'autre).

Le 49 710 provient de 2^32 / 86 400

[Rabaothewarri]

Le point sur la situation aujourd'hui…

Ecart 32 750 581
Depuis le 12/12/03, il s'est réduit de 2525423.
Soit près de 1250000 par mois.

A ce rythme, en 27 mois, notre Os est en seconde place…

[Gotchi]

dites, je viens pour le boulot d'acheter deux nouveaux PC : des P4 Bi proc 2.6GHz.
je les ai installé cette après midi, sous Win XP Pro, toutes mises à jour faites, et je viens de télécharger les derniers clients pour ces ordis.

et je ne comprends pas pourquoi ils tournent en moyenne à 900 000keys/secondes/processeur
ça fait très peu, puisque chaque processeur calcule ainsi un bloc/heure.

quelqu'un a une explication? (d'autant plus bizarre que le vieux PIII 600 MHz à côté fait mieux)

[popboy]

Pas de réponse mais plusieurs questions, sur PC tu as aussi toutes ces gentilles
petites lignes qui te disent quel est le processeur, sa vitesse, le nombre et la version et.c?
l'hyperthreading se met-il tout seul à l'instalation ?
Ton P III 600 est aussi sous XP ? Si oui, la vitesse est-elle correcte (j'en ai un démonté à la cave que je pourrais utiliser ).

P.S. à mon avis il faut éviter que kacace se mette à tripatouiller le client pour PC
ça pourrait nous faire mal.

Ce message a été modifié par popboy - 20 Feb 2004, 18:09.

[Gotchi]

le PIII est sous 2000
pour les 2 P4 : le client permet de faire des benchs pour les différents cores, et le core qui me donne (en bench) les meilleurs résultats est bien celui qui est sélectionné par le client pour les calculs. Donc la sélection du core me parait bonne.
de plus, le client me dit bien qu'il a détecté un système bi proc, à base de P4.

en fait, lorsque je fais des benchs, tout va bien. Pour le core sélectionné, les benchs indiquent une vitesse de 3.7Mkeys/sec, ce qui me parait correct.
mais lorsque le client calcule, les performances s'écroulent à 900 000 keys/secondes.
et ceci pour les deux PC. je ne comprends vraiment rien.

[nektarfl]

et je ne comprends pas pourquoi ils tournent en moyenne à 900 000keys/secondes/processeur
ça fait très peu, puisque chaque processeur calcule ainsi un bloc/heure.

Je suis surpris également car mon PC à 350Mhz tourne à 473,400 key/s, ou alors, il y a quelque chose qui tourne en tâche de fond sur les PC qui les ralentissent (au hasard XP?)

Pour ma part, je viens de rebrancher le MAC, et résultat:

CODE

distributed.net client for Mac OS X Copyright 1997-2003, distributed.net
RC5-72 PowerPC assembly by Malcolm Howell and Didier Levet
Enhancements for 604e CPUs by Roberto Ragusa
RC5-72 Altivec assembly by Didier Levet
Please visit http://www.distributed.net/ for up-to-date contest information.


dnetc v2.9007-486-CTR-03110414 for Mac OS X (Darwin 7.0.0).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/
Using email address (distributed.net ID) 'nektarfl'

[Feb 20 17:26:48 UTC] Connected to euro.v29.distributed.net:2064...            
[Feb 20 17:26:48 UTC] The keyserver says: "This is Cow 2 in Holland !!  
                     Ommmmmmmm"
[Feb 20 17:26:48 UTC] Retrieved project state data from server. (cached)
[Feb 20 17:30:40 UTC] RC5-72: Sent 2862 packets (2862.00 stats units) to se ...
[Feb 20 17:30:40 UTC] Connection closed.
[Feb 20 17:30:40 UTC] Input buffers are full (or projects are closed).
                     No fetch required.

faut pas s'affoler, je ne savais pas combien de temps je resterais déconnecté alors j'avais pris des réserves jusqu'à début Avril :

CODE

[Feb 20 17:37:43 UTC] RC5-72: 11220 packets (11220.00 stats units) remain in
                     buff-in.r72
                     Projected ideal time to completion: 47.15:49:00.00

mais c'est quoi ce "to se ..." à la fin du nombre de blocks? Il va y avoir une vérification dessus? j'ai trop posté d'un coup? je deviens le coupable idéal?
Je ne m'en fais pas trop, car la quantité de blocks que je calcule reste assez stable en moyenne!

Edit: pour enlever les balises caractère gras à 'to se ...' qui ne donnaient pas le résultat escompté

Ce message a été modifié par nektarfl - 20 Feb 2004, 18:51.

[caraboud]

en fait, lorsque je fais des benchs, tout va bien. Pour le core sélectionné, les benchs indiquent une vitesse de 3.7Mkeys/sec, ce qui me parait correct.
mais lorsque le client calcule, les performances s'écroulent à 900 000 keys/secondes.
et ceci pour les deux PC. je ne comprends vraiment rien.

Moi non plus je n'ai pas d'explication, mais ce qui est bizarre, c'est que mon PC P4 2.8 fait les même résultats que toi : En mode simple core, il calcule à 3,7MKeys, et en mode hyper threading, il tombe à 900 000.
Etrange que les résultats soient identiques ? Serait-ce dû à XP ?

[Gotchi]

comment tu fais pour virer le mode HT, afin que je puisse vérifier?

[caraboud]

Dans configure,
tu choisis l'onglet " 3) Performance related options"
et dans " 2) Number of crunchers to run simultaneously ==> -1 (auto-detect)"
tu mets "1" pour le forcer à ne faire qu'un block à la fois.
Et voilà !

[kakace]

popboy: Je ne risque pas de toucher au client PC. J'y suis allergique !
nektarfl : "to se ..." remplace "to server" parce que la ligne est trop longue (plus de 80 caractères).
caraboud/gotchi: L'hyperthreading est de loin moins performant qu'un véritable double CPU. La preuve... Quoiqu'il en soit, ce n'est pas un bug du client.

Au sujet de l'hyperthreading : Si j'ai bien compris (ce que j'ai lu il y a longtemps), le but du jeu consiste à remplir les unités de calcul avec des instructions venant de plusieurs threads, et à dépatouiller tout ça après calcul. Seulement si l'un des threads est suffisament optimisé pour bien exploiter la puissance (toute relative, dans ce cas là) du CPU, l'hyperthreading fait perdre beaucoup de temps (compétition entre threads).
Comme quoi le mieux est souvent l'ennemi du bien

[Mathiasr]

Moi non plus je n'ai pas d'explication, mais ce qui est bizarre, c'est que mon PC P4 2.8 fait les même résultats que toi : En mode simple core, il calcule à 3,7MKeys, et en mode hyper threading, il tombe à 900 000.
Etrange que les résultats soient identiques ? Serait-ce dû à XP ?

C'est normal, non ?
Hyperthreading c'est deux processeurs virtuels qui se partagent les mêmes unités d'exécutions. Ce système est prévu pour maintenir le processeur actif lors des accès en mémoire principale, mais le jeu de données du RC5 est ridiculement petit, tout se passe sur les registres et en cache L1, le flux d'instruction est optimisé pour exploiter au mieux chaque processeur.
Avec HT ça revient à casser le flux d'instruction optimal, en essayant d'en faire passer deux qui se marchent très vite sur les pieds... en voulant accéder aux mêmes unités alors qu'il n'y a pratiquement pas de bulles dans les pipelines, les performances s'effondrent donc.

[Melaurë Curufin]

Le point sur la situation aujourd'hui…

Ecart 32 750 581
Depuis le 12/12/03, il s'est réduit de 2525423.
Soit près de 1250000 par mois.

A ce rythme, en 27 mois, notre Os est en seconde place…

Cool

Sinon merci pour les explications sur les inconvénients de l'hyperthreading pour le RC5. Il va falloir y faire gaffe avec les prochaines générations de PPC.

Ce message a été modifié par Melaurë Curufin - 21 Feb 2004, 20:02.

[Rol@ndB]

juste pour signalé que j'ai fait 1711 blocks et que je suis 6éme aujourd'hui
grace au p'tit iBook qui a fait 1600 blocks mais il a mouliner quelque jours
poue cela.

Ce message a été modifié par Rol@ndB - 21 Feb 2004, 23:32.