Reprise du message précédent :
Juste une précision.
Tetedeiench ne gerait et ne developpait "que" le soft. Il a eu l'idée de la BDD et du site car il trouvait cela complémentaire au soft.
Donc rien que le soft demande enormément de boulot.

J'ai aussi commencé un bout de code multi-threadé avec une recherche sur les nombres premiers sur plusieurs thread et des transferts mémoire utilisant aussi le sse pour faire chauffer le proco avec un cycle de burn alternant sur les deux cpu puis les deux en meme temps,mais faudra attendre encore un peux..  je code en .net

Va falloir refaire un autre Topic dédié alors
Quand ce sera prêt !

Ce qui m'a dégouté, en fait, c'est le taff. Avant, lorsque j'ai lancé le projet, j'avais guère que cours. Ayant la chance d'avoir une excellente mémoire et de pouvoir apprendre rapidement, je suivais en cours ( pas de PC ), et hop, rentré chez moi, je pouvais coder, sans souci.
 
Maintenant, le problème, c'est que j'ai un taff. Qui dit taff dit 9/10h / jour devant un PC a bosser. OCCT est devenu plus un boulot qu'un passe temps. Qui voudrait bosser 50 heures par semaine et ramener du boulot chez soi ? Pas moi en tout cas  
 
la voilà la vraie raison de mon abandon d'OCCT. Le projet m'intéresse toujours... j'ai toujours envie de le faire avancer. mais le dual core a ruiné beaucoup de projets, vu la masse invraisemblable de travail derrière pour le supporter.
 
J'ai toujours dans mes cartons de m'y mettre un jour... mais je n'ai déjà que très peu de temps pour mes loisirs, il m'est très difficile d'arriver à caser OCCT... je sais c'est nul
 
ITM, je te souhaite bien du courage... que tu fasses quelque chose qui fasse chauffer plus qu'OCCT n'est pas difficile.... car OCCT vérifie les erreurs.
 
La détection est un double tranchant. D'un coté tu détectes les erreurs, ce qui est très bien, d'un autre coté il tu perds en perfs ( en introduisant des embranchements), donc en chaleur sur le core...
 
Bref.
 
je ne donnerai pas le code source d'OCCT. D'un coté parce que si le coeur me reprends, je recommencerai à taffer dessus, et je veux pas des versions XXXYYYZZZ fleurissant à droite à gauche... Je veux garder le contrôle là dessus, car je veux m'assurer que je sais ou c'est utilisé, dans quel cas, comment, et par qui. Suffit de voir le vampirisme des codes livrés en open source pour se rendre compte que bouaif... je veux que ca profite à des gens, mais à des gens qui utilisent la chose intelligemment. GPL, c'est bien beau, mais ca protège pas bezef.
 
Enfin voilà où en est OCCT. Le projet est toujours là, c'est toujours mon bébé, mais difficile de travailler dessus. Je suis super content d'être arrivé là, reste à trouver l'idée d'aller au delà ! Et pour ca... spa gagné.

donc si je te suis bien ,on ne peut pas tester le dual core avec lui ?

 
Tu me suis bien. Le faire revient à foutre en l'air la détection d'erreur, grosso merdo. Ca devient aléatoire, détectera des erreurs où il n'y en a pas, etc.

 
L'hyperthreading n'a pas beaucoup d'intérêt pour un programme comme OCCT. Non seulement ce serait plus difficile, mais en plus, l'intérêt est quasi nul...

 
 
t'as déja regardé des progs alternatif comme s&m ? il gere le dual core en full a 100% chacun , mais a savoir si c'est 9% fiable   , je sais que sur mon x2 a une freque"nce de 2.7ghz ca freez et a 2.6 ca passe

Bah sinon suffit de faire tourner 2 Prime95 en meme temps pour tester l'oc d'un dual-core c'est bon ?

Non. Perso ça tient 15 heures à 2.7GHz, que ce soit en blend, en small ou en large, et pourtant j'ai des erreurs à SETI au bout de 2 ou 3h maxi.

ca vaudarit peut etre le coup de creer un nouveau topic , soit ici , soit dans prog ?

 
Non, malheureusement. Prime95 n'est pas encore dual core, et pour lui aussi tu dis adieu à la fiabilité de la détection d'erreurs.

Je comprends pas pourquoi  

moi non plus...
 
le gros intérêt de OCCT, c'est quand même la détection d'erreur, ce serait dommage de s'en passer.

Ce que je comprend pas c'est le fait de lancer 2 Prime95 nous fait perdre la fiabilité de la détection d'erreur.

moi non plus puisque lorsque l'un des procs (physique ou logique quand HT) plante, on a bien une erreur de prime95...

Je comprends pas pourquoi, mais je l'ai expérimenté (cf mon post plus haut).

je ne pense pas que cela soit uniquement sur les dual core qu'il peut y avoir des surprises.
Dans mon cas(3700+) : Memtest86+, OCCT et Prime sans problème, et des ralentissements anormaux avec 3Dmark06.
 
En fait, il semble que j'avais dépassé les limites du controleur mémoire ou de la mémoire... en désynchronisant plus la mémoire, c'est redevenu normal.

je pense que c'est du au fait que ces logiciels commencent a etre ancien et ne gerent pas toutes les nouvelles capacités des processeurs
il est possible qu'un processeur soit stable pour certaines application mais sur d'autres il peut faire des erreurs
si les logiciel ne teste pas toutes les utilisations possibles d'un proco, on ne pas etre sur de sa totale stabilité

Là on parle uniquement du passage monocore -> dualcore.
Si Prime95 est fiable pour tester un A64, pourquoi 2 Prime95 sur un dualcore perdrait toute fiabilité quant à la détection des erreurs ?

je sais pas mais regarde l'expérience de asmomo

Je sais bien mais tetedeiench semblait savoir pourquoi. Et c'est ça qui m'interesse.

J'aurai besoin de volontaires pour tester ce petit prog qui détermine la fréquence du CPU :
http://olivier.fouge.free.fr/OCCT/CPU_Frequency.zip
 
C'est simplement pour déterminer quelle méthode est la meilleure (toute basée sur le RDTSC). En théorie, il faut que ce soit le plus proche de la dernière (frequence_10sec).
Chez moi, dans l'ordre (du + proche au + éloigné ) :
1) 500k1, 500k3
2) 500k2, 500k4
3) 128ms
 
Ce qui m'interesse en particulier, ce sont les CPU avec C&Q ou surtout avec l'EIST.
Normalement toutes les valeures sont bonnes et très proches les unes des autres. Si ce n'est pas le cas, dites le moi.
 
Merci

J'ai un message d'erreur qui me dit que la configuration de l'appli est incorrecte.

T'es sous Windows 32bit ?
J'ai compilé avec VS 2005 et j'ai le Framework 2.0
 
edit: retest, j'ai ajouté une DLL dans l'archive

 
idem meme avec la dll

Je crois que je vais repasser tout ça sous DevC++.
Quelle version de votre OS et de votre Framework ?
 
edit: ça commence bien

win xp pro sp2 à jour
framework 1.1

Sous Visual2005 (avec DLL) :
http://olivier.fouge.free.fr/OCCT/ [...] cy_VS5.zip
Sous Dev-C++ 5 :
http://olivier.fouge.free.fr/OCCT/ [...] DevCPP.zip
 
edit: a tous les coup VS2005 passe par le Framework 2.0 meme pour du mode console

 
oui pareil au 1er
 
le 2ème fonctionne parfaitement  

Mes résultats avec l'archive DevC++:
 
500k1: 2506.651
500k2: 2502.969
500k3: 2504.945
500k4: 2508.247
128ms: 2504.784
10sec: 295.458
 
CPU: Opteron 165@313*8, C&Q désactivé
 
A titre de comparaison: CPU-Z me donne: 2504.8

[DALTON]Joe> Tu peux me donner tes résultats ?
 
lombric> En lançant plusieurs fois, ces résultats sont grosso modo les même ?
10sec: 295.458 ???

moi j'ai :
2492.972
2492.941
2492.971
2492.999
2492.918
2492.968
 
avec un a64 2800+ @ 9*277 (cpu-z me donne une fréquence qui oscille entre 2492.9 et 2493.1)

Il y a très peu de variations, comme chez moi. C'est pour ça que le cas de lombric m'interesse plus
 
tester cette version pour ceux qui ont un résultat anormal au frequence_10sec :
http://olivier.fouge.free.fr/OCCT/CPU_Frequency3.zip

Deuxième essai:
 
k1: 2507.313
k2: 2502.953
k3: 2504.960
k4: 2508.442
128: 2504.761
10: 295.461
 
toujours 295mhz pour la dernière mesure, elle s'affiche quelques secondes plus tard que les autres et je ne m'explique pas cette valeur.
 
Troisième essai:
 
k1: 2507.331
k2: 2503.044
k3: 2504.955
k4: 2510.138
128: 2504.771
10: 295.464
 
EDIT: avec la version 3, la troisième valeur 10sec est la bonne.

Merci, peux-tu me redonner une série de résultat avec la 3ème valeur de 10sec ?

Hop,
 
1er essai:
 
2504.810
 
2ème:
 
2504.810
 
3ème:
 
2504.810
 
Perfect chez moi!

10sec sert de référence chez moi et le but est de comparer les autres (500k1, 500k2, 500k3, 500k4 et 128ms) pour voir lequel s'en rapproche le plus.

J'ai gardé  la 3ème formule de calcul qui ne bug pas chez lombric, gardé la méthode 500k3 + 2 variante de la 128ms.
http://olivier.fouge.free.fr/OCCT/CPU_Frequency4.zip
 
Chez moi, c'est 500k3 et 128_2 le + proche de 10sec.
Ton cas m'interesse lombric
 
NB: cet aprem, le prog sortira (normalement) la liste des instructions du CPU (MMX, SSE, etc.)

Il s'en passe des choses ici, la nuit  
 
Frequence_500k3 : 2390.421 MHz
Frequence_128_1 : 2390.375 MHz
Frequence_128_2 : 2390.417 MHz
Frequence_10sec : 2390.420 MHz
 
P4B 2.4 GHz @ 132.8*18

Exactement le même comportement que chez moi (et que sans doute ganply).
J'attend les résultats de lombric, ils sont beaucoup plus (et étrangement)  variables que nous.
 
edit: au finale je cherche un truc fiable à 0.1MHz près