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の各モデルについて知る必要がある。
誰かi5またはAMDでテストして、私が正しくビルドしたか確認してもらえると助かる。どちらもテスト用に持っていないのだ。
また、32ビットLinuxと64ビットLinuxで性能が大幅に異なるかどうかも気になる。
このコードはどこにあるのか？CentOS 5.5のボックスにいるので自分でビルドする必要がある。ビルドしたらLinux 32ビットと1MBキャッシュXeonの結果を報告する。
テスターが正しくビルドされたか確認できるよう、簡易ビルドをアップロードした。（i5やAMDは持っていない）問題なければ、完全なパッケージをまとめてリリース作業をすべて行う。
結果を記録できるように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%向上する。
Quote from: aceat64 on August 16, 2010, 12:37:54 AM
結果を記録できるようにWikiページを作成した：http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2
ハイパースレッディングが有効かどうか、物理コア数、Bitcoinが使用しているコア数の列を追加した方がいい。4wayなしでは、仮想コアの半分でハッシュした方がわずかに良い結果が出る。4wayでは、すべての仮想コアを有効にするとパフォーマンスが大幅に向上する。ハイパースレッディングをオフにすると、4wayの有無にかかわらずほぼ同じハッシュ量になると思う。
Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM
Quote from: aceat64 on August 16, 2010, 12:37:54 AM
結果を記録できるようにWikiページを作成した：http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2
ハイパースレッディングが有効かどうか、物理コア数、Bitcoinが使用しているコア数の列を追加した方がいい。4wayなしでは、仮想コアの半分でハッシュした方がわずかに良い結果が出る。4wayでは、すべての仮想コアを有効にするとパフォーマンスが大幅に向上する。ハイパースレッディングをオフにすると、4wayの有無にかかわらずほぼ同じハッシュ量になると思う。 Quote from: aceat64 on August 16, 2010, 12:37:54 AM 結果を記録できるようにWikiページを作成した：http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2
あなたの提案でページを更新した。いくつかのフィールドを説明する脚注も追加した。
私の-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/秒
Quote from: tcatm on August 16, 2010, 12:43:39 AM
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
Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM
Quote from: aceat64 on August 16, 2010, 12:37:54 AM
結果を記録できるようにWikiページを作成した：http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2
ハイパースレッディングが有効かどうか、物理コア数、Bitcoinが使用しているコア数の列を追加した方がいい。4wayなしでは、仮想コアの半分でハッシュした方がわずかに良い結果が出る。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スイッチで報告されるハッシュ速度がほぼ倍増する。この程度の改善は予想以上に思え、ボックスが本当にそれだけ速くハッシュしているのか、何らかの理由で数学演算が実際にはスキップされていて見かけ上の速度向上とブロック生成能力の欠如を引き起こしている可能性はないのか疑問に思う。
Quote from: satoshi on August 16, 2010, 02:57:57 AM
Quote from: tcatm on August 16, 2010, 12:43:39 AM
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
Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM
ハイパースレッディングが有効かどうか、物理コア数、Bitcoinが使用しているコア数のカラムを追加した方がいいかもしれない。4wayなしだと、仮想コアの半分でハッシュした方がわずかに良い結果が出る。4wayありだと、すべての仮想コアを有効にした方がかなり良いパフォーマンスが出る。ハイパースレッディングをオフにすると、4wayの有無にかかわらず同じくらいのハッシュ量になると思う。
おお、何か重要な発見をしたかもしれないな！
以前はハイパースレッディングが役に立たなかったのは、すべての処理が算術論理ユニットで行われ、ハイパースレッドがそれを共有していたためだ。
tcatmのSSE2コードは通常のx86命令とSSE2命令の組み合わせのはずで、一方がx86コードを実行している間に、もう一方がSSE2を実行できる。
ハイパースレッディングでどれくらい改善する？
数字は？どのCPUだ？ Quote from: tcatm on August 16, 2010, 12:43:39 AM sha256.cppを-O3 -march=amdfamk10でコンパイルすることを提案する（32ビットと64ビットの両方で動作する）。この命令セットをサポートするCPU（AMD Phenom、Intel i5以降）のみが-4wayの恩恵を受け、パフォーマンスが約9%向上する。
-march=amdfam10を試してみてくれ。
Quote from: Vasiliev on August 16, 2010, 03:17:07 AM
Quote from: satoshi on August 16, 2010, 02:57:57 AM Quote from: tcatm on August 16, 2010, 12:43:39 AM
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を試してみてくれ。
動いた。
おかしいな……同じものだと確信できるか？tcatm、amdfam10で試して同じ速度測定結果が得られるか確認してくれ。
model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz, Linux 64
約4950 khash/sで差なし
以下のアップデート： Code: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の実験でもそれ以上にはならなかった。
Quote from: jgarzik on August 16, 2010, 03:35:28 AM
Code:cpu family : 6
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%高速だ。
@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フラグを削除したが、それでも以下のようなエラーが出る。
Code: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
今試してみてくれ。
つまり、今のところ-4wayで速度向上の恩恵を受けるのはIntel Core i7プロセッサと一部の（Phenom？）AMDプロセッサだけということで正しいか？
Quote from: Ground Loop on August 18, 2010, 11:00:08 PM
つまり、今のところ-4wayで速度向上の恩恵を受けるのはIntel Core i7プロセッサと一部の（Phenom？）AMDプロセッサだけということで正しいか？
i5もだ。少なくとも私のMacBookProでは。
Mac以外のi5は対応してくれないのか？ Windows i5 64ビットではこちらだと遅くなった。 [訂正――正しくない。Windowsには-4wayがなく、Linuxマシンの方はXeonだった。]
私のCore i5ラップトップ（Ubuntu）は速度が倍増した。いや、正確には速度は倍増していない。速度は同じだが、CPU使用率が半分になった。フルCPU使用率に戻すことができない。とはいえ、ブロック生成時のラップトップはずっと涼しくなった。100%使用率に上がるのを確認したら報告する。
Quote from: Ground Loop on August 18, 2010, 11:14:26 PM
Mac以外のi5は対応してくれないのか？ Windows i5 64ビットではこちらだと遅くなった。 [訂正――正しくない。Windowsには-4wayがなく、Linuxマシンの方はXeonだった。]
Windows i5 64ビットではここでは遅くなった。 i5で遅くなったと言う人を聞いたのは初めてだ。他の全員がi5では4wayの方が速いと言っている。ハイパースレッディングを有効にするとさらにだ。
Quote from: nelisky on August 18, 2010, 11:02:25 PM
i5もだ、少なくとも自分のMacBook Proでは
良いな、ということはMacでも動作しているという確認だな？
LaszloがMacで-4wayのコードをコンパイルしたと言っていたので、-4wayスイッチはMacでも試せる。SVN上のmakefile.osxにはまだ入っていないと思うが、ビルドされたバージョンには含まれている。
Quote from: satoshi on August 19, 2010, 07:07:43 PM Quote from: nelisky on August 18, 2010, 11:02:25 PM
Quote from: Ground Loop on August 18, 2010, 11:00:08 PM
ということは、今のところIntel Core i7プロセッサと特定の（Phenom?）AMDプロセッサだけが-4wayで速度向上を享受していると言って正確か？
i5もだ。少なくとも私のMacBookProでは。
そうだ、問題なく動作している。以前投稿した数字はtcatmの変更を適用した古いsvnリビジョンのものだが、今日trunkをコンパイルしたところ、Makefileを再度調整する必要があったが、調整後は以前と同じ数字で問題なく動作している。
私のシステムでの変更は以下の通り。一部はwx-configの削除のように表面的なもの（WxWidgetsがインストールされていない場合に警告を避けるため）で、DEPSディレクトリのようにシステム固有のものもあり、32ビットライブラリがないために-arch i386があるとリンクステップが失敗する。 bsddbの変更は、タイプミスだと思う。IncludesとLibsはdb46を指しているが、リンカのオブジェクトリストではdb48になっている。とにかく、以下が動くようにした差分だ：
Code: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/秒
というわけで、パワーハウスリストからは外してくれ。 Smiley Grin
新しいAMD Bulldozerのプレスリリースを見た人はいるか？正しく理解していれば、コアあたり8つの64ビットハッシュを同時に処理できるはずだ。この同じコード設計を使えばかなりのスピードブーストになるだろう。
Slashdotに記事がある。 PC Perspectiveに詳細がある。
2009年11月にAnandTechでも取り上げられていた。
Quote from: ArtForz on August 21, 2010, 04:56:31 PM
- AMD K10: 128ビットユニット2つ
- Intel Nehalem: 128ビットユニット3つ これはおそらく、ハイパースレッディングが-4wayで性能を向上させる理由を説明している。3つのSSE2ユニットが過剰であれば、ハイパースレッディングがそれらをすべてビジー状態に保つのに役立つだろう。
ソースコードをレビューした。さらに最適化するアイデアがいくつかあり、4wayが部分的に壊れていることに気づいた：
main.cppより： Code: 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の最後のもの）しか処理しない。
こんな感じで修正できるはずだが、より高い難易度では安全ではないだろう。また、バイト順序を反転すべきかどうかもわからない。誰かレビューしてくれないか？ Code: 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); } } }