カテゴリー
software

Gcc Emacs

反撃の狼煙か。
⌨️

プログラムを書くことを仕事にしている私は、仕事で使う最も重要な道具であるテキストエディターとして長年Emacsを使用してきたのですが、先日Visual Studio Code(VS Code)への移行を果たしてしまいました。Emacs自体には特に問題があったわけではないのですが、40年以上前に生まれたものなのでさすがに基本設計が古く、最新のエディタに搭載された機能はやはり非常に便利で洗練されているのでした。

乗り換え以来かなり満足してVS Codeを使っていて、戻りたいと思ったり懐かしく感じることもほとんどなかったのですが、そんな私の気持ちも揺さぶる革新がEmacsにも起こっていることをこのゴールデンウィークのはじめに知ってしまいました。それがGcc Emacsというもので、ネイティブコンパイルEmacsの登場で紹介されています。早速私もこのブログ記事に沿ってインストールしてみたところ、実にオタク心をくすぐる面白いものでした。

マクロや拡張モジュールを使って機能を追加・変更できるというのは今のテキストエディタでは当たり前のものですが、Emacsではその登場当初からEmacs Lispという、LISPをベースにしたプログラミング言語を使って非常に高度な拡張を施すことができるようになっていました。このLISPという言語は今で言えばPythonJavaなどの、語弊はあるかもしれませんがC言語系の構文を持つ言語とは大きく異なる独特な文法を持ちますが歴史のある言語で、Emacs LispはこのLISPでできることは基本的にできるれっきとしたプログラミング言語です。そして今回のポイントはこのEmacs Lispのプログラムを画期的により高速に動作させるようになるというものです。

これまでもEmacs Lispのコードは「バイトコンパイル」という処理により「バイトコード」という中間表現に変換することで、予め構文解析を行い、サイズを小さくすることによって若干高速に動作させることが可能でした。今回使用できるようになった「ネイティブコンパイル」ではコンパイラGCC(libgccjit)をライブラリと使用することでEmacs LispのコードをCPUが直接実行できるネイティブコードに変換してしまい、極めて高速に実行できるようになるとのことです。実行する処理の内容にもよりますが、バイトコンパイルの場合とほとんど変わらない場合もあれば、何倍にも速くなる場合もあり、極端なケースでは測定不能なほどベンチマーク速く終わってしまうこともあるようです。私はしばらく使わなくなっていたのであまり体感的な比較もできないのですが、「こんなに軽快だったかな」というような印象がありますが、拡張機能の組み込み過ぎで重くなったVS Codeに慣れてしまっただけかもしれません。なお、技術の詳細はBringing GNU Emacs to Native Codeという論文で詳細に説明されているので、私も後でじっくり読んでみたいと思います。

今のところこのネイティブコンパイルに対応済みのバイナリは少なくとも公式には配布されていないようなので、最新のソースから自力でビルドする必要がありますが、通常のビルドとの違いはlibgccjitを使えるようにした上で、configureにオプション--with-native-compilationを付け加えるだけなので、特に難しいことは何もありませんでした。ただし、libgccjitはMacであればHomebrewDebianLinuxならAPT等でインストールすれば済みますが、WindowsではMinGWあたりを使うことになるのでしょうか…と調べるとStackExchangeで”Is there a gccemacs (native-comp) build for MS-Windows?“という質問をしている人がいて、回答が集まっているようです。私も仕事で使おうと思うとWindows版が必要になるので、いつか使えるようにしたいと思います。

コメントを残す

メールアドレスが公開されることはありません。

スパム対策のため日本語が含まれない投稿は無視されますのでご注意ください。