Posts on Hello https://maekawatoshiki.github.io/posts/ Recent content in Posts on Hello Hugo -- gohugo.io ja-jp <a href="https://creativecommons.org/licenses/by-nc/4.0/" target="_blank" rel="noopener">CC BY-NC 4.0</a> Fri, 26 Dec 2025 10:44:29 +0900 2025 https://maekawatoshiki.github.io/posts/2025/ Fri, 26 Dec 2025 10:44:29 +0900 https://maekawatoshiki.github.io/posts/2025/ 去年 掲げていた「来年の目標」 健康でいる あまり良くなかった。 今はまぁまぁ。 研究の最終ゴールを定める 右往左往しつつ、一ヶ所に落ち着いたと思っている。 なにかしらの尺度で、自立する ダメだね。 今年 明日は横浜行こうかなぁ &mdash; uint256_t (@uint256_t) January 24, 2025 横浜の技書博へ行った。 分岐予測むずかしすぎませんか &mdash; uint256_t (@uint256_t) February 10, 2025 分岐予測に苦戦。 そもそも現代のプロセッサをよくわかっていなかった。 AsiaLLVM に来ています pic.twitter.com/tdN3MniUoA &mdash; uint256_t (@uint256_t) June 9, 2025 AsiaLLVM に参加した。 最近会っていなかった人と話せて良かった。 念願の、Chris Lattner とのツーショットも撮れた。 Championship Branch Prediction 2025 で 1st place でした pic.twitter.com/jMOe6j7IK9 &mdash; uint256_t (@uint256_t) June 21, 2025 私たちの分岐予測器が、性能を競うコンペティションで優勝（まさしく state of the art）した。 素晴らしいメンバーに恵まれたと思う。 論文: RUNLTS: Register-value-aware Predictor Utilizing Nested Large TableS 去年 掲げていた「来年の目標」

健康でいる

あまり良くなかった。
今はまぁまぁ。

研究の最終ゴールを定める

右往左往しつつ、一ヶ所に落ち着いたと思っている。

なにかしらの尺度で、自立する

ダメだね。

今年

横浜の技書博へ行った。

分岐予測に苦戦。
そもそも現代のプロセッサをよくわかっていなかった。

AsiaLLVM に参加した。
最近会っていなかった人と話せて良かった。

念願の、Chris Lattner とのツーショットも撮れた。

私たちの分岐予測器が、性能を競うコンペティションで優勝（まさしく state of the art）した。
素晴らしいメンバーに恵まれたと思う。

論文: RUNLTS: Register-value-aware Predictor Utilizing Nested Large TableS

このあたりで仕事をすべてやめて、研究に専念し始めた。

研究会で高松へ行った。

情報処理学会の山下記念研究賞を受賞した。

58th IEEE/ACM International Symposium on Microarchitecture (MICRO) のワークショップ (CAMS25)に参加した。

今年の所感

  • 論文を書くときに，トップダウンで考えることを意識できた
    • 去年よりは構成が上手になったと思っている
  • 分岐予測器に詳しくなった
    • 久しぶりに酷いコードを読む能力を使った気がする
  • かなりいろんな場所へ行けて楽しかった
    • 日本各地だけでなく韓国にも行った

来年の目標

  • 健康でいる
  • 自立する
  • 自分の手で、ものを作る
]]> 色々なツールを研究で使う際のtips https://maekawatoshiki.github.io/posts/research-tool-tips/ Sat, 22 Nov 2025 15:33:00 +0900 https://maekawatoshiki.github.io/posts/research-tool-tips/ これは，名工大 Advent Calendar 2025 - 11日目の記事です． 世の中には、ソフトウェア・エンジニアリングを行う上で役立つツール（ツールと言わないものも含む）が様々あります。 この文書では、それらのツールを研究で使う際のTipsを紹介します。 きっと、研究に関係なく役立つ内容も多いかと思います。 シェルスクリプトの書き方 要約: スタイルガイドに従うこと、及び shellcheck を常用することを推奨します。 スタイルガイドに従う 誤読のなく、ポータブルなシェルスクリプトを書くためには、 Googler によるシェルスクリプトのスタイルガイドは 必読だと思います。 以下に、私が重要だと思った部分をスタイルガイドから抜粋します。 スタイルガイドにない項目もあるかも。 シェルとして bash を使う Shebang は #!/bin/bash で始めましょう。 スタイルガイドはこう述べています。 &hellip; In particular, this means there is generally no need to strive for POSIX-compatibility or otherwise avoid “bashisms”. POSIX 準拠を目指すとかなり書きづらくなるのは想像がつきます。 Bash は実質すべてのマシンで使えますから、このあたりが妥協点なのでしょう。 set -euxo pipefail オプションを使う Shebang の次の行に set -euxo pipefail と書きましょう。 set はシェルのビルトインコマンドであり、シェルのオプションを変更することができます。 オプションとは -euxo pipefail （-e -u -x -o pipefail と同じ意味）の部分を指しますが、それぞれの意味は以下の通りです。 以下の説明は荒いので、詳細は 4. これは，名工大 Advent Calendar 2025 - 11日目の記事です．

世の中には、ソフトウェア・エンジニアリングを行う上で役立つツール（ツールと言わないものも含む）が様々あります。

この文書では、それらのツールを研究で使う際のTipsを紹介します。

きっと、研究に関係なく役立つ内容も多いかと思います。

シェルスクリプトの書き方

要約: スタイルガイドに従うこと、及び shellcheck を常用することを推奨します。

スタイルガイドに従う

誤読のなく、ポータブルなシェルスクリプトを書くためには、 Googler によるシェルスクリプトのスタイルガイドは 必読だと思います。

以下に、私が重要だと思った部分をスタイルガイドから抜粋します。 スタイルガイドにない項目もあるかも。

シェルとして bash を使う

Shebang は #!/bin/bash で始めましょう。

スタイルガイドはこう述べています。

… In particular, this means there is generally no need to strive for POSIX-compatibility or otherwise avoid “bashisms”.

POSIX 準拠を目指すとかなり書きづらくなるのは想像がつきます。 Bash は実質すべてのマシンで使えますから、このあたりが妥協点なのでしょう。

set -euxo pipefail オプションを使う

Shebang の次の行に set -euxo pipefail と書きましょう。

set はシェルのビルトインコマンドであり、シェルのオプションを変更することができます。 オプションとは -euxo pipefail （-e -u -x -o pipefail と同じ意味）の部分を指しますが、それぞれの意味は以下の通りです。 以下の説明は荒いので、詳細は 4.3.1 The Set Builtin を参照してください。

  • -e: コマンド実行が失敗した場合にスクリプトを直ちに終了する
  • -u: 未定義の変数を参照した場合にエラーにする
  • -x: 実行する寸前のコマンドを標準エラーに出力する
  • -o pipefail: パイプで繋いだコマンド群のうち、どれか一つでも失敗した場合に全体を失敗とする

注意：Shebang を #!/bin/bash -euxo pipefail とするのは、意図した動作とならないため避けましょう。

そのように記述すると、例えば Linux カーネルでは /bin/bash に一つの引数（-euxo）しか渡されず、 pipefail は無視されてしまいます。

変数は ${var} 記法で展開する

変数展開は $var ではなく ${var} としましょう。
ブレース { } で境界を明示すると読みやすく、変数名の終わりが明確になります。

（単文字の特殊変数 $? や $# など は例外です）

変数名と後続の文字列を明確に区別できる

# ブレースなしだとエラー
prefix="test"
echo "$prefix_file"  # $prefix_file という変数を参照しようとしてエラー

# ブレースありで正しく動作
echo "${prefix}_file"  # test_file

デフォルト値の設定や未定義変数の検出にも使える

このほかにも、ブレース記法は文字列操作など色々な用途で使えます。

# 変数が未定義の場合にデフォルト値を設定
echo "${var:-default_value}"  # var が未定義なら default_value を出力

# 変数が未定義の場合にエラーにする
echo "${var:?var is not defined}"  # var が未定義なら `var is not defined` と出力

shellcheck を使う

シェルスクリプトを書いたら、とりあえず shellcheck コマンドに通しましょう。

shellcheck はシェルスクリプトの静的解析ツールであり、上記のスタイルガイドに反する箇所や潜在的なバグを指摘してくれます。
スクリプト実行前の安全装置として有用です。

最近のエディタは LSP 経由で shellcheck と連携できることが多いので、設定しておきましょう。

$ cat a.sh
#/bin/bash

echo "$var"

$ shellcheck a.sh

In a.sh line 1:
#/bin/bash
 ^-- SC1113 (error): Use #!, not just #, for the shebang.


In a.sh line 3:
echo "$var"
      ^--^ SC2154 (warning): var is referenced but not assigned.

For more information:
  https://www.shellcheck.net/wiki/SC1113 -- Use #!, not just #, for the sheba...
  https://www.shellcheck.net/wiki/SC2154 -- var is referenced but not assigned.

最後に：長い処理を書くなら他の言語を検討する

シェルスクリプトは便利ですが、複雑で長い処理を書くには向いていません。

以下のどれかに当てはまる場合は Python / Perl / Ruby / ECMAScript などの言語を使いましょう。

  • 100行を超える
  • 制御フローが単純でない
  • 単なるラッパー以上のことをする
  • パフォーマンスが重要
  • 今後も保守する可能性がある

git の扱い方

git の操作に自信がない場合は GUI で操作しよう

私は普段コマンドラインから git を操作していますが、わざわざそうする理由は特にありません。

エディタに Visual Studio Code などを使っている方は、付属の git 操作機能を積極的に使うのが良いでしょう。 きっと良いプラグインもあるでしょうし。

これ以降は、CLI で git を操作する際の tips を紹介します。

何かがおかしいと思ったら git status --ignored

ビルドが上手くいかないなど、リポジトリの状態に違和感を覚えた時は git status --ignored を確認してみましょう。

通常の git status は（.gitignore により）無視されているファイルを表示しませんが、 --ignored オプションを付けると無視されているファイルも表示されます。

気付かぬうちに生成物や実験結果などがコミット対象になっていることはよくあります。
そういった際は、まず落ち着いて、リポジトリがクリーンな状態かを確認しましょう。

過去の変更を追うなら git blame -C -M

ある行の変更履歴を、移動やコピーも含めて追う場合は git blame -C -M <file> が便利です。

リファクタリングを繰り返したリポジトリであっても、ある行の起源を辿ることが容易になります。

それぞれのオプションの意味は以下の通りです。

  • -M: 同じファイル内での行の移動・コピーを追跡する
  • -C: 別ファイルからの移動・コピーを追跡する

マージは non fast-forward で行う

ブランチのマージは non fast-forward で行うことをおすすめします。
git merge --no-ff でマージするか、グローバル設定を変更（git config --global merge.ff false）しておきましょう。

Non fast-forward マージはマージコミットを作成するため、マージが行われたことを明示的に履歴へ残すことができます。
また、これによりマージ単位のrevertが容易になります。

複数ブランチを同時に扱うなら git worktree

複数ブランチ間を頻繁に行き来したり、同時に複数のブランチを触りたい場合は git worktree を使いましょう。
一つのリポジトリについて複数の作業ツリーを同時に扱うことができます。

似たことは複数回の git clone & git switch でも実現できますが、git worktree は以下の点で優れています。

  • リポジトリの実体は一つだけ
    • 親となるディレクトリにしか .git が存在しないため、作業ツリーを増やしてもあまり容量を食いません
    • git fetch/remote/gc といった操作を一度行えば、すべての作業ツリーに反映されます
  • 一つのブランチは一つの作業ツリーにしかチェックアウトできない
    • 特定ブランチが複数のディレクトリでチェックアウトされることはないため、誤った編集を防げます

git stash を避ける

git stash は気軽に使える反面、「stash したまま忘れる」ことがあるので避けた方がよいです。 メッセージを付けたとしても、大抵役に立ちません（主観）。

別の作業をしたいときは git worktree を使うか、素直に（ブランチを切って）Work in progressとしてコミットしましょう。
コミットしておけば、簡単に remote へプッシュすることもできます（後から force push で取り消す必要が生じますが）。

git add -pu でファイルをステージングする

誤った変更をコミットしないために、git add -pu を使って対話的に変更をステージングしましょう。

各オプションの意味は以下の通りです。

  • -p (--patch): 変更を一ブロック（hunk）ずつ確認しながらステージングする
  • -u (--update): 追跡されているファイルのみ対象にする

これらのオプションを使うことで、ファイルに複数種類の変更が混じっていても（リファクタとバグ修正など）、 意味のある粒度でコミットを分けることができます。

最後に：とりあえずコミット・プッシュしておこう

昼食前、帰宅前など、一区切りついたタイミングでとりあえず変更をコミット・プッシュしておきましょう。
前日までの進捗を明示的にまとめられますし、バックアップにもなります。

最終的には適切な粒度でコミットし直すことをお忘れなく。

]]> 2024 https://maekawatoshiki.github.io/posts/2024/ Sat, 28 Dec 2024 22:59:42 +0900 https://maekawatoshiki.github.io/posts/2024/ 去年 掲げていた「来年の目標」 大学をなんとか卒業する 卒業できた 「決断」を下せるようになる 微妙。多少は決断できるようになったかもしれないが、結局時間が解決してくれた場合が多い。 将来何をしたいのかを考えるために、より多くの人と関わる 学会等で様々な人と話すことができた 今年 地震かな でか &mdash; uint256_t (@uint256_t) January 1, 2024 つらかった どうにか走り切らないといけない https://t.co/SuyPopM0xH &mdash; uint256_t (@uint256_t) January 5, 2024 今年はずっとパイプラインとにらめっこしていた きれい pic.twitter.com/qYyOO9gLKi &mdash; uint256_t (@uint256_t) January 31, 2024 卒業できたらしい 卒論発表 おわり ありがとうございました &mdash; uint256_t (@uint256_t) February 15, 2024 👏 卒業できた pic.twitter.com/1N01QSNGAZ &mdash; uint256_t (@uint256_t) March 26, 2024 SWoPP 2024 へ行った 来週は SWoPP に参加します. &mdash; uint256_t (@uint256_t) August 3, 2024 徳島 pic.twitter.com/0u8efprDjk &mdash; uint256_t (@uint256_t) August 6, 2024 以前の研究会での賞をもらった ARC 研究会 の 若手奨励賞 を頂きました。 pic. 去年 掲げていた「来年の目標」

大学をなんとか卒業する

卒業できた

「決断」を下せるようになる

微妙。多少は決断できるようになったかもしれないが、結局時間が解決してくれた場合が多い。

将来何をしたいのかを考えるために、より多くの人と関わる

学会等で様々な人と話すことができた

今年

今年の反省

  • 論文・スライドに取りかかるときは、まずトップダウンの構成を考える
    • ３点プロットをよく練る（塩谷先生のスライドを見直す）
    • 逆茂木型のパラグラフを書かない

来年の目標

  • 健康でいる
  • 研究の最終ゴールを定める
  • なにかしらの尺度で、自立する
]]> Tabbyによるコーディング支援を試した https://maekawatoshiki.github.io/posts/tabby/ Fri, 15 Nov 2024 14:58:50 +0900 https://maekawatoshiki.github.io/posts/tabby/ これは，名工大 Advent Calendar 2024 - 3日目の記事です． 長らくこのブログに書き込んでいませんでしたね．2024年が終わってしまいそうです． はじめに 昨今，GitHub Copilot 等の高度なコーディング支援ツールが普及しつつあります． 私もサービス開始当初から使っていますが，非常に賢いコード補完機能として，もはや手放せないほど手に馴染んでいます． さて，GitHub Copilot は（ほとんどの人にとって）有料ですから，毎月（毎年）一定の金額を支払う必要があります． 加えて，GitHub の判断によって，明日から使えなくなる可能性もあります． 手放せないツールが突然使えなくなっては困りますよね． 世の中には，似たようなサービスを自らセルフホスティングするためのプロジェクトが存在します． 本記事では，その中でも Tabby というプロジェクトを実際に試してみます． Tabby とは 以下に，リポジトリから引用した説明を載せておきます． 要約すると，お手元の GPU と Tabby さえあれば，GitHub Copilot に代わるコーディング支援環境を構築できるわけです． Tabby is a self-hosted AI coding assistant, offering an open-source and on-premises alternative to GitHub Copilot. It boasts several key features: Self-contained, with no need for a DBMS or cloud service. OpenAPI interface, easy to integrate with existing infrastructure (e. これは，名工大 Advent Calendar 2024 - 3日目の記事です．

長らくこのブログに書き込んでいませんでしたね．2024年が終わってしまいそうです．

はじめに

昨今，GitHub Copilot 等の高度なコーディング支援ツールが普及しつつあります． 私もサービス開始当初から使っていますが，非常に賢いコード補完機能として，もはや手放せないほど手に馴染んでいます．

さて，GitHub Copilot は（ほとんどの人にとって）有料ですから，毎月（毎年）一定の金額を支払う必要があります． 加えて，GitHub の判断によって，明日から使えなくなる可能性もあります． 手放せないツールが突然使えなくなっては困りますよね．

世の中には，似たようなサービスを自らセルフホスティングするためのプロジェクトが存在します． 本記事では，その中でも Tabby というプロジェクトを実際に試してみます．

Tabby とは

以下に，リポジトリから引用した説明を載せておきます． 要約すると，お手元の GPU と Tabby さえあれば，GitHub Copilot に代わるコーディング支援環境を構築できるわけです．

Tabby is a self-hosted AI coding assistant, offering an open-source and on-premises alternative to GitHub Copilot. It boasts several key features:

  • Self-contained, with no need for a DBMS or cloud service.
  • OpenAPI interface, easy to integrate with existing infrastructure (e.g Cloud IDE).
  • Supports consumer-grade GPUs.

環境構築

ドキュメントによると，Docker イメージが提供されており，以下のコマンドで Tabby サーバーを起動できるようです． Docker から GPU を使えるよう設定しておく必要があります．

利用できるモデルはこちらにリストされています． また，リストされていない Qwen2.5-Coder-1.5B 等も，どうやら利用可能のようです（リストが更新されていない？）．

# 初回起動時は巨大なファイル（=LLM）をダウンロードする
docker run -it \
  --gpus all -p 8080:8080 -v $HOME/.tabby:/data \
  tabbyml/tabby \
  serve --model StarCoder-1B --device cuda # --chat-model <いらないかな>

うまく行けば，以下のような出力を得られます． 表示されているURLへアクセスし，初期設定を行ってください（トークンを得られます）．

Writing to new file.
🎯 Downloaded https://huggingface.co/ikw/Qwen2.5-Coder-1.5B-GGUF/resolve/main/qwen2.5-coder-1.5b-q8_0.gguf to /data/models/TabbyML/Qwen2.5-Coder-1.5B/ggml/model-00001-of-00001.gguf.tmp
   00:05:00 ▕████████████████████▏ 1.53 GiB/1.53 GiB  5.22 MiB/s  ETA 0s.            ✅ Checksum OK.


████████╗ █████╗ ██████╗ ██████╗ ██╗   ██╗
╚══██╔══╝██╔══██╗██╔══██╗██╔══██╗╚██╗ ██╔╝
   ██║   ███████║██████╔╝██████╔╝ ╚████╔╝
   ██║   ██╔══██║██╔══██╗██╔══██╗  ╚██╔╝
   ██║   ██║  ██║██████╔╝██████╔╝   ██║
   ╚═╝   ╚═╝  ╚═╝╚═════╝ ╚═════╝    ╚═╝

📄 Version 0.20.0
🚀 Listening at http://0.0.0.0:8080

（補足）サーバー側の計算機環境

対象 バージョン等
OS Ubuntu 24.04 LTS
CPU Ryzen Threadripper 2990WX
GPU NVIDIA RTX 2080Ti 11GB
RAM 128GB
Docker 27.2.1 (Server)
Tabby 0.20.0

Neovim から使う

インストール

私は Neovim をエディタとして使っているため，ここに従って Tabby のプラグインをインストールしました． VSCode や IntelliJ からも使えるようです．

プラグインがインストールし終わったら，~/.tabby-client/agent/config.toml へサーバーの設定を追加します．

[server]
endpoint = "http://localhost:8080" # 適切に書き換える
token = "auth_..." # 適切に書き換える

動作

実際にコード補完している様子はこんな感じです（カーソルから下の部分）↓

モデルには Qwen2.5-Coder-1.5B を使いましたが， さすがに GitHub Copilot よりは性能が悪いなぁと感じました． 意図しない補完を提案する頻度が高いように思います． とはいえ，小型のモデルらしく Copilot よりも高速に補完してくれます．

GPU に余裕がある場合は，もっと巨大なモデルを試しても良いでしょう．

vim

追記：Tabby を有効にしながらこの記事を書いてみましたが， 小さなモデルであっても Markdown をいい感じに補完してくれるので便利でした．

まとめ

GitHub Copilot に代わるコーディング支援ツールとして，Tabby を試してみました．

モデルの性能や所持している GPU の性能によって補完能力がかなり変化するため，GitHub Copilot の代替品として使えるかは人によると思います．

ただし，個人的にはほとんどの場合で GitHub Copilot 並の仕事をしてくれそうだと感じました． おそらく，私はこういったツールを単なる（けっこう賢い）補完機能としてしか使っておらず， コードのロジックや設計は結局自分で考えているからだと思います． 普段 GitHub Copilot 側へそういった部分を委ねている場合は，ローカルで動作する LLM では性能的に物足りないでしょう．

]]> 2023 https://maekawatoshiki.github.io/posts/2023/ Sat, 30 Dec 2023 20:42:47 +0900 https://maekawatoshiki.github.io/posts/2023/ 去年 掲げていた「来年の目標」 多少は健康を意識する 意識していたつもりはないが、大きな病気はない。 大学へいけば必然的に~1万歩くらい歩くことになるし。 おそらく大学院に行くための試験があるので頑張る 推薦のおかげで試験を受けなくて済んだ。 それが本当に良かったのかはよくわからない。 研究というものと仲良くなる これは全くダメ。仲良くなれていない。 今年 9年ツイートしているらしい Do you remember when you joined X? I do! そうなんだ pic.twitter.com/pwjciaOBdg &mdash; uint256_t (@uint256_t) August 28, 2023 今年はチューターとしてセキュリティ・キャンプに参加しました pic.twitter.com/prLTXTTrD9 &mdash; uint256_t (@uint256_t) August 7, 2023 Python から GIL がなくなったら嬉しいよね GILとも もうすぐさよならなのかしら &mdash; uint256_t (@uint256_t) July 30, 2023 薄いキーボードが苦手だということにようやく気づき、結局これはあんまり使ってない 持ち運べるやつが欲しかったので。 pic.twitter.com/Aby7Uc8PsE &mdash; uint256_t (@uint256_t) July 18, 2023 これって今年だったのか https://t.co/uBdR998kBk 「プログラミング言語処理系が好きな人の集まり」は Slack から Zulip へ移行しました。 &mdash; uint256_t (@uint256_t) June 30, 2023 この頃は SPEC CPU95 を触っていたのかな（今は 2006, 2017 も触っている） 去年 掲げていた「来年の目標」
  • 多少は健康を意識する

意識していたつもりはないが、大きな病気はない。 大学へいけば必然的に~1万歩くらい歩くことになるし。

  • おそらく大学院に行くための試験があるので頑張る

推薦のおかげで試験を受けなくて済んだ。 それが本当に良かったのかはよくわからない。

  • 研究というものと仲良くなる

これは全くダメ。仲良くなれていない。

今年

  • 9年ツイートしているらしい

  • 今年はチューターとしてセキュリティ・キャンプに参加しました

  • Python から GIL がなくなったら嬉しいよね

  • 薄いキーボードが苦手だということにようやく気づき、結局これはあんまり使ってない

  • これって今年だったのか

  • この頃は SPEC CPU95 を触っていたのかな（今は 2006, 2017 も触っている）

  • qemu はとても便利で、研究でいつも使っている

  • いまもそう

  • 年の初めはレポートを書いていたらしい

来年の目標

  • 大学をなんとか卒業する
  • 「決断」を下せるようになる
  • 将来何をしたいのかを考えるために、より多くの人と関わる
]]> 2022年 https://maekawatoshiki.github.io/posts/2022/ Sat, 31 Dec 2022 15:52:23 +0900 https://maekawatoshiki.github.io/posts/2022/ 1 月 海からスタート pic.twitter.com/6fkbYD0CER &mdash; uint256_t (@uint256_t) January 1, 2022 まだ vicis をいじってたのかな Module::try_from(&quot;...llvm assembly...&quot;)って書けるようになってかなり良い &mdash; uint256_t (@uint256_t) January 30, 2022 2 月 わかる TLを見ていると、CPUからハイパーバイザ、人工衛星あたりまで色々なものが生み出されていてなんかすごい。 &mdash; uint256_t (@uint256_t) February 12, 2022 pull request その理由はGit誕生以前からある用語だからだったと思いますが、もはやGitHub以前の &quot;pull request&quot; という言葉のユースケースを探すことも困難になっているような…。 https://t.co/C6HvMcHw6f &mdash; FUJI Goro (@__gfx__) February 7, 2022 3 月 いつも同じことを考えている 勉強ってどうやってするんだろう。 &mdash; uint256_t (@uint256_t) March 25, 2022 Asahi Linux お試し Tweet from Asahi Linux! pic.twitter.com/A1rw8iFkuK &mdash; uint256_t (@uint256_t) March 20, 2022 いつ見ても好き この画像好きhttps://t. 1 月

2 月

  • わかる
  • pull request

3 月

4 月

  • 筑波へ行っていた
  • セキュリティ・キャンプの講師になった

5 月

  • けっこうすごい
  • チルダも慣れた

6 月

  • 著者の方から献本される体験
  • 真面目に深層学習ランタイムを作っていた
  • 大学図書館便利だなあと思った

7 月

  • 嬉しかった
  • Keychron K6 を買ったばかりなのに、HHKB を買った
  • まだ迷ってるよ

8 月

  • いつもレポートで困っている
  • セキュリティ・キャンプ開始
    • オンラインだったからあまり開幕した感がない
    • 無事終了
  • インターン開始
  • 東京にいたので色々なところへ行った

9 月

  • 技術書典 楽しかった
  • Zulip を導入
  • インターンの成果
    • 嘘書いてすみません（記事の最後参照）

10 月

11 月

  • スマホを変えた
  • はい
  • 全体的に、雑多なことをしていた感じ

12 月

総括

  • 相変わらずコンパイラのことを考えていた
  • セキュリティ・キャンプとインターンの印象が強かった

来年の目標

  • 多少は健康を意識する
  • おそらく大学院に行くための試験があるので頑張る
  • 研究というものと仲良くなる
]]> セキュリティ・キャンプ 2022 参加記（講師視点） https://maekawatoshiki.github.io/posts/seccamp2022/ Sat, 24 Sep 2022 18:14:08 +0900 https://maekawatoshiki.github.io/posts/seccamp2022/ はじめに 私は高校生の時にセキュリティ・キャンプ2018に参加 （参加記, 応募課題） しました。 流行り病のことを考える必要もなく、当たり前のように現地参加していた頃が懐かしいです。 いつの間にか大学生になってしまいました。 大勢が物理的に集まることが難しくなり、セキュリティ・キャンプがオンラインで開催されるようになってから久しいですが、 そんな今年、私は講師として セキュリティ・キャンプ全国大会2022 オンライン という場に帰ってくることができました。 この文章は、あまり見かけることのない「講師視点の参加記」という名目で、 率直な感想や反省などを述べていくものです。 自分の担当したゼミ（Cコンパイラゼミ）の話がほとんどなので、今年のキャンプの概観を知りたいのであれば他の方の記事を読んでみてください。 軽くゼミ紹介 私と hsjoihs さんがCコンパイラゼミの講師を担当しました。 このゼミでは以下のことを目指し、実際にある程度は達成しました。 本ゼミでは、実用的なプログラムをコンパイルできるC言語のコンパイラを開発します。 コンパイラを開発するための言語は問いません。そのため、C言語で開発しても良いですし、 ご自身の慣れ親しんだ言語を使って開発しても構いません。 目標は、C言語で書かれたOSSなどをコンパイルできるCコンパイラを開発し、 余裕があればより高度なものへと改造することです。コンパイラの基本的な要素はもちろん、 高度なコンパイラ最適化やコンピュータ自体についての理解が進むよう、講師が手助けをします。 大会期間前に多くの事前学習が必要となりますが、プログラミング言語やその処理系に関心を持つ皆さんの応募をお待ちしています。 引用元: https://www.ipa.go.jp/jinzai/camp/2022/zenkoku2022_program_list.html#list_s-l3 セキュリティ・キャンプでは、（私の参加した2018年から）Cコンパイラを自作するゼミが開講されていましたが、 2021年は開講されませんでした。2022年に再び開講したことになります。 応募課題 ゼミを開講するにあたっては色々とやることがあります。 特に、応募課題を作り、応募者の方の回答を評価することは重要です。 今年の応募課題は、過去の応募課題と似てはいますが、 応募者ごとに回答の内容に差が生まれやすい（であろう）問題を取り入れました。 （それが何問目なのかは、応募課題を確認していただければわかると思います。） 思惑通り、多種多様な回答をいただき、読んでいる側としても学ぶことが多かったです。 深くは述べませんが（=言っていいのかよくわからない; 確認が取れたら言うかもしれない）、回答の傾向をまとめると以下のようになりました。 質の低い回答（自分の{頭で考えていない, 手を動かして検証していない}回答）は少なかった （私の）想像以上に、（応募者が）普段コンパイラをいじっているのか（or いじっていないのか）が回答から伝わってきた 長すぎる回答はやめよう、とは最初に警告したものの、短い回答（を心掛けた結果内容が当たり障りのないものになってしまう）よりは、 分量があって熱意の伝わってくる回答のほうが、応募者の能力を評価しやすかった e.g. 問題の回答が思いつかなくても、「わからなかった」or それに類することを書くよりは、どこまで調べたのか・どこからがわからないのかを詳しく書いてもらったほうが評価しやすい 圧倒的に質の高い回答を創り出す方というのは本当に存在するのだなぁ、と感心した また、応募課題作成者のひとりとして、この問題はもうちょっと説明を加えるべきだったなぁと気づかせてくれる回答もいくつかありました。 問題を考えるのは難しいですね。 事前学習 応募課題を考えたり選考したりと忙しいですが、まだキャンプは始まってすらいません。 本番期間5日間の前には事前学習期間があり、開発に注力するゼミであればこの期間が非常に重要となります。 Cコンパイラゼミも例外ではありません。 事前学習期間には毎週進捗報告会を開き、受講生の方の進捗を確認したり、バグ取りを手伝ったりなどしました。 基本的には compilerbook や 事前に提供した本 を活用しながら、受講生の方が自主的にコンパイラ開発を進めるという流れだったため、 なるべく作業の手が止まらないように、 非同期なテキストチャットでの質疑応答も積極的に行っていました。 事前学習期間中にセルフホストまで到達した方もおり、 年々自作コンパイラ界隈のレベルが上昇しているなぁと実感しました。 ほんの10年前ならありえないことだったのではないでしょうか。 本番期間 事前学習期間は本番期間の5日間よりも長いですが、 受講生の方（や私）は試験期間などに重なって進捗を出しづらい 時期もあります。 やはりキャンプの真髄は、皆が集まって集中できる本番期間にあります。 はじめに

私は高校生の時にセキュリティ・キャンプ2018に参加 （参加記, 応募課題） しました。 流行り病のことを考える必要もなく、当たり前のように現地参加していた頃が懐かしいです。 いつの間にか大学生になってしまいました。

大勢が物理的に集まることが難しくなり、セキュリティ・キャンプがオンラインで開催されるようになってから久しいですが、 そんな今年、私は講師として セキュリティ・キャンプ全国大会2022 オンライン という場に帰ってくることができました。

この文章は、あまり見かけることのない「講師視点の参加記」という名目で、 率直な感想や反省などを述べていくものです。 自分の担当したゼミ（Cコンパイラゼミ）の話がほとんどなので、今年のキャンプの概観を知りたいのであれば他の方の記事を読んでみてください。

軽くゼミ紹介

私と hsjoihs さんがCコンパイラゼミの講師を担当しました。 このゼミでは以下のことを目指し、実際にある程度は達成しました。

本ゼミでは、実用的なプログラムをコンパイルできるC言語のコンパイラを開発します。 コンパイラを開発するための言語は問いません。そのため、C言語で開発しても良いですし、 ご自身の慣れ親しんだ言語を使って開発しても構いません。 目標は、C言語で書かれたOSSなどをコンパイルできるCコンパイラを開発し、 余裕があればより高度なものへと改造することです。コンパイラの基本的な要素はもちろん、 高度なコンパイラ最適化やコンピュータ自体についての理解が進むよう、講師が手助けをします。 大会期間前に多くの事前学習が必要となりますが、プログラミング言語やその処理系に関心を持つ皆さんの応募をお待ちしています。

引用元: https://www.ipa.go.jp/jinzai/camp/2022/zenkoku2022_program_list.html#list_s-l3

セキュリティ・キャンプでは、（私の参加した2018年から）Cコンパイラを自作するゼミが開講されていましたが、 2021年は開講されませんでした。2022年に再び開講したことになります。

応募課題

ゼミを開講するにあたっては色々とやることがあります。 特に、応募課題を作り、応募者の方の回答を評価することは重要です。

今年の応募課題は、過去の応募課題と似てはいますが、 応募者ごとに回答の内容に差が生まれやすい（であろう）問題を取り入れました。 （それが何問目なのかは、応募課題を確認していただければわかると思います。）

思惑通り、多種多様な回答をいただき、読んでいる側としても学ぶことが多かったです。 深くは述べませんが（=言っていいのかよくわからない; 確認が取れたら言うかもしれない）、回答の傾向をまとめると以下のようになりました。

  • 質の低い回答（自分の{頭で考えていない, 手を動かして検証していない}回答）は少なかった
  • （私の）想像以上に、（応募者が）普段コンパイラをいじっているのか（or いじっていないのか）が回答から伝わってきた
  • 長すぎる回答はやめよう、とは最初に警告したものの、短い回答（を心掛けた結果内容が当たり障りのないものになってしまう）よりは、 分量があって熱意の伝わってくる回答のほうが、応募者の能力を評価しやすかった
    • e.g. 問題の回答が思いつかなくても、「わからなかった」or それに類することを書くよりは、どこまで調べたのか・どこからがわからないのかを詳しく書いてもらったほうが評価しやすい
  • 圧倒的に質の高い回答を創り出す方というのは本当に存在するのだなぁ、と感心した

また、応募課題作成者のひとりとして、この問題はもうちょっと説明を加えるべきだったなぁと気づかせてくれる回答もいくつかありました。 問題を考えるのは難しいですね。

事前学習

応募課題を考えたり選考したりと忙しいですが、まだキャンプは始まってすらいません。 本番期間5日間の前には事前学習期間があり、開発に注力するゼミであればこの期間が非常に重要となります。

Cコンパイラゼミも例外ではありません。 事前学習期間には毎週進捗報告会を開き、受講生の方の進捗を確認したり、バグ取りを手伝ったりなどしました。 基本的には compilerbook や 事前に提供した本 を活用しながら、受講生の方が自主的にコンパイラ開発を進めるという流れだったため、 なるべく作業の手が止まらないように、 非同期なテキストチャットでの質疑応答も積極的に行っていました。

事前学習期間中にセルフホストまで到達した方もおり、 年々自作コンパイラ界隈のレベルが上昇しているなぁと実感しました。 ほんの10年前ならありえないことだったのではないでしょうか。

本番期間

事前学習期間は本番期間の5日間よりも長いですが、 受講生の方（や私）は試験期間などに重なって進捗を出しづらい 時期もあります。 やはりキャンプの真髄は、皆が集まって集中できる本番期間にあります。

オンラインでの開催とは言え、キャンプの開幕時は（主にテキストチャットが）大いに盛り上がり、 改めてこれが大きなイベントなんだと気付かされました。 そのままの勢いで、およそ3日間の集中開発が始まりました。

コミュニケーションには基本的に Zoom や Discord を使っていましたが、 ほぼ一日中リアルタイムで・相手の画面を見ながら会話出来たため、物理的に隣に座っているわけではないものの、 相手の状況（e.g. デバッグ中の画面など）を理解したり質問に答えたりすることに特段困ることはありませんでした。

印象的だったのは、とりとめのない会話から面白いアイデアが生まれることが多々あったことです。 例えば、このドーナツを自作 C コンパイラで動かそう、などのアイデアです。

受講生の方に私がどれだけのことを教えられたかはわかりませんが、 少なくとも彼らは十分すぎるくらいの成果を生み出していました。

感想

講師としてキャンプに参加する前は、人に何かを教える立場から距離をとっていました。 しかし、講師という立場をいざ体験してみると、色々な反省はあるものの、案外楽しいものだと思えるようになりました。

2018年に私がキャンプを終えた時に、将来講師として戻ってきてほしいと言われた気がしますが、その時は 本当に戻ってくるとは思ってもみませんでした。本当に。

今回のキャンプを卒業した方の中から、将来の講師になる方が出てくるといいなと思いました。

反省

  • もっとしっかりとした教材を用意したかった
    • 質問に答えているだけでも一応ゼミとしては成り立つけど、もっとこう、読み物として面白い教材を作りたい
    • 最適化の教材を途中まで作っていたけど、まだ完成していない
  • hsjoihs さんにかなり頼っていた気がする
    • 計算機科学含め、幅広い分野に精通したい
    • どの分野も繋がっているんだと改めて気付かされました
]]> DNN雑記 https://maekawatoshiki.github.io/posts/ml/ Thu, 23 Dec 2021 19:47:09 +0900 https://maekawatoshiki.github.io/posts/ml/ この記事は何？ いきなりDeep Neural Networkの世界に足を踏み入れた人がいろいろ語るだけ あまり細かい話はしない 丸と矢印 深層学習だとかニューラルネットワーク（以下NN）だとか検索すると、以下のような画像をよく見かけると思う。全結合層があって、多分最後の方に活性化関数が挟んである。 入力にデータを流し込んであげると出力を得ることができる、とてもシンプルな構造をしている。 丸と矢印と… しかし、近年実際に使われているDNNはこれほど簡単な構造はしていない。 例えば、以下は文字認識を行うモデル(MNIST1)をONNX2形式としてエクスポートしてnetron3で表示したもの。 一目瞭然だが、先ほどの画像のNNとはだいぶ見た目が違う。丸くないし、いや、でも矢印はある。 丸の代わりに角丸の四角が現れた。矢印の横には謎の数字の列が書いてある。 ぱっと見、グラフ（DAG）であることはわかると思う。 軽く説明すると以下の通り。 角丸の四角: 命令（Operator; ONNX用語？真に受けないでほしい）。命令はデータに対してなんらかの操作を行う。 例えば、上の画像中の Relu はデータの一要素づつ（数値一つ一つ）に ReLU4 を適用する 一方、Conv はデータ全体に対して畳み込み5 を行う 命令ごとに、一要素づつ(element-wise)に操作を行なうのか、部分的に({layer,channel,row,&hellip;}-wise)操作を行なうのか違ってややこしい 矢印: データの流れる方向。データというのは画像だったり文字列だったり… 謎の数字の列: テンソル6のshape。要するにデータがどのような形（のテンソル）なのかを表す。 なんと静的じゃないこともある。画像中ではすべての矢印の横に数字の列（＝shape)が書いてあるが、これは運がいいだけ。shape inference（=shapeを推論する）しても静的に shape が決まらないこともある。でもそのおかげで文字列とか複数のbounding boxを扱えたりする。 より複雑なモデル（画像を分類したりとか）は、もちろんより複雑な構造をしている。netron で表示すると重い。 グラフを計算機が理解するまで DNN はネットワークであり、グラフであり、そのままでは計算機上で動かない。 PyTorch, TensorFlow, Chainer, &hellip; などの機械学習フレームワークは、設計思想の差こそあれ結局はNNモデルを計算機上で実際に動作させるためのものである。そこにはコンパイラと呼べるものが必ずある。いわゆる機械学習コンパイラである。 機械学習コンパイラのやることは、簡単に言えば以下の通りである。 NNモデルのグラフをより簡単な表現に変換する。命令（ノード）同士をくっつけたり分離したり、大胆に順番を入れ替えたり。（数学的に正しくなくてもいい！） 命令の実行順序を決定する。動的に変える場合もある。グラフ中には並列に実行できる命令が含まれるので気を付ける。 CPU, GPU, 独自アクセラレータなどごとに命令列を機械語へ変換。アセンブリを吐いたり、（サボって）LLVMとかOpenCLとかでカーネル吐いたり。CUDAで頑張る？ このあと、CPU, GPU, &hellip; などが複雑に絡み合うヘテロジニアスな環境でどうやって高速にデータを受け渡すか、などの話もあるけどコンパイラの役割じゃない気がしたので省略。 現実 DNN は実際はただのグラフで、そこにデータを流し込んでるだけ。学習時はちょっと違うのかもしれないけど、少なくとも推論時はそう。 計算機をいかに高速に・効率的に動かすかを考えるのは面白い。けど、これが人工知能って呼ばれてるのをみるとなんか微妙な気持ちになるね。 （p.s. DNNの量子化の話聞きたい人いるかな？モデルのパラメータ数を減らしたり、モデル自体を小さくコンパクトにする系の話） 脚注 MNISTデータセット&#160;&#x21a9;&#xfe0e; Open Neural Network Exchange の略。ここでは ONNX の定める、NNのモデルを表現するためのフォーマットを指す。&#160;&#x21a9;&#xfe0e; この記事は何？
  • いきなりDeep Neural Networkの世界に足を踏み入れた人がいろいろ語るだけ
  • あまり細かい話はしない

丸と矢印

深層学習だとかニューラルネットワーク（以下NN）だとか検索すると、以下のような画像をよく見かけると思う。全結合層があって、多分最後の方に活性化関数が挟んである。

nn

入力にデータを流し込んであげると出力を得ることができる、とてもシンプルな構造をしている。

丸と矢印と…

しかし、近年実際に使われているDNNはこれほど簡単な構造はしていない。

例えば、以下は文字認識を行うモデル(MNIST1)をONNX2形式としてエクスポートしてnetron3で表示したもの。

mnist

一目瞭然だが、先ほどの画像のNNとはだいぶ見た目が違う。丸くないし、いや、でも矢印はある。 丸の代わりに角丸の四角が現れた。矢印の横には謎の数字の列が書いてある。

ぱっと見、グラフ（DAG）であることはわかると思う。

軽く説明すると以下の通り。

  • 角丸の四角: 命令（Operator; ONNX用語？真に受けないでほしい）。命令はデータに対してなんらかの操作を行う。
    • 例えば、上の画像中の Relu はデータの一要素づつ（数値一つ一つ）に ReLU4 を適用する
    • 一方、Conv はデータ全体に対して畳み込み5 を行う
      • 命令ごとに、一要素づつ(element-wise)に操作を行なうのか、部分的に({layer,channel,row,…}-wise)操作を行なうのか違ってややこしい
  • 矢印: データの流れる方向。データというのは画像だったり文字列だったり…
  • 謎の数字の列: テンソル6のshape。要するにデータがどのような形（のテンソル）なのかを表す。
    • なんと静的じゃないこともある。画像中ではすべての矢印の横に数字の列（＝shape)が書いてあるが、これは運がいいだけ。shape inference（=shapeを推論する）しても静的に shape が決まらないこともある。でもそのおかげで文字列とか複数のbounding boxを扱えたりする。

より複雑なモデル（画像を分類したりとか）は、もちろんより複雑な構造をしている。netron で表示すると重い。

グラフを計算機が理解するまで

DNN はネットワークであり、グラフであり、そのままでは計算機上で動かない。

PyTorch, TensorFlow, Chainer, … などの機械学習フレームワークは、設計思想の差こそあれ結局はNNモデルを計算機上で実際に動作させるためのものである。そこにはコンパイラと呼べるものが必ずある。いわゆる機械学習コンパイラである。

機械学習コンパイラのやることは、簡単に言えば以下の通りである。

  1. NNモデルのグラフをより簡単な表現に変換する。命令（ノード）同士をくっつけたり分離したり、大胆に順番を入れ替えたり。（数学的に正しくなくてもいい！）
  2. 命令の実行順序を決定する。動的に変える場合もある。グラフ中には並列に実行できる命令が含まれるので気を付ける。
  3. CPU, GPU, 独自アクセラレータなどごとに命令列を機械語へ変換。アセンブリを吐いたり、（サボって）LLVMとかOpenCLとかでカーネル吐いたり。CUDAで頑張る？

このあと、CPU, GPU, … などが複雑に絡み合うヘテロジニアスな環境でどうやって高速にデータを受け渡すか、などの話もあるけどコンパイラの役割じゃない気がしたので省略。

現実

DNN は実際はただのグラフで、そこにデータを流し込んでるだけ。学習時はちょっと違うのかもしれないけど、少なくとも推論時はそう。

計算機をいかに高速に・効率的に動かすかを考えるのは面白い。けど、これが人工知能って呼ばれてるのをみるとなんか微妙な気持ちになるね。

（p.s. DNNの量子化の話聞きたい人いるかな？モデルのパラメータ数を減らしたり、モデル自体を小さくコンパクトにする系の話）

脚注

  1. MNISTデータセット ↩︎

  2. Open Neural Network Exchange の略。ここでは ONNX の定める、NNのモデルを表現するためのフォーマットを指す。 ↩︎

  3. netron。NNのモデルを可視化してくれる。 ↩︎

  4. ReLU。角が尖ってる。 ↩︎

  5. Convolution ↩︎

  6. 行列は2階のテンソル。要するに高次元の行列だと思えばわかりやすい。 これがわかりやすい？ ↩︎

]]> Google Summer of Code 2021 を終えました https://maekawatoshiki.github.io/posts/gsoc3/ Thu, 09 Sep 2021 00:08:57 +0900 https://maekawatoshiki.github.io/posts/gsoc3/ TL;DR Google Summer of Code 2021 を終えました First, Final Evaluation ともに通りました、という意味 LLVM むずかしい 成果 Google Summer of Code とは 前に書いた記事を参照してください。 何をしたのか 2021/May/20 から 2021/Aug/28 くらいまで、メンターの方たちと共に LLVM へ貢献していました。 （まだマージされていないパッチがあるんですけどね&hellip;） 正確には、コーディングをはじめたのは６月くらいからみたいです。 LLVM? The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. The LLVM Compiler Infrastructure clang や lld などを傘下に持つ、コンパイラ基盤のプロジェクトです。 （以下 LLVM についてある程度詳しいことを前提として話を進めていきます；またいつか LLVM 自体の解説もしたい） テーマ 提出した Proposal のタイトルは Utilize LoopNest Pass でした。 Pass というと、Module Pass, Function Pass, Loop Pass, &hellip; など色々あります。 その中に、最近追加されたばかりの LoopNest Pass (New Pass Manager でのみ動作) というものがあります。 これは、ネストしたループを扱うための Pass なのですが、 まだほとんど使われていません（でした）。 私がこの夏にやったことは、LoopNest Pass として実装されている Pass を増やすことです。 TL;DR
  • Google Summer of Code 2021 を終えました
    • First, Final Evaluation ともに通りました、という意味
  • LLVM むずかしい
  • 成果

Google Summer of Code とは

前に書いた記事を参照してください。

何をしたのか

2021/May/20 から 2021/Aug/28 くらいまで、メンターの方たちと共に LLVM へ貢献していました。 （まだマージされていないパッチがあるんですけどね…）

正確には、コーディングをはじめたのは６月くらいからみたいです。

LLVM?

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. The LLVM Compiler Infrastructure

clang や lld などを傘下に持つ、コンパイラ基盤のプロジェクトです。

（以下 LLVM についてある程度詳しいことを前提として話を進めていきます；またいつか LLVM 自体の解説もしたい）

テーマ

提出した Proposal のタイトルは Utilize LoopNest Pass でした。

Pass というと、Module Pass, Function Pass, Loop Pass, … など色々あります。 その中に、最近追加されたばかりの LoopNest Pass (New Pass Manager でのみ動作) というものがあります。 これは、ネストしたループを扱うための Pass なのですが、 まだほとんど使われていません（でした）。 私がこの夏にやったことは、LoopNest Pass として実装されている Pass を増やすことです。

Loop Pass とは別に LoopNest Pass が作られた理由にはいくつかあります。 例えば、ネストしたループ向けの最適化手法には、Loop Pass (や Function Pass) として実装するとコード量が増えてしまうものや、そもそも うまく実装できないものが存在します。そのような最適化手法は、LoopNest Pass として簡単に実装できる可能性が高いです。

LoopNest Pass と Loop Pass の違い

Loop Pass Pipeline X に、Loop Pass A, B が順番に並んでいるとします。 ここで、X に以下のループを流してみます。（X に outerL に対応する Loop オブジェクトを渡す、の意）

outerL:
  innerL:
    body

すると、まず innerL が A, B によって最適化され、その後に outerL が A, B によって最適化されます。 要するに、最内ループから最外ループへ向かって最適化が行われるというわけです。

特に問題なさそうに見えますが、これはあくまで個別のループに個別の最適化を施す場合には問題がない、というだけです。

例えば、outerL と innerL を見比べてからループネスト全体に何らかの操作を施したい場合はどうしればいいのでしょうか。 （単純な解決法：innerL を無視して outerL の順番がやってきたらループネスト全体を見渡せば良い； 問題：innerL を飛ばすためのコードが必要になる。そもそも Loop Pass に渡される Loop オブジェクトはループネストを扱うのには適していない）

ここで LoopNest Pass の登場です。

Loop Pass Pipeline Y に、Loop Pass A, B と LoopNest Pass C が順番に並んでいるとします。 ここで、Y に先程のループを流してみます。

すると、まず innerL が A, B によって最適化され、その後に outerL が A, B, C によって最適化されます。 要するに、LoopNest Pass は最外ループにのみ適用されるのです。 しかも、LoopNest Pass は Loop オブジェクトではなく LoopNest オブジェクトを受けとります。 これにより、Loop Pass として実装する場合と比べて、ループネストを扱いやすくなります。

もうちょっと具体例: loop-interchange

以下のようなループネストを考えます。

for k = 0, 10:
  for i = 0, 10:
    for j = 0, 10:
      A[i, j, k] += B[i, j, k]

見るからに何かがおかしいですよね？最外ループの添字が k となっていますが、これではキャッシュに当たる気がしません。

このようなループネストには、それぞれのループの順番を入れ替える loop-interchange という最適化を施すと良いです。

# loop-interchange 後
for i = 0, 10:
  for j = 0, 10:
    for k = 0, 10:
      A[i, j, k] += B[i, j, k]

このような最適化は、ループネスト全体を見渡す必要があります。そのため LoopNest Pass として実装すると良いです。 （でないと、for-k を飛ばして・for-j を飛ばして、という処理を個々の Loop Pass 内に記述する必要が出てきます）

何を学んだのか

LLVM という大きな OSS プロジェクトに貢献する中で、色々なことを学びました。

例えば、私はいつも大きなソースツリーを見ると上から下まで読みたくなるのですが、 そんなことを LLVM に対してしていたら一生が終わってしまいます。 なので今回の GSoC ではそんなことはせず、自分の担当する部分に関連する部分だけを集中的に読みました。 大きなソフトウェアはその一部分のみを理解しているだけで十分（であることが望ましい…）なんだと実感しました。

もう一つ、痛感したことがあります。 それは、コーディング能力は確かに重要だけれども、それ以上にコミュニケーション能力が重要だということです。 パッチを投げる、レビューを受ける、変更の意図を説明する…、すべての過程で（英語での）わかりやすい説明を求められます。 自分の意図を正確に伝えられないと、相手に無駄な時間を取らせてしまうこともあります。

英語でのテキスト（&できれば口頭での）コミュニケーション能力は身につけておかないと痛い目に合います。

どうでもいいこと一覧

  • メンター２人（１人とはあんまり話さなかったけど）、プロジェクトメンバー２人、私の合計５人でプロジェクトを進めた
    • 私とプロジェクトメンバーの１人がほとんどのパッチを作ったと思う
  • 連絡は Discord で行った
  • 毎週 Webex でミーティングを行った。口頭での英語にほんの少しだけ慣れた。
  • LLVM のコミット権をもらえて嬉しかった
  • 2700USD 貰った （国ごとに貰える量は違うみたい）
  • お金は Payoneerってやつで受け取った
  • CI が落ちると怖い（メールが来る）
  • Address/Memory Sanitizer は偉い
  • 初めて master にコミットしたときは手が震えた
    • そしてそのコミットを何度も revert する羽目になって辛かった

以上。来年以降に参加する人の助けになればいいなあ。

（質問があれば twitter@uint256_t へ DM とか投げてください）

]]> GSoC 2021 の First Evaluation に通りました https://maekawatoshiki.github.io/posts/gsoc2/ Sun, 25 Jul 2021 01:16:16 +0900 https://maekawatoshiki.github.io/posts/gsoc2/ TL;DR Google Summer of Code 2021 の First Evaluation に通りました 2700USD * 0.45 = 1215USD = 13万円くらい貰えました 詳しいこと あとで書きます TL;DR
  • Google Summer of Code 2021 の First Evaluation に通りました
  • 2700USD * 0.45 = 1215USD = 13万円くらい貰えました

詳しいこと

あとで書きます

]]> Google Summer of Code 2021 に参加します https://maekawatoshiki.github.io/posts/gsoc1/ Wed, 19 May 2021 15:56:20 +0900 https://maekawatoshiki.github.io/posts/gsoc1/ TL;DR Google Summer of Code に提出したProposalが採択されました 晴れてGSoCに参加できることとなりました 参加団体はLLVMです 嬉しい Google Summer of Codeとは Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 10 week programming project during their break from school. (https://summerofcode.withgoogle.com/) Google Summer of Code は、OSSプロジェクトにメンター付きで参加することができ、さらに Google から報酬ももらえるイベントです。 その名の通り夏（休み）に行われるのですが、アメリカ規準であって、日本の大学などでは普通に授業が行われています。 本来であれば、学部2年生の私にとっては参加が少し厳しいはずでしたが、今年は新型コロナの影響でプロジェクトに取り組む時間の制約が緩くなった (40h/w→17h+/w) ので、思い切って参加してみました。(大学もずっとオンラインで、家にこもりっぱなしですし。) Proposal採択までの流れ 3月の初めから、以下の作業を始めました。 参加団体を選ぶ 公式サイトを見れば、様々な団体がGSoCに参加しているとわかります。 私は、ずっと LLVM に貢献したかったので、無論それを選びました。 参加プロジェクトを選ぶ 各団体のほぼすべてが、学生向けのプロジェクト一覧を公開しているはずです。LLVM ならここ。 興味のあるプロジェクトは、初めのうちは複数個選んでおいた方がいいと思います。後になって、選んだプロジェクトが想像以上に難しいものだと判明すると、Proposalを書くのが大変ですし、不必要に自分を追い込んでしまいます。 TL;DR
  • Google Summer of Code に提出したProposalが採択されました
  • 晴れてGSoCに参加できることとなりました
  • 参加団体はLLVMです
  • 嬉しい

Google Summer of Codeとは

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 10 week programming project during their break from school.

(https://summerofcode.withgoogle.com/)

Google Summer of Code は、OSSプロジェクトにメンター付きで参加することができ、さらに Google から報酬ももらえるイベントです。 その名の通り夏（休み）に行われるのですが、アメリカ規準であって、日本の大学などでは普通に授業が行われています。 本来であれば、学部2年生の私にとっては参加が少し厳しいはずでしたが、今年は新型コロナの影響でプロジェクトに取り組む時間の制約が緩くなった (40h/w→17h+/w) ので、思い切って参加してみました。(大学もずっとオンラインで、家にこもりっぱなしですし。)

Proposal採択までの流れ

3月の初めから、以下の作業を始めました。

参加団体を選ぶ

公式サイトを見れば、様々な団体がGSoCに参加しているとわかります。 私は、ずっと LLVM に貢献したかったので、無論それを選びました。

参加プロジェクトを選ぶ

各団体のほぼすべてが、学生向けのプロジェクト一覧を公開しているはずです。LLVM ならここ。 興味のあるプロジェクトは、初めのうちは複数個選んでおいた方がいいと思います。後になって、選んだプロジェクトが想像以上に難しいものだと判明すると、Proposalを書くのが大変ですし、不必要に自分を追い込んでしまいます。

メーリングリストと奮闘する

興味のあるプロジェクトを選んだら、各団体のメンターと連絡を取ります。ここから先は各団体の指示に従うべきです。 私の場合は、メーリングリストでメンターの方にプロジェクトの詳しい説明を聞いていました。このあたりから辿れます。

(英語のメールを書くのがかなり久しぶりだったので少し緊張しました。)

Proposalを書く

各団体に提出するためのProposalを書きます。ネット上には過去GSoCに参加した方のProposalの例が沢山公開されています。

もちろん私も公開します。

Proposalは、ある程度書いたらメンターの人に見てもらって、アドバイスを貰ったりしました。

(↑と同時並行で) 小さめのパッチを送る

Proposalの内容と関係のある小さめのパッチを送ったりもしました。 自分の能力を示すためにも、Issueを立てたり、PRを投げたりするのは重要だと思います。

Your proposal has been accepted!

May/18/2021 (JST) の深夜に、以下のメールが届きました。

受験が終わった時のような気分でした。 頑張ります。

次回予告

丁度今日の深夜にメンターの方と話すので、何か面白い話題が生まれたら書きたい。

]]> Play with LLVM-IR, without LLVM https://maekawatoshiki.github.io/posts/vicis/ Sun, 02 May 2021 22:04:08 +0900 https://maekawatoshiki.github.io/posts/vicis/ TL;DR LLVMの代替実装をRustで作っています。(ただの趣味) これを使って LLVM-IR とじゃれ合ってみよう、という記事です。 LLVM-IRに触れる。LLVM抜きで。 インターネットで放浪してたら、このような記事を見つけました。 RustのLLVM IRでプログラム分析ことはじめ - Toshihiro YAMAGUCHI’s Diary 私はこれまでに、rustcの吐くLLVM-IRを直接見たことがほとんどありませんでした。丁度よい機会なので、LLVMの復習がてら記事と同じようなことをしようとしたのですが、ただ真似るだけでは面白くない。 そうだ、LLVMをRustで実装して、同じようなことをしよう というわけで、趣味として LLVMをRustで再実装し始めました。(Vicisと名付けた) この記事では Vicis を使って、LLVM-IRを、LLVM抜きで触っていきます。 とりあえずプロジェクトを作る 記事の中では、モジュールに含まれる関数を列挙していました。これと同じことをやってみます。 cargo new viewer --bin # viewerというプロジェクトにします プロジェクトを作ったら、Cargo.tomlにVicisを追加しておきましょう。 ... [dependencies] vicis = { path = &#34;/path/to/vicis&#34; } IRを読み込む Vicisは現在、LLVM Assemblyの一部にしか対応できていません。(bitcode対応など頑張ります&hellip;) src/main.rsを以下のように変更します。 use std::{env, fs::read_to_string}; use vicis::ir::module; fn main() { let args: Vec&lt;String&gt; = env::args().collect(); let file = &amp;args[1]; let asm = read_to_string(file).expect(&#34;failed to read .ll file&#34;); let module = module::parse_assembly(asm. TL;DR

LLVMの代替実装をRustで作っています。(ただの趣味)

これを使って LLVM-IR とじゃれ合ってみよう、という記事です。

LLVM-IRに触れる。LLVM抜きで。

インターネットで放浪してたら、このような記事を見つけました。

RustのLLVM IRでプログラム分析ことはじめ - Toshihiro YAMAGUCHI’s Diary

私はこれまでに、rustcの吐くLLVM-IRを直接見たことがほとんどありませんでした。丁度よい機会なので、LLVMの復習がてら記事と同じようなことをしようとしたのですが、ただ真似るだけでは面白くない。

そうだ、LLVMをRustで実装して、同じようなことをしよう

というわけで、趣味として LLVMをRustで再実装し始めました。(Vicisと名付けた) この記事では Vicis を使って、LLVM-IRを、LLVM抜きで触っていきます。

とりあえずプロジェクトを作る

記事の中では、モジュールに含まれる関数を列挙していました。これと同じことをやってみます。

cargo new viewer --bin # viewerというプロジェクトにします

プロジェクトを作ったら、Cargo.tomlにVicisを追加しておきましょう。

...
[dependencies]
vicis = { path = "/path/to/vicis" }

IRを読み込む

Vicisは現在、LLVM Assemblyの一部にしか対応できていません。(bitcode対応など頑張ります…)

src/main.rsを以下のように変更します。

use std::{env, fs::read_to_string};
use vicis::ir::module;

fn main() {
    let args: Vec<String> = env::args().collect();
    let file = &args[1];
    let asm = read_to_string(file).expect("failed to read .ll file");

    let module = module::parse_assembly(asm.as_str()).expect("failed to parse module");
    println!("{:?}", module);
}

これだけで、コマンドライン引数として渡した *.llファイルの中身をパースして、内部表現としてのModuleに変換できます。 さっそく動かしてみましょう。

Hello World

RustでHello Worldを書いて、そのIRを見てましょう。hello.rsというファイルを用意します。

// hello.rs
fn main() {
	println!("hello world")
}

そして、rustcでコンパイルします。IRを出力する点に注意。

rustc +stable hello.rs -o hello.ll --emit llvm-ir

できあがった hello.ll を引数として渡してみましょう。

cargo run hello.ll

おそらくとっても長いIRが出力されたと思います。成功です。

解析

長いIRを目grepするのは大変なので、関数名と関数の引数の数を出力するパスを作ってみます。

main.rsを以下のように修正します。

use std::{any::Any, env, fs::read_to_string};
use vicis::{
    ir::{function, module},
    pass::{AnalysisPass, PassManager},
};

fn main() {
    let args: Vec<String> = env::args().collect();
    let file = &args[1];
    let asm = read_to_string(file).expect("failed to read .ll file");

    let module = module::parse_assembly(asm.as_str()).expect("failed to parse module");
    let mut pm = PassManager::new();
    pm.add_analysis(FunctionPrinterPass);
  pm.run_analyses_on_module(&module);
}

pub struct FunctionPrinterPass;

impl AnalysisPass<function::Function> for FunctionPrinterPass {
    fn run_on(&self, func: &function::Function, _result: &mut Box<dyn Any>) {
        println!(
            "Visit: {} (takes {} args)",
            func.name(),
            func.params().len()
        );
    }
}

パスマネージャとかの実装がまだまだ適当です。それはさておいて、実行すると以下のように表示されるはずです。

Visit: _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h2840e0051141d5fcE (takes 1 args)
Visit: _ZN3std2rt10lang_start17h2fcf2a95611b6d93E (takes 3 args)
Visit: "_ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h642830c734a0a093E" (takes 1 args)
Visit: _ZN3std3sys4unix7process14process_common8ExitCode6as_i3217he311503d36a1dd10E (takes 1 args)
Visit: _ZN4core3fmt9Arguments6new_v117h8a113b20b098f88cE (takes 5 args)
Visit: "_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h32e55b47309d557aE" (takes 1 args)
Visit: _ZN4core3ops8function6FnOnce9call_once17h2daf67ca1036ee98E (takes 1 args)
Visit: _ZN4core3ops8function6FnOnce9call_once17hcf10f9084cb14a26E (takes 1 args)
Visit: "_ZN4core3ptr85drop_in_place$LT$std..rt..lang_start$LT$$LP$$RP$$GT$..$u7b$$u7b$closure$u7d$$u7d$$GT$17h74f0928264863a31E" (takes 1 args)
Visit: _ZN4core4hint9black_box17h5fe2e550e252fbc3E (takes 0 args)
Visit: "_ZN54_$LT$$LP$$RP$$u20$as$u20$std..process..Termination$GT$6report17h8ac75e0172be52beE" (takes 0 args)
Visit: "_ZN68_$LT$std..process..ExitCode$u20$as$u20$std..process..Termination$GT$6report17h63a57c0453f08cd5E" (takes 1 args)
Visit: _ZN5hello4main17h391fdbb81e062d23E (takes 0 args)
Visit: rust_eh_personality (takes 5 args)
Visit: _ZN3std2rt19lang_start_internal17hd5b67df56ca01daeE (takes 4 args)
Visit: _ZN3std2io5stdio6_print17hfdac4ecf8a146755E (takes 1 args)
Visit: main (takes 2 args)

ちゃんと関数名と引数の数が表示されました。成功です。

終わりに

Vicisはまだまだ実装されていない機能が沢山あります。Issue&PR いつでも歓迎です。

]]> コンパイラと私 https://maekawatoshiki.github.io/posts/compilerandi/ Thu, 29 Apr 2021 22:42:05 +0900 https://maekawatoshiki.github.io/posts/compilerandi/ ここでは、私がどのようにして「コンパイラ」というものを認識し、そして夢中になったのかについて書いていこうと思う。 私が初めてプログラミングを体験したのは小学6年生のころだった。C言語を使って Hello World を画面（ターミナル、そのころは Windows を使っていたからコマンドプロンプトだった）に表示するという、いたって典型的な入門だった。正直あまり面白くなかったし、そもそもキーボードが打てない、ファイルをどこに保存したのかわからない、というレベルだった。 そんなレベルの私がなぜC言語を始めたかというと、もともと簡単な電子工作をしており、次はロボットを動かしたかったからである。C言語以外の言語を知らなかった私は、親に「猫でもわかるC言語プログラミング」を買ってもらい、どうにか Hello World をコンパイルできる程度の環境を構築したというわけだ。 それ以降の小学6年生の記憶はかなり曖昧だが、たしかある程度C言語を使えるようになり、Win32 APIでウィンドウを表示するサンプルが動いて喜んでいたと思う。同時に、「なぜこの英語の文章（＝プログラム）がウィンドウを表示したりできるんだ？」といった純粋な疑問も持っていた。「コンパイラ」という単語はうっすらと認識していたが、どちらかと言えば「コンパイルして実行」のような連続した語として記憶していたため、まだコンパイラというソフトウェア自体にはあまり興味を示していなかったと思う。 中学1年生になると、すっかりロボットを動かすという目標を忘れ、GUIプログラミングを楽しんでいた。 （物理的にも処理速度的にも）重たいパソコン上で Visual Studio を動かし、C言語を書いていた。F5を押せばプログラムは動いた。そこにコンパイラはなく、その存在は統合開発環境が隠蔽していた。 そのうちに HSP (Hot Soup Processor) を知り、簡単に GUI プログラミングができると興奮し、かなりの数のくだらないソフトウェアを作ったと思う。画面キャプチャ、ただファイルをゴミ箱に送るだけのソフト、画面端で常駐する電卓、円周率を計算するやつ&hellip;.. そう、HSP で円周率を計算し始めたことで気づいた。HSP は遅い。C言語は速かったのに。 そのころになってようやく、世の中にはコンパイル型言語とインタプリタ型言語というものがあると知った。いや、知ったというよりは実感したと言うべきだろうか。とにかく、コンパイラというものに惹かれ始めたのは中学1年生のかなり後半だったと思う。ここから、私とコンパイラとの関係が始まったのだと思う。 最初のうちは、Ruby の VM に興味を持っていた。なぜ Ruby なのかはよく覚えていないが、おそらく英語が読めない私にとって、日本語の資料が落ちていたのは魅力的だったのだろう。YARV の内部構造を説明するサイト（たぶんこのあたり）に釘付けだった。この文章を書きながらリンク先を眺めていたが、今見ても面白い。第3回：命令ディスパッチの話は、当時は理解こそできなかったものの、こんなことができるのか！すごい！と興味津々だった。これが中学2年生の初めの話。 インタプリタやコンパイラのことを認識した以上、何らかの言語を作りたくなるのは避けられない。 （実は HSP で電卓を作っていた頃に、小さな言語のようなものは作っていたが、BASIC よりもしょぼい文法で、AST すら知らなかったためぐちゃぐちゃのコードだったと記憶している。もう手元にはコードが残っていない。そのコードが入っている80GB HDDは分解して、ディスクを手裏剣のように投げて遊んでいた。） 今手元に残っている言語処理系で、一番古いものは Lit だ。いつのまにか C++ を覚えたようで、C++ で書いてあるし、なんとご丁寧にGitHubに置いてある。 まったく思い出せないが、どうにかgitやGitHubの使い方を覚えたようである。最初のコミットは中学2年生の夏休み頃となっている。 Lit は Ruby っぽい言語で、なんと JIT コンパイルできる。初期は手動でアセンブラ（と言っても命令に対応する16進数をハードコードしているだけだが）のようなものを書いており、それを使って JIT していたようだ。結局 LLVM を導入してしまったようだが。そもそもどのような経緯でLLVMを知ったのかも思い出せない。 中学3年生になると、ほとんど理解できていなかったと思われるが、Python や Clang を読んでいたような気がする。また、中学生が終わろうとしているときに、CMake があまりにも嫌いで C++ ごと捨ててしまった。同時に Rust を本格的に使い始めた。 ここでは、私がどのようにして「コンパイラ」というものを認識し、そして夢中になったのかについて書いていこうと思う。

私が初めてプログラミングを体験したのは小学6年生のころだった。C言語を使って Hello World を画面（ターミナル、そのころは Windows を使っていたからコマンドプロンプトだった）に表示するという、いたって典型的な入門だった。正直あまり面白くなかったし、そもそもキーボードが打てない、ファイルをどこに保存したのかわからない、というレベルだった。

そんなレベルの私がなぜC言語を始めたかというと、もともと簡単な電子工作をしており、次はロボットを動かしたかったからである。C言語以外の言語を知らなかった私は、親に「猫でもわかるC言語プログラミング」を買ってもらい、どうにか Hello World をコンパイルできる程度の環境を構築したというわけだ。

それ以降の小学6年生の記憶はかなり曖昧だが、たしかある程度C言語を使えるようになり、Win32 APIでウィンドウを表示するサンプルが動いて喜んでいたと思う。同時に、「なぜこの英語の文章（＝プログラム）がウィンドウを表示したりできるんだ？」といった純粋な疑問も持っていた。「コンパイラ」という単語はうっすらと認識していたが、どちらかと言えば「コンパイルして実行」のような連続した語として記憶していたため、まだコンパイラというソフトウェア自体にはあまり興味を示していなかったと思う。

中学1年生になると、すっかりロボットを動かすという目標を忘れ、GUIプログラミングを楽しんでいた。 （物理的にも処理速度的にも）重たいパソコン上で Visual Studio を動かし、C言語を書いていた。F5を押せばプログラムは動いた。そこにコンパイラはなく、その存在は統合開発環境が隠蔽していた。 そのうちに HSP (Hot Soup Processor) を知り、簡単に GUI プログラミングができると興奮し、かなりの数のくだらないソフトウェアを作ったと思う。画面キャプチャ、ただファイルをゴミ箱に送るだけのソフト、画面端で常駐する電卓、円周率を計算するやつ…..

そう、HSP で円周率を計算し始めたことで気づいた。HSP は遅い。C言語は速かったのに。

そのころになってようやく、世の中にはコンパイル型言語とインタプリタ型言語というものがあると知った。いや、知ったというよりは実感したと言うべきだろうか。とにかく、コンパイラというものに惹かれ始めたのは中学1年生のかなり後半だったと思う。ここから、私とコンパイラとの関係が始まったのだと思う。

最初のうちは、Ruby の VM に興味を持っていた。なぜ Ruby なのかはよく覚えていないが、おそらく英語が読めない私にとって、日本語の資料が落ちていたのは魅力的だったのだろう。YARV の内部構造を説明するサイト（たぶんこのあたり）に釘付けだった。この文章を書きながらリンク先を眺めていたが、今見ても面白い。第3回：命令ディスパッチの話は、当時は理解こそできなかったものの、こんなことができるのか！すごい！と興味津々だった。これが中学2年生の初めの話。

インタプリタやコンパイラのことを認識した以上、何らかの言語を作りたくなるのは避けられない。 （実は HSP で電卓を作っていた頃に、小さな言語のようなものは作っていたが、BASIC よりもしょぼい文法で、AST すら知らなかったためぐちゃぐちゃのコードだったと記憶している。もう手元にはコードが残っていない。そのコードが入っている80GB HDDは分解して、ディスクを手裏剣のように投げて遊んでいた。） 今手元に残っている言語処理系で、一番古いものは Lit だ。いつのまにか C++ を覚えたようで、C++ で書いてあるし、なんとご丁寧にGitHubに置いてある。 まったく思い出せないが、どうにかgitやGitHubの使い方を覚えたようである。最初のコミットは中学2年生の夏休み頃となっている。 Lit は Ruby っぽい言語で、なんと JIT コンパイルできる。初期は手動でアセンブラ（と言っても命令に対応する16進数をハードコードしているだけだが）のようなものを書いており、それを使って JIT していたようだ。結局 LLVM を導入してしまったようだが。そもそもどのような経緯でLLVMを知ったのかも思い出せない。

中学3年生になると、ほとんど理解できていなかったと思われるが、Python や Clang を読んでいたような気がする。また、中学生が終わろうとしているときに、CMake があまりにも嫌いで C++ ごと捨ててしまった。同時に Rust を本格的に使い始めた。

そろそろこの文章を書くのも疲れてきた。ここからは簡潔にまとめよう。

高校生になると、本当に色々なことがあった。入門したての Rust でいきなり C言語のコンパイラを作ったり (8ccには本当にお世話になりました) 。 ブラウザを作ったり。JavaScript処理系を作ったり。JVMを作ったり。.NET VMを作ったり。型システムにも少しだけ詳しくなった。受験が嫌でコンパイラ基盤を作ったりもした。そうそう、プログラミング言語処理系が好きな人の集まりというSlackワークスペースも開いた。受験期なのに地下鉄でLLVMのソースコードリーディングをしていた。

そして大学生になった。流行り病のことは完全に予想外だった。一年間完全にオンラインだったこともあり、家でずっとコンパイラのことを考えていられる生活ができたのは良かったかもしれない。これからもコンパイラのことを考え続けるだろう。

しかし、ひとつだけわからないのは、私はコンパイラの何が好きなのかということだ。ただ漠然と、好き、という感情があるだけで、それ以上何もない。 今後しばらくは、コンパイラの何に惹かれているのかを考えることになりそうだ。

]]> Third https://maekawatoshiki.github.io/posts/third/ Sun, 28 Feb 2021 23:30:39 +0900 https://maekawatoshiki.github.io/posts/third/ Second https://maekawatoshiki.github.io/posts/second/ Sun, 28 Feb 2021 23:26:09 +0900 https://maekawatoshiki.github.io/posts/second/ my second page my second page

]]> Welcome!! https://maekawatoshiki.github.io/posts/welcome/ Sun, 28 Feb 2021 14:00:00 +0000 https://maekawatoshiki.github.io/posts/welcome/ hello world hello world

]]>