Team RC5-72 MacBidouille

[Triceratops]

Mar 14 01:46:33 UTC] RC5-72 #a: Completed CB:3BE5ECF7:00000000 (1.00 stats ...
0.00:05:32.51 - [12,916,653 keys/s]
[Mar 14 01:46:33 UTC] RC5-72 #a: Loaded CB:3BE5ECFA:00000000:1*2^32
[Mar 14 01:46:33 UTC] RC5-72: Summary: 737 packets (737.00 stats units)
1.09:27:12.08 - [26.25 Mkeys/s]
[Mar 14 01:46:33 UTC] RC5-72: 87 packets (87.00 stats units) remain in
buff-in.r72
Projected ideal time to completion: 0.03:51:16.00
[Mar 14 01:46:33 UTC] RC5-72: 4 packets (4.00 stats units) are in
buff-out.r72
.....10%.....20%.....30%.....40%.....50%....a60%.b/

bon, ça donne du 26.25 Mkeys/s pour mon Dual 2 GHz Power PC G5, avec 1 GB de RAM... donc, pas mieux...

[PO_]

dans la nuit, donc en ne faisant que cela, Le G5 a eu une moyenne de 29,54, sur 228 Packets. Pour la même période de temps, le G4 a craqué 190 clés avec une moyenne de 26,49.

Au passage, j'ai fait mon entrée dans la team MacBidouille avec 836 blocs.

[popboy]

Bravo, mais le G4 fais plus de bruit et doit dégager une chaleur folle, non ?

[PO_]

Le G4 fait un bruit monstrueux, quasi intolérable. D'ailleurs, hier, je l'ai coupé toute la journée car j'avais à bosser sur ma compta .

C'est le G5 qui chauffe le plus (mais silencieusement), il est sous mon bureau, et bien qu'il ne soit pas collé contre le fond (pour la circulation de l'air), je sens beaucoup d'air chaud qui remonte de sous le bureau .... J'ose pas imaginer avec un Quad ...

Bon, les envois de blocs d'ujourd'hui seront meilleurs car je n'ai pas été là et les deux machines ont bien gratté (j'en suis à 860 blocs ) Je ne sais pas à quelle heure j'enverrais mes derniers blocs ...

[kakace]

dans la nuit, donc en ne faisant que cela, Le G5 a eu une moyenne de 29,54, sur 228 Packets.

Voilà une performance tout à fait normale, pour ne pas dire optimale. L'efficacité d'un G4 s'établie à 10,4 (par GHz), contre 7,5 pour un G5. Il suffit de multiplier par la fréquence du processeur et le nombre de coeurs/CPUs pour avoir une idée de la performance globale :
2 G4 1.25 = 10,4 * 1,25 * 2 = 26 MKeys/s
2 G5 2.7 = 7,5 * 2,7 * 2 = 40,5 MKeys/s
1 G5 1.8 = 7,5 * 1,8 = 13,5 MKeys/s

Pour corriger ce qui a été dit un peu plus haut, l'efficacité du G5 est moindre parce que ses "pipelines" sont plus longs, ce qui introduit des cycles d'attente entre deux instructions qui dépendent l'une de l'autre (et donc une perte de temps). En l'occurence, le G5 est utilisé à 60-70% de ses capacités, contre 100% pour le G4.

[patpan]

Voilà une performance tout à fait normale, pour ne pas dire optimale. L'efficacité d'un G4 s'établie à 10,4 (par GHz), contre 7,5 pour un G5. Il suffit de multiplier par la fréquence du processeur et le nombre de coeurs/CPUs pour avoir une idée de la performance globale :
2 G4 1.25 = 10,4 * 1,25 * 2 = 26 MKeys/s
2 G5 2.7 = 7,5 * 2,7 * 2 = 40,5 MKeys/s
Pour corriger ce qui a été dit un peu plus haut, l'efficacité du G5 est moindre parce que ses "pipelines" sont plus longs, ce qui introduit des cycles d'attente entre deux instructions qui dépendent l'une de l'autre (et donc une perte de temps). En l'occurence, le G5 est utilisé à 60-70% de ses capacités, contre 100% pour le G4.

Merci kakace pour ces précisions

parfaitement en accord avec toi ( je commence à avoir un peu d'expérience sur les performances des divers processeurs )

Le "pourquoi..." devient soudain beaucoup plus clair et irréfragable!

à tous : poursuivons notre effort

Cordialement

Pat

Ce message a été modifié par patpan - 14 Mar 2006, 22:29.

[PO_]

dans la nuit, donc en ne faisant que cela, Le G5 a eu une moyenne de 29,54, sur 228 Packets.

Voilà une performance tout à fait normale, pour ne pas dire optimale. L'efficacité d'un G4 s'établie à 10,4 (par GHz), contre 7,5 pour un G5. Il suffit de multiplier par la fréquence du processeur et le nombre de coeurs/CPUs pour avoir une idée de la performance globale :
2 G4 1.25 = 10,4 * 1,25 * 2 = 26 MKeys/s
2 G5 2.7 = 7,5 * 2,7 * 2 = 40,5 MKeys/s
1 G5 1.8 = 7,5 * 1,8 = 13,5 MKeys/s

Pour corriger ce qui a été dit un peu plus haut, l'efficacité du G5 est moindre parce que ses "pipelines" sont plus longs, ce qui introduit des cycles d'attente entre deux instructions qui dépendent l'une de l'autre (et donc une perte de temps). En l'occurence, le G5 est utilisé à 60-70% de ses capacités, contre 100% pour le G4.

Merci de ces précision.

Je ne sais si tu t'en souviens, mais nous avions eu un échange de message intéressant (pour moi) sur fcsm, au moment où tu as contribué (ou développé entièrement, je ne me souviens pas) module optimisé pour G4. La différence était foudroyante par rapport au précédent. Tu m'avais par la suite appris que contrairement à mes espérances, le G5 ne serait peut-être pas aussi bon que le G4 pour ce genre de calcul. Tu avais raison, hélas.

Dommage que tu n'aies pas pu optimiser le code pour le G5 de manière aussi magistrale que pour le G4.

Ce qui me déçoit également c'est qu'à priori, les coreduo, ne sont pas non plus des foudres de guerres pour le RC-5, alors qu'ils ont l'air intéressant dans d'autres domaines.

Ce qui est marrant, c'est que pour le RC5, un cluster de mac mini, serait infiniment plus intéressant en terme de rapport performance-coût qu'un cluster de G5 (même de quads)

PS : à noter qu'après maintenant 2000 blocs de calculés, (environ moitié-moitié sur chaque machine), je n'ai quasiment aucun décallage dans les crunchers de chacun des processeurs : moins de 2 % sur le G5, et 6 % sur le G4

Ce message a été modifié par PO_ - 15 Mar 2006, 00:03.

[Triceratops]

J'esaye de comprendre (pour un dinsosaure comme moi, c'est dur).
Quand même, un truc m'échappe:

PO arrive a 29.54 Mkey/s ce qui est très proche du théorique avec un G5 2x2GHz (d'après kakace, 7.5 * 2 * 2 = 30)

Avec une machine similaire (à RAM et OS près), je n'atteind même pas les 26.50 Mkey/s, soit 10% de moins, y compris lorsque je laisse tourner la bécane toute la nuit.

D'ou peux venir cette différence?

[kakace]

Avec une machine similaire (à RAM et OS près), je n'atteind même pas les 26.50 Mkey/s, soit 10% de moins, y compris lorsque je laisse tourner la bécane toute la nuit.

D'ou peux venir cette différence?

Quelque chose d'autre consomme de la puissance, tout simplement. Les petits ruisseaux faisant les grandes rivières, il se peut que plusieurs applications laissées ouvertes mais non utilisées consomment collectivement suffisament de puissance pour diminuer la performance du moteur RC5. En pratique, un simple coup d'oeil au moniteur d'activité permet de lever le doute : sur un bi-pro, dnetc doit consommer environ 190% de temps CPU (variations de 185 à 195%).
La RAM et l'OS n'ont aucune incidence.

[PO_]

Par contre, il y a un gros problème avec le client RC 5 actuel :

Quand on encode du MP3 ou de l'AAC, ça fait chûter d'environ 20 % les performances des "crunchers"

[patpan]

Par contre, il y a un gros problème avec le client RC 5 actuel :
Quand on encode du MP3 ou de l'AAC, ça fait chûter d'environ 20 % les performances des "crunchers"

Bonsoir PO_ ,
cela est normal, il faut bien que les processeurs travaillent à l'encodage!

le client dnect prend simplement les cycles processeur(s) non utilisés
même si tu lui alloues une priorité complète, tu verras que ton encodage sera plus lent - et à la fin cela reviendra au même -.

Cordialement

Pat

[Guest_anonym_5886c6_*]

un nouveau parmis la team MB
Zephir

je tourne sur un PM G5 de 2x2,3 Ghz
je sétisais depuis loooongtemps sur mes pc puis passé sur BOINC et bosse sur d'autres projets.
Le G5 déchirait absolument tout sur les bench de boinc avec le bench optimisé G5/altivec par la team MacNN mais j'ai étais très déçu par mes résultats très moyens en calcul réels.

résultat, je suis parti. Me voila donc sur RC5. J'ai bien suivi les indications pour configurer le client et je viens malheureusement de voir que ici aussi la puissance du G5 n'est pas utilisé à fond
franchement je comprends pas. certes les PPC sont peu nombreux dans le monde face aux x86 mais dans ce domaine particulier ils ont un réel avantage grace à cet altivec. Alors pourquoi les programmeurs de softs de calculs partagés ne poussent-ils pas l'optimisation à fond ?

On nous demande de participer et je le fais avec plaisir mais on pourrait s'attendre à ce que les clients soient à la hauteur

Ce message a été modifié par anonym_5886c6 - 17 Mar 2006, 02:42.

[popboy]

Gaffe, Kakasse pourrait t'entendre

Salut à toi nouveau cruncher
Si j'ai bien compris, c'est structurel ce n'est pas le code qui n'est pas optimisé,
bien au contraire les résultats avec des G4 sont fulgurants.
Non, ce seraient plutôt les processeurs qui sont moins altivec.

Mais regarde dans le sujet il en a été question ces derniers temps

[PO_]

Par contre, il y a un gros problème avec le client RC 5 actuel :
Quand on encode du MP3 ou de l'AAC, ça fait chûter d'environ 20 % les performances des "crunchers"

Bonsoir PO_ ,
cela est normal, il faut bien que les processeurs travaillent à l'encodage!

le client dnect prend simplement les cycles processeur(s) non utilisés
même si tu lui alloues une priorité complète, tu verras que ton encodage sera plus lent - et à la fin cela reviendra au même -.

Cordialement

Pat

rhôôô,, l'aut', hé, comment qu'il me prend pour une buse

Je sais bien tout ce que tu me dis : y a qu'à voir les smileys que j'avais mis

C'était juste un clin d'oeil, comme quoi on se prend au jeu ...

[kakace]

Alors pourquoi les programmeurs de softs de calculs partagés ne poussent-ils pas l'optimisation à fond ?

C'est optimisé à fond pour les G3/G4. Pour les G5, le code devient tellement complexe que personne n'a pu proposer mieux jusqu'à maintenant, moi le premier, et pourtant je sais ce qu'il faudrait arriver à faire. La difficulté, c'est de trouver la motivation et la patience pour passer des centaines d'heures à écrire et re-écrire du code jusqu'à ce que tout soit parfaitement synchronisé.

[popboy]

Ah, donc le G5 n'est pas que mauvais mais à combien estimes tu le gain potentiel
en pourcent ? En d'autres termes cela en vaut-il la peine pour un processeur dont le futur
est pour le moins compromis.

P.S. je n'ai pas encore mis dans mon profil que j'ai un G5 donc ça m'intéresse directement.

Ce message a été modifié par popboy - 17 Mar 2006, 17:42.

[Guest_anonym_5886c6_*]

raaa un G5 moins altivéqué que les G4 je raiiive
m'enfin, je laisse tourner quelques jours et je verrai...

[kakace]

Ah, donc le G5 n'est pas que mauvais mais à combien estimes tu le gain potentiel
en pourcent ?

30 pourcents minimum. Autrement dit, les performances d'un G5 sont au 2/3 de ce qu'elles pourraient être.

[popboy]

Ah !! je ne pensais pas autant, tu cherches un béta testeur ? Tu veux une (centaine de) boîte (s) de chocolats

Autrement dit ce serait au moins aussi rapide qu'un G4 voire plus, dommage.

Ce message a été modifié par popboy - 18 Mar 2006, 18:03.

[PO_]

Impossible, d'accéder aux stats ... chez vous aussi ?

[nektarfl]

Impossible, d'accéder aux stats ... chez vous aussi ?

Il me semble effectivement que chez moi aussi, ça ne passe pas!

[PO_]

c'est chiant, je notais scrupuleusement, tous les jours, les scores respectifs de MacBid et de XLR8, ....

[Mathiasr]

En d'autres termes cela en vaut-il la peine pour un processeur dont le futur est pour le moins compromis.

Je pense que dans 2 ou 3 ans il y aura encore des G5 en service, et qu'on aura probablement pas fini le RC5-72. Par ailleurs, l'implémentation pour le G5 pourrait servir aux machines IBM et pour le POWER6.

Ce message a été modifié par Mathiasr - 25 Mar 2006, 17:50.

[popboy]

Ce matin j'avais accès, mais effectivement il y a problème...
L'administrateur de Decibel étant en Belgique il faut être patient.

[Triceratops]

20h35 à Toronto: toujours pas de stats...

[popboy]

D'après le "plan" d'aujourd'hui c'est (encore) un disque qui à "claqué", il devrait être changé cette semaine encore.
Profitons de la pénombre statistique pour nous glisser subreptissement devant nos adversaires

Ce message a été modifié par popboy - 28 Mar 2006, 21:27.

[patpan]

D'après le "plan" d'aujourd'hui c'est (encore) un disque qui à "claqué", il devrait être changé cette semaine encore.
Profitons de la pénombre statistique pour nous glisser subreptissement devant nos adversaires

Salut popboy,

Ah!, je vois que le " Lac " frisonne !

Pas trop de coups de vent ?

C'est vrai, manger un cornet sur un vélo, cela n'est pas chose évidente!

Restons sérieux, il ne s'agit d'abord pas de grignoter des places, mais de ne pas perdre les nôtres !

Bon, je sors!

Pat

[popboy]

Attention cher patpan tes positions sécuritaires pourraient être mal interprètées

C'était surtout sur mon guidon que mes sachets de courses étaient pendus,
sache que je ne mange pas mes cornets mais je les utilises pour les déchets,
mais parlons nous de la même chose

Toujours pas de stats grignottons pour ne pas nous faire grignotter.

[patpan]

Attention cher patpan tes positions sécuritaires pourraient être mal interprètées
C'était surtout sur mon guidon que mes sachets de courses étaient pendus,
sache que je ne mange pas mes cornets mais je les utilises pour les déchets,
mais parlons nous de la même chose
Toujours pas de stats grignottons pour ne pas nous faire grignotter.

Incroyable popboy tu tombes dans cet abus de langage de ma part !
Yeah!, depuis 68, j'ai effectivement des "positions sécuritaires",
et actuellement nous subissons

Bien à toi, et gardes bien ton guidon en main ferme!

'Toujours pas de stats grignottons pour ne pas nous faire grignotter.'

@ + vilain cornet

Très amicalement

Pat
( désolé pour tous les adeptes de dnetc, mais il faut savoir ce qu'est un cornet outre Lac! )

[Triceratops]

Aaaaaah les stats sont revenues!
Pas de gros changements: Le Pommier (MacBidouille) toujours 5ème, derrière xlr8yourmac. C'est popboy qui va être déçu. Mais bon, y-a pas l'feu au Lac.

PS: le cornet, en plastique ou en papier?