Reprise du message précédent :

Ok j'ai trouvé et mon user y est déjà.
Ceci dit entre temps j'ai reboot l'ordi (chose que je fait 1 fois par 1 à 2 semaines maxi) et maintenant il arrive à allouer les 4 premiers.
Mais on dirait que c'est variable, si je le lance 2 fois en même temps par exemple le 2eme n'arrive pas a allouer quoi que ce soit.
Ah ben d’ailleurs en fermant mon winamp et firefox (9 fenêtres, 24 onglets) 6 pages sont allouées sans soucis et le hash est de 238/s
Au passage j'ai 4*4go si ça a un rapport /\°~°/\

exemple avec 1 lancement de 6 thread et mon firefox ouvert (3.76 /16 go ram utilisé):

J'ai aussi ce problème (avec un autre mineur) lorsque j'ai un navigateur avec plein d'onglets et plusieurs instance de Visual Studio qui tournent. Si ta mémoire est trop fragmentée, il ne pourra pas allouer et t'auras le code erreur 1450 (ERROR_NO_SYSTEM_RESOURCES).
Faudrait que JCE ajoute cette info pour confirmer

et du coup tu fait quoi ? tu défragmente la ram ? (je me souviens d'un soft à défragmenter la ram à l'époque des Pentium 75)

Généralement je ferme tout et ça passe. Et derrière tu peux tout rouvrir, ça gêne pas, sauf si tu dois plus tard relancer le mineur pour une quelconque raison.

Ho merde c'est de ma faute ça j'ai refait le code des nonces !
Merci, je vais faire une rerelease en urgence c'est grave comme bug

 
Les Huge Page sont une ressource rare et fragile sous windows : il faut les allouer au début du boot et ne plus y toucher, sinon elles se perdent et Windows n'en trouve plus.
Sous Linux c'est mieux géré.
 
Je ferme JCE en prenant soin de bien les rendre à l'OS, mais au fur et à mesure elles se perdent.
Quand je dev et que je lance JCE cent fois pour tester, je finis par les épuiser. Une seule solution : reboot.
 
Edit : Nicehash corrigé avec la 0.10b
Merci du diagnostic !  

Ok je comprend et je viens de tenter une méthode de sauvage :
- aucune allocation ne passée.
- j'ai lancé paint.net (en gardant mon Firefox et tout montralala ouvert)
- j'ai fait une image d’environ 20000*20000, et j'ai dessiné dessus (ça a mangé 6-8 go de ram)
- j'ai fermé paint.net (sans sauvegarder
- j'ai lancé le miner : les 6 huges page sont passées.

Edit : j'ai pas testé mais je suis sur qu'en utilisant un soft de type memtest86 ça doit aussi marcher

Certains soft de "libération mémoire" (qu'il faut fuire comme la peste sauf usage ponctuel et bien précis et il faut savoir ce qu'on fait) font ce genre de chose : ça lance un processus qui va allouer un maximum de mémoire jusqu'à ce que l'OS leur refuse d'aller plus loin et ensuite ce processus relâche tout et quitte. Bref, ta technique reprend un peu ce principe.
Si fermer les processus gourmands ne suffit pas, ça se tente. Ou alors reboot

Vous êtes des fous !
Enfin si ca marche...

En test depuis plusieurs heures, je confirme, c'est tout bon. Merci    
 
Question annexe concernant la version 32bits, c'est sensé tourner sous XP ? Parceque chez moi, pas moyen.
Erreur au lancement :
ERROR
Unable to load function : GetLargePageMinimum (kernel32.dll)

Windows Server 2003 minimum pour cette fonction, et pas de large pages possible sur XP.
J'suis déjà tombé sur le problème

Ok, merci    C'était juste pour test de toute manière, voir ce que sortait un E8400. Toutes mes autres machines sont en x64 sous 7, 10 ou 2016.

J'ai l'impression que dans le dernier fichier, l exe 32 est en réalité la version 64bit et l'exe 64 est en réalité la version 32bits  

J'ai inversé ? Possible, je l'ai fait en urgence, je vais verifier
 
OS minimum Vista, 2003 marche peut-être pas testé

Salut,
 
Pour info, sur un 7900x, en --auto le programme version 0.10b ne lance que 6 threads

La détection de "topologie" du processeur est cependant correcte.
 
Avec un fichier de config et 10 threads, ça donne :

Marrant les 13.75 Mo de L3 sur ton CPU. J'me demande comment est foutu  
physiquement cette série de CPU.

hello !
 
Bon, des nouvelles : j'ai fini de monter ma base Ryzen sur mon rig. Le bios UEFI n'a pas apprécié que je lui colle une HD7000 mais passons, ça marche.
 
Mon assembleur AES que j'avais développé sur Excavator donne des résultats... étranges sur Ryzen. Ce dernier est compliqué : faire tourner ne serait-ce que deux threads sur 2 cores différents a un impact sur leurs perfs respectives. Une histoire de turbo je suppose ?
Excavator lui est plus simple, comme un core2 : on peut bourriner chaque core, ça n'impacte pas l'autre, tant qu'on ne fait pas de FPU.
 
Résultat : j'ai un AES qui est effectivement + rapide que Stak sur un thread (à peine, 1,5%  ) mais étonnement plus lent sur 8 threads, en prenant exactement la même répartition (-1%). Je n'ai pas encore compris pourquoi  
 
Et comme prévu, le dual-mining est catastrophique sur Ryzen, à cause du SMT. Mieux vaut deux vrais threads qu'une paire maître-esclave. Cette dernière combinaison n'est utile que sur quelques CPU : sans SMT/HT et avec peu de cache mais assez de puissance. Ca exclut à peu près tout sauf quelques core2, Celeron ou Pentium-G, et chez AMD, les CPU avant Ryzen.

Sans overclocking, la fréquence de chaque coeur des Ryzen varie selon le nombre de coeurs sollicités, via le Turbo et le XFR.
Mais un utilisateur assez calé pour miner l'est généralement aussi pour overclockler son Ryzen et dans ce cas, tous les coeurs sont à la même fréquence (sauf overclocking via P-States mais c'est une autre histoire).
Tu devrais donc overclocker le tien, même si ce n'est que modérément, pour obtenir des résultats conformes à ceux qu'obtiendront l'immense majorité de tes clients possédant un Ryzen

+1 le mien est OC à 3.8 (valeur "classique" pour un 1600)
Si tu ne veut pas trop te prendre la tête généralement la plupart des 1600 tiennent 3.8 avec 1.3-1.35V

 
Mon 1700 est aussi à 3,8 Ghz mais avec 1,225 V et le LLC 5 (CPU Load Line Calibration).

ok merci des tuyaux je vais tenter avec un OC

Bon, ben oc ou pas, j'arrive à être on par avec Stack +/- 1% (et loin devant Claymore) mais pas à passer devant sur ryzen, ce qui est très décevant
 
Je garde tout de même espoir avec le dual mining : avec un assembleur ryzen, je retrouve les propriétés attendues : Un thread de trop (9 sur un ryzen 16M par exemple) et les perfs plongent.
 
Donc soit le dual mining marche et j'aurais au moins +10% sur Stak, soit ça merde et JCE ne dépassera pas Stak. Dans ce cas je le présenterai comme un mineur pour vieux cpu, mais c'est une niche

Pas glop ça... mais j'espère que tu ne t'avoues pas déjà vaincu. Tu as pu passer à côté d'un détail important et peut-être qu'avec de la persévérance, tu finiras par le trouver.

En fait l'assembleur version ryzen est paradoxalement très simple, c'est juste une énorme boucle qui fait des aesenc, je vois peu de place pour optimiser. Même si je passe devant Stak ça ne sera pas de beaucoup

Une idée :
Je vais inventer des chiffres pour mon exemple.
Si le cpu sans les extensions aes fait 200H/S
Qu'avec les extensions aes il en fait 240...
Est ce que tu peut combiner du code pour utiliser les extensions aes + la méthode sans aes pour augmenter un peut les perfs ?
Pas pour avoir 440H/s mais si déjà ça monte à 300 dans mon exemple ça serait bien ?

Oui pour utiliser à la fois les unités AES et standard, une sorte de dual mining hybride.
 
J'ai plein de pistes, et après tout je n'ai que 2 ou 3% à gagner pour depasser Stak, mais je pensais démarrer la compèt à +10%, pas à -1%    
 
Comme quoi il faut toujours bench avant de dire qu'un code est plus rapide
 
Je vais tâcher de sortir rapidement une 0.10c avec du code bien propre, et le dual mine sans AES, puis je tente de fusionner les deux.

Encore des nouvelles : J'ai réussi à faire du dual mining en AES, et le gain est... Négatif.  
 
J'ai compris pourquoi au moins : Le temps partageable en aes ryzen par le thread maitre est tellement court que le cout de transfert est supérieur au gain.  
 
Le comportement Ryzen est complètement different de tout ce que j'ai eu jusqu'ici

Mince

Vu l'archi un peu particulière ce n'est pas franchement étonnant. Il vaudrait peut être mieux garder le branch actuel pour les vieilles archi legacy et partir sur autre chose (si faisable) pour de l'archi ryzen

C'est ce que je fais, un nouvel asm de zero, et je suis à 99% des perfs de stak, mais pas encore dépassé pourl'instant.
 
JCE en interne contient une dizaine d'implé différentes, et indépendantes, parfois très différentes, spécialisées pour chaque cpu. Ca explique la taille du binaire. Ryzen sera un cpu parmi d'autres, juste il est vraiment très different du reste.

wokay sir.

   
Et autant en 32 bits donc une vingtaine de codes asm

Sans penser au RYzen qui semble te poser des soucis.  
 
As-tu la possibilité de faire du AES sur les I5 ou I7, ou bien cela n'est pas prévu?

Yo JC

D'apres le code XMR-stack la parti qui genere le "Scratchpad", est optimiser pour un cache L3 de 8Mo, du coup je me demandait s'il etait possible de faire touner 2 thread reel par core sur les CPU ayant 16 Mo de de cache L3.

Perso, j'ai pas ce genre de CPU sous la main, puis c'est une idée a creuser.

Edit: C'est possible d'assigner une tache a un seul coeur ?

Yo
 
Tu configures tout comme tu veux, chaque thread, le nombre de threads que tu veux, sur le ou les cores que tu souhaites
 
Ça avance !
J'ai rattrapé Stak, je monte à 500 sur mon ryzen !  
J'ai encore quelques pistes d'optim, je devrais pouvoir le depasser  
 
Je n'ai pas de core i5/7 mais je vais release un binaire qui marche avec les AES récents. C'est plutôt Bulldozer qui aura un aes spécial.

OK j'attends la mise à jour  

Je pense faire une release avec le AES générique (pas optimisée que pour ryzen, et sans AVX) et avec le dual mining, ce WE.
Le dual n'est finalement utile que dans peu de cas...

501 atteint, égalité avec Stak
Sur un seul thread, je suis à 79.3 contre 78.9
Avec SMT désactivé je suis à 440.3 contre 438.8
 
Je ne pige pas pourquoi l'écart n'est present qu'avec moins de threads...

J'ai regardé le code assembleur de l'algo avec AES-NI, je ne m'attendais pas à un code aussi simple et avec aussi peu de marges d'optimisations
Je comprends mieux pourquoi tout le monde est au coude à coude. Là où quelqu'un pourra se différencier significativement, c'est pour les CPU qui s'écartent du ratio 2Mo/core.
D'ailleurs c'était qui qui avait un quadcore avec 128Mo de L4 ?

Oui voilà, il y a je crois 28 instructions et pas moyen de gagner un cycle. Je gagne un peu sur le kekkak, le jh, le skein... Mais ca se joue à 0.5%  
 
Faut que je retourne sur Excavator voir, sur Ryzen y'a vraiment rien à gagner...
 
D'ailleurs on peut facilement vectoriser les deux additions, les deux XOR et les deux écritures avec du SSE2, mais c'est étonnamment contre productif. A se demander à quoi sert un pxor ou un padd ...
 
Le pauvre clang sait vectoriser direct à partir d'un code C naïf, mais ça produit des perfs très inférieures...

T'as déjà testé l'ICC ? Il se débrouille bien avec la boucle principale je trouve, sur du CPU Intel en tout cas.