コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方
01 の nand gate のところをやってます。 ベン図とかド・モルガンの法則とかの懐かしワードをどうにか思い出して解いてます。
なんか基礎をのばしてーなーと思って会社の制度を利用して今手元にあります。ありがたい。
書籍の公式サイトがあって、↑にシミュレータのプログラムもあります。
テストスクリプトもついてるので、サクサクと試行錯誤できてよい感じ。こーいうのやってると大学時代思い出しますねー
これは Rustその2 Advent Calendar 2018 の 2 日目の記事ということにしました。
ありがたい PR のおかげで更新できました！ tatsuya6502 さんありがとうございます！
246k record を 57.6 秒で処理したので、4,270 record/sec でなんと 4,000 の大台突破です。
修正内容は僕がサボったところを指摘いただいた感じでした。むしろすみません。
| Runtime | record/s |
|---|---|
| Python | 142.8 |
| Rust(on Python 2.7) | 2348.6 |
| Golang | 3910.0 |
| Rust(on Custom Runtime) v1 | 3967.2 |
| Rust(on Custom Runtime) v2 | 4270.0 |
ということで、4,000 を越えました！すごい！！
rohki.hatenablog.com rohki.hatenablog.com
初めて Kinesis Firehose で計測してから 1 年弱、 Golang で計測してから 10 ヶ月弱…
ついに正式対応ですよ！ なんかもっとすごかったけど！！ ということで、ここまできたら計測せねばということでやりました。
去年に作ったやつを適当にちょちょっと書き換えたら動きました。時間は 2 時間ぐらい?
この辺は数をこなしたおかげかと思っとります。
ほぼ一緒とも言う
— rohki (@r_ohki) 2018年12月2日
せっかく linux 環境作ったし、そのまま build したやつ動くかなーとやってみた結果、llibc のバージョンで怒られました…。
そして glibc すか…
— rohki (@r_ohki) 2018年12月2日
静的リンクすればいいんんだろう、ということで musl 版を以下を使って作りました。 rohki.hatenablog.com
コマンドは以下です。
cross build --target x86_64-unknown-linux-musl --release
いつも通りの下限性能です。
これまでと同じどおり、Kinesis Data Generator で Apache Log っぽいものを投入して、時間あたりでどれだけ処理できるかをみます。
246k record を 57.6 秒で処理しました。
| Runtime | record/s |
|---|---|
| Python | 142.8 |
| Rust(on Python 2.7) | 2348.6 |
| Golang | 3910.0 |
| Rust(on Custom Runtime) v1 | 3967.2 |
| Rust(on Custom Runtime) v2 | 4270.0 |
と、いっても最大風速の性能がならんだ、というところです。
感覚的には 3800 から 3700 が平均性能といったところでしょうか。それでも十分速いです。
今回は速度も安定してました。毎回 4,200 record/s を安定して出していたので、予測しやすくなってます。
熱意と覚悟、Lambda のコスト削減に並々ならぬ事情があれば。
Lambda の仕様を考慮した build まわりのややこしさがどうしたって足を引っ張ります。
OpenSSL の反省を踏まえて今回の GLIBC はさくっと対応できましたが、Lambda の仕様と対応策の検討が追いつかないとひたすらハマる落とし穴でした。
動いてますがなんか見落としがありそう…やるのであれば場所を選んで少しずつって所かと思います。
ついに正式対応。感慨深い…
書いてさらしたら PR もらえた。ありがたい…
ひさしぶりの Linux 環境である。
Wi-Fi につまったり、日本語入力の設定につまったりしたけども、まぁ動きました。この記事も新しい端末から書いてます。
DuckDuckGo で Wi-Fi について調べたら、右側に手順が出ましたよ!
内容はフォーラムから引っ張ってきている模様。
TouchPad が大きいせいで、カーソルがとんじゃいます。変なところに文字入力してて辛い。
キーボードは固めかなー。そのうちなれるでしょう。
パスワードマネージャと zshrc があればセットアップはわりと楽なもんですね。
次は開発環境構築。
新しい話をきいたり、初めて会う方とはなしたり、コントリビュートできたり、なじみの人に会えたり、同じ志向の人に会えたりしました。
まずスタッフの方と発表いただいた方、参加者のみなさん本当にありがとうございました。
同志よ！(一方的)
こんな調べものをしていたのでちょーワクワクしながら待ってました。
で、聞いてる間もひたすら頷いてそだよなーという感じ。
発表の後で話した時に
とか
とか。
分散トレーシングで詰まっていたところが解決したり、想定していた懸念点がその通りだったりととてもありがたかったです。
「ブログみました」もうれしかったです！書いてよかった…
2 日目のアンカンファレンスにて id:takezoe さんとお話しながら、サクッと GitBucket へコントリビュートできました！
本当に貴重な機会でした。
https://t.co/KkfSpgWoTP
— rohki (@r_ohki) 2018年11月11日
おー、@takezoen さんとお話しながらでスッといれていただきました! #scala_ks
いいおっさんなのでビビらずやれって話なんですが、いかんせんビビりなもので。
コントリビュートできたこともそうですし、Java や Scala の OSS 事情的なお話も興味深かったです。
経験できたってことが何より大事かなーとおもっていて、これで一つハードルを越えられた気がします。がんばってこう。
アンカンファレンスにて他の方が挙げたところに便乗して質問しました。
というのも、以前 Envoy の話を聞きました。
この時に聞いたコンセプト「アプリケーション開発者がドメインに集中できるようにする」と Akka がどこか同じような感じだなーとぼんやり思っての参加でした。
解決をどうすればよいのか、までは至れてません。そのあたりは各々の製品特性によるでしょうし。
それでも意見を上げて、反応をもらえるってのは貴重な機会でした。
お久しぶりですといったり、スタッフをされてた学生の方と盛り上がったり、同じことを調べてる方と情報交換したり、新しいことに挑戦できたり、2日間でいろいろなことができました。
パワーワードが生まれるところにも立ち会えましたし。
来年も参加しよう
でけたー。面白い。
クラウドベンダーの模様。
CDN やら DNS やらがある。
今回はインスタンスを作るタイプ。
Docker image でデプロイできるすごいやつです。
僕にとっては、デプロイ先のサーバーがない状態になります。
CLI 上で操作ができるよう、バイナリも用意されています。
が、今回は Github との統合を行いました。
Pull Request を送ると、すぐにデプロイが始まる感じです。
こんな感じ。
Docker image の上限が 100 MB まででした。
適当に書いた Dockerfile ではあったものの、400 MB…
ちょっと根本的に考えを変えないといけない感じです。
FROM ekidd/rust-musl-builder:stable AS rust-builder ADD . . RUN cargo build --release --target x86_64-unknown-linux-musl FROM alpine:3.8 COPY --from=rust-builder /home/rust/src/target/x86_64-unknown-linux-musl/release/zeit-sample /usr/local/bin RUN apk add --no-cache ca-certificates && update-ca-certificates ENV SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt ENV SSL_CERT_DIR=/etc/ssl/certs CMD ["zeit-sample"]
以下 2 つを参考にしました。
こんなことできたんすねー。知らなかった…
Multi Stage Build という手法で、ドキュメント もあります。
ビルド環境と実行環境を明確に分けることで、デプロイに使用する Docker image の内容物を最小限にできます。
上記で最終的には、6.6 MB になりました。
最初 EXPOSE 書いてたんですが、自動で見つけてくれるらしくいらなかったです。
5 分(だったかな?) で環境が Cold 状態に移行するのですが、そこからの起動が早いです。
Cold 状態からの起動だった場合は、上記したポートの自動検索の結果がログにでます。
でも、その差がわかりづらいです。
自動でやってくれるのはよいですねー。
Dockerfile 書いて now.json 書いたらデプロイまでやってくれるってのはありがたい。
環境や言語によっては、100 MB の制限は厳しい、のでしょうか?
Runtime やバイナリの大きさ次第では、この制限を通過するために、あれこれと努力する必要が出てくるかも。
Golang の 1 バイナリで済むというデプロイしそうがここでも聞いてくるのかなーとか思いました。
先ほどのビルド環境と実行環境を分けることで、純粋な Linux 環境にバイナリをコピーすればおしまい的な。
で、この文章を書いてるときに関連文書を見直してるとサンプルを見つけて、かつ Rust もあるという…
now-examples/rust-rocket at master · zeit/now-examples · GitHub
おんなじじゃん！！！
ちゃんとドキュメントというかリリースノートというか、そのあたりは読みましょう…
それはさておき、デプロイの方法とか環境情報の持たせ方とか、パフォーマンスの考え方、そして実装方法。
特に初期起動コストを支払う回数が増えるってのが違うかも。
いやー、最高でした！
2016年からなんだかんだ 3 年連続参加してました。
以下で特に気になったところの書きます。
やばいしか言えないくらいやばい #builderscon
— rohki (@r_ohki) 2018年9月6日
SNS 禁止なのであまりかけず上記が全てではあるのですが、ひたすら頷いたり質問したりしました。
昨年に続き、こういう話が聞けるのもいいですよねー。
しかし書きたい。共感したことをひたすら書きたい。
Envoy の名前は聞いていて、役割も知っていた つもり でしたが、もっと凄まじいものでした。
ネットワークについてのありとあらゆることをやり、アプリケーションエンジニアを業務ロジックに集中できるようにする、という強い意志を感じました。
一方で、当然ながら Envoy がそのあたりのつらさを一手に引き受けることになります。
(こーれめっちゃ複雑じゃん)という感想を発表中に持っていたら、「(Envoy は)複雑なプロセスである」「利用する時はネットワークを知った上で」という発表があり、やっぱりそうだよねーと安心しました。
ネットワーク詳しくならなければ。
過去にこんな調べ物をしていたりしてたので、こちらに。*1
アプリケーションを開発する方が追跡性の注入を意識しなくていいようにする、を徹底されててすごいなって感じでした。
Envoy の話を先に聞けていたが故に、内容がするっと入ってきました。良い構成したよ！
こちらでは質問しました。内容は「分散トレーシングで DB アクセスをつなげて出すためには、Envoy 経由になる? それとも DB の手前に簡易サーバーをおく?」 でした。
答えは Envoy 経由！まじか。
そしてそのあとの懇親会で、「でもコードを書き変えないで追跡の親子関係の伝播どうやるんだろう」で盛り上がりました。
で調べてみると、Trace context propagation に行き当たり、「入力コンテキストから取り出して、出力に注入する」とか書いてありそう。
まじか…まじなのか。いったいどうやってるんだろう
内容の多くは PodCast でお聞きしていたのですが、知らなかったところへ質問した結果、自分の考え方との差分に気がついた、というところでした。
質問は、「既存ツールとのバイナリ差分をなくすことを第一のゴールとしなかったのは、増分開発する方がよかったからですか?」でした。
それに対する回答は以下 3 つです。
特に最後にハッとさせられました。
確かに「調査する時間がないから詳細はわからないけどおまじないとして入れる」とかやっちゃってるんですよね。
でもそれってもしかしたら無駄なものかもしれないのに、全然改善できずそのまま次の人に渡すことになるわけで。
調べ切れる時間を作る、腕を持たねば。
振り返ると、もうちょい聞きに行くものの幅を増やした方が良さそうだなーと感じました。
k8s とか microservice あたりに心惹かれたものの、いやそれ聞くなら別の機会があってその時にしよ、と意図的に避けたりしました。が、それでもちょっと実利に寄りすぎな感じでした。
もしくは自分で発表するかか！何をだろ。
Rust と WebAssembly のやつは久しぶりに遊び要素が多めなのであの発展ですかねー
本当にすごいエネルギーであの場を作っていただいていて、感謝しかない感じです。
ありがとう！ builderscon!!
頑張ったけど無理でした。
やりたかったことは WebAssembly を使った音声操作です。
Rust 実装の音声ライブラリについて調べてたところ、cpal に行き当たりました。
んで、何とそこには Emscripten という文字が。
お? ブラウザでも動くの?? となぜか WebAssembly で書いてみようと思ったのです。
制限時間は1日。
それはそうなのですが、WebAssembly で動くと
こう書くと、風が吹けば桶屋が儲かる感がすさまじい。おかしいな、こんなはずでは…
それはともかく、速度を優先されてかつ私がすぐ試せるものとなると、大学時代にかじった音声処理でした。
ので、それでお試し。
#[no_mangle] pub extern "C" fn hoge() -> f64{ let device = rodio::default_output_device().unwrap(); let sink = Sink::new(&device); // Add a dummy source of the sake of the example. let source = rodio::source::SineWave::new(440).take_duration(Duration::from_secs(3)); sink.append(source); sink.sleep_until_end(); 1.0 }
サイン波を3秒再生する実装です。
使用したライブラリは rodio で、ドキュメントとかを見ながら実装しました。
上記ページを参考させてもらいました。
<!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <script> fetch('../target/wasm32-unknown-unknown/debug/wasm_sample.wasm') .then(response => response.arrayBuffer()) .then(function(bytes) { return WebAssembly.instantiate(bytes, {}); }) .then(results => { console.log(results.instance.exports.fuga(2)); }); </script> </head> <body> </body> </html>
IntelliJ で HTML を書いて右上にマウスカーソルを動かすと、HTTP サーバーとして動いてくれます。
ので、今回はそれを使いました。お試しなので許して。
WebAssembly 呼び出せてるよなー、の確認で加算関数を作って呼び出し。
無事呼び出せたので次。
いよいよ音声再生だーと呼び出してみたところ、即失敗。
WebAssembly.instantiate にてエラーが発生していて、エラーメッセージは以下でした。
TypeError: import object field 'env' is not an Object
env とは???
で、エラーメッセージで調べてみると、以下を見つけました。
Rocket - A Rust game running on WASM
なるほどなー、足りない関数の対応表を渡してやる必要があるわけですな。
ということで、そのままパクる。
関数の呼び出しに成功しました。んが！
動きませんでした。 そらそうだよね！
print デバッグをやって確認したところ、1行目でこけてる模様。
rodio と cpal をローカルにクローンして、書き換えながら確認しました。
#[cfg(not(any(windows, target_os = "linux", target_os = "freebsd", target_os = "macos", target_os = "ios", target_os = "emscripten")))] use null as cpal_impl; use std::error::Error; use std::fmt; use std::iter; use std::ops::{Deref, DerefMut}; mod null; mod samples_formats; #[cfg(any(target_os = "linux", target_os = "freebsd"))] #[path = "alsa/mod.rs"] mod cpal_impl; #[cfg(windows)] #[path = "wasapi/mod.rs"] mod cpal_impl; #[cfg(any(target_os = "macos", target_os = "ios"))] #[path = "coreaudio/mod.rs"] mod cpal_impl; #[cfg(target_os = "emscripten")] #[path = "emscripten/mod.rs"] mod cpal_impl;
引用元 cpal/lib.rs at 77ce5eba06447275ce6a094ac053e6775272ad8c · tomaka/cpal · GitHub
当たり前なのですが WASM の文字がなく、結果として未対応環境の null に行きついてエラーになってました。そらそうだ。
同じブラウザで動かすし、内部で使われてる stdweb は WebAssembly 対応してるぽいから、emscripten の記載部分に wasm 追加すればいいかなー、と安直に考えて追加しました。
中を見たところ WebAudio に対応してるかを判定してたので、WebAssembly から API 呼び出しできればいけるかなーってところでした。
追加方法の参考リンクは以下です。
https://stackoverflow.com/questions/48350087/how-do-i-conditionally-compile-for-webassembly-in-rust
https://github.com/koute/stdweb/blob/master/src/webcore/ffi/mod.rs
記載方法はこんな感じ。
#[cfg(any(target_os = "emscripten", all(target_arch = "wasm32", target_os = "unknown")))] #[path = "emscripten/mod.rs"] mod cpal_impl;
Cargo.toml も併せて修正。
[target.'cfg(any(target_os = "emscripten",all(target_arch = "wasm32", target_os = "unknown")))'.dependencies]
stdweb = { version = "0.1.3", default-features = false }
んでなんと通ってしまった！
そして次のエラー。
突破だーと思ったところ、またもやエラーでした。
LinkError: import object field 'sinf' is not a Function
なるほどな? 関数が見つからん、といってるので、先ほどの関数の対応表に sinf と cosf を追加して、突破です。
で、次のエラー。
軽く調べて C の header ファイルに行きついた瞬間に、これはちょっとこれまでのやつと違う気がする、となってきました。
C から Javascript の関数を呼び出すための関数、らしいのですが、今そういったことをやってないんですよね。
関数の役割的に sinf のように補填すればよい、ということでもなさそうです。
んで、stdweb の実装に確かに記載をみつけ、mod.rs での切り替えや macro.rs での呼び出しも見つけましたが、よくわからんぞーとなってきて心折れてきたところで夜でした。
そんな簡単にいくわけがない、とわかっていたものの、中途半端になってしまいました。
いつかリベンジ。いつか…