トップ «前の日記(2016-01-20) 最新 次の日記(2016-01-23)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2016-01-21

_ ラクに速くしたい

アンドロ、完全にビルドするもの無い時に make て叩くとむっちゃ速い時で 6 秒くらいかかる。普通は 8 秒とかそのくらい。 kati 以前は 2 分だったので、まあいいちゃいいんだけど、やっぱり 8 秒はちょっとイラっとくる…気がする。

2分から10秒にするならすごく頑張る価値があるけど、 8 秒のものを速くするならちょっとした努力ですむと嬉しい。

むっちゃ速い時の 6 秒、内訳を見ると大雑把に言って、 4.5 秒が ninja で 1.5 秒が kati の責任。

ということでとりあえず ninja でしょ、ということで書いた ninja のパース結果をバイナリとして保存するパッチ。入ってくれると 3.5 秒かかっているパース部分 1 秒になるので、合計で 4.5 秒だったのが 2 秒くらいになる。もうちょっと速くすることもできる(が相対的な嬉しさはたいして無い)。

https://github.com/shinh/ninja/commit/1ac857f8ca7ce5dcc8999b9b6d270bbae6074af4

これを入れてもらえると ninja 2秒 kati 1.5 秒となって、 kati 側の方が気になる。こっちは thread で並列で処理すると速くなるに決まってる処理なので、やってみたら 0.4 秒ほどになった。

https://github.com/google/kati/commit/6bbf9e29fcb069871a9153e845242ed6fe0e1b94

2つひっくるめると 6 秒が 2.5 秒ほど、まあそりゃ、もちょっと速い方がいいけど、費用対効果としてはこんなもんかなって感じ。

C++11 の lambda+thread で thread pool 書いてみたりした。書きやすい感ある…がまあ pthread は基本的な API はだいたい使い方覚えてるので、ぶっちゃけこっち書く方が時間かかるというのはある

https://github.com/google/kati/blob/6bbf9e29fcb069871a9153e845242ed6fe0e1b94/thread.cc

thread_local キーワードて Mac だとサポートされてないのかー、と今気付いた。修正しないとか。まあだいぶ前に書いたこれ使えばすぐできるだろ

https://chromium.googlesource.com/arc/arc/+/master/src/common/thread_local.h

さて

Makefile が書き変わったりして kati がこれは処理しなおさなあかんなーと気付いた場合、 Makefile をパースして評価しなおすんだけど、こっちはもっと時間がかかる。大雑把に言って

  • パースと評価: 23 秒
  • 依存グラフを作る: 8 秒
  • ninja を出力する: 13 秒

てとこ。最初の部分、これは一番気合が入ってる場所なので、まあそれなりに速いと思う。 GNU make が2分かけてる部分だし。

残りは割と適当なんだよな。こっちはまあ、 23 秒の部分は速くするの難しいと思ってて、残りの 21 秒頑張ってもたいした効果ではないので、ラクに速くできる部分があればやる…くらいかなと思う。

まあ普通に考えてスレッドで散らせ、ってことになると思う…がまあ、これはめんどくさい部分も多い。コードが汚なすぎるんだよな。あと順番が重要な処理もある。

グラフ構造みたいなのをトラバースするのを並列にやる必要がある。一つ一つのノードを処理するのはすごく速いけどノード数が多いので、新しいノードを見つけるたびにタスクキューに入れる、みたいなことすると待ち合わせの時間ばかりかかることになると思う。

たぶん分岐があったら、一定の確率で分岐先をタスクとして実行させる、とかでいいんだと思う。って parallel GC てそんな感じなんだっけ?

(20:28)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2016年
1月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h