tcatm の 4-way SSE2 Linux 32/64 ビット版 0.3.9 rc2
0.3.10 に tcatm の 4-way SSE2 がオプションスイッチとして搭載された。
有効にするには -4way スイッチを使用する。スイッチなしの場合は Crypto++ ASM SHA-256 が使用される。
Linux でのみ動作を確認できた。
ダウンロード： 0.3.10 は topic 827 から入手可能。
CPU と結果をぜひ報告してほしい！ Core 2 以下では遅く、i5 では速いことはかなり明らかだと思われる。i7 の結果はまだ得られていないと思う。AMD やその他のあまり一般的でない CPU の各モデルについての情報が必要である。
0.3.10 には tcatm の 4-way SSE2 がオプションスイッチとして含まれている。
-4way スイッチを使って有効にしてほしい。スイッチなしでは Crypto++ ASM SHA-256 が使用される。
Linux でのみ動作させることができた。
ダウンロード： 0.3.10 は topic 827 から入手してほしい。
お使いの CPU と結果を報告してほしい！Core 2 以下では遅く、i5 では速いことはかなり明らかだと思う。i7 の結果はまだ聞いていないと思う。AMD やその他のあまり一般的でない CPU の各モデルについて知る必要がある。
簡単なテストをやってみた。他のマシンでも試したらまた報告する。
Pentium E5300 Dual-Core 2.6 GHz（2MB キャッシュ、FSB 800MHz）
プロセッサー情報：http://en.wikipedia.org/wiki/Wolfdale_%28microprocessor%29
ストック = 2261 khash/s
4-way = 1103 khash/s（64 ビット）
Pentium 4 - 3.0GHz（ハイパースレッディング OFF）1MB キャッシュ、FSB 800MHz
プロセッサー情報：http://en.wikipedia.org/wiki/NetBurst_%28microarchitecture%29
ストック = 1024 khash/s（32 ビット）
4-way = 658 khash/s（32 ビット）
Pentium 4 - 2.8GHz（ハイパースレッディング OFF）1MB キャッシュ、FSB 800MHz
プロセッサー情報：http://en.wikipedia.org/wiki/NetBurst_%28microarchitecture%29
ストック = 917 khash/s（64 ビット）
4-way = 747 khash/s（64 ビット）
もし他に理由がないとすれば、鍵は CPU キャッシュのサイズだと言いたい。遅く動作する CPU はどれもオンボードキャッシュが 2MB 以下のようで、一方 Core i5 は最低 3MB のオンボード CPU キャッシュから始まる。
誰か i5 または AMD でテストして、私が正しくビルドしたか確認してもらえると助かる。どちらもテスト用に持っていないのだ。
また、32 ビット Linux と 64 ビット Linux で性能が大幅に異なるかどうかも気になる。
このコードはどこにあるのか？CentOS 5.5 のボックスにいるので自分でビルドする必要がある。ビルドしたら Linux 32 ビットと 1MB キャッシュ Xeon の結果を報告する。
テスターが正しくビルドされたか確認できるよう、簡易ビルドをアップロードした。（i5 や AMD は持っていない）問題なければ、完全なパッケージをまとめてリリース作業をすべて行う。
もし他に理由がないとすれば、鍵は CPU キャッシュのサイズだと言いたい。遅く動作する CPU はどれもオンボードキャッシュが 2MB 以下のようで、一方 Core i5 は最低 3MB のオンボード CPU キャッシュから始まる。
それは考えにくい。ループでアクセスするデータは 432 バイトだ。ほとんどのキャッシュに収まるはずだ。
-4way あり：5,911 khash
なし：11,260 khash
（Dual Xeon E5450、64 ビット、8 スレッド）
結果を記録できるように Wiki ページを作成した：http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2
sha256.cpp を-O3 -march=amdfamk10 でコンパイルすることを提案する（32 ビットと 64 ビットの両方で動作する）。この命令セットをサポートする CPU（AMD Phenom、Intel i5 以降）のみが -4way の恩恵を受け、パフォーマンスが約 9%向上する。
結果を記録できるように Wiki ページを作成した：
http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2
ハイパースレッディングが有効かどうか、物理コア数、Bitcoin が使用しているコア数の列を追加した方がいい。4way なしでは、仮想コアの半分でハッシュした方がわずかに良い結果が出る。4way では、すべての仮想コアを有効にするとパフォーマンスが大幅に向上する。ハイパースレッディングをオフにすると、4way の有無にかかわらずほぼ同じハッシュ量になると思う。
aceat64の投稿（2010年8月15日 15:37 UTC）結果を記録できるようにWikiページを作成した：
http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2ハイパースレッディングが有効かどうか、物理コア数、Bitcoinが使用しているコア数の列を追加した方がいい。4wayなしでは、仮想コアの半分でハッシュした方がわずかに良い結果が出る。4wayでは、すべての仮想コアを有効にするとパフォーマンスが大幅に向上する。ハイパースレッディングをオフにすると、4wayの有無にかかわらずほぼ同じハッシュ量になると思う。
あなたの提案でページを更新した。いくつかのフィールドを説明する脚注も追加した。
私の -4way の結果：古い 2 台のボックスでは遅く、新しいものでは速い。
（“model name”は Linux の/proc/cpuinfo から。CPU から直接報告される。）
- model name : Intel(R) Pentium(R) D CPU 3.00GHz
合計コア数: 2
-4way なし: 0.999 Mhash/秒
-4way 付き: 0.850 Mhash/秒
- model name : Dual Core AMD Opteron(tm) Processor 280
合計コア数: 4
-4way なし: 4.6 Mhash/秒
-4way 付き: 4.0 Mhash/秒
- model name : Genuine Intel(R) CPU 000 @ 3.20GHz
合計コア数: 4
-4way なし: 5.7 Mhash/秒
-4way 付き: 7.0 Mhash/秒
sha256.cpp を-O3 -march=amdfamk10 でコンパイルすることを提案する（32 ビットと 64 ビットの両方で動作する）。この命令セットをサポートする CPU（AMD Phenom、Intel i5 以降）のみが
-4wayの恩恵を受け、パフォーマンスが約 9%向上する。
GCC 4.3.3 は-march=amdfamk10 をサポートしていない。以下のエラーが出る： sha256.cpp:1: error: bad value (amdfamk10) for -march= switch
NewLibertyStandardの投稿（2010年8月15日 16:49 UTC）4wayでは、すべての仮想コアを有効にするとパフォーマンスが大幅に向上する。ハイパースレッディングをオフにすると、4wayの有無にかかわらずほぼ同じハッシュ量になると思う。
おお、何か重要な発見をしたかもしれないな！
以前はハイパースレッディングが役に立たなかったのは、すべての処理が算術論理ユニットで行われ、ハイパースレッドがそれを共有していたためだ。
tcatm の SSE2 コードは通常の x86 命令と SSE2 命令の組み合わせのはずで、一方が x86 コードを実行している間に、もう一方が SSE2 を実行できる。
ハイパースレッディングでどれくらい改善する？
数字は？どの CPU だ？
model name : AMD Phenom(tm) II X4 940 Processor 3.0 GHz Linux 64
-4way 付き “hashespersec” : 11132770
なし “hashespersec” : 5877668
クアッドコア Phenom II 64 ビット Linux マシン（ubuntu 9.10、両方とも）を 2 台持っているが、-4way オプションでハッシュ速度が非常に上がるので怪しいと感じている。以前は、そして n-4way オプションなしでは、これらのボックスで約 5〜6khash/秒だった。-4way では 11khash/秒以上出る！つまり -4way スイッチで報告されるハッシュ速度がほぼ倍増する。この程度の改善は予想以上に思え、ボックスが本当にそれだけ速くハッシュしているのか、何らかの理由で数学演算が実際にはスキップされていて見かけ上の速度向上とブロック生成能力の欠如を引き起こしている可能性はないのか疑問に思う。
tcatmの投稿（2010年8月15日 15:43 UTC）sha256.cppを-O3 -march=amdfamk10でコンパイルすることを提案する（32ビットと64ビットの両方で動作する）。この命令セットをサポートするCPU（AMD Phenom、Intel i5以降）のみが
-4wayの恩恵を受け、パフォーマンスが約9%向上する。GCC 4.3.3は-march=amdfamk10をサポートしていない。以下のエラーが出る： sha256.cpp:1: error: bad value (amdfamk10) for -march= switch
-march=amdfam10 を試してみてくれ。
-march=amdfam10を試してみてくれ
動いた。
おかしいな……同じものだと確信できるか？tcatm、amdfam10 で試して同じ速度測定結果が得られるか確認してくれ。
http://www.google.com/search?q=amdfamk10
AMD のアーキテクチャは K#番号なので、彼は記憶違いをしているのだと思う。
model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz, Linux 64
約 4950 khash/s で差なし
以下のアップデート：
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4
マシンは4コアで、各コアに2つのハイパースレッドがある。/proc/cpuinfoは8つの仮想プロセッサーを表示する。
-4wayなし、setgen 4: 5.7 Mhash/秒
-4wayなし、setgen 8: 5.0 Mhash/秒
-4way付き、setgen 4: 7.0 Mhash/秒
-4way付き、setgen 8: 9.3 Mhash/秒したがって、「ハイパースレッディングは速度を低下させる」という古い常識は、このマシンでは覆された。
他の 3 台の Intel マシンでも 4way の勝者はいなかった：
Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz（64 ビット Linux） 4way: 1565 標準: 3002
Intel(R) Xeon(TM) CPU 3.00GHz（32 ビット Linux） 4way: 1243 標準: 2048
Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz 4way: 932 標準: 1733
（すべて 0.3.10、-1 proclimit で実行） proclimit の実験でもそれ以上にはならなかった。
以下のアップデート：
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4cpu family 6 model 26 stepping 4 は Intel Core i7 だ。
-4way で 23%の高速化、-4way + ハイパースレッディングで合計 63%の高速化だ。
ハイパースレッディングありの場合、なしの場合より 33%高速だ。
クアッドコア Phenom II 64 ビット Linux マシン（ubuntu 9.10、両方とも）を 2 台持っているが、
-4wayオプションでハッシュ速度が非常に上がるので怪しいと感じている。以前は、そして n-4way オプションなしでは、これらのボックスで約 5〜6khash/秒だった。-4wayでは 11khash/秒以上出る！つまり-4wayスイッチで報告されるハッシュ速度がほぼ倍増する。この程度の改善は予想以上に思え、ボックスが本当にそれだけ速くハッシュしているのか、何らかの理由で数学演算が実際にはスキップされていて見かけ上の速度向上とブロック生成能力の欠如を引き起こしている可能性はないのか疑問に思う。
o_O……ハッシュ頑張ってくれ、健闘を祈る！
サトシ・ナカモトの投稿（2010年8月16日 02:57 UTC）NewLibertyStandardの投稿（2010年8月16日 01:49 UTC）4wayありだと、仮想コアをすべて有効にしたときに大幅にパフォーマンスが向上する。ハイパースレッディングをオフにすると、4wayの有無にかかわらず同じくらいのハッシュ数になると思う。
ねえ、何かに気づいているかもしれない！
以前はハイパースレッディングが効かなかった。なぜならすべての処理が算術論理ユニットで行われ、ハイパースレッドがそれを共有するからだ。
tcatmのSSE2コードは通常のx86命令とSSE2命令の混合に違いない。だから一方がx86コードを実行している間に、もう一方がSSE2を実行できる。
ハイパースレッディングでどれくらい改善するんだ？
数値を頼む。どんなCPUだ？
Ubuntu 10.04 amd64 上の i7 860 2.8 GHz で、自分のかなり曖昧な記憶からの結果はこちら。数値は少しずれているかもしれない。
4way なし、HT あり、4/8 仮想コア、4.5～5 Mhash/sec 4way なし、HT あり、8/8 仮想コア、上より少し低いが、基本的に同じ
4way あり、HT あり、8/8 仮想コア、6.5～8 Mhash/sec（気のせいかもしれないが、明らかにばらつきが大きいように見える。） 4way あり、HT あり、4/8 仮想コア、5～6 Mhash/sec
4way なし、HT なし、4/4 物理コア、4.5～5 Mhash/sec（ただし最初の結果より少し遅い。） 4way あり、HT なし、4/4 物理コア、5～6 Mhash/sec
grideconの投稿（2010年8月16日 03:15 UTC）自分はクアッドコアのPhenom II 64ビットLinuxマシン（どちらもubuntu 9.10）を2台持っているが、
-4wayオプションを付けるとハッシュレートが上がりすぎて疑わしい。これまで-4wayなしではこれらのマシンで5～6 khash/secほどだった。-4wayありだと11 khash/sec以上になる！つまり、-4wayスイッチは報告されるハッシュ速度をほぼ2倍にする。この改善幅は予想以上で、自分のマシンが本当にそれほど速くハッシュしているのか、それとも何らかの理由で数学演算が実際にはスキップされていて、見かけ上の速度を生み、実際にはブロックを生成できていない可能性があるのではないかと疑問に思う。o_O……ハッシュ頑張ってくれ、健闘を祈る！
おそらくそれは mhash/sec か、何千 khash/sec かのどちらかと読むべきだろう……しかしまあ、友人同士で 3 桁くらい何だというのか？
その誤記のせいで、-4way オプションによるほぼ 100%の速度向上が現実的かどうか、誰も答えてくれていないのかもしれない。自分のデスクトップマシンで本当に 11000 khash/sec の速度で暗号ハッシュが行われているとは納得できない。
ジェフ・ガージックの投稿（2010年8月16日 03:35 UTC）Code:cpu family : 6 model : 26 model name : Genuine Intel(R) CPU 000 @ 3.20GHz stepping : 4
cpu family 6 model 26 stepping 4 はIntel Core i7だ。
-4wayで23%の高速化、-4way+ ハイパースレッディングで合計63%の高速化となる。 ハイパースレッディングなしと比べて33%速い。
bitcoin は起動時にハッシュが正しく動作しているかを検証する自己テストを行っているのだろうか？
@satoshi: おっと、-march=amdfam10 のつもりだった。すまない。
@4way の改善について混乱している皆さん：このコードは Phenom（940）で開発し、（少なくとも 64 ビットモードでは）検証済みで、見ている改善は本物だ。
ハイパースレッディングについて：わずかなパフォーマンス向上があるようだ。おそらくロード/ストア命令を演算命令と並行して実行していることによる。ABI に関数を組み込むための通常の x86 命令はごくわずかだ。総 CPU 時間の 2%未満で済む（gprof で測定）。
Core 2 Duo T7200 では、デフォルトコードで約 1.8 Mhash/s、4way は 1.0 Mhash/s で遅い。L2 キャッシュは 4 MB あるので、どこかで示唆されたようにキャッシュサイズの問題ではないだろう。
残念ながら、（svn からの）コードは ARM ではもうコンパイルできない。SSE intrinsics がハードコードされているためだ。Makefile から-msse2 と-DFOURWAYSSE2 フラグを削除したが、それでも以下のようなエラーが出る。
sha256.cpp:8:23: error: xmmintrin.h: No such file or directory
sha256.cpp:34: error: «__m128i» does not name a typeしかし修正は簡単なはずだ。
sha256.cpp を以下で囲んだ： #ifdef FOURWAYSSE2 #endif // FOURWAYSSE2
今試してみてくれ。
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
-4way なし “hashespersec” : 2539397
-4way あり “hashespersec” : 2108791
Linux、Debian、32 ビット。
sha256.cpp を以下で囲んだ： #ifdef FOURWAYSSE2 #endif // FOURWAYSSE2
今試してみてくれ。
ありがとう、ちゃんと動くようになった。
モデル：Intel Atom n330（2 コア、仮想 4）。
OS：Ubuntu 10.04 64bit
-4way オプションを使うと、オプションなしの場合の半分の速度になる。
つまり、今のところ -4way で速度向上の恩恵を受けるのは Intel Core i7 プロセッサーと一部の（Phenom？）AMD プロセッサーだけということで正しいか？
つまり、今のところ
-4wayで速度向上の恩恵を受けるのは Intel Core i7 プロセッサーと一部の（Phenom？）AMD プロセッサーだけということで正しいか？
i5 もだ。少なくとも私の MacBookPro では。
Mac 以外の i5 は対応してくれないのか？
Windows i5 64 ビットではこちらだと遅くなった。
[訂正――正しくない。Windows には -4way がなく、Linux マシンの方は Xeon だった。]
私の Core i5 ラップトップ（Ubuntu）は速度が倍増した。いや、正確には速度は倍増していない。速度は同じだが、CPU 使用率が半分になった。フル CPU 使用率に戻すことができない。とはいえ、ブロック生成時のラップトップはずっと涼しくなった。100%使用率に上がるのを確認したら報告する。
Mac以外のi5は対応してくれないのか？
Windows i5 64 ビットではここでは遅くなった。 i5 で遅くなったと言う人を聞いたのは初めてだ。他の全員が i5 では 4way の方が速いと言っている。ハイパースレッディングを有効にするとさらにだ。
neliskyの投稿（2010年8月18日 14:02 UTC）i5もだ。少なくとも私のMacBookProでは。
良いな、ということは Mac でも動作しているという確認だな？
ラズロが Mac で -4way のコードをコンパイルしたと言っていたので、-4way スイッチは Mac でも試せる。SVN 上の makefile.osx にはまだ入っていないと思うが、ビルドされたバージョンには含まれている。
neliskyの投稿（2010年8月18日 14:02 UTC）i5もだ。少なくとも私のMacBookProでは。
よし、ということはMacでも動作しているという確認だな？
ラズロがMacで
-4wayのコードをコンパイルしたと言っていたので、-4wayスイッチはMacでも試せる。SVN上のmakefile.osxにはまだ入っていないと思うが、ビルドされたバージョンには含まれている。
そうだ、問題なく動作している。以前投稿した数字は tcatm の変更を適用した古い svn リビジョンのものだが、今日 trunk をコンパイルしたところ、Makefile を再度調整する必要があったが、調整後は以前と同じ数字で問題なく動作している。
私のシステムでの変更は以下の通り。一部は wx-config の削除のように表面的なもの（WxWidgets がインストールされていない場合に警告を避けるため）で、DEPS ディレクトリのようにシステム固有のものもあり、32 ビットライブラリがないために-arch i386 があるとリンクステップが失敗する。 bsddb の変更は、タイプミスだと思う。Includes と Libs は db46 を指しているが、リンカのオブジェクトリストでは db48 になっている。とにかく、以下が動くようにした差分だ：
Index: makefile.osx
===================================================================
--- makefile.osx (revision 139)
+++ makefile.osx (working copy)
@@ -6,29 +6,29 @@
# Laszlo Hanyecz (solar@heliacal.net)
CXX=llvm-g++
-DEPSDIR=/Users/macosuser/bitcoin/deps
+DEPSDIR=/opt/local
INCLUDEPATHS= \
- -I"$(DEPSDIR)/include"
+ -I"$(DEPSDIR)/include" -I"$(DEPSDIR)/include/db46"
LIBPATHS= \
- -L"$(DEPSDIR)/lib"
+ -L"$(DEPSDIR)/lib" -L"$(DEPSDIR)/lib/db46"
-WXLIBS=$(shell $(DEPSDIR)/bin/wx-config --libs --static)
+WXLIBS=
LIBS= -dead_strip \
- $(DEPSDIR)/lib/libdb_cxx-4.8.a \
- $(DEPSDIR)/lib/libboost_system.a \
- $(DEPSDIR)/lib/libboost_filesystem.a \
- $(DEPSDIR)/lib/libboost_program_options.a \
- $(DEPSDIR)/lib/libboost_thread.a \
+ $(DEPSDIR)/lib/db46/libdb_cxx-4.6.a \
+ $(DEPSDIR)/lib/libboost_system-mt.a \
+ $(DEPSDIR)/lib/libboost_filesystem-mt.a \
+ $(DEPSDIR)/lib/libboost_program_options-mt.a \
+ $(DEPSDIR)/lib/libboost_thread-mt.a \
$(DEPSDIR)/lib/libcrypto.a
-DEFS=$(shell $(DEPSDIR)/bin/wx-config --cxxflags) -D__WXMAC_OSX__ -DNOPCH -DMSG_NOSIGNAL=0
+DEFS=-D__WXMAC_OSX__ -DNOPCH -DMSG_NOSIGNAL=0 -DFOURWAYSSE2
DEBUGFLAGS=-g -DwxDEBUG_LEVEL=0
# ppc doesn't work because we don't support big-endian
-CFLAGS=-mmacosx-version-min=10.5 -arch i386 -arch x86_64 -O3 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)
+CFLAGS=-mmacosx-version-min=10.5 -arch x86_64 -O3 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)
HEADERS=headers.h strlcpy.h serialize.h uint256.h util.h key.h bignum.h base58.h \
script.h db.h net.h irc.h main.h rpc.h uibase.h ui.h noui.h init.h
@@ -42,6 +42,7 @@
obj/rpc.o \
obj/init.o \
cryptopp/obj/sha.o \
+ obj/sha256.o \
cryptopp/obj/cpu.o
@@ -55,7 +56,7 @@
$(CXX) -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_ASM -o $@ $<
bitcoin: $(OBJS) obj/ui.o obj/uibase.o
- $(CXX) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)
+ $(CXX) $(shell $(DEPSDIR)/bin/wx-config --cxxflags) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(shell $(DEPSDIR)/bin/wx-config --libs --static) $(LIBS)
obj/nogui/%.o: %.cpp $(HEADERS)新しい CPU と古い CPU の違いはかなり簡単に説明できる。 古いマイクロアーキテクチャは 64 ビットの MMX/SSE 実行ユニットを持ち、128 ビット SSE 命令を 2 つの 64 ビットマイクロオペレーションに分割する。 新しいアーキテクチャは 128 ビット SSE ユニットを持つ。
- AMD K8: 2 つの 64 ビットユニット
- Intel Core/Core2: 3 つの 64 ビットユニット
- AMD K10: 2 つの 128 ビットユニット
- Intel Nehalem: 3 つの 128 ビットユニット K10 = 4 コア以上の Opteron、Phenom、Phenom II、Athlon II Nehalem = Xeon 34xx/35xx/36xx/55xx/56xx/65xx/75xx、i3/i5/i7
明確にしてくれてありがとう。2007年頃に AMD がその変更を行ったという誰かが投稿したリンクを読んだが、Intel の状況は知らなかった。
Core/Core2 には望みがないな。SSE2 ハードウェアが半分しかない。
Intel が 3 つの 128 ビットユニットを持っているのに、2 つの 128 ビットユニットの AMD の方が速いのは奇妙だ。
Intel Atom 230 @ 1.60GHz。Linux 32 ビット。 （Acer Aspire Revo）
標準: 438 khash/秒（1 プロセッサーだと 354） 4way: 254 khash/秒
というわけで、パワーハウスリストからは外してくれ。 😊 😄
新しい AMD Bulldozer のプレスリリースを見た人はいるか？正しく理解していれば、コアあたり 8 つの 64 ビットハッシュを同時に処理できるはずだ。この同じコード設計を使えばかなりのスピードブーストになるだろう。
Slashdot に記事がある。 PC Perspective に詳細がある。
2009年11月に AnandTech でも取り上げられていた。
- AMD K10: 128ビットユニット2つ
- Intel Nehalem: 128 ビットユニット 3 つ
これはおそらく、ハイパースレッディングが
-4wayで性能を向上させる理由を説明している。3 つの SSE2 ユニットが過剰であれば、ハイパースレッディングがそれらをすべてビジー状態に保つのに役立つだろう。
ソースコードをレビューした。さらに最適化するアイデアがいくつかあり、4way が部分的に壊れていることに気づいた：
main.cpp より：
for (int j = 0; j < NPAR; j++)
{
if (thash[7][j] == 0)
{
for (int i = 0; i < sizeof(hash)/4; i++)
((unsigned int*)&hash)[i] = thash[i][j];
pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
}
}このコードは、正しいものである可能性のある 32個のハッシュのうち、1 つ（thash[7] == 0 の最後のもの）しか処理しない。
こんな感じで修正できるはずだが、より高い難易度では安全ではないだろう。また、バイト順序を反転すべきかどうかもわからない。誰かレビューしてくれないか？
unsigned int min_hash = ~1;
for (int j = 0; j < NPAR; j++)
{
if (thash[7][j] == 0)
{
if(thash[6][j] < min_hash) {
min_hash = thash[6][j];
for (int i = 0; i < sizeof(hash)/4; i++)
((unsigned int*)&hash)[i] = thash[i][j];
pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
}
}
}簡略化は意図的だ。thash[7]=0 が複数になるのは 134,217,728回に 1回だけだ。0.0000007%遅くなるだけだ。
@sgtstein：Intel の Sandy Bridge（2010年第 4 四半期にリリース予定）は AVX の 256 ビット SIMD レジスターもサポートする。つまり原理的にはスレッドあたり 8 つのハッシュ計算が同時に可能になる。
Pentium D（Presler）での 4-way SSE2 のレポートを持っている人はいないだろうか？どの程度のパフォーマンスが期待できるだろうか？古い Pentium D とマザーボードが転がっていて、パフォーマンスが問題なければマイニングサーバーとして起動させたい。もっとも、khash/Watt 効率は最高にはならないだろうが。
Pentium D（Presler）での 4-way SSE2 のレポートを持っている人はいないだろうか？どの程度のパフォーマンスが期待できるだろうか？古い Pentium D とマザーボードが転がっていて、パフォーマンスが問題なければマイニングサーバーとして起動させたい。もっとも、khash/Watt 効率は最高にはならないだろうが。
うちの Pentium-D は死んだが、基本的には 1 パッケージに 2 つの P4 が入っているだけのものだったから、bitcoin でもおそらくそんな感じで動くだろう。確かに電気を食う代物だった。4way コードは一般に P4 ではあまりうまく動かない。3.4GHz の P4 で -4way なしだと約 900 khash/s しか出ない。-4way ありだと 600 khash/s 台だ。
本気か？電気代がタダなのか？
難易度623 では、3000 khash/sec 以下のものはすべてシャットダウンした。