Antec P182マシン、大改修・完結篇?

というわけで、その後以下のように手を加えました。

  • 大騒ぎの原因の一つだったグラフィックカードですが、結局ロープロファイルでショートサイズのカードに変更
  • PCIスロットの空きスロットの蓋を、空気穴が無いタイプに総取替
  • 上面排気ファンは、中段前面で補助吸気ファンとしての使用に変更。排気穴は物を置いて塞いでいる
  • 排気ファンは煙突(?)で上段前面側に排気(5インチベイを全部潰して14センチファンを最低回転数で利用)
  • BIOSの設定で最低回転数(PWMのデューティ比20%)まで落とす方法がわからなかったため、PWM制御信号を発生するArduino工作品を追加
  • CPUクーラーをScytheの兜3に変更。手頃な大きめのトップフロータイプなら何でもよかったのですが、日本ブランドのScytheで、ということで
  • ファンレスグラフィックカードヒートシンクが「触るとちょっと熱いかな」ぐらいになるので、PCIスロットに付けるタイプのファンステイ(アイネックスブランド。作りは長尾製作所っぽい気もするが、長尾からは販売されていない? タイプのもの)に無理矢理斜めに付けた、9センチファンで補助冷却(こちらも回転数を下げて利用)

CPUクーラーの空気流の余りで周辺も冷却したい所なので、兜3標準の12センチファンから14センチファンへの装換を実験していたが、ワイヤークリップを自作する必要があり、さらに14センチファン(Scythe製品ではないものを使用)の個体の問題か振動がひどく異音を発生させるために断念。

だいたいこんな所でしょうか。

Antec P182マシン、大改修

前に書いた通り、電源とマザーボードを新調したわけですが、この際ということで大幅な改修を行うことにしました(画像は改修後)。

  • 大型のグラフィックボードとの干渉で難儀していたHDDを下段に移動、中段ケージを撤去
  • 同様に、張り出していて、パラレルATAケーブルが邪魔でもあった光学ディスクドライブも撤去
  • 元々は強制排気・自然吸気の、強い負圧タイプが前提のケースだが、下段前面にファンを追加し強力に吸気を行うことで、HDDの強制冷却と同時に、ケース全体を正圧に近づける
  • 下段と中・上段のエアフローを分離する当て板は撤去し、下段吸気は積極的に上にも流す
  • (下段の中間に元々あったファンは以前に撤去済み)

という方針で、完全な再組立を行いました。サーバ的な管理された環境にあるマシンであれば負圧のケースも良いのかもしれませんが、ホコリを避けられない環境ということもあり、フロントパネル内側など、吸気のせいで、かなりえらいことになっていました(正圧にこだわるなら SilverStone あたりに買い替えたほうが素直かも?)。

まずこのケースで難儀するのが下段前面ファンで、P183など後継機と違い、それっぽい空間があるものの12cm角ファンの設置はかなり無理をともないます(こちhttp://day8ge.blog15.fc2.com/blog-entry-503.html の報告にありますように、不可能ではありませんが)。

ひとまわり下のサイズの9cm角(25mm厚)のファンで検討してみたのですが、実際に収めてみると、下段ケージのハードディスクとの間にほとんど間隔が無く、ファンの性能や騒音にも悪影響がありそうで、諦めました。今回の私の選択とは逆に中段にHDDをまとめ、下段がガラ空きであるとか、マウンターを選べばSSD化で前面側に余裕があるとかであれば、(フィルタの爪との干渉の問題もありますが)ここにファンを置くのも悪くないでしょう。

私は思い切って、ケースの前にファンを取り付けてしまうことにしました(写真では側面が写っています)。当然、扉は閉められなくなるので取っ払ってしまい、防音はかなり諦めることになります。通風のため、ケースの金網状の部分は、ファン取付のための角の部分を除いて、ハンドニブラで切除してあります(四隅の角が、ほぼちょうど12cmファンの取付穴の位置にあります)。ホコリ対策は十全にする必要があるので、フィルタを挟み込むタイプの組立式のファンガードを付け、100円ショップにあった使い捨ての、換気口用の15cm角の不織布フィルタを入れています。

(以下、続き)

通風改善のため、電源のATX24線とCPU Power Connector8線は裏配線に回しました(後継のケースでは裏配線の使い勝手はかなり改良されていますが、P182では上下チャンバの分離が優先されていて、あまりたくさんは使えません)。その他、下段にあるので結構長さが余るSATAの電源線などは、中段にのたくらせることで下段および全体の通風の改善を図っています。

また、チップセットとCPU電源部の冷却のための、4cm角で10mm厚のファンがユーザ追加のオプションで取り付けられるマザーボードで、メーカーによる解説では吸気になっているのですが、やはりバックパネル付近がホコリを吸うので(バックパネルの吸入口からダクトを付ける手もありますが)排気の向きで付けました。すると全体のエアフローの設計として、ケース側であるP182の後部排気ファンを付けると排気を奪い合ってしまいますから、上部だけの排気としました。

チップセットヒートシンク付近の構造物の形状が吹付け前提で、逆にすると効果がだいぶ落ちるんじゃないかという気はしますが(そういえばこれまでどこにもマザーボードについて書いてないですが、Sabertooth 990FX です)、マニュアルにも書いてないギミックですので気休めだと思って気にしないことにします。

この4cmファンには、山洋のものでこのサイズでは回転数が最も高いの(6200RPM, 109P0412H901)を選びました。絶対的な騒音としては他の大径ファンのほうが大きいものの、高音の騒音が出るので取付方法を改造したいと思っている所です(その他にもこの日記を書き始めた後にあれこれ手を加えているのですが、それはまた別の記事とする予定)。

PCの電源を買った

無理な延命等が祟ったようでもあり、PCの電源が、2代目か3代目となるマザーボードと一緒に(原因がどちらの側かは不明瞭)壊れたため、現行のCPUとDIMMとの組合せでは多分最後となるマザーボードと、電源を買った。

というわけで以下検討過程などのメモ。

  • せっかくなのでTitanium認証の高効率型の電源にしてみよう

調べてみると、1000W級と比べ、700W級でTitanium認証の電源は多くない(10%負荷時に90%の効率を要求してるからなー……)。現在、日本で一般的に市販されているものには、基本的には、以下の2系統のものしかない。

Seasonic のほうは、日本国内代理店のオウルテック扱いのものが購入できる。

Enhance のほうは、Enhance ブランドではサイズから以下の2モデルがある。

  • ATX-1850GB (500W)
  • ATX-1870GB (700W)

(いずれもセミプラグインhttp://www.scythe.co.jp/power/ragepower-titanium-plugin.html ATX-1850GBは販売終了)

他に玄人志向と SilverStone ブランドによるOEMないしODM(ブランド元による設計のカスタマイズがどの程度入っているかは未把握)がある。いずれもプラグイン化や筐体サイズ(奥行)はいろいろ。

玄人志向のラインナップは、

SilverStone のラインナップは、

(いずれもフルプラグイン。日本国内代理店は、マスタードシードディラック・CFD販売・他?)

といった感じである。

結局、ST60F-TI を買ったのだが、実物で確認した所、ファンが Silver Stone の SST-AP123(のカスタム版?)になっていた(SST-AP123 http://www.silverstonetek.com/product.php?pid=402 )。

特徴的な大中小の3種類x3のブレード

徹甲弾」ファンの特徴的なグリルが確認できる

ブレードの色違いや、単体製品の SST-AP123 には回転数制御は付いていないことから、カスタム版だと思われる。

SICPと、6.001の話

調べていたところ、「弱LisperがMITでSICP(シクピー)を受講した結果」( http://qiita.com/kaz-yos/items/d1ecd4bfe9989c290e99 )というQiita記事を見つけたのでリンクしておきます。噂の(?)SICPを懐かしむチューターたちによって実施されている特別授業に潜り込んだ(?)方によるレポートです。

本題の、以前はSICPだった授業である6.001が、どのようになぜ変わったか、という話がこちらのページ( http://wingolog.org/archives/2009/03/24/international-lisp-conference-day-two )にあるのですが、その部分だけ訳してみます。

本文のなかほどの「The "debate" had an interlude, in which Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001.」という所から始まっていますが、そのちょっと先、because〜 から。

because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.

なぜなら、1980年代のエンジニアリングは、90年代中頃や2000年代のそれとは違ったものだったからだ。1980年代には、良きプログラマは思考に時間を掛け、そしてそれが働くべきと考えられる簡潔なコードを作った。コードは金物の近く(close to the metal)で走っていた、Scheme でさえ -- それは全て理解可能だった。例えば抵抗器のように。抵抗器はカラーバーを読むことができ、電力と許容差がわかり、抵抗値がわかれば V=IR それが全ての知るべきことだ。6.001 はエンジニアに、全てがわかっている小さいパーツをどのように扱い、シンプルなテクニックを使ってそれをどのように望むことをする大きなものにまとめ上げるか、を教えるためにあった。

But programming now isn't so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

しかし今のプログラミングは全くそのようなものではなくなっている、とサスマンは言った。こんにちでは、知らない誰かが書いたソフトウェアの、不十分だったり存在しなかったりするman pageと格闘しなければならない(訳注: ここでman pageを悪い例っぽく挙げているのは「The Rise of “Worse is Better”」のMIT/New-Jerseyの対立っぽい感じがある)。使おうとするライブラリに対して、異なった入力に対しコードがどう反応するかを確かめてみて、それがどう働くかを見る「基礎科学」(basic science)をする必要がある。これはファンダメンタルに違うジョブであり、違うコースが必要なのだ。

So the good thing about the new 6.001 was that it was robot-centered -- you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc -- you have to build in robustness to the system, in a different way than the one SICP discusses.

And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.

新しい 6.001 の良いことは、ロボットを中心に据えたことだ -- 小さなロボットを動き回らせるようプログラムしなければならない。ロボットは、理想的な関数の通りに働く抵抗器のようではない(are not like)。車輪はスリップするし、環境は変化する、など -- システムにロバストネスに構築しなければならず、それは、SICPが議論しているのとは違ったやり方だ。

そして、なぜPythonか。それはたぶん、単に既にロボットのインタフェースのためのライブラリが実装されてあったこと、それが全てだ。

ARMの設計(デザイン)

Oral History of Sophie Wilson( http://www.computerhistory.org/collections/catalog/102746190 )から、ARMの設計(デザイン)に関することのメモ

(主に、6502との関係について)

  • ARM以前のほとんどのマシンで6502を使用しており、6502での経験はあった
  • しかし、他のプロセッサを載せるボード(8ビット機時代によくあったもの)で他のプロセッサも使っていた
  • それでも6502が良い、と思っていた。メモリアクセスの帯域を有効に使っている、という所から(他のプロセッサではそこのバランスに問題があった)
  • (ビデオプロセッサが画面表示に間に合ってアクセスするためには、メモリアクセスにある程度の帯域幅が必要であり、その性能をメインプロセッサも生かせるのが、当時の「バランスの良い」デザイン、ということになるのだろう)
  • ARMの設計(デザイン)については、このバスアクセス帯域について以外には、(命令セット等)6502の影響があったというようには読み取れない

ARMの成功要因は何だろうか?(きしもとの私見による分析を含む)

  • 明解で単純な目標の設定、例えば
  • 6502の代替となること
    • (それまでのマシンでは機械語プログラミング等のテクニックの駆使が必要だったことを、高水準言語でできるように)
  • 「IPM PC 互換機の洪水」に対抗すること
  • スローガン「MIPS for the masses」(この「MIPS」は、プロセッサというよりは(それもあるが)性能のことを指している)。当時、他のRISCプロセッサは、ワークステーションを指向していて高価だった
  • 前述の「他のプロセッサを載せるボード」として、まず動くベンチとなるシステムを作ったこと
  • むやみに大きなプロセッサにしなかったこと(最初のプロセッサは25000トランジスタ)もあって、最初からちゃんと動くものを作ったこと。インタビュー中では、ナショセミのNS320xxがいつまでもまともに動かなかったことと比較している

Rubyスクリプト中からアセンブラを呼んでアセンブルして .so 作って動的ロードして実行するサンプル

Rubyスクリプト中からアセンブラを呼んでアセンブルして .so 作って動的ロードして実行するサンプル

Macr055発表の反省

プロシンでいただいたコメントとかに対するメモ

再帰的なマクロの例が欲しい

(言い訳: 「マクロに展開されるマクロ」がちゃんと再帰的に扱えれば、あとはそのマクロが自分自身でも同じことだ、と思っていたのですが)質疑応答のかなり最後のほうで、「再帰(によるループ)ができても、ifelseのようなことができないと、再帰すると止まらなくなるので結局使えない。一方ifelseがあればそれと再帰でいろいろできる」というように回答したのだけども、ifelseを紹介したついでとして何か簡単な「再帰的なマクロ」の例があればよかった(多分それで時間もバランスが取れたかもしれない)

プッシュバックの様子とかが可視化されるデモみたいなので説明が欲しい

(デモ用途に限らず、マクロプログラミング(特にデバッグ)に有効だろうと考えていて、インタフェイスを考えてるところ)

予稿のリファレンスの番号がズレている

後から確認したら、「LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.」が出てないか注意しましょう、というオチでした(参照番号が[?]になったりはしていなかったので油断した)。

「m55_define」は長くてうっとうしい

(設計者の弁: ユーザが任意の名前を使えるよう、処理系組込みの名前は「予約名前空間」のようなイメージで全てプレフィクスを付けている)

「例えば def という名前にしたりはできないのか」ともコメントされたので簡単に検討したところ、現在の仕様では全く透過的にはできないことがわかり、定義ではなくエイリアスの機能があったほうが良いかも、と思ったのでその後で簡単に実装した(抜けとかあるかもしれないのでそのうちチェックしたらリポジトリを更新する予定)。

『ソフトウェア作法』は「さくほう」

と読むのだ、と訳者の先生ご本人がおっしゃっていた、とのコメントが。(両方を掛けている、とどこかで読んだ記憶があるんだけどなぁ……)