ToDo:
http://wasabiz.hatenablog.com/entry/2013/10/03/124200
何が起きるかはわかるんだけど、なぜそれが欲しいのか、ってのがよくわからなくて。
たしかだいぶ前に聞いた時は、
みたいな話だったような気がする。前者はまあそいうもんだろうという気がするけど、後者はそうかいなという感
意味論て公理的表示的操作的とあって公理数学表示コンパイラ操作インタプリタ、R5RSが表示R6RSが操作、とメモ
(02:39)
スタック使う実装だと大雑把に言ってこの順で良いという理解
使わない実装だとどうなんの。
スタックフレームがヒープにあるようなやつだと、 GC のマークだけする感じだろうから全部似たようなもんかな
(11:42)
http://kusano-k.hatenablog.com/entry/2016/02/20/223229
の話。これ最初話聞いた時、「さすがPHPさんはPHPさんやなあ」とか思ったけど、まあ考えるととりあえずのリバート自体は適切な気がする。 kusano_k さんも書いておられる通り。
とはいえこれどっかで入れたいだろうから、
http://news.php.net/php.internals/91335
で言われてるようにどっかのリリースで入れるのがいい気がするよね。
てか乱数性だか周期性だか、これぱっと見損われるような気がするんだけど、
http://news.php.net/php.internals/91336
によると性能には問題がないとのこと。まあもしそれが本当なら mt_rand は MT rand じゃないです、ってドキュメントすれば十分という主張は全くナシではない…
にしてもこのバグ、テスト書けよって話だよなあ。真に問題なのはエンバグした「最適化」パッチをテスト無しで入れちゃってる文化な気がする
(12:15)
該当コード見ると性能差無いってのはちょっと信じにくいんだけど、乱数性に問題無いて根拠はこれらしい。
まあそっちはともかく、周期性はどうなん？ていう疑問はこっちで言われてる
http://news.php.net/php.internals/91337
なにかこの人の発言バランス取れてる感があって良いな
(18:14)
決定が出たけど予想通り苦情が出てるな
https://bugs.ruby-lang.org/issues/12004
https://github.com/ruby/www.ruby-lang.org/issues/1297
実効性のある CoC て基本的には良いことな気がする。自主的に立法するって発想は好きだし。
じゃあなんでこのスレの SJW が気に喰わないかっていうと、押し着せだからだろうな。全然自主的じゃねーぞっていう。先生に決められた生徒会規則かっていう
我々は文明的な装置を発見したこれはいいものだ、お前も使うべきーての、どういうレベルなら僕的に許容範囲なんだろう。宗教とか民族の自決とかからむケースでは、多少発展が遅れるとか死亡率高くなるくらいならやるべきじゃないと思うけど、虐殺とか極端な人権侵害とか起きてると、さすがにちょっとな。
Ruby CoC のケースはまあ CRuby 民族に自決させてやってくれって感しかない。てか「うーん、この CoC だとイマイチだと思うから残念だけど、無いよりはいいね。議論に時間使ってくれてありがとう。もし将来問題あったら遠慮なくコンタクトしてね！」とかいうノリだったら、「いいやつらだったな。。」的で良いと思うんだけど
はてなんでこんなに高圧的なんだ。まあなんか CRuby 民族の数人も高圧的感ある気がしてるんだけど
(13:18)
以前から glibc qsort て std::sort より速いこと多い気がするなーとか思ってたんだけど、まあ今回もそれで、ただ Mac だと std::sort の方が速いぽい (Apple qsort が遅いのか libc++ std::sort が速いのかどちらかは謎) し、うーんとか思ってて。
まあそもそも文字列は汎用ソートにかけるべきじゃないだろーということで、色々調べてて、なんかなるほどこういうのがあるのかーとか思ってたりしたんだけど、その全てがこのリポジトリに入っていた
https://github.com/bingmann/parallel-string-sorting
感動的すぎるね。。秋葉さん作のソートも入ってる
(01:35)
立って仕事してたら腰痛くないなーと思ってたけど、先週末からひどく痛い。マッサージの人が立ってても腰痛くなるのはスタンディングデスクあるあるですよー気をつけてね、て言ってた翌日くらいから痛くなったので、なんかの呪いをかけられたのだろうか。
今の状態だと立っても痛くて、座るともっとひどくて、寝ると大丈夫ではあるので最悪という感じではないが、まあつらい。筋弛緩剤飲むと結構効いてるぽいのでまあそれでほっときゃマシになるかな
(19:34)
あっ終わってしまいそうだ。なんかあのスレ流し見するのが日課になってた。
こいうのでいうと、在特会 vs しばき隊とかも似た構図かなあと思っていて、被害を被るのは、「うーん、どっちも、えー…」と思ってる人達ってのが。そいう人ってどっちかよりの意見を持ってたりもすることもあるのに、先鋭化した人達は俺より敵側にいるやつは全部敵、てなっちゃうんだよなあ
ちょっとずれて、なんとなく手塚治虫のマンガとかに出てきた、百姓が「おさむらいさんがいつも戦争してるけど損するのは百姓ばっかだべ……」とかぼやいてるシーンを思い出すのだけど、大きな違いは百姓がバカじゃないってことがあると思う。がまあ見るからに matz 以上に喋った人は被害は被ってるんだよなー
(22:42)
今日もらったバグレポをエアデバッグしてて、あーこういうことだなってアタリがついた事例
(gdb) p main
$1 = {int ()} 0x400596 <main>
つまりシンボルのある綺麗なバイナリです
(gdb) r Starting program: /ssd/test/a.out Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) bt No stack.
abort してるのに "The program no longer exists." ヘンすぎるやろ。というわけで以下のコードがこういう挙動を起こすことに気付いた。なるほどねー
$ cat vfork_fail.c
#include <stdlib.h>
#include <unistd.h>
int main() {
if (vfork())
sleep(1);
else
abort();
}
(20:33)
なんじゃこれ
https://bugs.ruby-lang.org/issues/12004
全体的に良い自転車小屋だなーと思いながら流し読みしてたら、極右によるなりすましまで現われてすごい
(06:42)
で、その極右は実は当初のやつを採用させたい派による、なりすましのなりすましであり、ほら code of conduct committee 必要でしょー、と実演してるという陰謀論
(06:46)
アンドロ、完全にビルドするもの無い時に 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 をパースして評価しなおすんだけど、こっちはもっと時間がかかる。大雑把に言って
てとこ。最初の部分、これは一番気合が入ってる場所なので、まあそれなりに速いと思う。 GNU make が2分かけてる部分だし。
残りは割と適当なんだよな。こっちはまあ、 23 秒の部分は速くするの難しいと思ってて、残りの 21 秒頑張ってもたいした効果ではないので、ラクに速くできる部分があればやる…くらいかなと思う。
まあ普通に考えてスレッドで散らせ、ってことになると思う…がまあ、これはめんどくさい部分も多い。コードが汚なすぎるんだよな。あと順番が重要な処理もある。
グラフ構造みたいなのをトラバースするのを並列にやる必要がある。一つ一つのノードを処理するのはすごく速いけどノード数が多いので、新しいノードを見つけるたびにタスクキューに入れる、みたいなことすると待ち合わせの時間ばかりかかることになると思う。
たぶん分岐があったら、一定の確率で分岐先をタスクとして実行させる、とかでいいんだと思う。って parallel GC てそんな感じなんだっけ?
(20:28)
| 前 | 2025年 7月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ ujihisa [Vimscript]
_ shinh [何が間違ってるんだろうと思ったら、間に空白が必要なんですね。 BrainFuck とかとともに四天王二軍として活躍し..]
_ shiro [スタック領域を可変(stack topだけでなくstack bottomもポインタを持っておく)にしておいて、継続が..]
_ shinh [あーなるほど。なにやらおしゃれな感じですね。]