つっても、非公開のを別につけているわけではない。
Copyright 1999- Jun Makino
2024/12 2024/11 2024/10 2024/09 2024/08 2024/07 2024/06 2024/05 2024/04 2024/03 2024/02 2024/01 ---- もっと昔一番足りないというかほぼ存在してないのは、「そもそもどういうものを作るのか」を決められる人=アーキテクト。
何を作るのかを決められれば仕様に落とせる人というのはまあまだいる。老人しかいないのではという問題はある。
仕様からシミュレータとか RTLとかおこせる人もまあまだいる。老人しかいないのではという問題はある。
RTL から GDS へはどうせもう最先端は TSMC だと Alchip, GUC, Broadcom あたりしかできない。
で、一体どのレベルの人材育成するの?という。
対応遅れてる皆様すみません。
私にとっては最初に研究内容について深い議論をした外国人研究者であり、また 20年以上にわたって使わせてもらった NBODYx の開発者であり、何度か IoA に長期滞在した時のホストであり、とにかくもっともお世話になった研究者の一人である。
また、多分 1970年代から彼がコード公開してドキュメントも書いて磁気 テープコピーすれば誰でも利用可能であったことが、天文シミュレーション業界で のコード公開の伝統の起源といえる。私(というか杉本先生)も稲垣さんから磁 気テープ送ってもらったはず。
85年に日本にきて、須藤さんのとこでセミナーしたのに私も参加して、 大型計算機センターでNBODY2 を2人でベクトル化した。自力でNBODY5 をベク トル化したあとだったので、1日で大体すんだような記憶が。
同時期の Cray-1 は完全な load-store 型、CDC Star/Cyber203/205 は完全な memory-to-memory 型アーキテクチャなんだけど、AP-120B はどっちでもなくて、1ポートのメモと 1R1W のレジスタファイル2つが命令から直接見える(演算器の入出力に指定できる)ようになっている。
GRAPE-DR では 2R1W だったんだけど、そうではなくてMN-Core 並みの 1R1W x 2 なのがなんかすごい。
乗算器と加算器でレイテンシが違い、この時期なので FMA ではない。で、命令はサイクル毎に投入される。例えば乗算結果をメモリに書き込むには、乗算命令からレイテンシの数後に「乗算器の結果レジスタの値をメモリに書く」という命令をだす必要がある。
プログラム自体は、簡単な整数CPU が実行して、これが64ビットの命令語に 命令実行自体の制御部分(整数レジスタのアクセスやジャンプ)+浮動小数点ユニットの命令という感じ。
バイポーラで6MHz で動く機械なのでジャンプとかも遅延スロットとか考えなくてもよかった感じ。
FMUL 3、 FADD 2 のレイテンシがプログラマーにみえてて演算命令に対応するストア命令をそこで必ず発行してね、はなかなか厳しいというか、GRAPE-DR ではそれはさすがにちょっとと思って命令語としては destination も同じワード内で発行する(SIMDなのでずらすコストは小さい)んだけど、アセンブラレベルでずらしてねと、、、
で、メモリ、2枚のレジスタファイルもアセンブラから丸見え。レイテンシ変わったらアセンブラ全体動かなくなるのはちょっとつらいかも。
Array processor なんだけど命令セット的にはベクトル命令はなくて、ループで処理されるのもちょっと面白い。まあこれはベクトル命令むけのシーケンサの中身がアプリケーションプログラマにみえるというほうが正しいかも。
「原子力は、(中略)他電源と遜色ないコスト水準で変動も少ない。」って書いてあるけど、これまともな根拠がある話ではないので。
最新の 発電コスト検証に関するとりまとめ（案) ではkWh あたり太陽光10円、原発 12.6円とか書いてあるけど、これは建設費用が 100万kW あたり4580億円という最近の原発のコストの 1/3-1/4 くらいが仮定されてる。
まあそもそも再処理が驚異的な低コストでできると仮定されてる時点で夢物語なんだけど、建設費用も非現実的な仮定をした上で他電源と遜色ないコスト水準といわれてもみたいな。
こういう、空想的な数値を政策立案の根拠にしちゃうことが正当化される現状が、政策の非合理性を招いている、というか、原子力政策はそういう非合理性によってるんだけど、それが他のところにも及んでいるのが経済政策が失敗するわりと大きな要因だと思う。
アーキテクチャの資料 あんまりまともに読んだことなかったんだけど、これ結構アレというか、まあこうなるよね的。
FPS-164 の Fortran compiler の論文というのはあるんだけど、120B そんなの動かないよね(制御部分のアーキテクチャが全然違う)？全部アセンブラでNBODY1 相当書いた？今度聞いてみよ。
私の tw が引用されてて、「理屈はわかるのだが、それはロジックダイの 発熱が穏当なものの場合だろう」とコメントされてるのが、うん、なんという か、私の主張へのコメントにありがちなパターンですね、、、
実際問題としてロジックを上に置くなら冷却の問題はないし、高いロジックダイにDRAM に電源供給するTSV あけるより安いDRAM ダイにロジックの電源供給のための TSV のほうが、、、というところもある。
もちろん、この場合には ダイ外へのシグナルがDRAM積層を通るので、その辺はちょっと面倒。
ロジック下の場合はDRAM 配線層の熱抵抗が問題だけど、チッブ上で分散メモリアーキテクチャになると、面積あたりの演算密度をあげることにあんまり意味がなくなって、むしろDRAM 容量にみあった性能があればよい、となるので、半導体プロセスどうするかから変わってくる。
これは、今の CPU と GPU で、面積あたりの発熱はCPU のほうがずっと大きいのが、さらに極端になっていくということである。これも、共有メモリ並列計算機から分散メモリ並列計算機への移行と同じで、小さく作る必要がなくなるということ。
前に使ったのは記録によると この辺。
今時なら Ruby や Python に expect モジュールがあるのでそっちのほうが使いやすいかも。
というわけで1月である。
年末なにもしないでゴロゴロしてたらちょっと体調改善した。体力というかまあ原因は明確なのでぼちぼち。
自分もだが他人も、、、記録というものは重要であるみたいな。