OCaml Weekly News

https://github.com/craff/CamlSurf

CamlSurf は Gles3 を使って書かれたソフトウェアで、陰関数曲面や曲線の可視化を可能にします。曲面と曲線を定義する小さなスクリプトを書き、CamlSurf_x11 script または CamlSurf_wayland script で一つ以上のスクリプトを実行します。

インストールするには、（opam update の後）opam install CamlSurf_x11 または opam install CamlSurf_wayland でできるはずです。

ドキュメントと動画については https://raffalli.eu/CamlSurf をご覧ください。

https://github.com/craff/gles3

Gles3 は、グラフィックプログラミングのために open GLES3.2 と EGL へのインターフェースです。2016年の以前のバージョンと比較した主な新機能は以下の通りです：

• 2 つのバックエンドのサポート：x11 と wayland。windows (wgl) および macos (cocoa) バックエンドは予定しており、ボランティアを歓迎します。
• 多くのアーキテクチャのサポート：opam-ci が提供するすべてのアーキテクチャ（freebsd や、X サーバーとして quartzx を使用する macos を含む）で動作するはずです。 win32 は例外ですが、実際には x11 を使ってもビルドできるはずです。ボランティアが試してみて msys2 または cygwin のパッケージリストを教えてくれれば、アップデートします。 opam-ci ではコンパイルできますが、サンプルの実行時にバグがある可能性があります。バグ報告は歓迎です！
• 複数ウィンドウ：新バージョンでは複数のウィンドウを扱えます。最もシンプルな解決策は、各イベントループを独自のドメインで実行することです（examples/windows を参照）。このサンプルのためだけに OCaml 5 が必要です。そのサンプルを除けば、OCaml 4.14 のソースからのコンパイルも動作するはずです。
• フォントを読み込んでテキストをテクスチャに変換する基本的なサポート。
• クリーンアップ/拡張されたサンプル。例えば、クリックしたピクセルの 3D 座標を取得するシェーダーの書き方を示す新しいサンプルがあります（マウスを使った正確なオブジェクト移動に活用できます）。

OCaml のトップレベルは、明示的なプリンター関数を必要とせずに任意の値を表示する機能を長らく持っていました。しかし、この機能はトップレベルの内部にとどまっていました。Introcaml はこの仕組みを標準ライブラリに持ち込み、任意の型の値の多相的な表示と構造的なイントロスペクションを可能にします。

コンパイルされたコードに埋め込まれたメタデータから構造を復元することで、Introcaml は抽象化の壁の背後に隠れたデータ構造も、面倒な pp 関数を書かずに検査できます。

Introcaml は opam で利用できます。アルファ版をテストするには、専用の switch を作成することをお勧めします：

opam switch create 5.5.0+introcaml

Introcaml は高性能を実現するために確率的なメタデータ復元スキームを実装しています：

1. 予約ビット： OCaml オブジェクトのヘッダーの予約ビットに "タグ" を格納します。
2. インデックス： サイドデータベース（Introspect.Index.t）がこれらのタグを ディスクリプタ（Introspect.Desc.t）にマッピングし、値の構文表現を記述します。
3. ゼロオーバーヘッド： コンパイルスキームはバイトコードではオーバーヘッドが無視できるほど小さく、ネイティブモードでは実質的にゼロになるよう設計されています。

以前は、トップレベルやデバッガーで不透明な型を表示すると単に <abstr> と表示されていました。今では、これらのツールはデフォルトで型指向の表示を使用しますが、不透明な構造に遭遇するとシームレスにタグベースの表示に切り替えます。

# let h = Hashtbl.create 3;;
val h : ('_weak3, '_weak4) Hashtbl.t =
  <abstr>
    {size = 0; data = (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
     seed = 0; initial_size = 16}

—

アルファリリースのため、いくつかの既知の制限があります。一時的なものと設計上固有のものがあります：

• アーキテクチャとコンパイラー：
  • 32 ビットアーキテクチャはサポートしていません。（x86_64 と arm64 でテスト済み）。
  • Flambda と互換性がありません。
  • js_of_ocaml は現在未サポートです（修正は簡単です）。
• メタデータの制約：
  • 定数： メタデータの格納スペースが限られているため、一部の定数は表示できません（例：print_any None は 0 と表示されることがありますが、println [None] はリストラッパーがメタデータを提供するため成功する可能性が高いです）。
  • Poly-variant： 近似表示されます（例：print_any `A は 65 or `A と表示されることがあります）。
  • FFI： FFI から来た値はタグ付けされておらず、タグ付き構造でラップされない限り生のタプル/値として表示されます。（注：FFI の互換性は完全に維持されています）。

• マーシャリング： タグはデフォルトではマーシャリング中に保存されません。保存するには Reserved_bits フラグを使ってオプトインする必要があります：

  let roundtrip flags x = Marshal.from_string (Marshal.to_string x flags) 0;;
  println [roundtrip [Reserved_bits] (ref 1)];; (* 出力: {contents = 1} *)
  

• オブジェクトサイズ： メタデータのために 22 ビットを予約することで、配列の最大長は約 40 億要素、文字列は 32GB になります。

—

謝辞： この作業は Ahrefs Grant Program for OCaml によって資金提供されています。

ヘッダービットの再利用というアイデアとインフラストラクチャを提供してくれた ocp-memprof の元となる作業を行った Çağdaş Bozman らに感謝します。また、この機能を維持してくれたメンテナーたちにも感謝します。

🤖 注： この機能の設計と実装中にロボットが傷つけられることはありませんでしたが、テストと校正の際にその助けを借りました。

簡潔さとコンパイル時間。イディオマティックな OCaml ソースコードがいかにエレガントに見えるかに本当に驚かされます。多くの形式なしにすべてが機能します：波括弧も角括弧もなく、ランダムな fn キーワードもなく、最も重要なのは邪魔になるものがない――let there = light と書けば、there は light になります。さらに、コンパイル-検証-書き直しのループが非常に速く、コンパイル時間が驚くほど短いためです。utop が REPL として存在し、コミットする前にアイデアをテストできます。これは Rustacean が慣れていないことです：通常、新しいクレートに出会ったとき、私は docs.rs でそのクレートの機能についてのドキュメントを参照するか、新しいユニットテストを作成してコンパイルして動作を確認するのに時間をかけます。OCaml が最も人気のある言語の一つでないにもかかわらず、開発者たちが OCaml を書き続けたい理由が今ではよく分かります。

Dune。これは簡潔さに関する前のポイントと関連しています：ビルド設定は本当にタプル/S 式だけです。Rust でも Cargo.toml を使って同様の効果を達成できますが、dune がすべて S 式である点で本当にオーバーヘッドがありません。このスタイルを 最小限かつ十分に簡潔 と考えるようになりました。例えば、S 式の括弧はデータの周りの最小限の構造であり、セマンティクスは括弧の間に置くものから自然に導き出されます。C との統合も非常にシームレスで、Rust との統合もありますが、後者は dune に cargo の使い方を教える必要があり、C がシステムプログラミングの共通言語としてはるかに確立されていることを考えると驚くことではありません。

[@@zero_alloc]。これが OxCaml がもたらすものであり、すぐにその効果を発揮します――インターフェース定義の val にマークを付けると、関数内で発生する可能性のあるアロケーションをすぐにキャッチしようとします。ゼロコスト抽象化に慣れていたので、一部の言語機能がアロケーション面でコストがかかることを知ったのは新鮮でした（option、お前のことだぞ）。詳しく調べると納得できましたが、初期の驚きはまだ残っています――素敵な言語機能に非自明なコストが伴うことを考えることに慣れていなかったのかもしれません。いずれにしても、このアノテーションは Rust からページを取っており、チェックが コンパイル時にすべて 行われるため、そのアノテーションでコンパイルされたコードはコンパイラーによってアロケーションがないことが保証されます。最高です。

ミュータブルローカル変数。標準的な方法が 'a ref を使うことは十分知っていますが、mutable が余計な手間なく私が思った通りに動作するのを見るのは非常に良かったです。値を読む際に "デリファレンス" するために ! プレフィックスが必要ありません。唯一の欠点は代入に <- が必要なことですが、これは避けられません。= はすでに多くの意味に使われているからです。実際、論理的な等価性が例外と言えるかもしれません。let バインディングとレコードフィールドはどちらも代入演算子のカテゴリーに属するとも言えます。

アンボックスされたタプルとレコード。パターンでも期待通りに機能します。すべてに # をプレフィックスするだけで機能します。例えば、Rust で 2 つ以上の値を同時に返したりバインドしたりする際によく使うパターンはタプルですが、OxCaml でも基本的に同じです：

let #(a, b) = if cond then #(#8L, foo) else #(#3L, bar)

自動バイトアライメント。OCaml の文字列とバイト配列はワードの整数倍に自動的にアラインされるため、最後の部分的なワードを読む際のミスアラインメントを心配する必要はなく、ワード境界に到達するためのプロローグも不要です。

機能の不完全さ。これは OxCaml がまだかなり新しい言語拡張であることの結果かもしれませんが、開発中に基本的な操作がなかったりします――論理中置演算子、ビットシフト、比較中置演算子さえも。一部はそもそも stdlib にもなく、コンパイラーの intrinsics に含まれています――Bytes.unsafe_get_in64_ne_indexed_by_int64 がコンパイラーのソースコードを掘り下げて初めて存在を知れましたし、符号なし int8 の unsafe ロードはどこにも intrinsic として存在しません。一方で、多相的な中置演算子が機能しない理由は理解できます――'a は value レイアウトを持ち、int64# は bits64 を持ち、両者の間の構造的比較は機能しないでしょう。パラメーターのレイアウトがレイアウトに関係なく一致する限り、多相的な演算子もそのレイアウトを無視してくれればとても良いのですが。

特定の関数のパフォーマンスへの影響。具体的には、ボックス化されたパラメーターとアンボックスされたパラメーターを混在させるものです。これが実際に何かに影響するかどうかは不明ですが、Claude に何度も嘘をつかれてきたので、直感的に言ってアンボックス化、特にボックス化には無視できないコストがあります。例えば、Int64_u.shift_{left,right} ではビットシフト数を示すためにアンボックスされた 2 番目の引数を使う必要があります。Int64_u.compare を使った比較で、結果としてボックス化された整数を比較するにもかかわらずアロケーションが発生しないと言われており、Claude は memchr.a のアセンブリがそれを証明していると言います：

Int64_u.(compare ((to_int i) + 8) n < 0)
---
22a:  lea    0x11(%rbx,%rbx,1),%r12   ; 2i + 17、つまり tagged(i + 8)
22f:  cmp    %rdi,%r12                ; tagged n と比較
232:  jg     280

i がもともとアンボックスされた整数だったため、この式から発行されるすべての命令がこれかどうかは確かめられませんし、Claude は i が再タグ付け/再ボックス化されるコンテキストを見落としているかもしれません。

アンボックス化バリアントは以下のようになります：

Int64_u.(compare (i + #32L) (of_int n) < 0)
---
101:  lea    0x20(%rbx),%r12      ; i + 32
109:  cmp    %rsi,%r12            ; n と比較（0xd7 で事前にアンタグ済み）
10c:  jg     224

額面通りに受け取れば、どちらも同じ数の命令を生成しており、パラメーター以外はすべて同一です。違いがあるとすれば、これらの命令に渡されるパラメーターの隠れたコストのはずです。これはホットループの実行パスにあるため重要で、ここで節約できる命令やナノ秒はマイクロ秒やミリ秒単位のスケールで効いてきます。

エルゴノミクス。これは両面あります。Int64_u.(expression) のようにローカルインポートを使えるのは好きですが、毎回繰り返すのは手間です。let open Int64_u in でローカルインポートを使うこともできますが、これが期待通りに機能しないことがあります。特にサイズの異なるボックス化された整数（前述の int など）も扱う必要があるときです。多相的なレイアウトの問題を解決しない限り一般的に解決できる問題とは思えないので、これはまだ痛点としてリストアップしておきます。

continue/break/早期リターンがない。これは本当に醜くなってきます――関数型プログラマーからの「命令型コードは通常、ミューテーションなしにより純粋な関数型スタイルで書き直せる」という議論は理解できますが、今やシステムプログラミング領域にいます。発行されるすべての命令が重要であり、continue、break、return を使って望む場所に直接ジャンプできないことはレパートリーの大きな穴です。例えば、ループから早期脱出するために使わざるを得なかったコードを見てください：

 while Int64_u.(i + #8L <= n64) do
  let r = swar_raw (Bytes.unsafe_get_int64_ne_indexed_by_int64 s i) in
  if not Int64_u.(r land mask = #0L) then (
    hit <- i;
    i <- n64)
  else i <- Int64_u.(i + #8L)
done

ループ条件を失敗させるために n64 を i に代入することでループを "break" するわけです。しかもここで終わりではありません。i はバイトを読み始めるオフセットを示しているため、後のループでそれが保存されている必要があります：

if Int64_u.(hit >= #0L) then i <- hit;

hit に代入しておいたため i を簡単に復元できましたが、他のループではそう上手くいかないことも容易に想像できます。ループを break したときの状態を格納するためだけに余分な変数を保持しなければならず、後続のコードパスで使うためにそれを保存しなければならないこともあります。確かに、これはホットな実行パスではなく、せいぜいループごとに 1 回起きることなので、私が思うほど問題ではないかもしれません。ただし continue は確かにそうではありません。適切な TCO された再帰関数では、新しいパラメーターで関数を再度呼び出すことが continue に相当しますが、TCO が命令型ループと同じ速さかどうかはまだ十分にテストしていません。

アトリビュートが簡単に無効化される。これは OxCaml の問題というわけではありませんが、memchr のイディオマティックな ML フレーバーで [@inline always] の使用を誤って無効化してしまいました。アノテーションを付けた関数が環境から変数をキャプチャーしていたためです：

let[@inline always] swar_raw w =
  let w = Int64_u.(w lxor cs) in
  Int64_u.((w - ones) land lognot w)
in

cs と ones がパラメーターとして渡されていないため、swar_raw は スタック上に アロケーションされる実際の関数になってしまいます。そのため、[@@zero_alloc] とベンチマークの mWd/Run の両方がそれを捉えられませんでした。これらは ヒープアロケーション を測定するからです。残念ながら、スタックアロケーションもパフォーマンスコストがあります。関数呼び出しは無料ではなく、コールフレームのセットアップ、メモリからの環境変数のロード、呼び出し先でのコンテキスト保存、戻る前のクリーンアップが必要です。これらは簡単に排除できる自明なコストではありません。

認めてしまえば、これは OCaml に十分習熟していない私の個人的なスキル不足ですが、コンパイラーが少なくともキャプチャーされた変数のために指定通りにインライン化されないことを警告してくれるべきだったと思います。このバグを修正すると、ML 関数型スタイルの memchr 実装の速度が命令型 ML スタイルと同じ速度まで下がりました。ベンチマークによっては 1〜2% 速いかもしれません。

数字を振り返ってみましょう：OCaml の Byte.index は Rust/C 相当のものより約 10 倍遅いですが、OxCaml は約 1.3 倍遅いまで抑えることができました。この差の大きさは大きな勝利です！OxCaml は機能がアップストリームされる可能性のある言語拡張として、OCaml がシステム向けのケーキを持ちながらそれを食べることもできるようにします。アンボックスされた整数を散りばめたイディオマティックに近い OCaml 構文を書くだけで、ベアメタルに近いパフォーマンスが得られるのです。OxCaml はその存在意義を完全に証明したと言えるでしょう。

OxCaml 開発中の摩擦点についても触れておくのは良いことだと思います――この投稿を書きながら、largely safe かつイディオマティックな Rust バージョンの memchr も書いてみましたが、それだけで OxCaml 相当のものより既に約 10% 速いです。ここで取り上げたいのは、これら 2 つの言語における私の異なるスキルレベル（実際にそれが要因になっているかもしれませんが）ではなく、プログラミング言語の哲学が思考方法をどのように導くか です。言語学における言語相対性やより古い Sapir-Whorf 仮説を聞いたことがある方ならご存知でしょうが、これがまさにプログラミング言語に適用されたものです――Rust は本質的に安全で堅牢かつ効率的なソフトウェアを構築するためのものであり、ゼロコスト抽象化、ひどく長いコンパイル時間、肥大化したコンパイラーエラーメッセージといった言語機能はまさに、デフォルトで安全かつ高速なコードを書くために設計されています。

OCaml はそうではなく、そう振る舞う必要もありません。OCaml には Rust では再現しにくい利点もあります――高速なコンパイル時間、実際には考える必要がないほど均一なレイアウト、ループ/再帰をベアメタルに近い速度にする末尾呼び出し最適化、GADT やモナドをサポートするリッチな型システム、そして忘れてはならないこと――OCaml なしには Rust も存在しなかったのです。OCaml はまだ世界に提供できるものが明らかにたくさんあり、我々（基本的には私だけですが）はまだそのすべてを見ていません。

私がリストアップした痛点のほとんどは、OxCaml が表向きにはシステムプログラマーが効率的なコードを書くために書かれているためです。そして現在の構文/ツールはそれらの目標を完全にはサポートしていません。速く動かすことは素晴らしいことです。誰でもデフォルトで効率的に実行されるプログラムを簡単に書けるようにすることは素晴らしいことです。

OxCaml は oxcaml_simd を通じて SIMD サポートを持っています。なので、最適化された C および Rust バージョン（後者は BurntSushi の memchr クレート——はい、これは彼の本物のユーザー名です）と比較したときにどうなるかをテストするのが自然な次のステップです。その後、小さくて自己完結した Rust クレートをいくつか OxCaml に移植して、パフォーマンス特性の実験を続けることを考えています。memchr は入力引数だけで動作する制約のある例であることを念頭に置いてください。時間とともにストレージとメモリを必要とするシステムでどう機能するかを見るのは興味深いでしょう。