Reprise du message précédent :
Ah ouai, passer du flottant à la chaîne de caractères pour tronquer...
 
http://rootaxbox.no-ip.org/lol/DDB-petitponey.gif

Je m'attendais à ce retour de flamme avec une telle suggestion
 
Je présume qu'il n'y a pas de fonction donnant la partie décimale d'un flottant comme modulo 1, parce qu'il suffirait alors de la soustraire à la valeur à arrondir.

C'est possible de le faire, mon but était de le faire en 10 intructions asm. Perdu, ce code existe mais a une erreur de 1 dans 0.0000001% des cas, ce qui n'est pas acceptable.
 
Je le refais en int32
 
edit pour la Science.
 
Cette histoire de division, je détaille un peu. Le problème n'est pas de la faire, on peut envoyer à un compilo:

 
et il fera le boulot, c'est ce que fait XMRig par exemple. Le probèle, c'est que c'est lent.
Ma première idée était de configurer la FPU en arrondi inférieur (FE_DOWNWARD) et de faire la division en FPU, avec des float80, qui ont, justement, 64 bits de mantisse. Parfait.
En Entiers, attention, -3 / 2 ça fait -2, donc prendre le flottant -1.5 et enlever la fraction n'est pas bon. Et même -1.0000000000001 ça doit faire -2.
Or la FPU, en interne, a ses limites, les fameux bits de garde, donc si elle trouve un résultat du type 35.999999999999999 elle va toujours l'arrondir dans la FPU même à 36, alors que ça devrait être 35. Aucun moyen de corriger ça. Enfin corriger... c'est pas un bug, c'est la norme FPU qui veut ça, le résultat interne est arrondi au plus proche, c'est l'extraction du résultat qui est contrôlable. Donc si je peux certes lui dire de me convertir -1.1 en -2, je ne peux pas la forcer à me convertir -1.0000000000000000001 en -2, elle me dira -1. Donc échec.
 
Empiriquement, les cas erronés étant très rares, on peut faire 5 loop complets de hash (soit des millions de divisions), et donc trouver 5 hashs valides (!!), sans tomber dessus. Et de temps en temps, hop des hash invalides. Ce n'est pas tolérable pour un mineur CPU, donc je jette mon code et je le refais

Algo en int32 terminé, il est presque aussi rapide, mais il fait bien plus que 10 instructions    
C'est un mélange de int32 et de SSE2, car ce dernier a la capacité de gérer les entiers 64 bits (pour faire tout, sauf une division ).
 
J'ajoute les nouveaux paramètres --archi et -t pour l'archi et le nombre de threads déduis de --auto (qui n'est donc plus vraiment automatique) car ça facilite les tests. La config manuelle reste nécessaire seulement pour les cas exotiques (plusieurs threads sur un core, ou vice-versa) ou pour miner avec des algos différents sur des cores différents (idiot mais possible, plutôt pour comparer les vitesses pendant la phase de réglage). Et pour le dual-mining.

Version majeure 0.17 en ligne.

salut
 
viens de tenter sur windows 10 x64,i7 3770k non oc   il se connecte a la pool,mais error :"utilitaire attribute a cesse de fonctionner"

Ha merde, la version 0.17 ? T'as le log qu'il affiche avant de planter ?
Quelle crypto ?
 
Pour Lermite : J'ai trouvé moyen de propager le titre de la console, mais pas rester dans la même

La 0.17 tourne sans problème chez moi sur du DERO.
 
 

Ce serait déjà pas mal, même sans le transfert de l'icône.
Merci en tout cas de t'être penché sur ce problème.

la fenetre de lancement,il se planque ou le log?
 
 
 
C:\Users\Alex\Desktop\jce_cn_cpu_miner.017>jce_cn_cpu_miner64.exe --auto --low -o xmr-eu1.nanopool.org:14444 -u wallet -p x
 
                +-------------------------------------+
                | JC Expert Cryptonote CPU Miner 0.17 |
                +-------------------------------------+
 
 
For Windows 64-bits
Analyzing Processors topology...
Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Architecture codename: IvyBridge
  SSE2          : Yes
  SSE3          : Yes
  SSE4          : Yes
  AES           : No
  AVX           : Yes
 
Auto-configuration, selected CPUs will be highlighted...
Found CPU 0, with:
  L1 Cache:    32 KB, shared with CPU 1
  L2 Cache:   256 KB, shared with CPU 1
  L3 Cache:  8192 KB, shared with CPU 1, 2, 3, 4, 5, 6, 7
Found CPU 1, with:
  L1 Cache:    32 KB, shared with CPU 0
  L2 Cache:   256 KB, shared with CPU 0
  L3 Cache:  8192 KB, shared with CPU 0, 2, 3, 4, 5, 6, 7
Found CPU 2, with:
  L1 Cache:    32 KB, shared with CPU 3
  L2 Cache:   256 KB, shared with CPU 3
  L3 Cache:  8192 KB, shared with CPU 0, 1, 3, 4, 5, 6, 7
Found CPU 3, with:
  L1 Cache:    32 KB, shared with CPU 2
  L2 Cache:   256 KB, shared with CPU 2
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 4, 5, 6, 7
Found CPU 4, with:
  L1 Cache:    32 KB, shared with CPU 5
  L2 Cache:   256 KB, shared with CPU 5
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 5, 6, 7
Found CPU 5, with:
  L1 Cache:    32 KB, shared with CPU 4
  L2 Cache:   256 KB, shared with CPU 4
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 4, 6, 7
Found CPU 6, with:
  L1 Cache:    32 KB, shared with CPU 7
  L2 Cache:   256 KB, shared with CPU 7
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 4, 5, 7
Found CPU 7, with:
  L1 Cache:    32 KB, shared with CPU 6
  L2 Cache:   256 KB, shared with CPU 6
  L3 Cache:  8192 KB, shared with CPU 0, 1, 2, 3, 4, 5, 6
 
Preparing 4 Mining Threads...
 
+-- Thread 0 config -----------------------------+
| Run on CPU:             0                      |
| Use cache:              yes                    |
| Assembly module:        generic_aes            |
+------------------------------------------------+
 
+-- Thread 1 config -----------------------------+
| Run on CPU:             2                      |
| Use cache:              yes                    |
| Assembly module:        generic_aes            |
+------------------------------------------------+
 
+-- Thread 2 config -----------------------------+
| Run on CPU:             4                      |
| Use cache:              yes                    |
| Assembly module:        generic_aes            |
+------------------------------------------------+
 
+-- Thread 3 config -----------------------------+
| Run on CPU:             6                      |
| Use cache:              yes                    |
| Assembly module:        generic_aes            |
+------------------------------------------------+
 
Cryptonight Variation: Cryptonight V7 fork of April-2018
 
Low intensity.
Starting Mining thread 0, affinity: CPU 0
Thread 0 successfully bound to CPU 0
Allocated shared Huge Page at: 00000155b4000000
Allocated 2MB Cached Huge Page Scratchpad Buffer for CPU 0 of NUMA node 0 at: 00000155b4200000
Starting Mining thread 1, affinity: CPU 2
Thread 1 successfully bound to CPU 2
Allocated 2MB Cached Huge Page Scratchpad Buffer for CPU 2 of NUMA node 0 at: 00000155b4400000
Starting Mining thread 2, affinity: CPU 4
Thread 2 successfully bound to CPU 4
Allocated 2MB Cached Huge Page Scratchpad Buffer for CPU 4 of NUMA node 0 at: 00000155b4600000
Starting Mining thread 3, affinity: CPU 6
Thread 3 successfully bound to CPU 6
Allocated 2MB Cached Huge Page Scratchpad Buffer for CPU 6 of NUMA node 0 at: 00000155b4800000
Connecting to mining pool xmr-eu1.nanopool.org:14444 ...
Devfee is 1.5%
 
19:20:40 | Monero (XMR) Mining session starts!
 
During mining time, press:
 h    display hashrate for each mining thread.
 r    display full report.
 q    quit.
 
19:20:41 | Connected to pool. Now logging in...
19:20:41 | Successfuly logged as wallet
19:20:41 | Pool changes Difficulty to 120001.

T'as un cpu avec avx mais sans aes ? Ca existe ??

Le site d'Intel dit que t'as aes, mais il a l'air desactivé

bonne question? dans le bios?

Possible, regarde le Max CPUID ou un truc du genre. Ou alors un pb de microcode.
Je vais blinder ma detection, actuellement trop souple.
Et ajouter le transfer de titre de console.

RE

Si je mets --variation 3

Ca me marque

Parameter error, unknown argument --variation

Par contre jce_cn_cpu_miner.exe -o cryptonightv7.eu.nicehash.com:3363 -u 3blablabla3 -p x --auto  ça à l'air de passer ...

Logique ?

Tu utilises bien la version 0.17 ?
 
Edit : La 0.17 supporte bien le parameter --variation 3 je viens de verifier. Mais si nicehash veut encore du cryptonight non v7 alors autant ne pas mettre ce paramètre car c'est le défaut.

0.3 me semble (c'est ce qui est écrit quand je lance le mineur)
 
Par contre mon proco prend 20 degrés par rapport au mineur NH pour 2 thread de plus utilisés

Houlà elle est très vielle, prends la 0.17 !
https://github.com/jceminer/cn_cpu_ [...] er.017.zip

Un truc bizarre:
Pour miner de l'XMR, j'utilise Claymore pour mes deux RX, et JCE pour mon 1700.
Les deux affichent la valeur de chaque share même si Claymore l'affiche en hexadécimal.
Mais alors que JCE semble toujours afficher 1000, les valeurs de Claymores sont variables au moins qu'il n'y en a pratiquement pas deux identiques.
 
Une capture illustrant cette incohérence: https://puissanceled.com/vrac/Claymore_vs_JCE_CPU.png
 
Est-ce JCE qui n'affiche pas la bonne valeur, ou Claymore qui affiche tout autre chose?

Parce que sur cpu tu as la puissance minimale pour miner, donc tu restes à la difficulté minimale 10000 (et pas 1000 ).
Tes gpu plus puissants eux entre dans l'intervalle supérieur qui est lui variable.
Donc tout est normal
 
Edit : Claymore affiche les 32 bits de poids fort du hash, c'est l'inverse (au sens mathématique) de la valeur du share, plus utile à mon avis, affichée par JCE.
Or le hash étant aléatoire, il est toujours différent d'un share à l'autre.
 
Donc JCE et Claymore 11 l'affiche pas la même chose, et curieusement sur claymore 9 c'était bien la valeur, et pas le hash, qui était affiché. Étonnant changement d'ergonomie. Ce que je dis plus haut reste valide.

Chui un ancien moi
Merci

up

Ton up a marché, voici la 0.18
https://github.com/jceminer/cn_cpu_ [...] er.018.zip

La récupération du titre de la fenêtre de lancement est déjà appréciable.
 
Un plus serait la fermeture automatique de cette fenêtre une fois que le mineur est lancé, pour nous éviter d'avoir à le faire manuellement.

Bonne idée, sera dans la 0.19 si j'ai le temps.
Il y aura aussi : (demandes de Bitcointalk)
Support de Intense et Ultranote.
Grosse optim en non-aes32, infime en non-aes 64

Et le double thread par core oublie pas

Un lecteur attentif !
Mais ça, ça va prendre plus de temps...

 
Version 0.19 en ligne, paramètre --elevate-and-quit

Merci mais ça ne semble pas marcher chez moi: la fenêtre de lancement reste ouverte après que le mineur ait été lancé dans sa propre fenêtre.
 
Oups, si, ça marche. J'avais oublié un "pause" après la commande de lancement  

hello ! lien vers la 0.19 en 404 sur la FP

Il a sorti la 0.20 entre temps, mais pas encore fait la hfr release on dirait bien

C'est fait
C'est une emergency fix suite à un bug signalé sur bitcointalk qui touchait les vieux cpu. Auncun autre changement sinon.
 
Le mode hfr est toujours là même si la version ne le mentionne plus (les ricains ne comprendraient pas...)

Vu le boulot très conséquent (tu fais un suivi du temps passé ?), et sans indiscrétions, tu as réussi à te faire quelques centaines d'euros de fees jusque là ?

Mon gain total est de l'ordre de 1$, sans blague. 1% de qlq mineurs cpu c'est infime...
Sur bitcointalk ca decolle un peu mais c'est finalement le 32 bits et le non aes qui ont du success. Comme prevu au départ les +1% en aes ne font pas rever...

 
Heuuuuuuu........ Oh man.

ça va venir faut adapter ton miner aux botnets

Il ne faut pas se faire d'illusion, les mineurs CPU resteront anecdotiques pour tout algo pouvant se miner aussi par GPU.
Mon Ryzen 1700 est loin d'être une bouse sur le Cryptonight mais il se fait déposer par n'importe quelle RX570.
 
Il n'y a que sur les Algos ne se minant que sur CPU, comme à priori le Yescrypt32, qu'un mineur CPU peut devenir rentable pour son créateur via une dev fee.
 
Sur les algos mixtes (CPU et GPU), l'idéal serait un mineur en mesure d'exploiter tous les CPUs en plus des GPU Nvidia et AMD, comme le fait Stak, mais avec des hashrates concurrençant ceux des mineurs plus ciblés (seulement OpenCL par exemple).

Optimisation ARM pour le non-AES

Il y a une raison au fait que tu limites à 32 threads ?

Car je prealloue 32 buffers de comptage de vitesse (de 512 hash chacun). C'est aussi con que ca. Tu veux que je relève cette limite ?

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