トップ 最新 追記

U-memo

2006|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|08|
2009|08|10|
2010|02|03|
2011|11|12|
2012|04|
2016|02|
All= / Today= / Yesterday=

2007-09-01

_ [Golf] ゴル会

引き篭もりでもいいですか?

本日のツッコミ(全1件) [ツッコミを入れる]

_ shinh [もちろん! ぜひぜひ。]


2007-09-05

_ [雑記] 年齢攻撃

「人生の半分くらいは昭和を生きてませんか」

今年は平成何年でしたっけ orz

(補足) 今年は平成19年らしいので平成のほうが長いようです。だから何?


2007-09-08

_ [雑記] ゴ会

午後5時から6時の間に出現の予定。


2007-09-12

_ [雑記] ゴ会の反省

  • タバコ吸う人がいなかったよ!
  • 二つ名をかたるひとがいたよ!

ヒキコモリデゴメンナサイ

_ [プロセッサ] マシン語を知らない子ども達とその追記

マシンを構成する論理要素は全て論理回路なので、論理回路を理解しないとコンピュータの動作原理を理解していないことになります。

そんなあほな。原理の理解程度に論理素子の知識は不要という。 そんなことを言い出したら今なら MOSトランジスタの知識が必要になりませんか。(昔ならリレーとか)

NOT や XOR ゲートを知っていたって1命令をメモリから取ってくることすら出来ませんぜ。加算器を知っていたって演算部分だけしか作れない。Z80 の 4state のうちの1個(の部分集合)でしかない。

最低でも、論理回路だけで桁上がりをサポートした加算機を作れる程度の理解はしておいて欲しいと思います。

この理解(だけ)ではコンピュータは作れません。

コンピュータの中で加算器なんてのは飾りです。

ストアードプログラム方式というかノイマンアーキテクチャというか、 メモリ(というか入出力)が登場しないコンピュータは今の主流には 存在しないんだから、その理解の方が先だろうとかいう感じ。

また、ブクマコメント中で80386についての理解があまりにも得られなくて驚きました。

386の構造を知るべき、と思うのはそれが現在のマルチタスクOSの根幹部分を成しているからです。

それよりもはるか昔のメインフレームで既に。 Z80 と 386 の差に言及するならそもそも以下略。

z80 と 386 の違いって特権系とか一種の仮想化(MMUとか)よね。個人(user level) では違いはほとんど意識する必要が無いとか思うんですが。OS kernel や device driver に手を出す話をするなら別だけど。 で、命令セットだけを知ってもマルチタスク OS を作れないし、Z80 でも頑張れば低レベルなマルチタスクなら実現不可能では無いとか思うわけで。

個人が使う上でもっとも普及しているのが x86 である点において 386 を避けて通る選択はないのかもしれませんが、 歴史的には 386 の30年位前(適当)にすでにその全てをメインフレーム(370) が実現していたことへの何かはあっても良いんじゃないかとか。 (386 は所詮その猿真似とまでいうと言い過ぎでしょうが。)

# 360 は知らないので言及できないの。

や、shi3z さんの 386 関連のの記述部分は宗教でしかないですよという話。

# 実際に汚いよ x86 の命令セット(370 よりもな!)。

## SPARC だって汚いけどなっ!

これほど並列処理が重用視された時代はなかったからです。並列処理や高負荷分散をやるならマシン語の知識があるに超したことはありません。

並列処理なら、それよりは SMP の原理とかのほうが重要で、機械語なんて飾りです。たとえば SMP マシンで cas 命令使うと何が起こるのかなんてのはマシン語の知識レベルでは語れない。

って釣られ過ぎ?

本日のツッコミ(全7件) [ツッコミを入れる]

Before...

_ 加算器(代弁うんの) [> 加算器なんてのは飾りです。 ふぬー、なにをー!! 加算器がなければ、アドレス計算だってできないくせに!! も..]

_ ukai [>アドレス計算だってできないくせに そんなことはないよ。 ROM にほげほげしておけば加算器の代用になるとかね。..]

_ うんの [あーあー、泣かしたー。]


2007-09-13

_ [プロセッサ] マシン語を知らない子ども達のコメント

Shiroさん:

それと、「低レベルを知らなきゃならないって言い出すなら半導体、量子力学…ってなってきりがないんじゃ」という反応が見られたが、そういう人こそ論理回路と機械語を学ぶべき。論理回路のレベルで非常に強固な抽象化の壁があり、その下の層とはかなり独立性が高い (下層は真空管でもリレーでもパラメトロンでも歯車でも構わない)。その独立性の高さが、これだけ巨大なソフトウェアがその上に乗っかることを可能にしたわけだから。

なんで「論理回路」で切れるんだろうか。

NOT や XOR (ゲート)なんてのは飾り(低レイヤ過ぎる)で、むしろ register (=flip-flop) あたりが抽象化の切れ目のはず。順序回路ならば論旨として納得いくけど。(int が 32bit register とか見えてるからね!)

CPU の回路構成のほとんどメモリとレジスタとセレクタ(と配線)であって、セレクタの条件指定に組み合わせ回路(つまり NOT や XOR)が出てくる程度。

セレクタなんて今時は transmission gate がほとんどで AND-OR(=NAND-NAND) のような理解である必要はない(セレクタという抽象化で十分)し、flip-flop が(本質的には) NAND のフィードバック回路で出来ているとか RS-FF やら D-FF やら JK-FF やらの知識も不要だろうと思う(レジスタという抽象化で十分)。

セレクタの条件指定こそ組み合わせ回路だけれど、それにしたってソフトの if 文の条件式とやってることは同じ。論理ゲートしかないから論理ゲートを使っているだけに過ぎない。プログラマの基礎知識なんだから論理ゲートを学んだところで得るところはほとんど無い。

演算器(adder)だって基本は 1 bit full-adder とはいえ、32bit/64bitの加算機はダイナミックロジック(ドミノ回路)でできていたりして論理回路の知識で通用しないんだけど、こんなの知らなきゃならんとかマジか?(加算器があるで十分だろう)

というわけで(組み合わせ)論理回路なんてのは飾りなんですよ。

ハード的に言えば RTL がソフトから見える最下層だろうしそれで十分すぎる。ゲートレベル(or それ以下)の知識は(ハード設計者には必須だが)ソフト屋に必要とは全く思えない。

それとももはや「論理回路」= Verilog or VHDL = RTL なんですかね(泣

というわけでVHDLゴルフすると良いと思うよ! (設計にもRTLの勉強にも役に立ちません)

_ [雑記] odz buffer - どこまで必要か のコメント

shiro 『私は元のshi3zさんのエントリの「機械語を理解する」は「ストアドプログラムアーキテクチャ+MMU+特権管理+コンテキストスイッチングのメカニズムを理解する」

それは機械語ではなくて ISA (命令セットアーキテクチャ) を理解すると書かないとだれにも通じない気がしますー。 で、それなら参考文献は IA-32 インテル アーキテクチャー・ソフトウェア・デベロッパーズ・マニュアル だな。

_ [雑記] たわごと

CPU 設計者はアプリケーションやコンパイラの挙動まで調べて、頻出するクリティカルパスの最適化を CPU ハードに落とし込んでたんだからねっ! という点で論理回路はどうでも良いから CPU の構造というか性質というかは知ってほしいというか旨味を引き出してほしいとか思ったりする。

本日のツッコミ(全11件) [ツッコミを入れる]

Before...

_ うんの [しまつた。ググったら一発だった。 「クヌースのような極めて優秀な数学者でさえ、「奇怪」語(訳註1)を教えているのだ..]

_ ukai [shiroさん: >不正アクセス マイクロコードが見えることはないですね。というのと同じで論理回路が見えることもな..]

_ shiro [ふむ。確かにISAより下については、たとえバグとわかっててもソフト屋さんは手がでないので、バグ対応で降りる下限ってこ..]


2007-09-15

_ [プロセッサ] 京速(ペタコン)のプレスリリース

正直なところ、試作評価期間(1年)が短いよなーと思う。 45nm プロセステクノロジの進捗は全然知らないけど。

研究開発の成果を明確にすることが求められる。くどいが、次世代機を開発して終わりではない。ステークホルダーである国民に、どう説明するかだ。貴重な税金をまさか「πの計算に使っています」とは言えないだろうから。

πでもちゃんと説明できれば良いと思うんだけど、 プレスリリースを見る限り、現状そこまですらほど遠い気はしますね。

_ [プロセッサ] 次世代スパコンは2010年に10PFを達成できるのか?

「可能である」といわれても、「どうやって?」

論旨に乗れば、ラック内の密度をあげるしかないという結論しかなさそうですね。BG/L とかはそういう方向じゃありませんでしたっけ。

M9000の1ラック32CPUは、

32CPU→192CPU/ラック になれば 6倍になるわけで、密度をあげたぶんUP性能を落とす羽目になったとしても単純に 5PF あたりは行ける計算になって、不可能と断じるには早い気がします。まぁ、何も語られていないので想像するしかありませんが。

そもそも SparcEnterprise はHPCではなくビジネス系サーバなので密度の考え方はスパコンと違って当然ですし(たとえば何百ノード以上をつなげることなんて考えられてないでしょう)。

ところで計算上は誤差かもしれませんが、このスパコン漫遊日記の計算は理論性能が(ですら?)10PF がアレと言っているけど、Linpack 10PF が目標設定だから、13PF くらいが理論peakでないといけないというのは要注意。

現在米国では10PFといったプランは、BG/Qを除いて、聞こえてこない。

牧野先生のところ

NSF のペタスケールの話がリリースされました。 HPC wire の報道によると
   * 2011 年完成
   * IBM Bluewater を イリノイ大学に
   * ピーク性能は 10 ペタフロップスらしい
とのこと。これは、CMU-Intel の 40Pflops、 UCSD-IBM(BG/Q) 20Pflops、
U Tennessee/ONRL-Cray 20Pflops を押しのけて採択されたもの

とか書いてあったりするわけなんですが。だから牧野先生に突っ込まれる羽目になるんでは、とか思った。

_ [雑記] プログラマの教養あるいは常識

結論: だいたいさあ、プログラマのくせに論理回路も知らねぇとなると、このジョークすらいちいち説明してやらにゃならんわけ?

「プログラマはシェークスピアを知っている」ことを暗黙のうちに仮定するのはいただけないとか思いました :-)

# すでに同案あり

(ネタばれ?) 分からん人はWikipediaの説明 へ。

本日のツッコミ(全2件) [ツッコミを入れる]

_ うんの [「わたしは IEEE 準拠の IEC logic symbol しか読めません」という言い訳を考えたのですが、野暮な..]

_ ukai [ドイツ方式かな。名前忘れた。 __ | \ -+--| -+--| |_/ こんなやつ。]


2007-09-17

_ [プロセッサ] 順不同に見せない努力

記事内容の言わんとするところにケチを付ける気は無いのだけれど、

並列に実行しちゃうことをOut of Order (OOO)実行とか言っちゃうのだけど、(厳密に言えばOOOは並列に実行することを含意していない。実行順が機械語の順番と違うことを言っているだけ)、それによって、ある命令列によって引き起こされる効果を、他の人が観察すると機械語と違う順序で観察されるのである。

それ違うし。 まず「並列に実行すること」は業界的には「スーパースカラ」と言っておいた方が良いと思うけれどさておいて。

OoOE でも、あくまでもプロセッサはプログラムオーダを保証しているので、少なくとも観測できる形式としては順序を「保証」しています。 と既にOut of Order (アウトオブオーダー)実行って・・・ で突っ込まれてますな。

OoOE で行っていることは、

  • 順序を引っくり返したところで結果に影響が無い

ときに順不同に(Out-of-order)実行する(Execution)わけです。 演算器の個数が限られているので、演算器の利用効率をあげて性能向上を図っているわけなのですが。そういうわけなので、

このとき、いつキャッシュミスが発生し(それはμOPの実行を数百命令浪費する)、いつキャッシュヒットするかはプロセッサの状態によるので、後ろの命令が先の命令を追い越して先に実行するというのは通常に発生している。上の命令列のどれが最初に終了するかは、誰もわからないのである。(すげーな、これは)

これは前半は正しいが後ろは嘘。 引っくり返して「実行」しているかもしれないけれど、「終了」は順番通りに行われる。IntelやAMDの用語にあわせれば、retire は順番通りになる。 AMD は retire すら順不同にしていた時期はあるけれど(今もかも)、それを観測出来る術は無いはず。(観測できる範囲内では順番通り)

例えば、あるアドレス(X) にAレジスタの値を代入し、次のアドレス(X+1)にBレジスタの値を代入するなんていう命令列では、Aレジスタの値が代入されてからBレジスタの値が代入されるなどという順序は、プロセッサは保証していないのである。(ああああ〜)

これは順序がきちんと保証されている。 Intel x86 でも(一部の命令に例外があるが)。

形式的に

store %a -> [X]
store %b -> [X+1]

という順序で命令が書かれていてこれらを実行したとき、 お隣のプロセッサで X+1 の中身が %b になっていて X の中身が まだ %a になっていないように処理されている、 と観測できてしまうとすれば、 これは一般的な SMP システムにおけるメモリオーダリング (Total Store Ordering などと呼ばれるもの) に違反している。

なお、問題をややこしくするのはこの順序を「観測する」手段であって、 Intel がプロセッサオーダリングと呼んでいるメモリオーダリング規則では、load の順は「推論」によって順不同に動く可能性があるのが話をややこしくする。参考: IA-32 インテル召アーキテクチャー・ソフトウェア・デベロッパーズ・マニュアル、下巻: システム・プログラミング・ガイド の7章。

ちゃんと知っていないと。ストアの順序を観測しようとおもって組んだプログラムが 意図通りに動いてくれない罠に陥る。 こういったメモリオーダリングは、 別に最新の OoOE でもスーパースカラでもない昔のパイプライン実行の CPU であっても、マルチプロセッサシステムになれば回避して通れない難しい話です。 とりあえず、Binary Hacks の Hack#94 でも読むと良いんだけれど、 余計混乱すること請け合い。

そういうわけなので、

こーゆー実行の挙動は外部から、観測するしかないのである。

そういう CPU の頑張っている様は、性能の変化という間接的な手段以外での直接的な観測はできないのだー。全ては ISA (Instruction Set Architecture) という壁に阻まれるのです。


2007-09-19

_ [プロセッサ] GRAPE-DRと次世代スパコン

相変わらず論旨グダグダやなー。

殆ど不可能といってよいと思う。

思い込みで論じてもなー。

いやわしも Linpack は力技が通用するからともかくとして、 HPC challenge 4冠は大変だとは思うんだがね。

コンピュータ技術としてはTILE64、Polarisなどの正統派メニーコア方式の方が遥かに本質的であり、安心安全有用である。

Intel 80コアは(現時点では)命令領域がわずかしかない上に 書き換え手段がない(汎用には明らかに不足)んだけど、 それが安心安全有用とは。

本質的かどうかは知らんけど。もとい、スパコンにおいては本質的かもしれないけど、それこそ GRAPE がずっとやってきたことちゃうんかいな。

# Tile64 も商売としては成り立つのかねぇ?

拡張スロットに刺さる方が個人でも 気軽に使えるという点でおもしろいと思うんだけど。 自己完結かどうかなんてどーでもいいと思うんだな。 むしろサポートの悪い OS/middle 環境で作業したくないとか。

要するに海外では、GRAPE-DRに関する報道数は少なく、また位置付けとしても天文学という特殊分野での特殊計算用のアクセラレータの後継機と認識されているに過ぎないということは頭の隅に入れておいて良いかもしれない。

で何がいいたいのかね。 宣伝が足りないとか?

結局「日本はダメだ」「IBM(or米国)マンセー」 という電波がゆんゆん出てるんだけどー

あとね、

(2)ブロック内共有メモリ方式での、性能維持は?

このセクションは素人丸出しすぎますよ。


2007-09-22

_ [雑記] ジェイミー・オリバーのマシン語革命

わかってない。(なぜか断定

食材にこだわる一方で386だけを勧めるのは 「マクドナルドだけ食っておけばいいんだよ、売れてるんだから」 と言っている事に気づかないのかなぁ、とか思った。

最高のフォアグラを探すよりも、 大根の桂むきができるほうがいいんじゃねぇの?とか。 料理の仕方を知らないんじゃ料理になりませんぜ。

彼にとって何が暗黙の前提なんだろうか。 「食材だけ良ければ他はどうでもいい」と思われる書き方を していることにいつになったら気づくのだろうか。

そのとき、最後の最後で「仕様にありません」「Java処理系がバグっています」では困るのだ。

...

あらゆる問題に対処する必要がある。

で、そのときにマシン語が必須というのに飛躍がある、と思うわけで。 問題を局所化、顕在化させる、あるいは問題に対処するために、 低レベルの知識は便利なのは肯定するけれど。 たとえ処理系のバグとわかったところでどのみちベンダにお伺いを立てるしかないのであれば、 処理系のバグを詳細に突き止めるよりも、 問題を局所化できた時点で、そこから問題回避する(例えばマシン語に手を出さずとも、同じことを別の手段で実現すればいいわけだ)ほうが優先されるのが現場というか。

必要なのはマシン語じゃなくて問題対応能力では。 その助力としてマシン語の知識とかがあると便利であるに過ぎない。

# (補足)局所化できずに ad-hoc な回避をするのは論外。それが回避になっていることが立証できることは必要だから。

もちろんそこに論理回路はいらんだろ。

それは量子力学を含む自然科学の研究対象が自然物の解析という方向に向いており、根本的にはどれが正しいのか誰にもわからないのに対し、論理回路やマシン語などによって構成される工学は、人間が自ら論理を積み上げていったものであるという違いがある。

これはひどいとおもう。工学を冒涜してるんかしら。

工学のほうがよほど自然物の解析をしているし、 むしろ自ら論理を積み上げるのは数学というか。 論理は要するにブール代数なんだし。

最先端の世界というのは常に実装技術の限界との戦いで、マシンの性能を限界まで引き出すにはその知識が不可欠なのだ。

そこでもちいるべき「その知識」はマシン語じゃなくて ISA だから。

単に抽象化されているから、という理由でその内部構造を知ろうともしないという姿勢では競争に勝てないと思う。

さいしょから「姿勢」の問題「だけ」にしておけば反論を食らわずにすんだんじゃなかろうかー。 だとしても(ISAではない)「386マシン語」は相対的に低いよなぁ。

...釣られるのはもうやめよう。

_ [雑記] マシン語より大切なこと

マシン語(アセンブリ言語)なんて所詮、 (制約がやたら多い)プログラミング言語の一方言でしかないし、 結局、同様またはそれ以上に制約条件がいっぱい出てくる code golf ができるなら、 マシン語なんてちょろいと思うのよね。

だから

そういう基礎体力を養う、つぶしの効くソフト屋になるための方法

あなごるするといいと思うよ!


2007-09-26

_ [雑記] アルゴリズム以外の最適化

ループの内側が最もたくさん実行されるからそこを最適化するのは一般常識だと思っていましたが、違ったのでしょうか。

結果的にそうなるのは多いでしょうが、いまどきは 「まずプロファイラかけろよ」という話のような気がします。

(突っ込まれたようなので補足 9/27) Intel VTune(tm) はふつーに知ってますが使ったことはありません。文脈からは VTune 使うのが一般常識ではなく「ループの内側最適化万歳」:というように読めました。

その最内ループが本当に実行時間にクリティカルならば、 そこを最適化すればよいけど、 見当外れの場合もあるわけです。

コードの20%の部分が80%の実行時間を担当する

これは今でもよほど考えて作らないこうなるわけですが、 「最もたくさん実行される」「もっとも時間食っている」 のがどこなのか、想定している場所で本当に正しいのかどうか 確認するのが最初、ですね。 どーでもいいと思っていたところで時間を食っていることもままあるわけで。

あー、あと、 最内ループは unrolling せよ、とかいう人はいるかもしれない (これは必ずしも正しくはないけれど)。したがって、

 1.  分岐の数を減らせ
 2. ループを短くしろ

短いループは展開したほうがいい、が追加されたりする。

-O5 したら unrolling するだろうからある意味「-O5 せよ」は 正しいかもしれない。

「ループを短くする」ことそのものが本質ではなくって、 (動的)実行命令数を減らすのに直球ど真ん中だという話なんだから。

#命令数が多少減ったって実行時間が減るとは限らないから過激な一般化は難しいけれど。

r=0;
for(i=1;i<n;i++)r+=i;
r=(n+1)*n/2;

しかしこれは最適化の罠でもある。nが1の場合、計算量は乗除算が入っているからどっちが速いかはわからない。

後者は整数の掛け算は 5clock 程度、/2 はシフトだから 1clock、足し算とあわせても 10clock でお釣りがくる。

前者は、初期化で1clock(rとiは独立変数なので並列実行可能)、 1 を足すのに 1clock、i<n の条件判定が謎(っていうかバグってませんか)だけど、 (i<=n だとして) n = 1 で常に呼ばれたとしても、この条件判定は true, false 交互に変わるわけです。 最近のプロセッサは規則性があれば当ててくれますから予測100%正解とかして 1clock 実行になって高速ですが(!)、 教科書的な 2bit predict なら 1/2 の確率で分岐予測が外れるので、 パイプラインフラッシュのペナルティをくらって(10clockとか)、 後者よりも遅くなるとかいう罠。

中途半端な知識はむしろ足を引っ張るとかいう。

  • できるだけキャッシュに乗るように、データの局所性を意識
  • 分岐予測ミスができるだけおきないように

そんなもん?あれ、命令セット関係ないな。いや他にもあるはず。

マイクロアーキテクチャの領域ですね。

あとまぁ、Pentium 4 の分岐予測ミスのペナルティがでかすぎ。ランダムなデータと逆順に整列されたデータに対して bubble sort をすると逆順にソートされたデータのほうが倍以上速いとか、なんだそれ。

条件 move のほうが高速だろうなぁ、これは。 おお、これはマシン語の領域かも。(μarchの領域でもあるけれど)