|
Namazu for hns による簡易全文検索 詳しくは 詳細指定/ヘルプを参照して下さい |
|||||||||||||||||||||||||||||||||||||||||||||||||||
2007年12月04日(火) 旧暦 [n年日記] [更新:"2007/12/05 16:54:04"]#1 [機械] Athlon x2, Opteron の bc bench を測って見た
> time sh -c 'echo scale=2000\;4*a\(1\) | bc -l' > /dev/null 3.832u 0.001s 0:03.84 99.7% 0+0k 0+0io 0pf+0w pts/0:makoto@modena 21:42:30/071204(~)> @ mfs で byte-bench:
mfs を作って、/tmp に mount し、その環境で
bytebench
して見た →
330
それなりには速い。が、BE 2350 の 368 にはまだ負けている
(ただし、こちらは都合で GENERIC.MP)。
/etc/rc.local より: /usr/sbin/mdconfig /dev/md0d 4096000 & /sbin/mount_mfs -b 16k -f 2k -s 4096000 /dev/md0d /tmpこれで 2G memory disk。 (普通は 4,294,967,296 かな ... 違う ?) こんなことしなくても自動的に mfs になる気がしたが ? 最近は mfs でなくて tmpfs では ? というつっこみあり (IRC) @ 4.99.37 で再び:
2007/12/04 の
4.99.40 では何故か bytebench の途中で(決った場所ではなく)全く反応がなくなる
ような気がした。
また 2007/12/05 では kernel の開始時に再起動してしまう。
そこで、4.99.37 (2007-11-24 0000-UTC) で 上と同じ mfs を使い、CPU は一つで
pckbc.c の変更
は当てた上で測ったら、手元の機械の中で辛うじて最速
370
となった (でも何故 69% ?)。
sys/arch/amd64/amd64/lock_stubs.S だけは 1.9 にした。 何故 TNF では 11/24-27 までこの問題が表面化しないのか不思議 (多分手元の他の何かだけが新しくなっているのだろう)。 ( つっこみ )
|
最近の日記 2024年07月03日 ・kicad oddity 2024年05月08日 ・comparison on ./buildsh tools 2024年05月06日 ・py-setuptools (python 3.11.9) ・make release took 1 hours and 10 min ・qemu invocation for 10.99.10 2024年05月05日 ・Windows 10 version ・serial connection ・bc bench 2024年05月04日 ・Trial on 10.99.10 ・another version (later trial) to succeed | ||||||||||||||||||||||||||||||