Name Last modified Size Description Parent Directory 16-Apr-1994 19:46 - ai 12-Jul-1993 12:35 5k akina 12-Jul-1993 12:35 5k crazy 12-Jul-1993 12:35 6k curry 12-Jul-1993 12:35 4k curry.c 12-Jul-1993 12:35 1k genkoku 12-Jul-1993 12:35 5k high 12-Jul-1993 12:35 5k inchiki 12-Jul-1993 12:35 5k kankoku 12-Jul-1993 12:35 5k kyoto 12-Jul-1993 12:35 5k mac 12-Jul-1993 12:35 6k macdonald 12-Jul
あんまし日本語のドキュメントがみつからなかったので試行錯誤のあとを書いてみます。まぁ,Support for test suites - automake に書いてあるんですが。 Makefile.am に TESTS という変数を定義しておくと,make check したときに実行して結果を教えてくれます(make とかと同じく 0 なら成功,です)。 たとえばシェルスクリプトでテストコードを書いているのであれば, # Makefile.am TESTS = tests.sh #TESTS = test1.sh test2.sh test3.sh のように書いて,スクリプトを実行可能にしておけば OK です。 Perl でテストコードを書いた場合とかは TESTS_ENVIRONMENT という変数も定義して,どのように実行するのかを指定できます(@INC を指定したり,とかね)。今回は
思ったことをつらつらと支離滅裂な個人的メモ。 1.シンプルマルチスレッドGC このあいだからいじってるやつだが、とりあえず世代別GCがあるのとないので3倍も違うというのはおかしいのでまだどこかバグっているんじゃないかと思う。効率面での話なのでヒープスロットの取得・解放戦略のへんが怪しい。 単純な再帰型マーク関数を2つのスレッドで同時に動かすというのは、まあそれなりに短時間で終わるのだろうが、それはあくまでも遊んでるCPUがあるという前提であって、システム全体のスループットとしてはたぶんあまり嬉しい話ではないだろう。作るのは楽だが無駄が多い。 このシンプルな手法が通用するのは関数を再帰呼び出しするというマシンスタックを使った探索の場合のみであり、たとえばmrubyやrubyのようにリストを繋いだりたどったりする方法ではリストのアクセスに排他制御が必要になって思ったような性能は出ないと思われる
動きのおかしいコードをそのままにしておくのも気持ち悪いのできちんと動くように修正してみた。64指定のao-render.rbが34秒で動くようになったので相当おかしいことになっていたのだと思う。githubにあげたコードはあれこれいじっているが、バグっていた箇所はsweepの中で、コードの削り方を失敗していた。あとは未マークがgrayは微妙なのでwhiteにしたり、objectspaceが動くようにis_deadの条件を変えたりした。 http://github.com/mirichi/mruby/tree/simpleGC この状態で動かした128指定のao-renderが4分42秒、2スレッドマークGC化したmrubyでは3分32秒となり、我が目を疑うような高速化となったわけだが、そもそも元のmrubyでの実行は1分38秒なので世代別GCの威力がすさまじい。ao-renderのGC負荷
githubがよくわかってないのでbranchとかがなんか変なことになっているような気がするのだが、それはさておき。 このあいだ、マルチコアを活用するマルチスレッドGCについてアイデアをひらめいたので、とりあえず手ごろなmrubyをいじって実験してみようと思ったわけだ。CRuby難しすぎるし。mrubyのGCは世代別GC+インクリメンタルGCで意外に複雑なことをしているので、世代別のあたりとインクリメンタルのあたりのコードをばっさりと削って、素朴なマーク&スウィープGCにしてみた。コードはこんな感じである。 http://github.com/mirichi/mruby/tree/simpleGC objectspaceとの相性が悪いらしくうまくうごかないのでmrbgemsから外す必要がある。あと負荷をかけるとコケるのがいまいちわからないが、完璧に動かすのが目的でもないのでこれでいいとして
_ コード読むと良い そういえばそんな偉そうなことも言った気がする。けど別にコード読むのが特別良いとは思ってない。まぁ他の人が僕に比べてコード読まないと感じることは多い。そうそう shi3z さんの最適化の話とかすごいたくさんはてぶとかついてて、 twitter でもたくさんコメントされてたのに、誰もかけ算の回数数え間違ってると指摘してなくて、あの時もいやーホントみんなコード見ないもんだなと感心した。いや、僕も途中とかめんどくさいから最適化された後とされるコードしか見てないけど。 けど僕もそんな四六時中読んでるわけでもなくてもっともりもり読んでる人もいるし、あと読む派の人も色々ある気がする。 読む派の色々は、最初から最後まで全部読んでく人と、おおまかな設計とかを調べるのが好きな人、気になるとこの実装だけ細かく読む人、みたいなのがある気がする。僕は最後の派閥で、おおまかな設計の把握とかはあま
_ C pangram ちょっと考えたけどそうとうなにもできないな。 なにもしないコードを書けるかですらあやしい。 @#`"' あたりは捨てれるんだろうか。 (10:05) _ getauxval auxv を取ってくる関数だけど、この覚えにくさは異常。まぁ普通のユーザコードで取ってきたいことがあるのか知らんけど… man 見てるとなんでこんな情報渡してんだろってのが結構多いな…ざっとながめてみる AT_BASE: 普通に無いとこまる AT_BASE_PLATFORM: 謎。 glibc は使ってない AT_CLKTCK: 謎。あんまいらない気がするんだけど… AT_DCACHEBSIZE: 謎。 glibc は使ってない AT_*(U|G)ID: LD_PRELOAD 使っていいかの把握で必要 AT_ENTRY: 普通にあっていい、というか ehdr がマップされてない可能性考えると必須
ことほどさように main は全人類の至宝 LD_PRELOAD をもってしても簡単に奪えないということは、 main 蹂躙厨の間では有名な事実なのですが、 valgrind 使うと割に簡単なことに気付きました。 いつも通り Hello, world を書きます。 #include <stdio.h> int main() { puts("('-') Hello, world!"); } で実行。 > ./a.out ('-') Hello, world!平和です。こんな時代が続けば良かったのに! 不審なコードを書きます。 #include <stdio.h> void _vgrZU_Za_main() { puts("('-') ku ku ku ..."); } 主にシンボル名が不審です。さて実行。 > LD_PRELOAD=./hook_main.so valgrind --tool
gistfile1.sh `�'�rU 0Kz�rU $ git log --until=v2_0_0_0 --pretty=format:"%an" | sort | uniq -c | sort -r 7424 nobu 3475 akr 2553 matz 1618 naruse 1514 usa 1469 svn 1412 eban 902 ko1 644 drbrain 605 knu 536 mame 501 kosaki 466 tadf 448 aamine 396 nagai 360 shugo 315 ocean 302 tenderlove 302 kazu 269 yugui 264 marcandre 257 gotoyuzo 247 nahi 201 kou 188 suke 181 nagachika 158 dave 133 shyouhei 121 emb
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
周囲にWindowsユーザがめっきり減ってきた昨今ですが、 Windowsユーザの皆様はいかがお過ごしでしょうか。 Windows8は使えないだの、 シェルがしょぼいからあれだのと言われることも多いですが、 圧倒的にたくさんのPCで安心して動かせるOSとして、 私個人としてはとても便利に使っています。 Let’snoteのCF-S10Dという2年ほど前の機種を使っているのですが、 ようやくPanasonicのWindows8サポートがこの機種までやってきたので、 Windows8に入れ替えることにしました。 実は発売当初にもWindows8を入れていたのですが、 Let’snoteを快適に使うには必須の、「くるくるホイール」が使えなかったり、 謎の認識されないデバイスがあったりだったので、 Windows7に戻していました。 というわけで、セットアップついでにそのときの記録を書いておこうと
_FORTIFY_SOURCEというバッファーオーバーフロー攻撃を防ぐのにとても有用なマクロがある。 知らなかった人は以下のmanでもまず見てください http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/feature_test_macros.7.html _FORTIFY_SOURCE (glibc 2.3.4 以降) このマクロを定義すると、文字列やメモリの操作を行う様々な関数を 使用する際にバッファオーバーフローを検出するための軽めのチェックが 実行されるようになる。すべてのバッファオーバーフローが検出される わけではなく、あくまでよくある例についてだけである。 現在の実装では、以下の関数にチェックが追加されている: memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3),
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く