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公開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のパフォーマンス関連の続きになります。
前回、
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のパフォーマンスについて考察してみます。
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自体のコストはまた別の話になります）。
ADP公開一周年記念記事がまだ途中ですが、
Ver0.74のリリースを行います。
Ver0.74は、Accessでの整数のインサート時のエラーの改修と、pipe述語の実装があります。
pipe述語というのは、以前話に出ました、マルチスレッド機能の1つでパイプライン処理を実現する述語になります。
ちなみに、本リリースにに基づき、
LLPlanetsのライトニングトークで発表を行います。私を見かけた人は『ブログ見てます』と声を掛けていただければうれしかったりします。
では、pipe述語の使用例を見てみましょう。何回かやっていて最近ホットなSQLのパフォーマンスについての例になります。
関連記事１：[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１
関連記事２：SQLの実行パフォーマンスについて 2010
実験環境
JOINのパフォーマンス実験環境はこちらに記述しています。
実験１ 素直にSQL側でjoinをさせたものを実行(再掲）
例により、SQLで素直にjoinさせてみます。以下のようなコードになります。
,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
"INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).csv.prtn,next;
[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１の実験1と同じです。
実行時間も同じで、約119秒です。
実験２ ADP側でjoin(ネステッドループ＆キャッシュ）
続いて、ネステッドループjoinをADPのキャッシュ機能を使って高速化をはかります。
,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
,pipe
,sql( $db,$company, [$rec[0]], $name)
,csv($rec,$name).prtn,next;
[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１の実験2-Bと同じコードになります。
実行時間ですが、約117秒となりました。実験1と比べて約1.6%程速くなっています。
実験３ ADP側でjoin(事前にマップ作成）
３つ目は、ADPでも事前にマップを作成し、joinを行うことができます。
,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
,$key == $rec["CODE"].str
,csv($rec,$tbl[$key]).printn,next;
[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１の実験3と同じコードです。
実行時間ですが、約111秒で実験１より7%ほど速くなっていることが解ります。
続いて、pipe述語を使って並行処理をさせてみます。
実験１-Ｐ 素直にSQL側でjoinをさせたものをpipe実行
実験1のコードにpipe述語を挿入しています。
,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
"INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).pipe.csv.prtn,next;
実験１のコードとの違いは4行目の
,sql@($db,$str,[]).
pipe.csv.prtn,next;
のpipeという記述で、これがpipe述語になります。pipe述語で区切られたコードは並行で処理を行います。
つまり
,sql@($db,$str,[])
の部分（バックトラックの実行）と
.csv.prtn,next;
の部分は並行で動作します。
sqlの部分は、.csv.prtn,nextの実行中にバックトラックを行います。
next述語で、pipeまで戻りますと、sqlの実行を待ち（同期）データを受け取ります。
ややこしいかも知れませんが、図で示すとよくわかるかと思います。
図で、青の矢印の部分と赤の矢印の部分がそれぞれ別のスレッドになっており平行で動作しています。
pipe述語が無い場合の動作イメージは以下のとおりです。
比較してみますと分かりますが、sql述語～next述語まででループがありますが、それを2つに分けて実行するイメージになります。
UnixのシェルやWindowsのコマンドプロンプトで、|（パイプ）を使ってコマンドをつなげることがありますが、pipe述語の実行イメージはこれと同様になります。
シェルのパイプ(|)は20年以上前からあり、お手軽にマルチタスク処理を実現できるのですがプログラム言語レベルで使えるものがなく、マルチスレッドプログラムとなるとなぜかややこしくなります。
ADPではお手軽にマルチスレッドプログラムを体験して頂くため、その一つとしてパイプを実装しました。
実行時間は、約108秒で、約9％速くなっています。少しですが実験３よりも速くなっていることが解ります。
実験２-Ｐ ADP側でjoin(ネステッドループ＆キャッシュ）でpipe実行
続いて、実験2のコードにpipe述語を挿入しています。
,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
,pipe
,sql$( $db,$company, [$rec[0]], $name)
,csv($rec,$name).prtn,next;
実行時間は、約89秒で実験２と比べて約24%速くなっています。
興味深いのは実験１－Ｐよりも速度向上が大きいです。pipe述語は半分に分割してそれぞれ実行するという方式をとっていますが、当然ですが常に半分になるとは限りません。上手く半分に分割できる場合もありますし、そうでない場合もあります。そのような関係でこのような逆転現象が発生します。一口にＪＯＩＮのパフォーマンスといってもこのように様々な要因が絡んできますので、一概に『○○が効率的』といえないことを表す良い例となっています。
実験２-ＰＰ ADP側でjoin(ネステッドループ＆キャッシュ）でpipe実行2
実験2-Pのコードにさらにpipe述語を挿入しています。pipe述語は1つだけでなく複数入れることもできます。
,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
,pipe
,sql$( $db,$company, [$rec[0]], $name)
,pipe
,csv($rec,$name).prtn,next;
実行時間は、約112秒で実験２－ＰＰと比べて逆に遅くなっています。このように闇雲にマルチスレッドを行っても必ずしも速くならない場合がある（もちろん速くなる場合もある）のが面白いところです。pipe述語を2つ使うと3つスレッドが動作しますが、実験環境ではCPUコアが2つしかないので足の引っ張り合いのようなことになったようです。
実験３-Ｐ ADP側でjoin(事前にマップ作成）でpipe実行
続いて、実験3のコードにpipe述語を挿入しています。
,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
,$key == $rec["CODE"].str
,csv($rec,$tbl[$key]).printn,next;
実行時間は、約91秒で、実験３と比べて約18%速くなっています。
ちなみに実験3-Pからさらにpipeを挿入しても良いのですが、実験2-Pの時と同様にあまり速くならないので省略します。
結論
各実験結果を示します。
pipe述語の効果
| 実験 | 実行時間（秒） |
|---|
| 実験１ | 119 |
| 実験２ | 117 |
| 実験３ | 111 |
| 実験１－Ｐ | 108 |
| 実験２－Ｐ | 89 |
| 実験２－ＰＰ | 112 |
| 実験３－Ｐ | 91 |
実験１～３どの場合でも、pipe述語が有効だということが分かります。これは、
・DBMSからデータを取得する
・ファイルへ書き出す
という2つのIO処理があり、pipe述語によって、それらを同時に実行することが出来る為です。
また実験２－ＰＰと実験２－Ｐを比べても分かりますとおり闇雲にマルチスレッド化しても高速化が図れない場合もあります。
パフォーマンスアップは様々な要素が関わってきますので実験により確認しながらということが必要になります。
pipe述語はお手軽にマルチスレッドを実現でき、また取り外しも楽なので簡単に実験や試行錯誤が出来ます。
ADPのpipe述語はキャッシュ機能と同様に便利な道具として利用できるかと思います。
また、実験１－P、２－P、３－Pを比較しますとどれをとってもパフォーマンスにあまり差がないことがわかるでしょう。ADPの開発にあたりプログラマの自由度を高めるということも考慮しています。つまり、『○○でなければダメ』ではなく、どのアルゴリズムを採用するかはプログラマーの判断で、いか様にも選択できるような言語を目指しています。
追記：コメント欄での指摘およびテスト再現性を考慮してテスト環境を整備して再度計測しています。