2017-04-11

リポジトリごとに user.name と user.email を変更する

git

会社で Github Enterprise を使っているので、github.com の方の user.name と user.email でコミットしてしまわないようにリポジトリごとに設定を変更できるようにした。

gitconfig にあった user.name と user.email をけして、useConfigOnly を true にした。こうすることで、リポジトリごとに user.name と user.email を設定しないと *** Please tell me who you are. などといわれてコミットに失敗するようになり、誤ったユーザでのコミットを防げる。変更前

[user]
    name = ganmacs
    email = ganmacs@gmail.com

変更後

[user]
    useConfigOnly = true

あとは、シェルに以下のような関数を定義しておけば良さそう。

function company() {
    git config user.name "namae"
    echo "Set user.name as $(git config --get user.name)"
    git config user.email "foo@bar.com"
    echo "Set user.email as $(git config --get user.email)"
}

function private() {
    git config user.name "ganmacs"
    echo "Set user.name as $(git config --get user.name)"
    git config user.email "ganmacs@gmail.com"
    echo "Set user.email as $(git config --get user.email)"
}

その他

pre-commit hook などでディレクトリごとに自動で設定する方法も考えたが、大げさだなと思ってこの方法に落ち着けた。もっといい方法があれば教えて欲しい。

2017-04-02

Ruby の Monitor

Ruby

Ruby には Monitor というクラスがあるんだけど、よく見るわりに Mutex との違いをよくわかっていなかった。たまたま Java Concurrency in Practice を読んでいたら 2.3.2 Reentrancy で同じような概念の話が出てきて、少しわかった気がするのでそのメモ。

Java Concurrency in Practice

作者: Brian Goetz,Tim Peierls,Joshua Bloch,Joseph Bowbeer,David Holmes,Doug Lea
出版社/メーカー: Addison-Wesley Professional
発売日: 2006/05/09
メディア: ペーパーバック
購入: 7人クリック: 14回
この商品を含むブログ (22件) を見る

Monitor とは

Ruby の Monitor は何度も lock 出来る Mutex とドキュメントに書いてある。特になんの意味もない例だけど以下のようにロック中にさらにロックできる(もちろん同じスレッド内で)。もしこのコードを Mutex を使用して m = Mutex.new とした場合、2回めの m のロックする部分(m.synchronize)でデッドロックが発生するが Monitor を使用すると発生しない。

m = Monitor.new
m.synchronize do
  m.synchronize do
    # your code
  end
end

使い所

たぶん使い所は、すでにあるコードを組みわせてアトミックな処理をするところ。下のようなコードのような感じ。もともと Nanika クラスに sugoi というスレッドセーフなメソッドがあったとする。この時、メソッド内でアトミックに sugoi を2回呼び出す ultra_sugoi というメソッドを新たに追加しようとしたときに Monitor が使えそう。 Monitor ではなく Mutex を使用すると、ultra_sugoi 内でロックを取ってから sugoi のメッソド呼び出しが発生して、 sugoi 内でまたロックを取りに行きデッドロックが発生する。しかし、Montior を使用すると何度でもロックが成功するので、 sugoi をアトミックに2回呼び出せる。

class Nanika
  def initialize
    @monitor = Monitor.new
    @sugoi_value = 0
  end

  def sugoi
    @monitor.synchronize do
      @sugoi_value += 1
    end
  end

  def ultra_sugoi
    @monitor.synchronize do
      sugoi
      sugoi
    end
  end
end

nanika = Nanika.new

[*1..2].map {
  Thread.new do
    nanika.ultra_sugoi
  end
}.each(&:join)

その他

javaの本では reentrant という言葉で説明されていた。

reentrancy とは

Reentrancy means that locks are acquired on a per-thread rather than per-invocation basis.

リエントラント性とは、呼び出し単位ではなくスレッド単位でロックが取得される。

Lock with reentrant

同じスレッドであれば、何度でもロックを取得できるロックしたスレッドとそのスレッド内でのロック保持数を記録しておく。Ruby の Monitor。

Lock without reentrant

呼び出し(処理)単位でロックを取っているので、同じスレッドであっても再度ロックを取れない。単純にロックされているかどうかだけを見る。Ruby の Mutex。

RubyはGILが

そうね

2017-03-25

リーダ選出: ring アルゴリズム

Leader Election Distributed Systems Ruby

Raft Consensus Algorithm をみつけてリーダ選出とは、となったので調べてちょっと書いてみたメモ。なお、この記事では raft のことは書いてない。

リーダ選出とは

リーダ選出アルゴリズムとは、分散システム内で特別な役割を持ったノード(プロセス)を選出するためのアルゴリズムのこと。リーダを決め、中央集権的にシステムを動かすことで、権限が分散している場合にくらべシステム内の一貫性を容易に保てる¹。たとえば、分散メモリがあるとすると、あるプロセスが分散メモリに値を書き込む際には、そのプロセスはロックを取ってから書き込みをしないとレースコンディションが発生する可能性がある。この時、一つのプロセスをリーダにし、そのプロセスが他のプロセスにロックを提供し、書き/読み込みをしたいプロセスがロックを取ってクリティカルコンディションに入ることで安全に分散メモリを操作できる。

ring アルゴリズム

ring 型のネットワークを考える。 ring型ネットワークとは、それぞれのプロセスが自分以外の２つのプロセスと結びついてる様なネットワーク。要は以下の形をしたネットワーク。 f:id:ganmacs:20170325110434g:plain

CS 551: Synchronization, Token Ring Election Algorithm Exampleより

この記事での ring アルゴリズムは以下の話。wikipediaの分散システムのページを見てると、これは ring アルゴリズムの中でも Rings with unique IDs というやつっぽいのだけど、いまいち全体の世界観をつかめていないのでよくわかってない。

このアルゴリズムは election message を送るステップと coordinator message を送るステップの２つのステップに分かれる。まず、現在のリーダが何かしらの理由 (通信不能になったり、プロセスが死んだり) で fail したところからリーダ選出が始まる。リーダが fail したのを他のプロセスが検知して election message というメッセージを次のプロセスに送る。もし、次のプロセスが fail したリーダのプロセスだった場合はその次のプロセスに送る。 election message とは自分の id を追加した配列を含んでいるメッセージのこと。例えば、下の図の場合は P3 が自分の id である 3 というメッセージを、それを受け取った P5 は、受け取ったメッセージに自分の id である 5 を追加した 3,5 というメッセージを次のプロセス P0 に送る。この 3 であったり、3,5 であったりを election message といっている。そして、election message が ring を一周して元のプロセス(図ではP3)に戻ってきたところで election message を送るステップは終了する。

f:id:ganmacs:20170325111007g:plain

CS 551: Synchronization, Token Ring Election Algorithm Exampleより

ここからが、次の coordinator message を送るプロセスになる。 election message が ring を一周して、最初にリーダの fail を検知したプロセスに戻ってきたとき、election message の中身は ringに所属しているプロセスのidが全て含まれている。この id の中から一番大きな値を選びだし、その id が次のリーダだということを他のプロセスに周知するメッセージが coordinator message になる。coordinator message が ring を一周して元のプロセスに戻ってきたところで coordinator message を送るステップも終了しリーダが決定する。例えば下の図では、P3が最初にリーダの fail を検知したプロセスだとして、そこに返ってきた election message が 3,5,0,1,4 だとすると、この中から一番大きな数である 5 を次のリーダ(つまりプロセス P5 )とする。そこで P3 は「次のリーダは P5 だ」というメッセージまた他のプロセスに送信する。このメッセージを coordinator message という。他のプロセスも自分の次のプロセスに「次のリーダは P5 だ」というメッセージをおくる。そして、P3 に戻ってきたところリーダ選出を終えて P5 がこのシステムのリーダとなる。

f:id:ganmacs:20170325122210g:plain

CS 551: Synchronization, Token Ring Election Algorithm Exampleより

作った

ring アルゴリズムを実装してみた。

github.com

ring アルゴリズム自体の実装は https://github.com/ganmacs/eve/blob/master/lib/eve/agent/ring.rb この辺にある。仕様的なものを見つけることができなかったので、上の図を見て気持ちを感じて実装した。

EffatParvar, MohammadReza, et al. “Improved algorithms for leader election in distributed systems.” Computer engineering and technology (ICCET), 2010 2nd International Conference on. Vol. 2. IEEE, 2010.↩

2017-03-18

Linuxシステムプログラミング８章

zatsu Linux

Linux システムプログラミングの８章メモリ管理の雑なメモ。下に行くほど雑になってそう。この本。

Linuxシステムプログラミング

作者: Robert Love,ロバートラブ,千住治郎
出版社/メーカー: オライリージャパン
発売日: 2008/04/16
メディア: 大型本
購入: 5人クリック: 181回
この商品を含むブログ (31件) を見る

プロセスアドレス空間

物理メモリを仮想化しているため、プロセスは物理メモリを参照するのではない。
カーネルがプロセスそれぞれに仮想アドレス空間を与える
仮想アドレス空間は0から始まるリニアアドレス

ページとページイン/アウト

仮想アドレス空間はページで構成される
サイズはマシンによる 32だと4KB、64ビットマシンだと8KB
ページには有効と無効という概念がある
- 有効なページは実際に対応する物理メモリ、またはディスク上のファイルがが存在する
- 無向なページはアクセスするとセグフォになる
プログラムが物理メモリに存在せず二次記憶装置に存在するページにアクセスしようとすると、ページフォルトをMMUが発生させる
- カーネルがページフォルトに対応し、二次記憶装置から物理メモリにページインする
- 物理メモリ上にあって、直近で最もアクセスされていないデータはページアウトされる

ページ共有とcopy-on-write

(異なるプロセスの)異なる仮想アドレスから物理メモリ内のデータを共有できる
- 読み書き専用、読み取り専用どちらでも良い
書き込む処理は二種類ある
- 一つは単純に共有しているページにプロセスが書き込み変更された同じデータを参照
- もう一つはMMUが書き込みを検知し例外をなげる、カーネルがその例外を検知して透過的にそのうろセス専用のページを新たに作り、そこに書き込むようにする(Copy on write)

メモリ領域

カーネルはページを複数のブロックに分けアクセスパーミッションなどの属性を管理している
- このブロックをメモリ領域、セグメント、マッピングという
すべてのプロセスには決まったメモリ領域が存在する
- テキストセグメント - プロセスの実行コード、文字列、定数、その他専用のデータを格納。読み取り専用、オブジェクトファイルにマッピングされる
- スタック - 実行時に動的に拡張、縮小するデータ。ローカル変数や関数の戻り値などに使う
- データセグメント(ヒープ領域) - プロセスの動的メモリを格納する。書き込み可能(malloc)
- bss - 未初期化のグローバル変数を格納。

動的メモリ割り当て

動的メモリは、コンパイル時ではなく実行時に割り当てるもの
- 実行時になるまで、実際のサイズなどはわからない
cだとmalloc で動的メモリ割り当て出来る
- 成功すると、割り当てたメモリ領域の先頭アドレスを返す

配列割当

配列の割当にはcallocをつかう
- mallocと違って0で初期化する

メモリ領域のサイズ変更

realloc でメモリ領域のサイズを変更できる

動的メモリの解放

動的に割り当てたメモリは明示的に解放するまでプロセスアドレスの一部として存在し続ける
- free を使う
- 開放しないとメモリリークする
- 解放後のメモリにアクセスしてはいけない(ダングリングポインタ)

アラインメント

ハードウェアからみたメモリ領域とアドレスの関係
データサイズの定数倍のメモリアドレスへ配置された変数を自然なアライメントという
- 32ビットの変数がメモリ上で4の倍数のアドレスに配置されているとき

アラインメントされたメモリの割当

コンパイラとCライブラリがよしなに解決してくれる
32ビットシステムでは8バイト,64ビットだと16バイト境界にアライメントされる
posix_memalign を使用すると、任意の倍数でアライメントされたsizeバイトの動的メモリを割り当てられる

他のアライメント問題

非標準の型
- 構造体のアライメントはメンバの最大サイズに合わせる
  - 最大サイズを持つメンバが4バイト境界でアライメントされる32ビット整数なら、その構造体は4バイト以上のアライメント
- パディング(padding)が必要。
  - char(１バイト)のあとにintのメンバ(4バイトでアライメントされる)がある場合、charの後ろに３倍とのパディングが必要
- 共用体のアライメントはメンバの最大サイズに合わす
- 配列アラインメントは要素に合わせる
ポインタ
- 以下の例では、unsigned longは4 or 8バイト境界に割り当てられるのに、charはほぼ確実に1バイト
- そこで c をロードするとアラインメント違反
- 違反の結果はアーキテクチャ依存でクラッシュすることもある

char greeting[] = "Ahoy Matey";
char *c = greeting[1];
unsigned long badnews = *(unsigned long *) c;

データセグメントの管理(ヒープ領域)

でたーセグメントを直接操作する関数はあるが、malloc などが使いやすく機能も豊富であるためほぼ使われていない
brk はデータセグメントの末尾(break point)を渡された場所を変更する

無名メモリマッピング

典型的な malloc はデータセグメントを２の累乗のサイズの領域が並んだ状態に分割し，要求されたサイズに最も近い領域を貸す
- 直前の領域がフリーの場合はつなげて，一つの大きなフリー領域にする
- 戦闘だった場合は領域を縮めてカーネルに返す
- バディメモリ割り当てシステムという
内部フラグメンテーション - 要求されたメモリより大きなメモリ領域を返す問題
外部フラグメンテーション - サイズ分のメモリ領域があるにも関わらず，複数のメモリ領域に分断されている
領域Bと領域Aが隣接しており，領域Aがbreakpointに隣接している場合，Bを開放してもAが終わらない限り開放されない
巨大なメモリ割り当てをするとglibcはヒープを使用せす無名メモリマッピングをする
- ファイルを使わない
- 巨大で，０に初期化された領域を使用できる
- 本来のヒープの外にあるのでフラグメンテーションが発生しない
- メモリ領域はサイズ，アクセスパー密書の変更が可能
- 短所
  - メモリのサイズがページングサイズの整数倍になる，要求サイズがページサイズより小さいと無駄な領域が発生する
  - カーネルからのヒープ割当に比べてオーバヘッドが大きい

無名メモリマッピングの作成

munmapシステムコール(mmpa に MAP_ANONYMOUSを指定しても行ける)

/dev/zero のマッピング

/dev/zeroを使うことでunixでも無名メモリマッピングができる

高度なメモリ割り当て

mallopt を使用してカーネルパラメータを変更できる。

メモリ割り当てのデバッグ

環境変数MALLOC_CHECK_を設定すると、メモリサブシステムをデバック出来る
環境変数なので、アプリケーションをリコンパイルする必要がない

メモリ割り当て統計情報

mallinfo でメモリ割り当ての統計情報を得る

スタック上のメモリ割り当て

スタックはプログラムのオート変数(automatic variable)を格納する場所
allocaを使ってスタック上で動的にメモリ割り当てをする
- メモリ領域はスタック上に取られる
- つまり、alloca を実行した関数がリターンしたら解放/破棄される -> freeしなくていいのでコードが簡潔に
- alloca を関数コールのパラメータ内で使用すると、関数パラメータの用のスタック領域にメモリを割り当ててしまうため使用を避ける

スタック上へ文字列をコピー

文字列の一時的なコピー等に使える
- そのためのインターフェイスとして、 strdupa strndupaがある

メモリ割り当て方法の選択

malloc
- 単純だが割り当てられたメモリがゼロクリアされていない
calloc
- 配列の割当が容易でゼロクリアされてる、配列以外には使いづらい
realloc
- メモリサイズを変更できる、ソレ以外使えない
brk and sbrk
- ヒープを完全に制御できる、低位すぎるインターフェイス
無名メモリマッピング
- 共有可能、アクセスパーミッションもできる。サイズが大きいときにも使える。メモリが小さいと効率が落ちる
posix_memalign
- 任意サイズの境界に従うメモリを割り当てる。移植性に難がある
memalign and valloc
- unixシステムで使えるかも、posix標準ではない
alloca
- 高速なメモリ割り当て、解放不要、サイズの大きな割当には不向き。
可変サイズ配列
- allocaとほぼ同じ、スコープを抜けたときに解放される。配列に限り有効

メモリ操作

バイト設定

memset(void *s,int c,size_t n) sのメモリ領域へcをnバイト分設定

バイト比較

memcmp(s1,s2,n) s1の先頭からnバイトs2と比較
- 構造体は持つ内部にパディングを含むため正しく比較できない(パディングは不定値だから)

バイト移動

memmove(dst,src,n) srcの先頭nバイトをdstへこぴー
- メモリ領域が重なっていない場合も正しく動く
- もともと重ならないとわかっている場合にはmemcpyを使用する

バイト検索

memchrはメモリ領域内の指定されたバイトを検索する

メモリのロック

linuxのカーネルは不要なページはスワップアウトして、必要に応じてスワップインするデマンドページングを使用している
- この操作は透過的に行われるのでアプリケーションは気にしなくて良い
- しかし意識したい場合もある
  - 決定論
    - 時間的な制約を持つアプリケーションではページフォルトしてディスクIOが発生して時間的制約を超過してしまう
  - セキュリティ
    - 機密情報がページアウトされてしまうと、暗号化されずディスクへ保存されてしまう
- 当然全体のパフォーマンスが落ちる可能性があるので気をつける

アドレス空間の一部をロック

mlock(addr, len)でアドレスの範囲を指定して物理メモリ上にロックする

アドレス空間全体をロック

mlockallで(カレントプロセスの)メモリ全体を物理メモリ上にロックする

メモリのアンロック

munlock, munlockall

メモリの遅延割当

カーネルへメモリの追加を要求すると，カーネルは実際には物理メモリを割り当てずに成功を返す(commit)
書き込んだ時点で初めて割り当てる(CoW)
- 遅延できる
- 実際に使用する分（割当要求分ではない)のみ物理メモリを使用する(ページ単位にする)
- コミットしたメモリサイズをシステムの持っているメモリよりも大きくすることが出来る。(overcommit)

オーバコミットとOOM

2GBのファイルのCoWをマッピングするのは2GBのメモリが必要
- オーバコミットを使用すると、実際に書き込んだ部分だけで良い
実装メモリサイズおよび、スワップ領域より大きなメモリ領域を要求したとき
- カーネルは要求したしシステムコールに対して成功を返す
- コミットしてるからどこからからメモリを取ってこないといけない
- そこでkillするプロセスを見つけ出しOOM killerで殺す
OOM killer は sysctlパラメータの vm.overcommit_memoryに値を設定してOOMを逃れる
- 0がデフォルトで、ヒューリスティックオーバーコミットする
- 1はメモリを非常に多く使用するアプリだとこれがいいか
- 2はオーバコミットを禁止する。

2017-03-09

golang で Future を実現する

golang

ここで言う Future オブジェクトとは、clojure の Future を使用して作成できるオブジェクトのようなものことをいう(結果をキャッシュしてないとかはあるけど、その辺は割愛している)。つまり、何か処理を受け取りその処理を別 thread で実行するオブジェクトのことで、それを golang で作る。

シンプルな Future

とにかくブロックせずに、後から値を取り出せるようなオブジェクトを作成する場合は以下のようにする。ジェネリクスがないので int に対する Future を書いた。NewFuture の引数の f がブロックするような重い処理をする。クロージャ f の戻り値を future (chan int) にいれて、Get() を使ってあとからその値を取っている。

type Future chan int

func (f *Future) Get() int {
    return <-*f
}

func NewFuture(f func() int) *Future {
    c := make(Future)
    go func() {
        c <- f()
    }()
    return &c
}

使い方は以下のようになる。

f := NewFuture(func() int {
    // a time-consuming code
    return 10
})

f.Get() // 10

Get()のブロックを回避

上の実装だと、Get() したタイミングで NewFuture に渡した処理が終わっていなかった場合そこでブロックしてしまう。そこで、処理中 (pendding) か終了 (filfilled) かをブロックせずにわかるようなメソッドを持った Future オブジェクトは以下のようになる。

const (
    Pending   = iota
    Fulfilled = iota
)

type Future struct {
    State int
    ch    chan int
}

func (f *Future) Get() int {
    return <-f.ch
}

func NewFuture(fn func() int) *Future {
    f := Future{
        State: Pending,
        ch:    make(chan int),
    }

    go func() {
        ret := fn()
        f.State = Fulfilled
        f.ch <- ret
    }()

    return &f
}

State を使用すると渡され処理が完了しているかわかるので例えば、以下のように終了したか(fulfilled)かどうかによって処理を変えられる。

f := NewFuture(func() int {
    // a time-consuming code
    return 10
})

if f.State == Fulfilled {
    f.Get() // 10
} else {
    // something code

    f.Get() // 10
}

感想

以上のように golang を使うと Future はシンプルに書けるので、無理に Future ライブラリを使うのではなくてその都度かんたんなものを作れば良さそうな気がした。

2017-03-01

Go版retriable作った

golang

Rubyの retirable の Go版を書いた。

github.com

使い方

一番シンプルな使い方。引数として渡されたクロージャが成功するまでリトライし続ける。リトライ回数のデフォルトは3で、リトライ間隔は randomized exponential backoff アルゴリズムを使っている。簡単に言うと、CSMA/CD みたいにコリジョン(失敗)すると次に実行するまでの時間が徐々に長くなっていくアルゴリズム(をちょっと変形させたやつで、元ネタはここらしい google-http-java-client )。

retriable.Retry(func() error {
    // your code
    return nil
})

リトライ回数を変更したい場合は Options を使う。リトライ回数を5、最初のリトライ間隔を1秒に設定した例。

opt := retriable.Options{
  retries:  5,
  interval: 1 * time.Second,
}

retriable.RetryWithOptions(func() error {
  // your code
  return nil
}, opt)

処理全体にタイムアウトを設定することも出来る。 RetryWithOptionsに渡されたクロージャが5秒以上かかった場合にリトライするのをやめて、処理を返えす。

opt := retriable.Options{
    timeout: 5 * time.Second,
}

retriable.RetryWithOptions(func() error {
    // your code
    return nil
}, opt)

リトライ間隔がexponentialに増加するのではなく、一定にしたい場合はbackoffをConstantBackoffに変更する。

opt := retriable.Options{
    backoff: backoff.NewConstantBackOff(1 * time.Second),
}

retriable.RetryWithOptions(func() error {
    // your code
    return nil
}, opt)

まとめ

ご意見があればぜひ

2017-02-23

Rust で LLVM やってみる

Rust LLVM

Rust と LLVM やってみたくなってやってる． llvm-sys という LLVM の Rust バインディングのライブラリを使って LLVM 動かしてみた話と自分用メモ．

きつねさんでもわかるLLVMを読んでからやるかと思ったが，5章以降はちょっと自分には合わなかったのでブログ探して、それをやりながら参照程度に狐さんを見るという作戦でいった．

環境設定

何とかして Rust を入れる．これを真似すればだいたい行ける．

気付いたらRustの環境構築がかなり楽になってた | κeenのHappy Hacκing Blog

後は LLVM を入れてpathを通す．

brew install llvm
export PATH="`brew --prefix llvm`/bin:$PATH"

やったこと

LLVM IR の雰囲気を知りたかったので幾つかサンプル書いてみた．

playground/rust/llvm-example at master · ganmacs/playground · GitHub

llvm*.rsは上の方に動かしたい擬似コードを書いてある． codegen*.rs は AST ができてる体でそれを LLVM IR に変換するコードをかいた．

Rust で作った言語(中途半端なlisp) のバックエンドを LLVMにしてみた．

ほとんど Rust かいた経験がないため，色々おかしいところがありそう．マクロかけるようにするかってところで気持ちが終わり，LLVMバックエンドにリプレイスとかやってる．

GitHub - ganmacs/rlisp

参考になったブログとコード

LLVM: LLVM

llvm の公式のサイト．実際 LLVM IR 書いてる(実際に書いてるのはRustのラッパーだけど)と使い方がわからず，ググると大抵これしかヒットしないので一生懸命これを読む．

A Toy Front-End for LLVM, written in Rust: Getting started | Ulysse's Blog

Rust で llvm-sys.rs を使って数字を出すところから phi 関数(というのがある) を使って if 式を作ることまでやってる．

Go言語で利用するLLVM入門 | プログラミング | POSTD

Go 言語用のバインディングもあるようでそれを使って，加算するところまでやってる．序盤の説明が分かりやすかった．

大学院生のためのLLVM | インフラ・ミドルウェア | POSTD

LLVM の外観をつかむのには良かった．ただ，読み進めてるといきなり Pass の話をしだすので，LLVM IR について知りたい場合は序盤だけ読んで，後半は後で読むと良さそう．

GitHub - jauhien/iron-kaleidoscope: LLVM tutorial in Rust language

LLVM のチュートリアルを Rust でやってる．この作者が作った iron-llvm という llvm-sys.rs をラップしたライブラリを使って LLVM を触っているのでいきなりこれを見ること混乱するかもしれない．最初はむしろ iron-llvm のコードを読んで llvm-sys.rs の使い方の雰囲気をつかむのが良い．

GitHub - Kmotiko/DummyCCompiler

きつねさんでもわかる LLVM のサンプルコードのリポジトリ．割りと大きめのコードなので実際に真似しやすい．構文の定義( https://github.com/Kmotiko/DummyCCompiler/blob/master/dummyC_ebnf.txt )を読めばどんな言語かわかるので本の方は読まなくてもだいたい分かると思う．