うっかり世界最強のWasmコンパイラを作ってしまった件 - Qiita

TCPの初期ウィンドウサイズ（MTU 1500バイト基準）なら、最初の1〜2パケットでブラウザへ完全に届きます。ネットワーク遅延は事実上ゼロ、V8などのエンジンによるJITコンパイルも一瞬で終わります。 動作デモはこんな感じです。ブラウザのDOMを操作するJavaScript側のコードも、WASM側のプログラムに一緒にかけてしまいます。 なぜここまで削ぎ落とせたのか？ 1. libc（C標準ライブラリ）の徹底的なセルフホスト化 多くのWasmコンパイラが肥大化する最大の要因は、言語ランタイムが暗黙のうちに要求するC標準ライブラリ（printf、memcpy、strlen、strcmp など）にあります。 Hikeでは、外部リソースに触れないメモリ・文字列操作をすべて自前のLLVM IR内部関数（define internal）として実装しました。 ; LLVM IR による純粋な memc

[udzura]

はてブコメント見て、逆にそもそも実行領域とのメモリ分離がされているwasmにとってはlibcが重厚すぎなのかもな、と思った

[kaorun]

Libcみたいな汎用ライブラリを自前で持って最小限に縮めるのは合理的だけど、その分のバッファオーバーランみたいな脆弱性対策も自前にならざるを得ないので潜在的な手間と責任は増えそうな気も…

[gfx]

ほうほう。あとで Wado と比べてみよう（Wado も世界最小のwasmをうたう処理系）。

[amd64x64]

やっぱり専用言語があった方がいいよね。どうしてもランタイムライブラリとセットになるわけだし。

[yarumato]

“ブラウザで高速なバイナリ処理や計算ロジックのためにWasm。C/C++: POSIX互換や仮想FSまで引き連れてくる。Rust:学習曲線、ビルドパイプライン。Go: 最小構成でも2〜3MB。自作のGoライクなプログラミング言語を開発”

[ihirokyx]

1. libc（C標準ライブラリ）の徹底的なセルフホスト化 2. スライス構造による $O(1)$ 文字列処理

[irohairoha168]

最小バイナリサイズのwasmを作りたいならEmscripten(clang)が現状最強の認識。あと、memcpyを例に出すのは不適切でmemory.copyを使えばwasm上は1命令で済む

[circled]

free: (ptr) => {}, // 解放しない, this.heapPtr += (s + 7) & ~7; // 単調増加 → DoSだな。あと「フォームのバリデーション」や「軽いパーサー」程度なら、そもそも素のJSで書いた方が依存も生成物も少ないという事実が

[chi-bd]

Wasmはもっと手軽にCPU BoundなJSメソッドの置き換え目的に使えるようにならないかなぁ。自分にとっては進化の方向性が右斜め上に感じることしばしば

[t_f_m]

"多くのWasmコンパイラが肥大化する最大の要因は、言語ランタイムが暗黙のうちに要求するC標準ライブラリ（printf、memcpy、strlen、strcmp など）にあります"

[igrep]

"外部宣言（declare）された標準関数はLLVMにとってブラックボックスですが、IR内部関数として定義することで、Clangの最適化パス（-O2）によって自動でインライン展開やSIMDベクトル化が行われます"

[atsushieno]

Qiitaアカウントを見た感じ、自作コンパイラの解説記事を書いたが願望に反して全然広まらなかったので「世界最強」みたいな誇大広告を混ぜて宣伝することにした、という流れ（誇大広告撲滅委員会）

[dentaro]

うっかりね

[toaruR]

もー、変態なんだから

[strawberryhunter]

最近、自分もプログラミング言語を作ってみたけど、うっかり作れるものでは全然なかった。うっかりとか、ちょっと（かなり）盛ったと言ってほしい。

[soulfulmiddleagedman]

遊んでみたい

[ika2434]

凄すぎる試したい

[shoh8]

“2.56 KB”え、すげえじゃん（ｷｭﾝ）

[napsucks]

しゅごい

[nguyen-oi]

Go風構文で2.5KBのWasm吐いてJS連携コード自動生成とか夢の技術すぎるだろ

[deb]

世界最強の世界最小のwasm-goトランスパイラ！！WASMの呼出規約とかABI、ランタイム問題はともかく