[plamo:19685] 2.5.75(Re: Re: make-jについて)

[KOJIMA Mitsuhiro]

From: Shun-ichi TAHARA (田原 俊一) <jado@flowernet.gr.jp>
Subject: [plamo:19683] Re: make -jについて
Date: Mon, 14 Jul 2003 22:42:42 +0900 (JST)

> > ちょっとカーネル2.6preが突然出てびっくりです。さっそくいれてみようと思います。
> 
> ちなみに、これを生の 3.1/3.2 に入れようと思ったときに、どれとどれを入
> れ換えたらいいかっていうリストは作れませんか? あれば幸せになれる人がい
> ると思うんですけど。

2.5.75 の Document/Changes によると，最低限必要なバージョンとチェック
方法は以下の通りらしい．

o  Gnu C                  2.95.3                  # gcc --version
o  Gnu make               3.78                    # make --version
o  binutils               2.12                    # ld -v
o  util-linux             2.10o                   # fdformat --version
o  module-init-tools      0.9.9                   # depmod -V
o  e2fsprogs              1.29                    # tune2fs
o  jfsutils               1.0.14                  # fsck.jfs -V
o  reiserfsprogs          3.6.3                   # reiserfsck -V 2>&1|grep reiserfsprogs
o  xfsprogs               2.1.0                   # xfs_db -V
o  pcmcia-cs              3.1.21                  # cardmgr -V
o  quota-tools            3.09                    # quota -V
o  PPP                    2.4.0                   # pppd --version
o  isdn4k-utils           3.1pre1                 # isdnctrl 2>&1|grep version
o  procps                 2.0.9                   # ps --version
o  oprofile               0.5.3                   # oprofiled --version
o  nfs-utils              1.0.3                   # showmount --version

さらにざっと見だけど，jfs/xfs のサポートツールは入ってないので必要に応
じて入れる必要あり．reiserfsprogs/quota-tools/procps あたりは要更新，
oprofile って何か知らない，って感じかな．

# goole で引いたら system profiler らしいけど

> > それにしてもなんかもっとパソコンの性能を発揮させる方法はないですかねー？
> 
> 何を持って「性能を発揮」とするかによって変わってきますが?

排熱を利用してお湯を沸かしてみるとか :-)

# 手元には Athlon と Celeron なマシンがあるけど，Athlon 機の電源を入れ
# ると部屋の温度が数度上昇する感じ．ファンもうるさいから，性能的には劣
# るんだけど，24 時間運転のファイルサーバは Celeron 機にしてしまった．

> この手の流れは、プログラミングスタイルにも現れてますよね。最近では、ス
> テップ数の少ないコードよりも、美しくて読みやすい(メンテしやすい)コード
> が好まれるのは、十分な計算機資源が確保できることと無縁ではないと思いま
> す。もちろん、高速で良質なアルゴリズムはいつの世も正義ですが、大昔のよ
> うに「こう書いた方が1バイト少ない」とか「こっちの方が1クロック短い」的
> なチューニングは、通常行なわれなくなってしまいました。

最近だと，ヘタすると perl や ruby あたりで書く方が設計やコーディング，
デバッグの部分がすごく短縮できるので，C とかで書くより全体の効率はいい
かも知れないですね(苦笑)

# 何回となく使うコードの場合はちゃんとコンパイラで書くべきなんだろうけ
# ど，GUI とかの皮を被せたら中は何でも構わない気が，，，

> Intelのコンパイラとか、AthronGCC とかで最適化のかかったバイナリを作る
> というのもこっちに入るのかな。苦労の割に実は得るものが少ないんですが、
> 個人的な満足度はかなり高いかも。

私よりもずっと詳しい人がいらっしゃると思うけど(^^;)，計算を可能な限り
高速化する HPC(High Performance Computing)の世界だと，クラスタな環境で
並列度をいかに高めるかが重要だから，ループを回す順番を調整したり，実際
に載っている RAM のサイズに合わせて配列を取ってみたり，，みたいなチュー
ニングが残っているみたいですね．

# 最適化コンパイラもかなり優秀になってるそうだけど

--------
こじま