タグ

ブックマーク / mkosaki.blog46.fc2.com (18)

  • 革命の日々! Rubyで学ぶx86_64 ABI

    ひさしぶりにプログラミングの話題でも。 現在のRubyのtrunkをx86_64上のFedora12でmake test-allすると8個ぐらいテストが失敗するのだが、その中の1つにこういうエラーがある 1) Failure: test_sin(DL::TestDL) [/home/kosaki/linux/ruby/test/dl/test_dl2.rb:95]: <1.0> expected but was <1.38523885234213e-309>. test/dl/test_dl2.rbというのが、なにをしているテストかというと、ようするに以下のようにdlモジュールを使ってlibmのsin関数を呼んでいるわけだ module DL class TestDL < TestBase # TODO: refactor test repetition def test_sin() pi

    TAKESAKO
    TAKESAKO 2010/01/22
    Rubyで学ぶx86_64 ABI 「呼び出し側がrdiに引数を詰んでいるのに、呼び出され側はxmm0を呼んでいる」!
  • 革命の日々! C++0x ってhex numberなの?

    Kaz Kylheku: もし2010年にC++0xが出たら C++0x7DA ってこと? Mathias Gaunard: そのjokeはもう古いんだぜ (´・ω・`) http://groups.google.com/group/comp.std.c++/browse_thread/thread/5aa7115a76eaeb33# おまえは何を言っているんだ という感じで最高です

    TAKESAKO
    TAKESAKO 2009/12/12
    こちらをどうぞ→「C++0x ってhex numberなの?」
  • 革命の日々! さようならandroid?

    なんか、DreamCastの巻き添えをらってandroidのコードが全削除らったようだ。 何この面白展開 On Mon, Oct 05, 2009 at 04:21:35PM -0700, Randy Dunlap wrote: > On Mon, 5 Oct 2009 19:03:24 +1100 Stephen Rothwell wrote: > > > Hi all, > > > > Changes since 20091002: > > > drivers/staging/dream/gpio_axis.c:18:30: error: linux/gpio_event.h: No such file or directory Argh, I'm getting sick of the dream code. I'll sit down tomorrow and work it

  • 革命の日々! Java の closeDescriptors()

    kzk さんに教えてもらったネタ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6336770 Javaは新しいプロセス作るときに、ファイルディスクリプタを全部閉じようとするけども、実装がバグっているのでデッドロックが起きる可能性があるそうだ。 てきとうに見つけたクロスリファレンスサイトから引用すると http://www.jiema.org/xref/openjdk/jdk7/jdk/src/solaris/native/java/lang/UNIXProcess_md.c#293 fork-and-exec処理の時のディスクリプタ全クローズ処理で、よりにもよってopendir()。ここでmalloc()が発生。あぼーん。 なんで、UNIX系OSってcloseall()システムコールがないんだろうね。困ったもんだ 追記: Linux

  • 革命の日々! Kernel Podcast に Aoshima パッチが掲載されたよ!

    Tatsuhiro Aoshima ってのは、プログラミングキャンプ2009に参加した中学生ハッカー。これがマージされればLKMLの平均年齢が相当下がるな。 詳しくは以下のリンクをみてね。 2009/08/16 Linux Kernel Podcast http://www.kernelpodcast.org/2009/08/18/20090816-linux-kernel-podcast/ On another security related note, David Wagner drew attention to a security paper from this year’s USENIX playing up the impact of making various files world readable in the task directories under /proc

  • 革命の日々! A new GCC runtime library license snag?

    http://lwn.net/Articles/343608/rss 新しいgccで、GPLv2のプログラムをコンパイルすると再配布不可能になるよ。という話。よく知られているように、gccはコンパイル時に(勝手に)libgccをリンクする。これは除算のサポート等が含まれている。うろ覚えだけどC++の例外の補助コード等もここ。 んで、勝手にリンクされる都合上、あんまりきつい制約に出来ないのでGPLなんだけど、特別免除としてプロプラなライセンスとリンクしてもOKということにしてあげるよ。ということになっている。 で、このGCC runtimeのライセンスが、gcc 4.4からGPLv3になった。で、プロプラなライセンスは従来の特赦条項で救われるのでOKだけど、GPLv2は再配布時にライセンス変更しちゃダメ条項があり、かつ、GPLv2とGPLv3はincompatibleなので、自動的にライセン

    TAKESAKO
    TAKESAKO 2009/07/30
    恐れていたことが現実に・・・?>GCC runtimeのライセンスが、gcc 4.4からGPLv3になった。GPLv2は再配布時にライセンス変更しちゃダメ 条項があり、かつ、GPLv2とGPLv3はincompatibleなので、自動的にライセンス違反になる
  • 革命の日々! FSベンチマーク対決

    http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1 たぶん、デフォルトパラメタで勝負しているので、ext3はwritebackモードだと思う。 要約 ・SQLiteテストはext3が20秒で終わるところが、ext4では870秒、btrfsに至っては1472秒もかかった ・PostgreSQLのpgbenchのbtrfs, XFSは完走できなかった ・IOZone Write: ext3:107MB/s, ext4:131MB/s, Btrfs:89MB/s Read: ext3:202MB/s, ext4:219MB/s, Btrfs:93MB/s Btrfs遅いな~ ・Dbenchはext3:100MB/s, ext4:32MB/s, Btrfs:46MB/s やはり、ordered-mod

  • 革命の日々! セキュリティ&プログラミングキャンプ2009

    http://www.jipdec.or.jp/camp/ 応募開始しました! 私も一応講師に任命されておりますゆえ、一枚噛んでおります。 22歳以下の人はぜひ応募してください。 企業ベースのカンファレンスではありえない、講師陣の豪華さが自慢・・・らしいです。 参考: 未来のいつかの日記 - セキュリティ&プログラミングキャンプ2009今年も開催。 http://d.hatena.ne.jp/hyoshiok/20090610#p1 カーネルハックをしたいけど、やりかたがよく分からん。とかそういう人を大募集です。 よろしく! 追記: なんか、世間ではこういうウリになっている模様 このキャンプの大きな特徴としては、全部無料! 社会人の方がお金を払ってでも参加したくなるぐらいの内容ですが、 参加費用や教材費はもちろん、宿泊費や費、それに交通費まで無料です。 学生の方や親御さんのフトコロに優し

  • 革命の日々! [LKML名言集] こっち見んな( ゚Д゚ )

    > > > > I dunno. Is this true of all linux filesystems in all cases? Maybe. > > > > > > Assuming one of them is not would you rather want to fix that file system > > > or 10 zillion user programs (including the kernel core dumper) that > > > get it wrong? @) > > > > > > > I think that removing one bug is better than adding one. > > > > Many filesystems will return a short write if they hit a memor

    TAKESAKO
    TAKESAKO 2009/05/28
    w
  • 革命の日々! おまえら本当にNOPが好きだなぁ

    Efficient x86 and x86_64 NOP microbenchmarks というスレッドでLinusはx86のprefix命令は遅いとか言ってるけど、ちがうよ、全然違うよ。5バイトNOP (0x66 0x66 0x66 0x66 0x90)最強だよ。 とか議論してる。 おまいら、当にNOPが好きだなー * Steven Rostedt (rostedt@goodmis.org) wrote: > > On Fri, 8 Aug 2008, Linus Torvalds wrote: > > > > > > On Fri, 8 Aug 2008, Jeremy Fitzhardinge wrote: > > > > > > Steven Rostedt wrote: > > > > I wish we had a true 5 byte nop. > > > > > > 0

  • 革命の日々! 連載中止するかも

    ジェットコースター的展開 某連載の編集者様から、不況だから原稿料下げますというメールが来た。むーん、そんなに不人気だったのか。しかも割合がでかい。 元々、執筆にはかなり時間を取られていたので時給閑散では最低賃金を大幅に下回っており、時給閑散では被害がすくないのだが、これって自己欺瞞だよな。とかとか LKMLを全部読むというのはヨガの賢者も真っ青の苦行だったので、やめるなら今がチャンスでもある。 現在、関係者と鋭意協議中。

    TAKESAKO
    TAKESAKO 2009/02/03
    なんと…
  • 革命の日々! [kernel watch没ネタ集] long nop バトル

    x86には様々なNOPがあり、Intel® 64 and IA-32 Architectures Software Developer’s Manual に記載のあるものだけでも1byte長から9byte長までの種類がある。 これにprefix等の選択肢を考えると、まさに無限に広がる大宇宙。といった感じの可能性の広さである。 で、LKML内ではNOPの種類によって速度が変わることが広く知られていて、時折どのNOPを使うのがよいかが熱い議論になる。 特に近年は自己書き換えコードの都合で最速5byte NOP議論が熱い(long jumpが5byteだからね)。 まあ、5byte NOPと3byte NOP + 2byte NOP(とprefix NOP)のどれが速いか、なんて議論は、自転車置き場理論によって無駄にスレッドがのびていくので見ていて楽しい(ほんとか?) で、最近話題になったのはl

  • 革命の日々! なんで、pthread_once()なんて存在するの?

    http://d.hatena.ne.jp/amachang/20080612/1213244820 お気に入りなサイトのIT戦記より // ここを volatile にする // (この変数の値はアトミック(つまり、レジスタにだけあってメモリにないということがない変数に)になる) volatile char* p = NULL; pthread_mutex_t m; void* f(void* _p) { // ロックかからない if (p == NULL) { pthread_mutex_lock(&m); // ここからはクリティカルセクション // 一個目の初期化時にここでブロックしたスレッドのために // もう一回 NULL チェック if (p == NULL) { // ここではまだ p に代入しない // 代入したら別スレッドで初期化されていない p が返ってしまう cha

  • 革命の日々! relatimeがどこで実装されているのか調べてみた

    ITProのLinuxチューニングの記事がひどい事になっている件について http://mkosaki.blog46.fc2.com/blog-entry-535.html という数前の記事について、id:shiumachiさんが追試してくれました。 つ http://d.hatena.ne.jp/shiumachi/20080605 むむむ、すばらしいです。 特にrelatimeのあたりが秀逸です。relatimeの性能測定って他にあんまりないのではないかしら。 複数の方からご指摘いただいておりますが、noatimeはあの記事のなかで数少ない、現在でも意味のあるオプションです。 せっかくなので、お礼がてら、relatimeについてちょいと追記してみます。 まず、atimeまわりのオプションの意味から デフォルト:   常にatimeを更新する noatime:    常にatimeを更

    TAKESAKO
    TAKESAKO 2008/06/09
    NFSとかで(ry
  • 革命の日々! ITProのLinuxチューニングの記事がひどい事になっている件について

    http://itpro.nikkeibp.co.jp/article/COLUMN/20080528/304432/ あまりに酷いのでdisる記事を書こうかと思ったら、末尾に小さく 出典:日経Linux 2002年4月号 45ページより (記事は執筆時の情報に基づいており,現在では異なる場合があります) と書いてあった。6年前の記事かよ!! 古い内容が多いので、よい子は信用しないでね。

  • 革命の日々! この連載は期待できる

    先日書いた@ITの記事ですが、結構ブックマークされているようです。 で、苦笑いしちゃったのはこれ。 id:TAKESAKO のコメント「この連載は期待できる」 いや、ただの番外編ですから。。 連載の話なんて欠片もありませんから。。 読みきりの続編の話すらありませんから。。 とりあえず、このブクマ数だと色々と厳しいと思うんだ。うん。 だれかブクマ数増やしてくれ

    TAKESAKO
    TAKESAKO 2008/05/26
    期待してますw
  • 革命の日々! MALLOC_TRIM_THRESHOLD_ と MALLOC_MMAP_MAX_ パラメタについて

    どうもあまり有名ではないらしいので、ここで書いてみる。 http://mkosaki.blog46.fc2.com/blog-entry-241.html で書いた事とほぼ同じだけれど。 Linuxにおいて、CPU負荷を測定するベンチマークでは以下の環境変数を設定すると往々にして性能があがる。 % setenv MALLOC_TRIM_THRESHOLD_ -1 % setenv MALLOC_MMAP_MAX_ 0 MALLOC_TRIM_THRESHOLD_ はOSに未使用になったメモリを返却する契機をあらわしていて、-1は決して返却しない事を表す。 MALLOC_MMAP_MAX_ は最大mmap数で0は決してmmapせず、どんなに大きなメモリでもbrkを使ってメモリを取る事を意味する。 で、性能に効くのは(たいてい)MALLOC_MMAP_MAX_のほう。 glibcはアンチフラグ

  • 革命の日々! Ruby会議いってきた

    ちょっと(かなり)アウェイだったので正直発表は半分ぐらい理解できなかったけれども、やっぱりLLは元気があっていいね。と なんか性能改善関係はまだまだこれからとか言っていたので、なんか 参画したいね。 (あの界隈でスケーラビリティー大好き人間があつまってるところってどこなんでしょ??) 個人的に印象深かったのはTim Bray(ってRubyじゃないやんけ) Docomoの絵文字だの文字鏡だの、あからさまな日ローカルな単語が ぼんぼん飛び出してくるのはびっくりした。 よく勉強してんな。 しかし、そんなTimもYiエリアは説明せずに、お茶を濁して話をすすめる。そこでまた個人的にツボにはまりまくる。 Tim、かわいいよ。Tim. あと、去年隣の部署にインターンに来ていたサイトウくん(仮名)が実行委員やっていてばったり再開してお互いびっくり。とかとか

  • 1