tcatmの4-way SSE2 Linux 32/64ビット版が0.3.10に搭載
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月16日00: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月16日01: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オプションでハッシュ速度が非常に上がるので怪しいと感じている。以前は、そして -4wayオプションなしでは、これらのボックスで約5〜6khash/秒だった。-4wayでは11khash/秒以上出る！ つまり -4wayスイッチで報告されるハッシュ速度がほぼ倍にもなる。この程度の改善は予想以上に思え、ボックスが本当にそれだけ速くハッシュしているのか、何らかの理由で数学演算が実際にはスキップされていて見かけ上の速度向上とブロック生成能力の欠如を引き起こしている可能性はないのか疑問に思う。
tcatmの投稿（2010年8月16日00: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 : 4
cpu family 6 model 26 stepping 4はIntel Core i7だ。
-4wayで23%の高速化、-4way + ハイパースレッディングで合計63%の高速化だ。
ハイパースレッディングありの場合、なしの場合より33%高速だ。
クアッドコアPhenom II 64ビットLinuxマシン（ubuntu 9.10、両方とも）を2台持っているが、
-4wayオプションでハッシュ速度が非常に上がるので怪しいと感じている。以前は、そして-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〜6khash/秒だった。-4wayでは11khash/秒以上出る！ つまり-4wayスイッチで報告されるハッシュ速度がほぼ倍にもなる。この程度の改善は予想以上に思え、ボックスが本当にそれだけ速くハッシュしているのか、何らかの理由で数学演算が実際にはスキップされていて見かけ上の速度向上とブロック生成能力の欠如を引き起こしている可能性はないのか疑問に思う。o_O……ハッシュ頑張って、幸運を祈るよ。きっと要るだろうから！
おそらくそれはmhash/secか、何千ものkhash/secかのどちらかと読むべきだろう……しかしまあ、仲間うちなら3桁くらい誤差のうちだろう？
その誤記のせいで、-4wayオプションによるほぼ100%の速度向上が現実的かどうか、誰も答えてくれていないのかもしれない。自分のデスクトップマシンで本当に11000 khash/secの速度で暗号ハッシュが行われているとは納得できない。
ジェフ・ガージックの投稿（2010年8月16日03:35 UTC）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%高速だ。
bitcoinは起動時にハッシュが正しく動作しているかを検証する自己テストを行っているのだろうか？
@satoshi: おっと、-march=amdfam10のつもりだった。すまない。
@everyone（Phenomでの改善に戸惑っている皆へ）：このコードは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日23:02 UTC）i5もだ。少なくとも私のMacBookProでは。
よかった。ということは、Macでも動作しているという確認と受け取っていいのかな？
ラズロがMacで -4wayのコードをコンパイルしたと言っていたので、-4wayスイッチはMacでも試せる。SVN上のmakefile.osxにはまだ入っていないと思うが、ビルドされたバージョンには含まれている。
neliskyの投稿（2010年8月18日23: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);
}
}
}
@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以下のものはすべてシャットダウンした。