gcc 4.4.1 の info を眺める.
今まで無かったんだな.
何コレ? ああ,固定小数点数か.不動点がどうだとか,そういう話かと思った(でも,文脈から理解出来ず).
なんだ,gcc 拡張ってことなのか.てことは,あのオプションは何なんだろ.strict な C に加えて使いたいとき,ってことなのか.
なんかえらい沢山あるな.
gcc --help={class|[^]qualifier}[,...]
で色々見れるんだなぁ.
diff -y を初めて知った.
お,-fconserve-stack は使うといいんじゃないか.4.3 であるか調べないと....無かった.残念.
LLTV も,FLTV 面白そうだなぁ.最近自分のアクティブティが下がってる.
.maxPriority = .max{|a,b|a.priority<=> b.priority}
これを,maxPriority = -> {|this| this.max{|a, b| a.priority <=> b.priolity} 解釈すればいいんだよな.ええと,一般化すると,
.foo = .bar(args){...} #=> foo_closure = -> (this, *args) { this.bar(args) {...} }
こんな感じ? あとは,それで呼び出してるメソッド名をちょいちょいなんかすれば.
というか,以前 ruby-dev で話題になった,Proc の拡張に似てるような.
というか,一度 Scheme, Python 風で Ruby っぽい言語を作ってみるか.効率は悪そうだけどなぁ.
http://d.hatena.ne.jp/udzura/20090830
LOOPからMAPへ!
という表現を見てえらい衝撃を受けた.Map なんて抽象度の低いものが幅をきかせてるなぁ,なんだかなぁ,と思ってたんだけど,そうか,世の中はまだ loop だったのか.そうだよなぁ.かなり,ショックな発見.
RHG ふつぱいら編:
#include <stdio.h> int main(int argc, char **argv) { int a$=1; int $b=2; int $=3; printf("Hello World %d, %d, %d\n", a$, $b, $); return 0; }
gcc version 4.3.2 (Debian 4.3.2-1.1) では,何もオプション付けなくても(-fdollars-in-identifiers 付けなくても)受け入れられた! きもーい.
http://slashdot.jp/yro/article.pl?sid=09/08/28/1510231
Fx 3 が出たときに思った懸念が今頃.いや,Fx 3 使ってるけどね.
今日は,JavaScript について色々勉強させて頂きました.楽しかった.
こんなプログラムを書いて,mmap の挙動を調べた.今回も,小崎さんに色々とお世話になりました.
#include <stdio.h> #include <stdlib.h> #include <sys/mman.h> #define PAGE_SIZE 4096 void * xmmap(size_t size) { void *ptr = mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0); if (ptr == MAP_FAILED) { return 0; } return ptr; } int main(int argc, char *argv[]) { int i, j; char *ptr; volatile char a; char buff[0x100]; for (i=0; 1; i++) { ptr = (char *)xmmap(PAGE_SIZE*1024); for (j=0; j<1024; j++) { a = ptr[PAGE_SIZE*j]; // read ptr[PAGE_SIZE*j] = 1; // write } if (ptr == 0) { printf("fin: %d\n", i); return 0; } if (i % 10000 == 0) { printf("%d\n", i); } } return 0; }
人捜し難しい....未踏とかに出て行って積極的に狩るべきだろうか.狩るってなんだよ.
日本の政党をソフトウェア関連の勢力図にマッピングしてみようと思ったけど,恐くなってやめた.
MSとかAppleとかGNUとか!
madvise (2) の MADV_DONTNEED が対象ページを即座に zero-clear するか,実験をやってみた.
#include <sys/mman.h> #include <stdio.h> #define PAGE_SIZE 4096 #define PAGE_COUNT 16 void check_zero(void *page) { char *buff = (char *)page; for (i=0; i<PAGE_SIZE*PAGE_COUNT; i++) { if (buff[i] != 0) { printf("non-zero: %p (%02x)\n", &buff[i], (int)buff[i]); return; } } } int main(int argc, void *argv) { void *block = 0; int i=0; for (i=0; i<1000; i++) { block = mmap(0, PAGE_SIZE * PAGE_COUNT, PROT_READ|PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0); if (block == MAP_FAILED) { perror("mmap"); exit(1); } check_zero(block); ((int *)block)[10] = 10; if (0 != madvise(block, PAGE_COUNT * PAGE_SIZE, MADV_DONTNEED)) { perror("madvise"); exit(1); } check_zero(block); if (0 != munmap(block, PAGE_COUNT * PAGE_SIZE)) { perror("munmap"); exit(1); } } return 0; }
FreeBSD の man ではこう書いてあるから,page fault -> zero-clear (zero-page のマッピング)しても良さそうなもんだけどなぁ.
MADV_DONTNEED Allows the VM system to decrease the in-memory priority of pages in the specified range. Additionally future references to this address range will incur a page fault.
というか,これだと「解放する」って感じじゃないな.swap out する可能性を高くするって感じだ.Linux の DONTNEED とは違うっぽい.MADV_FREE だと解放する(かも)
MADV_FREE Gives the VM system the freedom to free pages, and tells the system that information in the specified page range is no longer important. This is an efficient way of allowing malloc(3) to free pages anywhere in the address space, while keeping the address space valid. The next time that the page is referenced, the page might be demand zeroed, or might contain the data that was there before the MADV_FREE call. References made to that address space range will not make the VM system page the information back in from backing store until the page is modified again.
ちなみに,mmap 後は,やはり zero-clear されたページが返ってくるのね.
うーん,たしかに Linux の MADV_DONTNEED って変だよな.今回の場合都合がいいけど.
mono の人はちゃんとわかってるんだなぁ.
セキュリティ&プログラミングキャンプ2009,終わりました.一昨日.帰ったら死んでた.お疲れ様でした.
いろいろ書きたいことはあるのだけれど,やはり,コード書こう,って言って終わるのがいいんではないかな,とかなんとか.はっぴーはっきんぐ.
そういえば,今年はPPLのPCの話はなかったな.私の実力が正しく認められたに違いない.
なんか無茶ぶりが来た.そのテーマはちょっと難しい....
仕事がたまってる...。
http://www.mwsoft.jp/programming/other/compare_speed_ruby_python_java.html
Ruby 1.9 って遅いんだね−。うわー。
squeeze on x86の自分は、結構違う結果になりました。 http://gyazo.com/a07ea82e2c7bf970a683e7a2e2708df8.png
あ、Pythonが古すぎましたね。なのであんまり気にしないでください。
締め切り延長したそうです。上原先生はとても凄い人なので、一度会ってみるべき。むしろ、俺が行くべきか。
哲太郎さん!! 是非よろしくお伝えくださいませ♪
超ひっかかった! ご迷惑おかけしました>各位
Direct Message だと信じちゃうね。うーむ。実は、別のアプリケーションと勘違いしちゃったというのもあるんだけど。
twitter にログインできなくなった。情報リテラシーの無いやつはくんなということかもしれん。
白髪が結構見えてきた。ううむ。
SWoPP、明日の朝早く行きます。起きれるかな。
しかし、OS と PRO が被ってるのが大変悲しい。しかも、BoF も被ってるんだよな。
新しい F8 が欲しいような気がするが、Windows 7 が出るまで待った方がいいよな。
Hugh Dickinsの説明によると、昔Rik van RielがMADV_FREEを実装しようとしたんだけれども、Nick PigginがMADV_DONTNEEDを今の形に書き換えて議論が収束したらしい。だって2つあるメリットがよく分からんし。という理屈みたいだ
MAP_ANON は非推奨とか,モヒカンですねぇ.
MAP_ANONとはちょっと違うと思っていて、FreeBSDのMADV_FREEの説明を読むと完全に実装を書いちゃってるでしょう。これはインターフェースの切り方が悪いってこと。そもそも、すでにexplicit に dont need と宣言しているのに、なぜに追加のアドバイスが必要なんだよ。みたいな。あるべき論でいうと「いらない」とヒントだすまでがアプリの仕事、それ以降、どう実装するかはカーネルの責任ってのが、madvise()の根本原理だったはず
あれれ、「中身はとっておいて欲しいけど、主記憶に置いておく必要は現状ない (MADV_DONTNEED)」と、「中身もいらない (MADV_FREE)」は、違う要求で、どちらも欲しいと思うんですが、なんか勘違いしてるでしょうか? 片方だけ残すにしても、ゼロクリアするっていうのは意味が違うんだから、MADV_FREE だけ残すべき(でないと、他のOS向けに書かれているアプリケーションが壊れてしまうんじゃ?
sadaさんの指摘を読んでから、しばらく考えてやっとささださんが提起していた問題点を理解しました。MADV_FREEって使ったことなかったから存在意義が理解できてなかったわ。そうです。LinuxのDONTNEEDは中身を捨ててしまうのでPOSIX違反です。しかも他の*BSDとの互換性もありません。昔LinuxのDONTNEEDは*BSDのMADV_FREE相当なんだから、MADV_FREEにrenameしようという議論があったんだけど、そんなマイナーOSとの互換性よりも後方互換性の方が重要だろJKという結論になったはず。うん、たしかにモヒカンだ
バイナリ互換性は残して(#define MADV_FREE 4 を追加)、シンボル MADV_DONTNEED は削除ってするのが普通の判断じゃないかと思いますが... それで後方互換性は十分保てると思いますが(ソースの方は直してもらうと)...モヒカンというよりは、単に駄目なだけな気が...^^;
何が普通かはさておくとして、Linuxの世界ではカーネルの都合でアプリを直す必要がある修正は絶対ダメという文化。一方BSD互換を望んでいる人はいないわけで。たぶん、BSDがもっとメジャーなOSになればいいんだと思います
バイナリ互換性を崩さないというのは当然だと思いますが (*BSD でも、少なくとも NetBSD あたりはそうです)、ソースレベルでの上位互換性も絶対なんでしょうか? glibc レベルだと、ソースレベルの互換性のない変更が入ることがあるわけで (sched_setaffinity() の引数の数とか)、カーネルだけ頑張っても、ユーザから見ると現実的には意味がないような…
よくよく調べてみると、POSIX_MADV_DONTNEED の方は、POSIX 互換に直ってますね。 http://sourceware.org/bugzilla/show_bug.cgi?id=3458 でも、このパッチでは「POSIX_MADV_DONTNEED の値を変更し、古い値ならば Linux 式の MADV_DONTNEED を行なう」といった措置を欠いているので、 ソース互換性どころか、バイナリ互換性まで失われているようです。 まあ、わざわざ POSIX_MADV_DONTNEED を使っておいて Linux 風の MADV_DONTNEED を期待するってのはプログラムの側のバグだという判断なんでしょうけど。 同じ Linux 上なのに、MADV_DONTNEED と POSIX_MADV_DONTNEED で意味が違うのは、 気持ちが悪いと個人的には思うんですが… (NetBSD の場合、ソース互換性については 必ずしも保証していないので、deprecated な機能は新しくコンパイルするプログラム からは利用できなくして、API の見通しを良くしておくことがあります。もちろん、 古い API がすごくメジャーな場合には、そういうわけにはいきませんが…) あと、Linux の MADV_DONTNEED が、*BSD や Solaris の MADV_FREE と比べて 意味が強い (Linux の場合必ず zero fill されたページを返すが *BSD や Solaris だと、そうとは限らない) ために、性能低下があるという話題が出てた んですね。 http://kerneltrap.org/mailarchive/linux-kernel/2007/4/3/73000 そういう意味では、「#define MADV_FREE 4」というのは不適当で、 _FREE と _DONTNEED は厳密に POSIX 通りの意味とし、それとは別に 「#define MADV_ZEROFILL 4」を定義するという方が (現実の Linux で、可能か どうかは別として、理想的には) 良さそうです。
間違えました。zero fill なのは anonymous なページだけだから、「#define MADV_ZEROFILL 4」は名前がよろしくないですね。「#define MADV_RESET 4」とかかな。
今回の例では,zero page CoW を明示的にやるインターフェースがあるといいですねぇ.というか,それだけでいい.でも,madvise という名前では無さそうですね.munmap() + mmap() するといいんだろうか.Linux だったら,デバドラ一個書けば出来そうだけど.
たぶん、sodaさんの発想はBSD界隈のひとたちの発想に近くて、彼らはユーザランドも自前で抱えているからリリースの管理できる範囲が広いんです。でもLinuxはlibcすら別コミュニティだし、ディストリも一杯あるのでコントロール範囲がすごく狭い。んで、ディストリがいっぱいある分だけユーザ側はバージョン識別をいやがるので、互換性に対するプレッシャーが高いんだと思います。glibcでUlrichがしばしば問題のある修正をやらかしてしまうのは事実ですが、glibcは開発が楽しくないので新規開発者が増えていかないんですよね。。。問題です。
ところで、僕は人様のblogで何を延々と関係ない雑談を繰り広げているのでしょうか :-)
RubyはGiant lockが残っているという話なので、mmap()でも十分かも。mmap(MAP_FIXED)使えばmunmap()いらなくね?
ああ、一点だけ。MADV_FREEはPOSIXにないっすよ。
直接 mmap(2) する発想は無かった.すでに割り当てられたアドレスに mmap したらどうなる,って(FreeBSDとかの) man 見ても分からないんだよな.調べます.コンパイルファーム欲しい.
おお、確かにそうですね。Solarisにも、ずいぶん前(おそらくSolaris 8)からある のでPOSIX_MADV_FREEもあるもんだと思い込んでました。指摘ありがとうございます。 MADV_FREEはどうやらFreeBSD起源の機能のようですね。 FreeBSDだとFreeBSD-2.2.0(1997年リリース)で既に存在したようです。
新しいmmapの方が有効になりますので問題ないです。