ヨタの日々

_ 朝ッ

0520 起床

やばい眠い

_ 仕事

0830 出勤

リソースビジー

実機ビジー

_ ;;

キーワード のばら

_ NetBSD blog でいう「now」

NetBSD 6 のことか

NetBSD 6 なう

_ [翻訳][negative symbol cache][NetBSD]NetBSD Blog - NetBSD runtime linker gains negative symbol cache 翻訳

The NetBSD runtime linker now has a negative symbol cache. In a nutshell, this has reduced the startup time of the Evolution mail client from around 5 minutes to 3 seconds on my QuadCore amd64 machine. Not many applications have a lot of plugins with a large amount of links to external libraries and I doubt many other applications will gain such a drastic speed bump, but the GNOME desktop as a whole now loads small bit quicker. I would imagine that KDE will now load faster as well.

現在の NetBSD のランタイムリンカ( 訳: ld.so_elf のこと )はネガティブシンボルキャッシュを使うようになった。ようするに、これがあるとメールクライアントの Evolution を起動するのに 5 分かかっていたものが 3 秒で起動するようになる( 私の QuadCore AMD64 マシンの場合 )。大量の外部ライブラリを使うアプリケーションはそう多くないし、他のほとんどのアプリケーションではそれほど劇的にスピードアップすることはないだろうと思っているけど、GNOME デスクトップ全体では微妙に速くなる。KDE は現在のものよりは速くなりそう。

_ [翻訳][negative symbol cache][NetBSD]NetBSD negative symbol cache 翻訳

Significant changes from NetBSD 5.0 to 6.0

ld.so_elf
Implement negative symbol lookup cache [roy 20100227]

[PATCH] ld.elf_so - Cache objects checked

I've been researching why Evolution from GNOME takes over 5 minutes to load on my quad core amd64 beast. It boils down to dlsym looking for a symbol that does not exist directly and as such examining every needed library. However, the current implementation does not remember what libraries it as already checked. Normally this isn't a problem, but with the way Evolution is built the search chain is massive.

なぜ私の Quad core AMD64 の環境で GNOME を起動するのに 5 分もかかるのか調べてた。ようするに、dlsym はシンボルが見つからなかったとっきに必要なライブラリをその都度探しにいくんだが、現在の実装ではどのライブラリがチェック済みなのか覚えてないのだよ。普段はこれは問題にならないのだけど、重量級の環境だと問題になる( 訳: ???? )

As such, I've ported FreeBSD's DoneList cache from their runtime linker to ours. The main implementation difference is we xmalloc + xfree vs their alloca + no free needed. They've been using this for a long time, so the idea + code is pretty solid.

そういうわけで、私は FreeBSD の DoneList キャッシュを NetBSD の( 訳: ours )ランタイムリンカに実装した。

However, I've added a second cache for weak symbols to _rtld_symlook_needed which is where the real performance gain is made for my use case. Whilst this doesn't break my system and I cannot see a flaw in it's design maybe someone can comment?

あと( 訳: However ) 私の使い方で本物のパフォーマンス( 訳: ???? )を引き出すために、さらに weak シンボルのための 2次キャッシュを _rtld_symlook_needed へ追加した。私のシステムで使ってるうちは死ななかったし( 訳: break ) 設計に問題ないように見えるのだけど、何か意見ある？

With this patch, Evolution (without the patches to and a glib I added to pkgsrc a few days ago) loads in under 2 seconds (5 seconds with initial disk thrashing).

添付したパッチを使うと Evolution ( パッチなし glib を数日前に pkgsrc に追加した ) は 2 秒以内に起動する( 初期化のためのディスクスラッシングに 5 秒かかる )

_ weak シンボル

• Weak symbol - Wikipedia, the free encyclopedia
• リンクされているライブラリによってプログラムの動作を変える - bkブログ
• リンクと同名シンボル: weak シンボル編 - bkブログ

weak シンボルについては Linkers & Loaders の6章に以下の解説があります。

ELF では、weak参照のほかに weak定義というもう1つの weakシンボルを追加している。 weak 定義は、通常の定義が存在しない場合に大域シンボルを定義する。通常の定義が存在する場合は、 weak 定義は無視される。

_ [翻訳][NetBSD][ELF]NetBSD Blog - Kernel modules for macppc and shark 翻訳

As of past night, the macppc and shark ports have support for the new-style kernel modules. I've added support for these through a workaround in the build system, which makes the compiler generate long jumps for all calls in the code, avoiding unsupported ELF relocation types. This allows us to use the modules even if the kernel-level loader is not able to deal with such relocations. The kernel-level support is now enabled by default in macppc and shark GENERIC kernels.

昨晩( 訳: ? ) macppc と shark ports に新しいスタイルのカーネルモジュールが取り込まれた。未サポートの ELF 再配置(のタイプ)を回避するために、コンパイラに long jump を挿入したコードを生成させる仕組みを追加した。たとえカーネルレベルローダーが ELF 再配置できないとしても、カーネルモジュールにこの手段を適用できる。カーネルレベルサポートは macppc と shark ports の GENERIC カーネルではデフォルトで有効になっている。

We'll need to revisit this in the future and implement real support for dealing with those relocation types. Why? The modules built with this flag are slower than they should be... but at least they do work.

( この対処については )近い将来また考え直す必要があるし、再配置タイプをちゃんとサポートしないといけない。なぜかって？ このフラグを立ててビルドしたモジュールはノロいし、それに...まあ少なくとも一応動作する。

_ [ELF]ELF

• FreeBSD 2.X、3.X、4.X についての FAQ (よくある質問とその答え)その他の質問 FreeBSD の実行フォーマットの a.out、ELF とはどのようなものですか? また、a.out、ELF を使う理由は何でしょう?
• elf(5) : FreeBSD 一般コマンドマニュアル
• NetBSD ELF FAQ
• ELF - osdev-j (MMA)
• ELF/実行時の話 - osdev-j (MMA)
• The Linux ELF HOWTO

_ [リッジレーサー7]リッジレーサー7

オフライン自主練。リバースチャージがようやくトリプルニトロ溜まるようになった。しかし一度ミスるとニトロが尽きる。