マルチスレッド＆アセンブラプログラミングをしてみる（ドラフト）

　多コアCPUのコアを使い切るにはどうするか？とここ数年考えていたのですが、そういえばコラッツ予想（3n+1問題）を確認するプログラムはちょうどよい例だと思いプログラムを作成してみました。

CollatzAsmについて

　せっかくなので64ビットアセンブラで作成し、128ビット（2の128乗）までの数を扱えるようにしました。ちなみに64ビットだと入力が数百億程度（35ビット程度）で内部の計算が桁あふれを起こします。
Visual Studio 2022(C++/Asm)で作成しています。ここからプロジェクトファイル一式をダウンロードできます。

　Visual C++ですが32ビットバージョンはインラインアセンブラが使えるので、お手軽にアセンブラを使えたのですが、64ビットになりなぜかインラインアセンブラをサポートしなくなりました。ということで約30年ぶりにアセンブラのソースコードを書きました。
ちなみに、16ビット時代はアセンブラプログラミングの参考書が豊富にあったのですが、64ビットになりあまり見当たらなくなりました。昔はミックスドランゲージといって、Cからアセンブラを呼び出す方法もよく解説をされていたのですが、今では、ここに資料があるくらいで、基本的なことが分かっている人じゃないと意味不明かと思われます。
詳しい解説はご希望があればやりますが、このプロジェクトをサンプルとしてもらえればと思います。

　また、このサンプルはC++14のマルチスレッドのサンプルにもなっています。長い間マルチスレッドプログラムと言えばOSのAPIかランタイム関数を使って作っていたのですが、C++14からプログラミング言語にサポートされたということで作成してみました。

実行例は以下のとおりとなります。

最初の引数で何処までの数を確認するかを入れ、2つ目の数は並列度（スレッド数）になります。
サンプルでは10になっていますが、当然コア数以上の値をいれます。32論理コアに対して100とかにしてもパフォーマンスが上がります(後述）。

CollatzAsmBenchについて

　アセンブラでのプログラミングに限った話ではないのですが、プログラムの最適化の過程で試行錯誤を行うことがあります。特にアセンブラでプログラムすると様々な命令を使うことができるのでそのバリエーションが増えるかと思います。
ということで試行錯誤の記録として10個程アセンブラのコードのパフォーマンスを比較するプログラムを書いてみました。
以下、実行結果になります。

ChatGPTの出力コードとの比較

　いわゆるバイブコーディングということで専用のツールも出てきていますが、コラッツ問題を扱うプログラムに関していうと、どこにでもあるのでChatGPTでも簡単なプロンプトでかなりいい感じのコードを出力しています。ということでChatGPTでプログラムを出力させてみました。、実際に試してみたところ可能でしたがあまり速度が変わらなかったので、今回はアセンブラでの出力はしていません。ChatGPTが作成したマルチスレッドのものを掲載します。

　私が作ったコードと比較するとマルチスレッドの初期化の取り扱いがうまいです（emplace_backを使っている）。一方で、データ長は64ビット止まりで、並列性も論理コア数に従ってスレッドを作成していますが（hardware_concurrencyメソッドを呼んでコア数を取得している）、このプログラムの場合、各スレッドの実行時間が必ずしも同じではないので、スレッド数をより多くして各スレッドのタスクを細かくした方が、実行時間のばらつきの減少が期待できます。一方で、一般論になるのですが、論理コア数以上のスレッドを実行させると各スレッドがCPUのリソースを食い合いすることになるので、実行スレッド数を論理コア数に合わせるのも一つの手になります。

　今回はアセンブラでは比較をしませんでしたが、CやC++のコードを単純にアセンブラにしてもあまり早くならないということもあります。一方で128ビットのような桁数の多い計算をさせる場合、アセンブラには桁あふれを処理する命令があり、CやC++で組むよりはるかに効率的なプログラムが記述できます。機会があればChatGPTでアセンブラプログラムの最適化を行いたいですが、↑の例にあるようにAIに任せるより、自分で工夫をした方が手っ取り早い面があります。もちろんですがアイデア出しをAIに頼ることもできますので、こういうことではあまりAIと人間の比較は意味がない（人間からしたらAIも利用する）ということになりますが、2025年9月現在、このあたりのチューニングはまだ人間の方に一日の長があるかと思います。（追記）この記事の公開後、１週間でClaudebotと名乗るロボットからZipファイルがダウンロードされたのでひょっとしたらClaudeにコードがパクられるかもしれません。

　最後に実行結果を

ということで、倍以上のパフォーマンスを示しています。逆にいうと倍程度にしかならないのですが、ある処理時間が半分になるということは2020年代のCPUの進化でいうとほぼ10年に相当します（この場合シングルスレッド性能の比較になる）。つまり上手くアセンブラでプログラムを書き直すことができればCPUの進化を１０年先取りできるとも言えます。CPUのシングルスレッド性能の向上が顕著だった90年代ですと概ね1，2年でパフォーマンスが倍になっていました。
余談ですが、アセンブラでのプログラミングは8ビットや16ビットの時代は割と一般的でした。90年代以降ではCPU自体の進化が早かった為、アセンブラでのプログラミングがエンコード等、いやゆるSIMD命令を使うため等、ニッチになった感がありました。CPUのシングルスレッド性の向上が見込めなくなった昨今、アセンブラでのプログラミングが見直されるかもしれません。
話を戻すと、コラッツ予想の確認プログラムの場合、スレッド数を100にしても性能が伸びていることを確認できます。これは、前述のとおり値により処理ステップにばらつきがあるためで、区間を細かくした方が（スレッド数を多くし多方が）、CPUから見た場合のトータル処理時間が平均化される為です。

Intel Turbo Boost Max Technology 3.0 と ハイパバイザー

Intel Turbo Boost Max Technology 3.0(ITBM)とは、Broadwell-E以降のハイエンドCPUに搭載された機能で、要するに「さらにブーストする（クロック周波数が上がる）」機能になっている。
Core i7-6950X(Broadwell-E)の場合、従来のブースト（Intel Turbo Boost Technology 2.0)では、3.5GHzまでの最大周波数となるが、3.0になると、1コアのみであるが4.0GHzまでブーストする。下記タスクマネージャの画面では3.88GHzまで周波数が上がっている。



比較で、下記はIntel Turbo Boost Technology 2.0までが有効のちょうど1世代前のCore i7-5960X(Haswell-E)のタスクマネージャの画面。3.47GHzまで周波数が上がっている。



以前、Core i7-6950Xを入手しましたが、Windows11のセットアップを行い、Intel Turbo Boost Max Technology 3.0(ITBM)のドライバーを入れたが、気が付いたらログイン時に起動時にエラーが出るようになった。

「ITBM Driver Not Available
　Exiting application」

これは、Intel Turbo Boost Max Technology 3.0のコンソール画面の起動時にでていて、結局コンソール画面は出てこなくなった。
クロック周波数を見てみると、下記のように5960Xレベル（Intel Turbo Boost Technology 2.0）まで周波数が落ちていることが解る。



エラーメッセージで調査をしたのですがエラーメッセージの検索では不具合原因にはたどりつかなかった。長らくそのまま放置していたが、最近分かったのが、どうもハイパバイザーをONにしているとダメらしいことが解った。さらに調査をしていくと、

インテルのサポートページ（ページを見るには登録が必要）を見るとTurbo Boost Max Technology 3.0はサポートしているが、Intel® Turbo Boost Max driver solutionはサポートしていないという一見、良くわからん回答があった。

どうやら、driverは動かないということなので、「ITBM Driver Not Available」との整合性がとれる。

結局、Turbo Boost Max Technology 3.0は動作しないのか？という話になるが、Turbo Boost Max Technology 3.0は以下の２つの機能がある。

（１）全コアに負荷がかかってもブーストクロックまでブーストする
（２）１コアだけ、より高クロックにブーストする。

で、どうやらハイパバイザー環境では（１）は有効となるが、（２）が無効になるらしい

ということで、試しにCinebenchで全コアに負荷をかけてみたが、確かに約3.5GHzまで動作した。ちなみにCore i7-5960Xの場合、全コアに負荷をかけると3.3GHzまで周波数が落ちた。

6950Xと5960Xを比べると、ハイパバイザーを使うならコア数が多くさらに最大メモリ搭載量が倍の6950Xが良いが、Turbo Boost Max Technology 3.0の機能に制限が加わるのは痛い。悩ましいところである。

追記：
Vtuneを使おうとするとハイパバイザーを止めなければならず、結局、6950Xのマシンと5960Xのマシンのメモリを入れ替えて5960Xの方をハイパバイザーを使うように変えた。

[ADP開発日誌]Ver 0.82のリリース

　忙しさにかまけてブログの更新を怠っていましたが、気がつけば今月末でADP公開2周年になります。公開一周年記念の記事も完成していないのに、時の立つのは速いものだと感慨に浸っております。

というわけで、間が空きましたがVer 0.82のリリースです。

今回の変更点は、
・バグフィックス
・sprintfの改修
・パフォーマンスの改善
になります。
また、今回のリリースからホスティングサイトをSourceforge.JpからSourceforge.netに変えました。

sprintfの改修ですが、詳しくはsprintfのマニュアルをご参照頂くとして、たとえばDBからの戻り値をsprintfで成型する場合に、便利に使えるようにしています。
例えば、以下のように記述することができます。

,db.sql@("SELECT * FROM users WHERE hogehoge ",[]).each.
 sprintf("%s:first_name; %s:secondname;様 の誕生日は、%s:birth_dayです。").
 prtn,next;

DBの取得から成型、表示まで一気に書けるところがAnother Data Processorらしくなかなかよろしいかと思います（自画自賛）。


パフォーマンスの改善ですが、Ver 0.60以来の改善になります。
Ver 0.60から0.81になったことでパフォーマンスが下がりましたが、Ver 0.82は0.60以上のパフォーマンスになりました。

前回と環境が変わりましたので改めてベンチマークをとりますと、

◆Windows上でのJavaScript vs ADP
■マシン
・CPU　　Core i7-920（2.66GHz HT/Turbo Boost OFF）
・メモリ　12GB（DDR3-1066 2GB × 6）
・OS　　　Windows 7 Ulitimate (x64) 電源管理：高パフォーマンス
　
■結果

28のフィボナッチ数を求める時間

IE8（64ビット版）	452ミリ秒
FireFox 13.0.1	12ミリ秒
ADP 0.60（32ビット）	343ミリ秒
ADP 0.81（32ビット）	452ミリ秒
ADP 0.82（32ビット）	265ミリ秒

0.60と比べても20%以上速くなっています。今回はChromeの結果を掲載していません。またFireFoxですが、12ミリ秒とかなり速いです。前回パフォーマンスについて『FireFox3.6未満』と記載しましたが、残念ならがFireFoxと比較するのは厳しくなりました。

という訳で別の比較が必要になりましたので、ADPと、PHP、Javaと比べてみます。

◆CentOS6.2上でのPHP,Java,ADP
■マシン
・CPU　　　Core i7-980X(3.33GHz HT/Turbo Boost OFF）
・メモリ　　24GB（DDR3-1066 4GB × 6）
・ホストOS　Windows 2008R2（Hyper-V）
・ゲストOS　CentOS 6.2（実行環境）

■テストコード
　テスト１：28のフィボナッチ数を求める　PHPソース(Test1.php)　Javaソース(Test1.java)　ADPソース(Test1.p)
　テスト２：１０万までの素数を求める　PHPソース(Test2.php)　Javaソース(Test2.java)　ADPソース(Test2.p)

テスト２のPHPのコードですが、Stackoverflowさんのコードを使わせて頂きました。

■結果(timeコマンドのuser部分を抜き出した）

Linux（CentOS6.2 x64)上でのPHP（5.3.3）、Java（1.6）、ADP(0.82）の比較

	テスト1	テスト2
PHP(5.3.3)	207ミリ秒	31,915ミリ秒
Java(1.6)	38ミリ秒	4,862ミリ秒
ADP(0.82)	190ミリ秒	3,765ミリ秒

テスト結果をみますとADPはPHP5.3以上のパフォーマンスが出ています。特にテスト２の結果が1桁近く速くなっており、Javaよりも早くなっています。テスト１ではADPよりJavaが圧倒的に速いのですが、テスト２ではADPの方が速くなっています。テスト２のJavaはコレクションクラス（ArrayList）を使っておりその分遅くなっているようです。実際にこの部分を固定配列にすると実行速度は1/10になります（もっともコレクションクラスを使わないという選択肢はないかとも思いますが）。ADPの配列はC++で実装しています。私自身気づいていませんでしたが、かなり効率良く実装されているようです。

また、テスト２の、リンク先のトピックは元々「PythonがPHPより遅いのだが？」という質問でしたがADPのパフォーマンスはそれ以上なのでいわゆるスクリプト言語より速いことが解ります。
もっとも一部のテストからですので今後も色々ベンチマークテストを行い検証しようかと思います。

ちなみに、もっと大幅にパフォーマンスアップが望める改善策を思いついたのですが、かなりの改修が必要なので、ここまでの成果を0.82としてリリースし、より速くしたものを後のバージョンで出そうかと思っています。打倒JavaScriptですね（まぁJITを入れないとダメなような気がするが・・・）。

JOINのパフォーマンスについての考察2（リレーションとの関係2）

ちょっと間があきましたが、JOINのパフォーマンス関連の続きになります。
前回、JOINのパフォーマンスについての考察（リレーションとの関係）でJOINを行った結果、データが非正規化するとその非正規化の度合いによってパフォーマンスが下がるという話をしました。
前回の記事では、1対ｎの結合ではJOINを外す（単純なSQLに分割してホスト言語側で結合させる）ということで、定性的な話しかしていませんでしたが、幾つか実験を通して、もう少し定量的な話をしてみます。
『たかがJOINで、なぜこねくり回すのか？』と思われるかもしれませんが、こういう実験＆考察というのは意外に行われていないかと思います。私自身定性的なことは理解していたつもりでしたが、実際に実験を行うと色々と発見がありますので、記事にしてみます。
大切なことは解った気になることではなく真実を追究する姿勢で、先入観を持たずにきちんと実験を行いパフォーマンスに対する感性をみがくことは大切かと思います。

今回、調査するアルゴリズムについて

今まで何回か実験してきましたが、実験で使用してきたアルゴリズムについて説明します。

１．SQLでJOINを行う。

SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME
FROM Price INNER JOIN Company ON (Price.CODE = Company.CODE)

という風にSQLでJOINを行います。普通の処理になります。

２．ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）

　１．のSQLを以下のように分割します。

(1) SELECT CODE,RDATE,OPEN,CLOSE FROM Price
(2) SELECT NAME FROM Company WHERE CODE = ?

(1)のSQLを実行して結果を取得しますが、NAMEについては(2)のように再度SQLを発行します。
ここで、単純にPriceテーブルの全ての行に対して(2)SQLを発行するのではなく同じ結果をキャッシュして同じCODEの場合はキャッシュからデータを取得するようにします。
　

３．ホスト言語側でJOINを行う（ハッシュJOINを行う）

１．のSQLを以下のように分割します。

(１) SELECT CODE,NAME FROM Company
(２) SELECT CODE,RDATE,OPEN,CLOSE FROM Price

（２）のPriceテーブルからのデータの取得に先立ちまして、（１）でComapnyテーブルから全てのデータを取得しておきます。
多くのDBMSで行っているハッシュ結合を真似ています。

1対ｎの2つのテーブルのJOINにおけるパフォーマンスモデル式

続いて、各アルゴリズムのパフォーマンス（実行時間）のモデル式を示します。
ここで、
n ： Priceテーブルの行数
m ： Companyテーブルの行数
c10,c10,c20,c21,c22,c23,c30,c31,c32 ：　比例定数
になります。

１．SQLでJOINを行う

１．のパフォーマンスのモデル式は以下のようになります。

c11 * n + c10

　Priceテーブルの行数に比例した時間で結果を取得できます。ここでc11は比例定数であり、C10はオーバーヘッドにあたります。

２．　ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）

　２．のパフォーマンスのモデル式は以下のようになります。

c21 * n + c22 * m + c20

　Priceテーブルの行数に比例した時間と、Companyテーブルの行数に比例した時間およびオーバーヘッドの合計になります。
　『c22 * m は　c22 * n * m になるのでは？』と思われるかと思いますが、キャッシュのおかげでこのようになります。
また、「１．SQLでJOINを行う」と比べますと、c22 * m と余計な項が付いていますので、

SQLでJOINした方が速い

と早合点される方がいらっしゃるかと思いますが、JOINのパフォーマンスについての考察（リレーションとの関係）で述べたことは、c11とc22の定数値の差異となって現れてきます。

３．ホスト言語側でJOINを行う（ハッシュJOINを行う）

　３．のパフォーマンスのモデル式は以下のようになります。

c31 * n + c32 * m + c30

　面白いことですが、形式的には「２．　ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）」と同じになります。
ちなみに、[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１ にあります、「SQLの発行回数のオーバヘッドはどこにいったんや？」と思われるかもしれませんが、それはc32とc22の差異に出てくるということになります。

実験と結果

　今回の実験では、nの値を変えながら実行時間を計測することにより、各モデル式の定数を求めます。求めるといってもグラフを書いて状況を観測します。厳密には回帰分析とかを行うことになるでしょうが、グラフが直線になることと、ｎが増えたときの傾向をつかめればよろしいかと思います。
アルゴリズムの教科書ではオーダーという概念があり、オーダーでは定数を求めることは無意味とされています。つまり上記のアルゴリズムは論理的には違いがなくどれも一緒ということになります。
つまり、2倍や3倍の差はあまり意味がないということですが、もっとも、実際の現場ではこのような差にも敏感になるので、きちんと計測して値を出すことになります。
また、今回はｍは固定（約2000）で行っています。ｍが変動したときにどう変わるのかも興味深いですが今回は、m << n ということで結果にはあまり影響しません。

先ずは、結果から、

Priceテーブルから取得する行数を変えながらSQLを実行（単位ms）

	0行	373,740行	1,172,191行	2,002,749行	4,671,568行
１．SQLでJOIN	718	10,015	29,938	52,329	119,192
２．キャッシュ付のネステッドループJOINを行う	671	10,469	30,172	49,814	116,770
３．ハッシュJOINを行う	2,828	11,422	29,797	49,845	110,988

つづいて、グラフを以下に示します。

縦軸が時間で、横軸が行数（ｎ）になります。グラフをみますとPriceテーブルの行数（ｎ）が増えると「１．SQLでJOIN」より、「２．キャッシュ付のネステッドループJOINを行う」や「３．ハッシュJOINを行う」の方が速くなっていくことが解るかと思います。

パフォーマンスにシビアになる時は、往々にしてｎの行数が増えるような場合にあたるということになります。その場合は１より２や３を選択した方がよいということになります。

もっともグラフを見て解るとおり差はあまりないので、通常はやはり普通にSQLでJOINを行い、パフォーマンスを稼ぎたくなったら２や３を検討するということになるでしょう。

JOINのパフォーマンスについての考察（リレーションとの関係）

コメントを頂いたのですが、ちょっと返し方が悪かったのか音信普通になりましたので、改めてJOINのパフォーマンスについて考察してみます。

1対ｎ結合の場合、JOINとは正規化データから非正規化データを作り出す操作になる

RDBのテーブルは、きちんと設計されていれば、正規化されています。つまりデータに重複がなく容量の面で効率的になっています。ここで正規化データとはあくまでもRDBにとって効率的というだけでそれ以上のものではありません。一方で人間が理解しやすいデータ形式は必ずしも正規化データというわけではなく、往々にして非正規化されたデータの場合があります。
JOINを行うということは正規化されたデータを非正規化データに戻す操作ということに相当します。つまり、効率のよいデータから人間にとって理解しやすいデータ形式に戻す操作になります。JOINは正規化されたデータから非正規化という効率の悪いデータ形式に変換する操作になります。
SQLでJOINを行い、その結果を取得するということは何らかの非効率な行為が行われているということがわかるかと思います。
RDBのコピーを行おうと考えた場合、わざわざJOINなどせずに、テーブル毎にコピーを行おうとするでしょう。RDBからデータを取り出すとき同様に正規化された単位でデータを取得した方が有利な場合があるということは理解できるかと思います。

RDBでは正規化データから非正規化データを作り出す方が非正規化データから正規化データを取り出すより効率的

先ほど、JOINは非効率といいましたが、なぜRDBでは効率の悪いJOINが行われるのでしょうか？
理由は簡単で、RDBの理論では、
・非正規データ から 正規データ を作る
操作より
・正規データ から 非正規データ を作る
操作の方が効率的と考えられているからです。非正規データから正規データを得るにはグループ化を行います。つまりGROUP BYを行う必要がありますがこれはつまりソートを行った上に重複したデータを圧縮することに相当します。一方でJOINはデータの検索に相当します。例外はありますが検索の方がソート＆圧縮より効率的なのは理解できるでしょう。
さらに、正規化データは非正規化データより更新が容易ということもあります。
つまり、関係データベースの世界では正規化されたデータは非正規化されたデータより効率がよいと考えられています。ちなみに、この認識が間違って拡大解釈され、『SQLは効率がよい』という誤解が生まれたと想像されます。

1対ｎの結合で一方のレコードサイズが小さいとき、2つのテーブル間の単純なJOINは効率的、だがデータの出力が非効率

FROM table_a INNOR JOIN table_b ON (table_a.table_b_ID = table_b.ID)
のSQLがあるときに、
table_aがマスターを参照するテーブルで、table_bがマスターテーブルと仮定します。つまりtalbe_aとtable_bが1対ｎで結合されており、さらにtable_bがメモリに入る場合、JOIN自体のコストはほとんどかかりません。
2011年現在、サーバーに搭載されるメモリ容量が数十GBのオーダーになります。一方でマスターテーブルの容量は多く見積もっても数百万件のオーダーになり、各データを多く見積もって１KBとしてもマスターテーブルのデータ容量は数GBのオーダーとなります。実際にはJOINに必要なデータのみメモリにおいた場合、必要なデータは1桁も2桁も減ることになります。結果として1対ｎの結合ではほどんどの場合、マスターテーブル側はメモリに乗ることになり、JOINにおいてマスター表の操作は高速に行えます。
しかし、1対ｎの結合では、結果を取得する場合に、結果データが非正規になる為に非効率になります。
この場合、JOINを分割して、呼び出し言語側でJOINした方が理論的には効率的になります。実際どこまで効率的になるかは分割による複数回のSQLの呼び出しのオーバヘッドと繰り返しデータの量に左右されます。

1対1結合の場合は、JOINは出力も含めて効率的になる

1対1結合の場合は、結果データも正規化しているのでJOINは効率的になります。JOIN自体が効率的に行えるかどうかはデータ量やデータ（または結合キーのインデックス）が整列されているかどうかによります。

結論

以上のように、扱うデータの性質によってSQLでJOINさせる方がよい場合とSQLではJOINさせない場合の方が理論的に速くなる例を示しました。
結合の種類が1対ｎの場合、JOINを行うとデータ非正規化し、容量が増えるので出来るだけJOINを遅らせるテクニックが有効になる場合があります。
実際にどのような状況のときにJOINを遅らせたほうがよいかですが、マシンのスペック、ネットワークの環境等に依存しますが、傾向として行数が増えた場合や1対ｎのJOINの数が増えるとJOINを遅らせる方が有利になります。このような場合でパフォーマンスに問題が発生した場合にJOINを遅らせるテクニックを検討されると上手くいく可能性が高まります。
一方で、結合の種類が1対1の場合、データは非正規化しないので、SQLの発行の段階でJOINを行えば有利になります（JOIN自体のコストはまた別の話になります）。