トップ 最新 追記

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-08-03 [長年日記]

_ [プロセッサ] スパコン漫遊日記(5)

言っていることに正論がそれなりに含まれているだけに、 「反論のための反論」ふうの文章になっているのが残念だなぁ。

米国の業界が(国際的視点において)自由競争ではない現実の前では 外資関係なく入札なんて説得力がないよ。

まぁ、1000億の使い道がどうというのはあるけどねぇ。 作る方に回すか使う方に回すか。 日本国民の幸せが増える方向につかってくれなきゃですけどね。


2007-08-06 [長年日記]

_ [雑記] she-bang (#!)

日々の破片-プログラムの書き方(4)

「そりゃそうだが、Rubyがシーバン行を参照して、

「しぇばん(ぐ)」とばかり思ってたから最初何いっているのか分からなかった。


2007-08-08 [長年日記]

_ [雑記] 末尾再帰じゃないのに最適化

int fact(int x) {
    return x == 1 ? 1 : fact(x-1) * x;
}

関数型言語なら

int fact(int x){
   fact_iter(x,1);
}
int fact_iter(int x, int pp) {
  return x==1 ? pp : fact_iter(x-1, pp*x);
}

に(プログラマが自発的に)書きかえレ、と言われるケースでんな。

たしかにこの程度は末尾再帰じゃなくても勝手に変換して欲しい。

# 上の書き方のほうが短いのに Stack Overflow するから泣く泣く書き換える golfer 談


2007-08-10 [長年日記]

_ [雑記] 末尾転送の最適化

#include<stdio.h>
int a(int x);
int b(int x);

int main()
{
  printf("%d\n",a(100));
}
int a(int x){
  void *m=malloc(x);
  free(m);
  return x>0 ? b(x-1) : x;
}
int b(int x){
  void *m=malloc(x*2);
  free(m);
  return x>0 ? a(x-1) : x;
}

普通の末尾転送な相互再帰(…にしたのは単にインライン展開を邪魔したかっただけ)。これを x86-64 環境で gcc -O4 (version 3.4.6) すると、以下のコードを吐く。b() だけ掲示すると

b:
.LFB14:
        pushq   %rbx
.LCFI0:
        movl    %edi, %ebx
        leal    (%rbx,%rbx), %edi
        movslq  %edi,%rdi
        call    malloc
        movq    %rax, %rdi
        xorl    %eax, %eax
        call    free
        testl   %ebx, %ebx
        jle     .L2
        leal    -1(%rbx), %edi
        popq    %rbx               ;; スタックを元に戻す
        jmp     a                  ;; call ではなく jmp
        .p2align 4,,7
.L2:
        movl    %ebx, %eax
        popq    %rbx
        ret

一般的に末尾「再帰」でなくても末尾転送 (関数の最後が return func() になっている) なら、最適化を強くすれば call ではなく単純分岐になる。 スタックに保存されている呼び元(リンクアドレス)がそのまま次の関数func()に引き継いで使えるようにスタックの状態を正しておく(&引数を設定など する)必要があるだけ。

なお、x86 じゃなくて SPARC だと delay slot があるので、

b:
   save 〜     ;; スタックフレーム確保
   (中略)
   call a
   restore 〜  ;; スタックフレームを戻す

と、call は相変わらず残って消さないんですがね。 ( call - restore の実行順になることで、もとの呼び元リンクアドレスが期待どおりに保存されるのでこういう芸当が出来る)

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

Before...

_ うんの [あー、ごめんなさい。きっと関係ないです。]

_ ukai [leaf subroutine はスタック確保しない(SPARCならsave/restoreのない)routine ..]

_ うんの [↑おっしゃるとおり。leaf subroutine という言葉は思い出さなかったんですが、スタック確保しない(しなく..]


2007-08-15 [長年日記]

_ [tDiary] trackback spam うざすぎ

しかし tDiary 2.0 系では対処がもうそろそろ限界 (100件制限の対処が必要なところまできた) ので、 近いうちに 2.1 系に移行予定。

# データ移行に失敗しなきゃいいんだけど。

現在は日本語を含まないコメント、TB は全部はじかれます。


2007-08-16 [長年日記]

_ [Golf][OCaml] あなごるTwin primes

OCaml は prime numbers とたいして違わない書き方でとりあえず通した。 記述の上ではもう少し短くできるけど stack overflow しやがるので お手上げ。

OCaml とちょっとだけ違うアルゴリズムで ruby は timeout ぎりぎり。 2000を2e3 に書き換えるだけで完全に timeout してしまう...。

perl の 61B って絶望的に遠すぎ...。なんか必殺の module でもあるんかしら。


2007-08-18 [長年日記]

_ [プロセッサ] 京速スパコン

漫遊日記 日々雑感より

  • ベクター型でなければ解けない問題があるのか?
  • スカラー型で実行するとどのような不都合が生じるのか?
  • 不都合があるなら、その不都合を定量的に示す必要がある。

実行効率の差が如実に出る(解くのに現実的な差が出る)ケースがあるのでしょうが、HPC challenge の4種類でトップを取るのにどうかと言われるとアレ感が漂いますかね。

むしろ、その先の展開をするのに vector 型が必要とかいったほうがよかったんじゃないかとか思いますが。

  • その量的不都合は、商業的に先が無いと思えるベクター型スパコンに巨額の投資をして新たな開発をしなければならないほどのものなのか?

そもそも vector と scalar との予算配分比が不明ではありませんか。 単に Earth Simulator を転がすだけかもしれません。

  • 海外では殆がスカラー型だけで済ませているが、日本にはスカラー型では済ませない問題があるのか?

scalar だけでは勝てないと踏んだ理由があるのでしょうか。 まぁ、新聞に出ていた通りの話だとは思いますが。

  • 「なぜ複合型なのか」から始まって

本当に複合型で実績を出せるのであれば、 旧型スパコンと新型スパコンとの複合でも性能を出す道が出るので、 リプレースのときのネタとして面白いかもしれません。

  • いきなり45nmの使用や、ESの高々40テラからいきなり10ペタへ、などといった大ギャップを越えることの実現可能性の問題

いきなりもなにも、Intel はすでに 45nm を実現している最中のような気がしましたが (45nm の Penryn が今年11月登場予定)。むしろなぜ時期的に 32nm とかではないのかを問うほうが面白いような気がします。

10PFlops は単に2011年ごろの予測性能に毛を生やしただけでしょうし、 peak 性能だけなら詰め込むだけ詰め込めばいいんだから出すことは可能。そのときに Linpack 実行効率 80% とかを出せる構成になっているのかどうかは知りませんが。逆に Linpack 10PFlops にするために必要な量だけ詰め込むんでしょうね。

Earth Simulator もその前から見ればギャップを超えてきているわけで、 それ自体文句を言うほどには感じません。 とはいえ具体的なものが何も出てきてないわけですが。

  • 消費電力や設置面積の問題

設置面積は神戸の新設地に入ることが要件として出されてるでしょうから、逆に消費電力も冷却含めて建屋に収納するのが絶対条件にはなっているんでしょう。

「画期的な省電力」の具体的な何かがないのでそれ以上は全く分からないのがなんともですが。

米国が先んじたために HPC challenge でトップをとれなかったときの保険(マージン)の追加マシン分まで考えられているかどうかは全く分かりませんね。

  • これらのギャップに対するリスクマネジメント」の問題

新しいことをやるんだからリスクは当然あるんでしょうが、 「失敗」したときに何が残るんでしょうね。 ここでΣの反省が生きるといいんですが。

  • 商品としての価値や国際競争力の問題

日本国内での超巨大スパコンの需要は(国が関係しない民間では)ないし (商品の観点では京速の時点で捨てているでしょうに)、国際競争力といっても政治的にアメリカに買って貰える可能性が低い(ほとんどない)以上、どないにもならない気が。

  • システム開発経費

赤字にしても黒字にしても出した時点で方々から文句が出ることが分かりきっているものを表には出せないのでは。


まぁ、なんというか、牧野先生のほうがズバズバ書いているよなぁ。


2007-08-23 [長年日記]

_ [Golf][OCaml] あなごる twin primes

ぱっと見、kozima さんのがどうやって終わるのかが分からない。 実行してみると...

ちょうど狙い目で Stack overflow になるなんてっ! 恐ろしや。

# 最後は in 3<3 じゃなくて ;;3<3 のほうが 1B 短いけど。

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

_ うんの [おぉおぉ、なんて、恐ろしい……。 「旗つつみ」でホールイン・ワン! ええぇ? みたいな。]


2007-08-26 [長年日記]

_ [雑記] VMware の Fedora Core6 を更新したらはまる

とりあえずメモ:VMware 上の Fedora Core 6 で 2.6.22 カーネルを使う場合の注意点について

おお、これで直った。


2007-08-27 [長年日記]

_ [プロセッサ] error inject

メモリエラーのインジェクションツールはまだ〜

一般論として、 メモリインタフェースを CPU chip に持つ AMD Opteron でも無い限り、 North-bridge などにお伺いにいかないといけない (= CPU chip とは別の存在であるブリッジチップの実装に依存する)罠。

FSB へのエラーインジェクション(to North bridge)ならふつーに出来てほしいところですが。


2007-08-30 [長年日記]

_ [プロセッサ] スパコン漫遊日記

あら捜し度が大きくなってきたな。

 これは、本当に驚くべきことで、技術的可能性、電力消費、設置面積、など全てにおいて、閣議決定の内容を完全に覆す多大な変更を強いるものであるからである。

これはそうなのだろうけれど、真っ先には 「この変更で予算が増額されたわけではない」 ことがアレというか。 もともとこれで儲ける気だったのが儲からなくなったのか、あるいはもっと大赤字になるのかは知りませんけど。

技術的にはそれこそ BG/Q そのほか米国は同時期に同程度(orそれ以上)のことをやってこようとしているんだから、理論的には不可能ではないはず。 時期的に間に合うかどうかは知りませんけど。

スカラ部で10PFの場合は65MW+ベクタ部電力で、その他を含めて100MW前後必要と考えられるからである。

これは45nm前提になったおかげで多少は減るとしてもそのままでは (これに冷却設備そのほかで電力は食うので)

 これは完全に原子力発電機1基を必要とする程の電力消費量であり、

ではあるわけですが、最近の報告書でも

国内の大学や研究機関におけるスーパーコンピュータセンターの
受電設備容量は約1.5MW 以下、設置面積は約600 ㎡以下

の要求は変わらず表に出ているので、神戸の建設地の面積が大きく変わらない限りは個々から電力を下げる何らかのからくりはあるはずです。

部品単位の水冷技術を用いてCPU の動作温度を低く保つことにより
消費電力を低減化

という文言だけは出てきますが。 最近のテクノロジは off leak がかなり大きいので、極低温にして leak をおさえれば、冷却コストが上がってもトータルでは減るのかもしれません。 というわけで、直接

こんな馬鹿げた機器や施設がほんとに必要なのか? 

と断定するには早いわけです。依然多くは謎ですけれど。

Primepowerの例では実行性能比50%以下

現在は改善されていると言うのは牧野先生が指摘済のような。 とはいえ PRIMEPOWER は HPC2500 後継を出しておらず TOP500 登録するところがなくて直接確かめる術はないんですがね。 (でも SPECfp のスコアを見比べれば分かるところがあるとかいう)

まぁ、悪い数字を集めれば悪く見せられるのは当然と言う。

<地球シミュレータ(ES)は失敗作>

これはあまりにもひどい。

やり方はさておいても、現実に作ったうえで2年半トップに君臨した実績、 その脅威から米国があれこれやっているというのが常識だと思っていたのだが。 地球シミュレータ以降 SX シリーズは売り上げが上がっているとか聞いた覚えもある。

あと歴史的にはコンピュータが省電力をはっきり言い出したのは ES 以降 であり、「今だから言える」ことを当時に当てはめるのはなんと言うか。

で、日本は ES の成功に胡坐をかいていたのは最大の失敗だろうね。

# あと日本ではスパコンが売れないと言う商業的な理由もあるな。民間だけでは飯食っていけない。ES も稼働率はずいぶん低いらしいし。

あと、ES そのままで次が作れないのは理研や文科省も知っているから、ベクトル単独案になることが一度もなかったんだと思います。