7z なんて拡張子を初めて見たわけだが、そういう圧縮ツールがあるのね。 という点を除けば起動まではほとんど一直線。 network系がダメならあきらめる(debianをあきらめた人談)。
"C:\Program Files\coLinux\colinux-daemon.exe" -t nt "@C:\Program Files\coLinux\default.conf"
起動しないようなら -t nt をはずしてログを見るとよい。
まだ swap の設定すらしていないんだが、 あまり激しいことする気がないから後回し。
# passwd
してもうまくいかない。実際は更新はされているが login 時に参照してもらえないような挙動。 /usr/share/cracklib がおかしいと文句を言っているようなので適当に作り直す。
# echo test > test # /usr/sbin/create_cracklib_dict ./test
自分で使うだけだから cracklib はいらんだろ。
# yum update
# useradd xxxx # passwd xxxx
OCaml が入ってないのはいいとして、zsh が最初から入ってないのはいまどきどうよ。
# yum install zsh # yum install ocaml*
ruby すら。
/etc/sysconfig/keyboard を書き換える。 現時点では : の位置が違っているので vi を立ち上げる気なら要注意。(Shift-; の位置になっているはず)
KEYBOARDTYPE="pc" KEYTABLE="jp106"
/etc/sysconfig/network あたり。
# visudo
# User privilege specification root ALL=(ALL) ALL xxxx ALL=(ALL) ALL <=== 追加
TZ=EST になっている。余り実害はないのだが。 設定可能なのは /usr/share/zoneinfo 以下。
/etc/sysconfig/clock
ん？効果がない。
# cd /etc # rm localtime # ln -s /usr/share/zoneinfo/Japan localtime
(Thanks:Fedora Core を使っていて時計がくるったときの対処)
まずは X を突っ込む。group まとめて。
# yum groupinstall "X Window System"
使えない。firewall が悪さをしてるか？
Todo:
サーバが落ちているのでー。
解答埋め込みだとこんなの。
let b,t,l,r="bottom ","top ","left ","right "let c=b^r^t^l^b^r;;print_string[|r^b^l;c;t^r^c^b|].(read_int()/4)
まじめにやったのはこれだか suiginto さんには遠いな。
let w,a=print_endline,read_int()let rec r u=try r(read_line()::u)with _->u let l=r[]let rec f n y=try String.index(List.nth l y)(Char.chr(48+n)),y with _->f n(y+1)let rec t p i q=let u,v=f(a-i)0in i<a&(p=u&(q>v&()=w"bottom"||()=w"top")||p<u&()=w"right"||()=w"left");t u(i-i/i)v;;t 0a 0
パス。
竹内関数。等価関数に置き換えるのは当然として 6B 足りない。
let rec(!)f=let(%)a b=f a<f b&print_endline b=()in Scanf.scanf"%s %s %s "(fun a b c->a%b||b%c||c%a);!f;;!float_of_string
for i=1to 100do let p u n=i/n*n=i&print_endline u=()in p"FizzBuzz"15||p"Fizz"3||p"Buzz"5||p(string_of_int i)1done
kskさんのヒントに従うとこんな感じだけど、これでもまだトップにはならないな。
for i=1to 100do let(%)n u=i/n*n=i&print_string u=()in not(5%"Buzz")>3%"Fizz"&1%string_of_int i;1%" "done
そのまま埋め込みしただけでまじめに考えてないのでパス。
論外の結果なのでパス。
埋め込み。
print_int[|14;3;32768|].(read_int()mod 7)
まじめ。
let rec g a b=g(a=0&()=print_int b;b mod a)a;;Scanf.scanf"%d %d"g
出題したのにやってない。パス。
99shinh を改造して埋め込み。
トップ取れてるのはこの手のものばっかりだなぁ。 整数だと overflow するので float を使うしかなさげ。
while 1=1do Scanf.scanf"%f %f "(fun a b->let rec(%)x y=x>0.&mod_float y x%x||()=Printf.printf"%.f "(a*.b/.y)in a%b)done
埋め込みなのにまともなやつに勝てない。パス。
let rec(@)l a=List.mem a l||()=print_endline a;a::l@read_line();;[""]@""
let rec(!)s=try!s^read_line()^" "with _->s;;print_string!""
こんなのでは全然届かない...
open String;;while 1=1do let a=read_line()in let b,s=length a,sub a in let rec(@)r i=s(b-i)i=sub r 0i&()=print_endline(s 0(b-i)^r)||r@i-1in let rec(&)r i=try s i 1^r&i+1with _->r@b in""&0done
let rec c s=print_char s.[String.index s(Char.uppercase(input_char stdin))/4*4];c s;;c"1+ 2ABC3DEF4GHI5JKL6MN 7PRS8TUV9WXY*- 0OQZ# "
わずかに届かず。
今日はここまで。
これは凶悪だ。同じアルファベットが2回使えないと言うことは、
のどれも使うことができませんっ！
＃ 解ける気がしません
素で printf って書いてるな。 OCaml ではこれはダメ (unbound value printf と蹴られる)だ。
けど、F# だと Printf モジュールがデフォルトで読まれているのか、Pervasives に引っ越したのかどうか知らないけど、大丈夫なんですね。
いきなり数時間の遅刻が確定なので Lightning 部門賞はやる前からまずダメ。 まぁそもそも、参加することに意義がある程度だけどエントリしてみた。
日本時間で今日19:00〜月曜日19:00。 サラリーマンなので月曜も無理だけどな。
とりあえず参加の証としてサブミットしてあるけれど、 プログラムが完成する気配がない。
午前4時現在、pattern だけ動くようになってる(遅っ！)が、 このまま進めたところで、どうにもならん気がしてるので戦略 練り直す...前に寝る。
当たり前だけど一人はつらいのぅ。
(午前5時：追記) バグはどこだー(涙)
頭が働かなくなったので寝る。
ぎゃぼーん。Stack overflow とな。--> 解決
まだどこかバグってる。所望の画像にならない。 2 loopめ以降 RNA が出てこないし。
＃ あきらめ
日本人で top20 をにぎわしているのは shinh さんと、前回2位のグループ kuma-- (-が増えてるな)と、irori さんなのかな。 すでに RISK=1160658 (prefix length=28) よりどれだけ高いレベルに成ってるのか知るべくもないけれど、がんばれー
(追記am3:50) 順位表の区切り位置が変わったな。で、prefix length=27 が16位以下に押し出されてきてるな。kuma-- がはじき出されちゃってる。がんばれー
まめめもさんの 根底を覆す事実ってなんだろう？ (kuma-- チームで参加してらっしゃるのかな？)
スタートラインに立ってない私がネタ晴らしするよぉ。
OCaml で参戦。ていうか C で参加したら死ぬ。
最初の1日(22:00過ぎから21日5:00くらいまで)はコーディングしながら、たまに気まぐれのprefix をサブミットしてははじかれる状態を繰り返してました。ランダムにサブミットしたところであかんね、と。 で、寝る。
起きたら昼すぎてて、日記のとおりにデバッグ。 このときの間違いは quote() の処理を間違ってたんだが、えらいロスをした。
RNA がいくつか出ていることは確認できていたので、夕方から RNA を書き始めて、へんな文字列が書かれているのを確認。 OCaml の Graphics モジュールは原点が左下なのでそのまま描いて天地逆で読めずにひっくり返す。 文字列を拾ってサブミットしても 3583420 ってあかんやんけ。
このあたりですでにぐだぐだで何度もゲームに逃避する。ダメすぎ。
22日は昼間爆睡していて進捗はほとんどなし。 夜から再開したものの、Stack Overflow|http://www.math.sansu.org/u/diary/?date=20070723#p01 にはまる。末尾再帰になってくれてないっぽいので書き直す。 実際にはそこじゃなくて fill() の実装解釈の問題だったのでこれも書き直し。しばらくしてあきらめて観戦モード。
23日はサラリーマンしていたので会社でスコアボード見てましたー。
稲葉さんの 2/22:00 の「ヒント」は同じような時間帯に得ているっぽいな。 うちのプログラムは RNA を吐いたらそのたびに bitmap に反映させる 方針を採っていた(リストなんか作ってられるか) ので、他がバグっていようが、pattern と RNA 系がいい加減に実装されていれば 1 iteration の 途中までで出てくるのよね、その30Bのヒント。
＃ line の実装が面倒でコレだけ先に (bitmapに反映させずに) draw させてたから見つけるのは早かった。
しかし、稲葉さんのその感想を見る限り、世界の数十人はすでに完成させた上でそこを通過していたわけだねー。
で、なまじコレを見てしまったがために、shinhさんみたいな力技をする気はまったくなくなった。その 30B をsubmitさせてみるも、最初の28Bよりスコアが悪いので、用途が全く違うと言うことだけは分かって、 とりあえずプログラムを全部完成させないとスタートラインにならないっていう結論に到達したのです。最初は自前で描くのかとか揺れてましたが...。
どのみちバグってて作戦以前ですが orz
そしてデバッグしきれずに今に至る。全然あかんやんけ。
line 49/pattern の IF の3文字消費とか言う、見落としがちなヤツは気づいてたんだけど、そもそも普通のプログラマ以前でした orz。 一流の人らの生産量(と正確さ)は全然違うねぇ。
反省：
万が一今後デバッグすることがあったら作ったプログラム公開するかも。 未完成品を公開する気にはなれぬ。
って makerss 使ってたら大抵の人が引っかかりませんかかかっ (「大抵」は言い過ぎかもしれんが)。 緊急対処した。はふぅ。
＃ Virtual Host 機能を使ってるから一見安全と思えるけれど穴があるのよね。
たるさんの新作 に対するツッコミ。
データ量が小さいPC用途では キャッシュの恩恵は絶大である。一度BIOSでキャッシュを切ってマシンを動かしてみればその効力が如何に大きいかは実感していただけると思う。
Intel さんの中身を解析しているわけじゃないので憶測でしかないですが、 Cache off 設定の場合には、単にキャッシュが無い設計よりもかなり 遅くなると思われます。 すでにキャッシュがある前提の設計をしているうえに、 そもそも通常使われることが無い cache off 設定は「矛盾なく動く」 程度に簡素化されているはずですから。
特に、write-back cache の作りに対する cache off 動作ってのは (ストア動作が)もともと相性が悪すぎるので、 互換性のために残しているに過ぎない設定をもって判断するのは危険です。
＃ 下手すると、1命令実行ごとにキャッシュフラッシュして見かけをごまかしてるだけかもしれませんよ :-)
まぁ、x86 はメモリオペレーションが多い(RISCに比べてね)命令セット なので、キャッシュがないことによる痛手がかなり大きいのは事実ですが。
次に、PentiumM発表時に使われた公開資料を見てみよう。この資料によると、CPUの動作時間の内データミスで約20%のマシンタイムが奪われている。
--> http://www.watch.impress.co.jp/pc/docs/2002/0919/kaigai01.htm
この図の割合が何に対する割合かがわからないのが罠なのですが、 少なくとも「ストールしていない」は必ずしも最高の ILP 性能が でているわけではないです。 μarch 上は4並列実行できるはずなのに1並列(!?)実行で あってもストールはしていないので「実行」扱いでしょう。
20% は「本当に何もやることが無い時間」として計上されているとみなす方が 無難で、実行の53%の中にもキャッシュストール要因が含まれている 可能性が高いです。 で終わると根拠が薄弱なので別の資料を見てみます。
安藤さんの報告 による SPARC64 V の動作グラフを同じように読み取ると、
になっている。 PentiumM よりもメモリストールが大きいけれど、 比較する分にはそんなに変な数字ではないでしょう。
このグラフでは、ストールしなかった部分について 1〜4 並列に 分類されているところに注目すべし。 4命令並列commitになっているのは10%もない。 じゃあ、1〜3並列(あるいは0の一部も含まれるだろう)はなぜ？という疑問がわくのだが、図はそれには答えていない。
その理由は謎、ということで。
＃ まぁ、100% hit のキャッシュがあっても2倍に性能があがる可能性はほとんどないですが。
ここで、この性能向上の予想に役立ちそうな情報がある。それは以前AMD64系で２次キャッシュ容量が２倍になったCPUとクロックを10%向上した CPUは同じ性能のプロセッサナンバーとして扱われていたという点だ。つまり、２次キャッシュ容量が２倍になると、性能はクロック10%分向上する事になる。
現実にはありえない「キャッシュ100%ヒット」を考えるとき、 L2 で考えるのではあまり意味が無い。 L2 ないし L3 キャッシュはHitレイテンシが大きく、 コアのリソース(レジスタ等)ではそのレイテンシを隠蔽できない。
とはいえ、現実にはL1キャッシュを256MB にできないし、 そんな大きなキャッシュだとL1キャッシュヒットレイテンシを 隠せないから同じ事だけれど。
キャッシュを生かすためにはキャッシュ以外の性能向上手法と組み合わせて相乗効果を狙うしかないと思う。
結論のこれは正しい。 けれど、いろいろとしがらみがあるのでなかなかね。
BlueLightningはコードサイズの小さいDOS時代のソフトでは爆速だったが、 Wiondows3.1ではそれなりの高速性に効果が縮小してしまった。これは、おそらくDOSとWindows3.1では扱うコードサイズが異なるために、キャッシュの効力に大きな違いが出てしまったためと考えられる。
この理由は絶対に違う。コードサイズではなくデータサイズに理由がある。
BlueLightning も Cx486 も unified (命令／データ共通) のキャッシュだったはずだ。 つまり、扱うデータが大きくなると、そのしわ寄せとして命令コードがキャッシュから追い出されるという副作用が現れる。つまり、 命令キャッシュとしての効果がほとんどなくなることになる。
ご存じの通り、Windows はたとえばフォントデータだけでも (DOSとは比較できないレベルで)でかいので、 ローカルキャッシュはどうでもいいデータによって 簡単に駆逐されてしまう。
現実には命令専用キャッシュなら16KBもあれば大抵は事足りる。 クリティカルとなる実行時間のほとんどはL1I$に十分乗る 小さなコード片で消費されているんだから。 ソフトウェアを書く人(でプロファイラで性能チューニングする人)）なら、 特に意識せずに書いたプログラムでは特定の関数で実行時間の99%を占める、なんてのはしょっちゅう見ているはずだ。
＃ Pen4 のトレースキャッシュがアレなのは...
たまにしか実行されないコードが山のようにあって、それがたまに実行されることでキャッシュが汚れるので、ある程度の容量を超える命令キャッシュは性能が(すでに)頭打ちである。 命令フェッチ系は、それよりも分岐予測の方が頭がいたかろう。
それに較べると、データ方面はまだまだ細かい改善はあるはずなのだが。
ちうわけで、ソフトの肥大化はどうでもいいっちう話。(話が発散
ノード数が京速計算機レベルの場合は今でもベクトル機のコストパフォーマンスはPCより良いと考えているわけである。その理由は、PCはスケ−ラビリティーが極端に悪いので、京速計算機レベルでは実はコストパフォーマンスが極端に低下してしまうからである。 (当サイトの論理を完膚無きまでに叩きのめす方針ならば、PCでもスケーラビリティーが成り立つという論理を構築する必要性がある。そうでない論理構築と言うことは、つまり守備的ということだろう。)
牧野先生の仰っていることは、スパコンにおいてノード間接合 (ネットワーク)設計の重要性はあまり否定してなくって、 その際にプロセッサはよほどの性能が出ない限り安いx86でいい (cost performance を悪くするプロセッサ独自開発の意味が無い) という趣旨と思われます。 さらにいえば、PCの5倍程度の値段設定でそういうネットワークを 調達できると(数万ノードで出来るのかどうかの根拠は示されてないけど) いっているんだと思います。
つまり、ノード間通信が本当に避けて通れないアプリケーション (牧野先生は工夫次第でほとんど回避できる派だと思いますが)では、 スパコンの意味がでてくるけど、 SETI@Home みたいにノード間接合にほとんど意味の無いプロジェクトでは 、もはや鎮座ましますスパコンである意味はなくなっているわけで (単純にマシン台数だけでスケールする)、 ターゲットアプリに依存する話ではあります。
ネットワークボトルネックは PC の拡張スロットにそういう専用ハード をのっければいいのか？というほど現実は甘くないけど。 牧野先生がこのへんで 書いてらっしゃいますね。
実際には設置面積(京速は神戸の新建屋にいくらかけるんでしたっけ?)や 運用コスト…おおむね電力(発電所がいるというのが冗談でない世界) の問題のほうが大きい気がするんですがね。