K.Sasada's Home Page

Diary - 2009 August

研究日記

葉月

_31(Mon)

gcc 4.4.1 の info を眺める.

  • 5.55 Binary constants using the `0b' prefix

今まで無かったんだな.

  • 5.13 Fixed-Point Types

何コレ? ああ,固定小数点数か.不動点がどうだとか,そういう話かと思った(でも,文脈から理解出来ず).

  • 5.29 Dollar Signs in Identifier Names

なんだ,gcc 拡張ってことなのか.てことは,あのオプションは何なんだろ.strict な C に加えて使いたいとき,ってことなのか.

  • 5.50.3 ARM NEON Intrinsics

なんかえらい沢山あるな.


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 だったのか.そうだよなぁ.かなり,ショックな発見.

_30(Sun)

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 付けなくても)受け入れられた! きもーい.

_29(Sat)

http://slashdot.jp/yro/article.pl?sid=09/08/28/1510231

Fx 3 が出たときに思った懸念が今頃.いや,Fx 3 使ってるけどね.


今日は,JavaScript について色々勉強させて頂きました.楽しかった.

_28(Fri)

こんなプログラムを書いて,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;
}

_25(Tue)

_wordcopy_bwd_aligned というのがとても遅い.さて,どうしたものか.

_22(Sat)

人捜し難しい....未踏とかに出て行って積極的に狩るべきだろうか.狩るってなんだよ.


日本の政党をソフトウェア関連の勢力図にマッピングしてみようと思ったけど,恐くなってやめた.

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;
}
  • Linux 2.6.26 では zero clear された.
  • FreeBSD 7.1 では,zero clear されなかった.
  • sun4v では MADV_FREE で zero clear された.

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 って変だよな.今回の場合都合がいいけど.


http://www.google.com/codesearch/p?hl=ja&sa=N&cd=3&ct=rc#4ewjdMf3tBc/mono/utils/mono-mmap.c&q=madvise%20MADV_FREE

mono の人はちゃんとわかってるんだなぁ.

_kosaki(Sun Aug 23 01:56:09 +0900 2009)

 Hugh Dickinsの説明によると、昔Rik van RielがMADV_FREEを実装しようとしたんだけれども、Nick PigginがMADV_DONTNEEDを今の形に書き換えて議論が収束したらしい。だって2つあるメリットがよく分からんし。という理屈みたいだ

_ささだ(Sun Aug 23 03:01:05 +0900 2009)

 MAP_ANON は非推奨とか,モヒカンですねぇ.

_kosaki(Sun Aug 23 16:51:55 +0900 2009)

 MAP_ANONとはちょっと違うと思っていて、FreeBSDのMADV_FREEの説明を読むと完全に実装を書いちゃってるでしょう。これはインターフェースの切り方が悪いってこと。そもそも、すでにexplicit に dont need と宣言しているのに、なぜに追加のアドバイスが必要なんだよ。みたいな。あるべき論でいうと「いらない」とヒントだすまでがアプリの仕事、それ以降、どう実装するかはカーネルの責任ってのが、madvise()の根本原理だったはず

_soda(Mon Aug 24 21:07:27 +0900 2009)

 あれれ、「中身はとっておいて欲しいけど、主記憶に置いておく必要は現状ない (MADV_DONTNEED)」と、「中身もいらない (MADV_FREE)」は、違う要求で、どちらも欲しいと思うんですが、なんか勘違いしてるでしょうか? 片方だけ残すにしても、ゼロクリアするっていうのは意味が違うんだから、MADV_FREE だけ残すべき(でないと、他のOS向けに書かれているアプリケーションが壊れてしまうんじゃ?

_kosaki(Tue Aug 25 10:05:15 +0900 2009)

 sadaさんの指摘を読んでから、しばらく考えてやっとささださんが提起していた問題点を理解しました。MADV_FREEって使ったことなかったから存在意義が理解できてなかったわ。そうです。LinuxのDONTNEEDは中身を捨ててしまうのでPOSIX違反です。しかも他の*BSDとの互換性もありません。昔LinuxのDONTNEEDは*BSDのMADV_FREE相当なんだから、MADV_FREEにrenameしようという議論があったんだけど、そんなマイナーOSとの互換性よりも後方互換性の方が重要だろJKという結論になったはず。うん、たしかにモヒカンだ

_soda(Tue Aug 25 14:32:19 +0900 2009)

 バイナリ互換性は残して(#define MADV_FREE 4 を追加)、シンボル MADV_DONTNEED は削除ってするのが普通の判断じゃないかと思いますが... それで後方互換性は十分保てると思いますが(ソースの方は直してもらうと)...モヒカンというよりは、単に駄目なだけな気が...^^;

_kosaki(Wed Aug 26 04:53:06 +0900 2009)

 何が普通かはさておくとして、Linuxの世界ではカーネルの都合でアプリを直す必要がある修正は絶対ダメという文化。一方BSD互換を望んでいる人はいないわけで。たぶん、BSDがもっとメジャーなOSになればいいんだと思います

_soda(Wed Aug 26 11:04:36 +0900 2009)

 バイナリ互換性を崩さないというのは当然だと思いますが (*BSD でも、少なくとも NetBSD あたりはそうです)、ソースレベルでの上位互換性も絶対なんでしょうか? glibc レベルだと、ソースレベルの互換性のない変更が入ることがあるわけで (sched_setaffinity() の引数の数とか)、カーネルだけ頑張っても、ユーザから見ると現実的には意味がないような…

_soda(Wed Aug 26 13:46:05 +0900 2009)

 よくよく調べてみると、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 で、可能か どうかは別として、理想的には) 良さそうです。

_soda(Wed Aug 26 13:58:50 +0900 2009)

 間違えました。zero fill なのは anonymous なページだけだから、「#define MADV_ZEROFILL 4」は名前がよろしくないですね。「#define MADV_RESET 4」とかかな。

_ささだ(Thu Aug 27 05:20:40 +0900 2009)

 今回の例では,zero page CoW を明示的にやるインターフェースがあるといいですねぇ.というか,それだけでいい.でも,madvise という名前では無さそうですね.munmap() + mmap() するといいんだろうか.Linux だったら,デバドラ一個書けば出来そうだけど.

_kosaki(Thu Aug 27 11:07:28 +0900 2009)

 たぶん、sodaさんの発想はBSD界隈のひとたちの発想に近くて、彼らはユーザランドも自前で抱えているからリリースの管理できる範囲が広いんです。でもLinuxはlibcすら別コミュニティだし、ディストリも一杯あるのでコントロール範囲がすごく狭い。んで、ディストリがいっぱいある分だけユーザ側はバージョン識別をいやがるので、互換性に対するプレッシャーが高いんだと思います。glibcでUlrichがしばしば問題のある修正をやらかしてしまうのは事実ですが、glibcは開発が楽しくないので新規開発者が増えていかないんですよね。。。問題です。

_kosaki(Thu Aug 27 11:08:10 +0900 2009)

 ところで、僕は人様のblogで何を延々と関係ない雑談を繰り広げているのでしょうか :-)

_kosaki(Thu Aug 27 11:26:15 +0900 2009)

 RubyはGiant lockが残っているという話なので、mmap()でも十分かも。mmap(MAP_FIXED)使えばmunmap()いらなくね?

_kosaki(Thu Aug 27 12:16:53 +0900 2009)

 ああ、一点だけ。MADV_FREEはPOSIXにないっすよ。

_ささだ(Fri Aug 28 10:20:54 +0900 2009)

 直接 mmap(2) する発想は無かった.すでに割り当てられたアドレスに mmap したらどうなる,って(FreeBSDとかの) man 見ても分からないんだよな.調べます.コンパイルファーム欲しい.

_soda(Fri Aug 28 11:24:14 +0900 2009)

MADV_FREEはPOSIXにないっすよ。

おお、確かにそうですね。Solarisにも、ずいぶん前(おそらくSolaris 8)からある のでPOSIX_MADV_FREEもあるもんだと思い込んでました。指摘ありがとうございます。 MADV_FREEはどうやらFreeBSD起源の機能のようですね。 FreeBSDだとFreeBSD-2.2.0(1997年リリース)で既に存在したようです。

すでに割り当てられたアドレスに mmap したらどうなる

新しいmmapの方が有効になりますので問題ないです。

_21(Fri)

Windows で HOME にしていたディレクトリの . で始まるディレクトリが全部消えて泣きそう.なんで?

_19(Wed)

論文が全然読めていないのだけれど,今日徹夜して間に合うだろうか.

_18(Tue)

セキュリティ&プログラミングキャンプ2009,終わりました.一昨日.帰ったら死んでた.お疲れ様でした.

いろいろ書きたいことはあるのだけれど,やはり,コード書こう,って言って終わるのがいいんではないかな,とかなんとか.はっぴーはっきんぐ.


そういえば,今年はPPLのPCの話はなかったな.私の実力が正しく認められたに違いない.


なんか無茶ぶりが来た.そのテーマはちょっと難しい....

_10(Mon)

幕張と舞浜と浜松町が混ざる.

_にしお(Mon Aug 17 13:56:50 +0900 2009)

 っ[浜町]

_9(Sun)

サーバ復活。マシンは復活してたんだが、途中のハブの電源が落とされていた。しまったなぁ。

_7(Fri)

仕事がたまってる...。


http://www.mwsoft.jp/programming/other/compare_speed_ruby_python_java.html

Ruby 1.9 って遅いんだね−。うわー。

_斎藤ただし(Sat Aug 08 15:41:24 +0900 2009)

 squeeze on x86の自分は、結構違う結果になりました。 http://gyazo.com/a07ea82e2c7bf970a683e7a2e2708df8.png

_斎藤ただし(Sat Aug 08 15:47:58 +0900 2009)

 あ、Pythonが古すぎましたね。なのであんまり気にしないでください。

_5(Wed)

第42回情報科学若手の会

締め切り延長したそうです。上原先生はとても凄い人なので、一度会ってみるべき。むしろ、俺が行くべきか。

_かずひこ(Thu Aug 06 00:42:22 +0900 2009)

 哲太郎さん!! 是非よろしくお伝えくださいませ♪

_3(Mon)

超ひっかかった! ご迷惑おかけしました>各位

Direct Message だと信じちゃうね。うーむ。実は、別のアプリケーションと勘違いしちゃったというのもあるんだけど。


twitter にログインできなくなった。情報リテラシーの無いやつはくんなということかもしれん。


白髪が結構見えてきた。ううむ。


SWoPP、明日の朝早く行きます。起きれるかな。

しかし、OS と PRO が被ってるのが大変悲しい。しかも、BoF も被ってるんだよな。


新しい F8 が欲しいような気がするが、Windows 7 が出るまで待った方がいいよな。

_1(Sat)

英語頑張ったのが記事になってた。


たまるひろしってこんな顔だったんだ。


神様のパズル、読了。うーん、こう終わるのか。色々、えーって感じ。何が「ありがとう」だったんだろう。うーん。

Sasada Koichi / ko1 at atdot dot net
$Date: 2003/04/28 10:27:51 $