Reprise du message précédent :
Perso, il est utilisé sur VM. donc que du cpu.
Par contre du turtle donc ca va pas faire lourd en feed !!

Si ca te prends pas longtemps à faire pour une prochaine release je veux bien merci  

Ya beaucoup de cpu intel avec plus de 32 thread ?  

Ok je vais caser ça dans la prochaine version, monter à 64

 
Ben c'est surtout que des machines avec plusieurs CPU ca existe...

 
  ok

Sur bitcointalk aussi j'ai un utilisateur avec 40 cores, un bi xeon e5
Je prepare ca en meme temps que je corrige le dual-thread mining.

Je t'avoue que j'ai pas suivi mais en gros au lieu de miner avec 1 thread par core on pourra miner avec 2 threads par core

Donc hasrate x2 ?

nope, ça serait trop beau.
C'est que si t'as par exemple 10M de cache et 4 cores, par défaut tu alloues 4x2M de cache pour miner. Reste 2M de gaspillé. Et bien là tu pourras avoir un thread qui mine 2 hash en même temps avec 4M de cache. Il parait que ça va un peu plus vite, même si sur xmrstak je ne vois pas trop de différence sur mon Xeon.
 
0.21 en cours de compilation

Tiens, c’était quoi le k8-k10 bug ?

trouvé sur Bitcointalk, ça ne faisait que des hash invalide, mais sans crash. C'était une typo dans mon asm Athlon.
 
Version 0.21 dispo, je mets à jour le changelog
 

 
C'est fait

Nickel, merci

Intéressant merci

0.22 en ligne. Revision mineure

Je sais pas ce que t'as foutu mais depuis la 0.20 je suis à 320 constant avec pointes à 330 h/s sur mon I7-4790k.
 

C'est mieux sur ryzen maintenant !
 
sur la 0.3 -> 280 h/s stable  
sur la 0.22 -> 400 à 500h/s  
 

J'ameliore mon assembleur un peu à chaque fois, sans toujours le documenter, car c'est à coup de +0.1%
 
La 0.22 apporte un boost de une   instruction   sur le 32 bits et le Heavy par exemple (un mov en moins dans les deux cas).

En fait le but du jeu c'est de faire le taff en moins de "mots" possible c'est ça ?

C'est plus compliqué : en moins de cycles.
Alors entre deux assembleurs identiques, mais avec un mot en moins, c'est ce dernier qui gagne. Sauf très rares cas particuliers.
 
Mais un assembleur court n'est vraiment pas forcément rapide, sur x86/64. Sur d'autres CPU plus ancien, cette règle était plus vraie.
 
J'ai découvert par exemple que faire un padd (packed-add) qui fait donc deux additions 64 bits en une instruction était bien plus lent que faire deux add séparés de 64 bits chacun. La raison : le add est hyper rapide sur les cpu moderne, mais pas trop le padd.
 

 
Merci pour l'explication    

0.23 dispo
 
Avec plein de shicoins, dont des deadcoins avec même le site officiel hs. Demande de bitcointalk. Le site du blueberriescoin est à voir absolument.

 
apparement le BTC n'était aps la premiere cryptomonnaie. Le blueberrycoin était là dès la fin des année 90  

Hello,
Je viens de mettre à jour vers la 0.23 et j'ai beaucoup de rejected sur nicehash avec des ''share above target''.
Je crois que j'étais en 0.14 avant, il y a eu beaucoup d'update ces derniers jours
Vous savez de quoi ça vient ? J'ai pas tenté de revenir en 0.14, mais j'ai laissé tourner XMRig quelques heures et RAS.

Bon, après plusieurs heures de 0.23 je confirme que tous mes shares trouvés sont rejetés.
Je viens de repasser en 0.14a et ça roule pour le moment.

 
Ce bug doit être spécifique à Nicehash ou ta config, parce que la 0.23 tourne chez moi depuis 1h45 cette nuit, et tous ses shares ont été acceptés par xmrpool.eu

Ptetre NH, je retesterais plus tard.
Pour la config, c'est la même, j'ai juste remplacé les .exe
Et si tu parles de matériel, j'ai exactement le même problème sur 10 machines donc c'est pas de ce côté non plus

On m'a remonté des shares reject aussi sur bitcointalk, je vais faire un audit de toutes les combinaisons, il peut y avoir un assembleur pété et pas l'autre.

Tu mines avec combien de cpu, de machines différentes, et de threads ?
Je crois avoir pété Nicehash quand on mine avec un nombre de threads qui n'est pas une puissance de deux. Comme moi je mine avec 4 et 8 threads respectivement, je n'ai rien vu venir...
 
edit : j'ai trouvé du code douteux, corrigé, mais en aveugle, chez moi Nicehash ça marche bien

6 configs différentes et je crois qu'un seul type mine à 3 threads (je regarde demain), tout le reste est à 4, 8 ou 14 threads.
Merci pour le correctif, je test ça demain

Bon, la 0.24 n'aura rien changé pour moi Faut que je change de pool si je veux avoir une version > à la 0.14a ?
Exemple avec une machine à 8 Threads (mais ça me le fait sur toutes) :

PS : c'est depuis que ça bosse en cryptonight v7, faudrait que je force en version précédente voir si ça déconne aussi.

Lien du topic sur bitcointalk ?
Trouvé en  FP

Ca te le fait depuis la 0.14b ? T'utilises quel "cpu_architecture" ?

la 0.14b est ancienne et bien rodée.
S'il y a régression, c'est depuis la 0.21
 
Attention aux fork, essaye avec --variation 1, 2, 3, 4, 5 si tu n'as que des bad shares

Je laisse le mode auto et j'ai pas toutes les releases en stock, je sais que la 0.14a ou 0.14b fonctionne bien, peut être quelques suivantes aussi.

Oui c'est ce que j'ai testé cet aprèm, en 1 et en 3 ça à l'air de rouler. 2 et 4 non. Pas testé le 5. Je ne sais pas sur lequel il bascule en mode auto, mais il prends pas un qui fonctionne chez moi
Faudrait que je comprenne les diff entre ces modes. Je crois que c'est le 4 j'ai fais x4 sur le H/s, mais en bad shares.

Ce sont les variations de l'ago Cryptonight (les forks)
 
    N=1 Original Cryptonight
    N=2 Original Cryptolight (for AEON)
    N=3 Cryptonight V7 fork of April-2018
    N=4 Cryptolight V7 fork of April-2018
    N=5 Cryptonight-Heavy
 
Rien à voir avec la vitesse, qui elle se configure avec -t et --archi
 
0.24a en ligne, hotfix des bad shares.

0.24b avec un gros fix de netcode, upgradez SVP

Thx, par contre pourrais-tu ajouter un checksum ?

checksum des zip de release ?
ok je le ferai à présent

Bon, merci pour vos différentes remarques, mais chez moi plus rien ne va. Je suis en train de tester en N=1 mais sinon :
N=5 : Rejected + H/s divisé par 2
N=4 : Rejected + H/s multiplié par 3,5 voir 4
N=3 : Rejected + H/s normaux
N=2 : Rejected + H/s multiplié par 3,5 voir 4

Mes paramètres sont --auto --low --hfr --nicehash --variation X et le --elevete-and-quit dans l'autre .bat
Vous voyez quelque chose d'anormal ? Je ne comprends pas pourquoi tout fonctionne bien avec les anciennes versions.

EDIT : avec le N=1 pour le moment ça fonctionne, je continue de surveiller.

L'ancienne version c'est équivalant à N=1.
Ensuite c'est tout à fait normal d'avoir des différences significatives de hashrate entre Cryptonight (1 et 3), Cryptolight (2 et 4) et Cryptonight-Heavy (5).
Et il faut sélectionner celui qui va bien en fonction du pool ou de la monnaie que tu vises.
Bref tout ce que tu écris semble cohérent.