(Ich denke, diese Frage gilt im Prinzip auch für Bitcoin, aber da das CPU-Mining von Bitcoin scheinbar unrentabel ist, stellte sich diese Frage tatsächlich in Bezug auf das Yacoin-Mining).
Ich verwende derzeit die AVX-Version des 64-Bit-Windows-Miners, dessen Link auf der Homepage von Yacoin zu finden ist . Wie bei allen Forks von Minerd können Sie angeben, wie viele Bedrohungen Minerd für das Mining verwenden soll. Es scheint, als ob die verwendete Standardzahl die Anzahl der logischen Prozessoren ist, was in meinem Fall 8 ist. Ich habe jedoch versucht, mit diesem Wert herumzuspielen, und es scheint, dass das Herumspielen mit der Anzahl der Threads erheblich sein kann meine Hash-Rate erhöhen (natürlich kann es sie auch verringern) . Ich denke, das war eine kleine Überraschung, da ich einfach davon ausgegangen bin, dass die Standard-Thread-Anzahl am effizientesten gewesen wäre.
Es gibt auch die Variable, wie viele Worker ich im Pool (in meinem Fall yac.coinmine.pl) ausgeführt habe und wie viele Minerd-Prozesse ich betreibe.
Das bedeutet, dass es verschiedene Kombinationen von Prozessanzahl / Threadanzahl gibt, mit denen ich herumspielen könnte, um zu versuchen, die effizienteste Kombination zu finden, aber bevor ich dachte, ich würde die Zeit damit verbringen, mit diesen verschiedenen Möglichkeiten zu spielen, wäre es einfacher, einfach zu fragen Jemand, der eine bessere Vorstellung davon hat, wie das tatsächlich funktioniert: Gibt es einen Grund, warum es vorteilhaft wäre, 8 Minerd-Instanzen mit jeweils 1 Thread im Vergleich zu 1 Minerd-Instanz mit jeweils 8 Threads auszuführen? Vielleicht sollte es im Prinzip nicht so sein, aber weil ich in einem Pool schürfe, macht die Tatsache, dass separate Instanzen separate Worker erfordern, einen Unterschied? Was sollte eine ideale Thread-Anzahl sein und warum sollte dies tatsächlich eine effiziente zu verwendende Thread-Anzahl sein? Zum Beispiel scheint die Verwendung von 16 Threads meine Hash-Rate gegenüber der Verwendung von nur 8 zu verbessern, aber eine erneute Verdoppelung auf 32 Threads scheint die Hash-Rate wieder zu senken. Warum sollte dies der Fall sein?
Als separate, aber verwandte Frage: Warum scheint sich meine Hash-Rate zu verlangsamen, je länger der Miner läuft?
Eine Minerd-Instanz ist alles, was Sie brauchen. Die Anwendung synchronisiert sich auch mit dem Pool. Das Öffnen von mehr als einer Minerd-Instanz führt also nur dazu, dass Ihr Netzwerk zweimal für dieselben Informationen verwendet wird. Außerdem hat das Betriebssystem einen gewissen Overhead zum Ausführen der Anwendung. Das Öffnen einer weiteren Instanz bedeutet mehr Overhead und damit weniger Hashes!
Sie haben eine CPU mit Hyper-Threading, also 8 logische Kerne, das ist nicht dasselbe wie 8 physische Kerne. Haben Sie versucht, es mit 4 Threads auszuführen (nur zum Spaß)?
Stellen Sie sich auch vor, Sie hätten eine Rennstrecke mit 4 Spuren. Sie können 8 oder 16 Autos darauf fahren. Aber Sie müssen immer noch 4 Autos nebeneinander fahren lassen. Sie können beliebig viele Autos darauf werfen, aber jemand muss diese Autos synchronisieren, sodass die Rennstrecke weniger genutzt wird.
Idealerweise sollten Sie 8 Autos auf einer 4-spurigen Rennstrecke haben. Auf diese Weise haben die Autos, die die Rennstrecke verlassen haben, etwas Zeit, ihre Rundenzeiten auszutauschen, während die anderen 4 Autos die Rennstrecke benutzen. Sie können sich dann fast perfekt ablösen, wie bei einem Staffellauf.
Weniger als 4 Autos auf dieser Rennstrecke bedeutet, dass die Rennstrecke nicht die ganze Zeit benutzt wird, da die Rennfahrer in den Autos nach dem Verlassen der Rennstrecke ihre Rundenzeiten untereinander austauschen wollen (die Prozesse wollen dem Minerd ein Ergebnis zurückgeben Faden).
Wenn Sie mehr als 8 Autos haben, warten immer Autos darauf, auf die Rennstrecke zu fahren, also müssen Sie einfach viel Zeit warten, bevor sie auf der Rennstrecke fahren können.
Als ich Slackware benutzte und meine Kernel kompilierte, gab es eine Empfehlung, Threads auf 2xN zu setzen - N=Anzahl der Kerne. Aber hier http://www.databook.bz/?page_id=2319 habe ich einen Typen gefunden, der diese Meinung nicht teilt. Offensichtlich ist es auf den verschiedenen Plattformen unterschiedlich. Wenn Ihre Beobachtungen zeigen, dass 2xN auf Ihrem Computer besser funktioniert, klingt dies vernünftig.
Ich habe einen I3 330M Laptop mit 2 Kernen und 2 Threads pro Kern. Das Festlegen des Thread-Werts von m-minerd auf 2 Threads anstelle der Standardeinstellung von 4 Threads hat die Leistung in keiner Weise beeinträchtigt, während das Arbeiten mit 4 Threads etwas weniger effizient zu sein schien. Klingt, als hätte Jonathan Gleason eine ähnliche Erfahrung gemacht. Meine Spekulation ist also, dass m-Minerd oder der Mining-Prozess selbst nicht für Hyper-Threading (oder die Verwendung von mehr als einem Thread pro Kern) geeignet sind. Jedenfalls ist das meine Erfahrung. Ja, es ist ein alter Beitrag, aber ich dachte, ich erwähne ihn mal.