Previous Page | Next Page

llama.cppの開発＆最適化、環境構築

老兵は死なず、AIと踊る


　私のAI体験、2026年2月の活動、ということで、我がAIマシン（Core i9-10980XE,メモリ256GB＋GeForce GTX1080Ti、GeForce RTX3070）にllama.cppの環境構築を行ったので、そのメモになります。


（事前セットアップ）


  • OSのセットアップ、各種ドライバーをインストール
  • Cuda toolkitをインストール
    インストールされているグラフィックボードのバージョンに合ったバージョンをインストールする。
    例）GeForce GTX1080Ti用のCuda toolkitは、12.8.0になる。
  • Visual Studioをインストール
    Visual Studio 2022 community Editionをインストール
  • Gitもインストールしておく

llama.cppをダウンロード＆ビルド


  • https://github.com/ggml-org/llama.cppのページにあるQuick startのBuild from source by cloning this repository - check out our build guideを参照
  • ダウンロードは
    git clone https://github.com/ggml-org/llama.cpp cd llama.cpp
    で行う。
  • ビルドのコンフィグレーションを行う
    cmake -B build -DGGML_CUDA=ON -DCMAKE_CXX_FLAGS="/utf-8 /EHsc" -DCMAKE_C_FLAGS="/utf-8" -DLLAMA_BUILD_BORINGSSL=ON -DLLAMA_BUILD_LIBRESSL=ON -DCMAKE_CUDA_ARCHITECTURES="61;86"
    最後の、DCMAKE_CUDA＿ARCHITECTURESの61が1080Ti、86が3070用の設定になる。
  • ビルドを行う
    cmake --build build --config Release
  • コードページに関するワーニングがでるが無視しても動作した。一部のツールは文字化けするかもしれません。

動作確認


  • llama-serverの実行
    llama-server -hf unsloth/Qwen3-VL-235B-A22B-Thinking-GGUF:Q5_K_M -ngl 0 -b 512 --flash-attn on --host 0.0.0.0 --port 8080

    ファイアーオールが警告が出たらポートを解放する
  • クライアントからアクセス
    http://（llamaのマシンのIP）:8080/でアクセス


モデルがQwen3-VL-235B-A22B-Thinking-GGUF:Q5_K_Mで、だいたい、１～２Token/sec、つまり1秒に1文字出力される。何かすると20分ぐらいかかるので、これを高速化できればうれしいという話。


Visual Studioからの起動＆コンパイル


  • 　llama.cppをダウンロードした場所にbuildフォルダが作成される。このフォルダをカレントディレクトリとしてVisual Studio（devenv.exe）を起動する。
    下記の要領でショートカットを作っておくと良い

    リンク先："C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe" llama.cpp.sln （デフォルトインストール）
    作業フォルダ：C:\llama.cpp\build （llama.cppをc:\llama.cppにダウンロードしたと仮定）

    「詳細設定ボタン」→「管理者として実行」にチェックを入れる（プロファイル時に必要）。

  • デバックモードとリーリースモードで、リコンパイルを行ってみる。



VTuneのインストール＆動作確認


  • VTuneをインストール
    使っているCPUに対応したバージョンのVTuneをインストールする。
  • VTuneは、最新バージョンしかダウンロードできない。2026年2月現在の最新バージョン2025.8.1.7では、Ice Lake以降のCPUしか対応していない。Core i9-10980XEは、Cascade lake（1世代前）なので対応していない。ので、事前にダウンロードしているもの（2023）を利用する。
  • 2022では、Windows11 25H2の環境ではインストールに失敗した（厳密にいうと2024のインストール＆アンインストール後に行ったのでそのせいでインストールに失敗した可能性もある）。
  • 2024では、正常にプロファイルが取れなかった。
  • インストール時のオプションで、Visual Studioのツールにチェックが入っていることを確認すること。
  • 先に2024をインストールするとアンインストールしても一部ファイルが残っており、2023をインストールしてもショートカットが2024側を指すので起動しない。
    C:\Program Files (x86)\Intel\oneAPI\vtune
    以下のフォルダをチェックすること。
  • 出来れば、古いバージョンから試して不用意にバージョンをあげない方がよい。
  • VTuneの起動
    インストールが終了すると、Visual Studioのメニューにアイコンがでるのでプロファイルを行える。
  • ソースコードを見るには、プロジェクトの設定でデバッグ情報を出力するようにすれば良いが、デバッグモードで行った方が面倒が少ない。この場合、コードが最適かされないのでパフォーマンスが下がるが、概ね、半分ぐらいの速度になる。あまり遅くなっていない。そもそも手動で最適化を行うのでコンパイラの最適化は止めても大丈夫かと思う。手動の最適化が終わった後に最終的にＯＮにすればよい。




目的の箇所にたどり着けたのでよいが、途中、Bottom-upタブの見方が良く分からないので学習する必要がある。


最も時間がかかっている個所が判明したが、

sumi = _mm256_add_epi32(sumi, _mm256_add_epi32(p16_0, p16_1));

どうも、AVX2のコードのようである。まずは、AVX512で動かすにようにして、最適化をかけるようにする。


ボトルネックについて


　パット見た感じなので確定的ではないですが、ボトルネックになっているコードは、モデルの重みデータを戻す処理のようである。このモデルデータは、重みが5ビットのものを使っているので内部で8ビットにしているようです。
llama.cppはAVX512を使うといっているがこのデータを戻すところはAVX2のままのようです。
考えてみれば当たり前といえば当たり前なのですが、なんとなく5ビットに圧縮したら展開するのに時間がかかるのではないかと思っていたら、その通りのようでした。この部分の処理時間は全体の約70%ぐらいを占めており、この部分を最適化することは期待がもてる。
もっとも、RAMを大量に積んで利用するモデルを8ビットとかにすればこの部分の処理をカットすることが出来るのでかなり早くなるかと思うが、メモリはこれ以上は積めないので最適化を頑張ろうかと思う。


老兵は死なず、AIと踊る

2026-02-18 | コメント:0件

変数は「箱」か「名札」か？― 初心者教育から束縛モデルまでを考える

　以前、「変数は箱か名札か？」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。



プログラミング教育の現場では、今も昔も「変数とは何か？」が最初のハードルです。
伝統的には「変数は値を入れる箱」と説明されますが、
最近では「変数はオブジェクトに貼られた名札（ラベル）だ」と主張する声も聞かれます。


一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。



Ⅰ. 初心者教育での「箱」モデルの意義


最初に登場するのが、もっとも直感的な「箱」モデルです。


変数とは、値を入れておく箱である。


a = 1
b = a
a = 2

このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。


C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。



Ⅱ. 「名札」モデルの登場と混乱


一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。


変数は、オブジェクトに貼る名札である。


a = [1, 2, 3]
b = a
a[0] = 9

ここで b を出力すると [9, 2, 3]。
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。


しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。

Ⅲ. C/C++が示す「共存モデル」

C や C++ では、値型と参照型（ポインタ型）が共存しています。

int a = 1;
int &r = a;

このとき r は a の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。

教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。

ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。

Ⅳ. 関数型言語における「束縛モデル」

さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値（あるいは式）に束縛される名前”だ」
という考え方が登場します。

束縛（binding）＝変数と式の対応を定めること。

Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。

x = 1
y = x + 2

このとき x や y は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。

この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。

Ⅴ. 束縛モデルの強みと限界

束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL（ドメイン固有言語）の分野では、
式構造を保持して解析・変換する必要があります。

しかしその一方で、束縛モデルには現実的な制約もあります。

項目 束縛モデル（遅延評価） 参照モデル（即時評価）
抽象性 高い 低いが直感的
実装効率 低い（オーバーヘッドあり） 高い
デバッグ 難しい（評価タイミング不明） 容易
メモリ予測 困難 明確

結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する設計を採用しています。

Ⅵ. 束縛モデルが主流にならなかった理由

    1. パフォーマンスとメモリ効率の問題
      遅延評価や式構造の保持にはコストがかかる。

    1. 最適化の困難さ
      コンパイラが静的解析しにくく、最適化しづらい。

    1. デバッグや可視化が難しい
      どの時点で評価されたかが分かりづらい。

    1. 実際に必要なケースが限られている
      自動微分やDSLなど一部領域に限定される。

Ⅶ. 現代的アプローチ：必要な部分だけ「束縛的」に

今日では、C# の Expression<T> や
Python の sympy / jax、
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。

つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。

Ⅷ. 教育的まとめ：段階的理解のすすめ

学習段階 目標 モデル 教育上の重点
初級 値の代入と操作の直感的理解 箱モデル シンプルな心象で理解する
プロ（中級） メモリと参照の関係を理解 箱＋参照モデル オブジェクト共有・ポインタ・参照
研究レベル 抽象的な束縛・遅延評価・純粋関数 束縛モデル 数理的抽象化・関数をデータとして扱う

Ⅸ. 結論：「名札」は“箱”を超えるものではない

「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。

しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。

実務的な観点から見れば、
「箱モデル＋参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。

最後に：比喩の目的を取り違えない

変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。

重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。

プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造（値 → 参照 → 束縛）を自然に昇っていけるように導くこと
なのかもしれません。

この文章は、ChatGPTとの共同作業により作られています。

2025-10-30 | コメント:0件

マルチスレッド＆アセンブラプログラミングをしてみる（コラッツ予想のプログラム）

　多コア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から見た場合のトータル処理時間が平均化される為です。

2025-09-08 | コメント:0件

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の方をハイパバイザーを使うように変えた。
2022-09-18 | コメント:0件

[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.112ミリ秒　
　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を入れないとダメなような気がするが・・・）。
2012-07-12 | コメント:0件
Previous Page | Next Page