2010-06-21
■Scala が腹立たしい
Scalaを使って色々書こうとしています。が、使えば使うほど使いにくい言語だなあと思っているのでここに書きます。大きく二点あります。
Javaとの共存関係が不明
そもそも、JVMの上で動くからお互いのクラスが使いやすいよってのが半分売りだったんじゃないかと思うんですが、使ってみると全然そんなこと無いなあと。多くのクラスを、わざわざJavaと独立に実装していてインタフェースの互換性のかけらも無い。そのくせ、名前だけは同じだったりするので、本当に使っていて頭が痛いです。Listって言ったらjava.util.Listだと思うわけですが、scala.Listって何それと。JavaのBigIntegerの代わりにBigInt作ってみたり、もう何やりたいのかわかりません。そのくせ、StringだけはJavaと共通なんだとか聞くと、しっちゃかめっちゃかだと思います。
手続き型(C)系の悪い文法のみを引きずっている
普通、関数型言語ってのはa bと書いたら値bに対して関数aを適用するじゃないですか。Lispだと(a b)って書きますけど、まあそうですよね。それに対してCをはじめとする言語の多くは、a(b)ですよね。
手続き型の書きかたって、オブジェクト指向とかなら悪くはないんですけど、関数の適用結果が関数だったりすると破綻するんですよ。(((a b) c) d)はまだわかるけど、a(b)(c)(d)って何ですかこれ。結合順序もわからない感じに。
思ったこと
Scalaがこんなぐだぐだになってるのは、Javaって強敵がいたからかもしれませんけど、言語設計を最初からやったのが間違いだったんじゃないかと思います。全体的に見て、明らかにJavaと別言語なんであれば、マルチプラットフォームで動くということを含めてもわざわざScalaを使うメリットは少ないと感じています。Scalaを使いこなすのに必要な勉強時間は、Ocamlを勉強するのに必要な時間と大きく変わるとは思えません。
結局、僕がほしかったのは関数型が簡単に書けるJavaだったみたいです。Closure作るのにAbstract Classのnewとかやるのが嫌だったんです。Java 7が出たらきっと解決されるものだと思ってます。それまで愚痴を言いながらScalaを使うこともあるかもしれませんが、Scalaのうわさを聞いて感じた胸の高鳴りはもう戻ってきません。
2010-06-06
■生存報告と、その他もろもろ
一応生きているってことで。
Google CodeJam参加
今年もRound2で敗退。俺・・・本当に過去にWorld Final行けたんだよね？今回の敗退の主要因は、Aにはまってしまったこと。A-smallに1時間半かけるとか。しかもA-largeでミスするとか！白状すると、実はA-smallもバグ有りコードで提出しているので、smallも本当は通ってません。
関数の最小値を求める
あるイテレータブルな何か(配列・リスト・コンテナ等)があって、各要素を受理する関数があったとしましょう。このとき、関数の返り値の最小値を求めたい。手続き型っぽく書くとこんな感じ。
int function(T t); Container<T> container; int min = Integer.MAX_VALUE; for(T t: container){ value = func(t) if(min < value) min = value; }
あるいは、関数型っぽく書くとこんな感じ。
min (map func container);
問題は、上の手続き型のソースの中の、Integer.MAX_VALUEってのが曲者で、左辺がintだからInteger.MAX_VALUEだけど、longだとLong.MAX_VALUEになるし、BigIntegerだとどうにもならなかったりする。
今回の場合、大きめの値をminに代入してたものの、もっと大きくしておかなきゃいけなかったらしく大失敗。
解決案1 最初の項目を特別扱いする
containerの第一要素の結果をminに格納することで、変なminの値にならないようにする。
int min = func(container.get(0)); for(T t: container){ value = func(t) if(min < value) min = value; }
問題点: 第一要素が取り出しにくいときには書きにくい。
解決案2
minを特別な値-1にする。
int min = -1; for(T t: container){ value = func(t) if(min == -1 || min < value) min = value; }
問題点: ifの中が読みにくくなってよろしくない。
解決案3
class MinimumObject<V>{ boolean set_min; public V min; public MinimumObject(){} public int set(V v){ if(!set_min || min.compare(v) > 0) min = v; } } MinimumObject<Integer> min = new MinimumObject<Integer>(); for(T t: container){ min.set(value = func(t));
ということで、いまだに有効な改善策が見つかっておりません。
PC環境とか
ところで世間ではiPadとやらが発売され大人気な様ですが、みんなが何を期待してあれを買っているのか、いまだにわからないです。世間がほしがるものを作る職務についているのに、世間の需要がわからないのはよくないことなのだと思いますが、自分の生活があのデバイスによって変わることが全く想像できません。
Googleマップを持ち運べる点についてはいいと思うんですが、それってノートPCでもできるよなあと。使ってる人を見ても、パラダイムシフトが発生する気がしなくて。それにあれ、プログラミングしにくそうじゃない？
ということで、I(dea)Padを買いました。http://ascii.jp/elem/000/000/499/499886/
重さは、1.5kgとiPadの倍くらいですが、それなりに動くみたいです。これを買おうと決断したきっかけは、「NetBookでVisual Studioって普通に動くし使えるよ」という先輩の一言でした。
CPU的には、10年前のPentium 4初期といろんな意味で同程度ですが、HDDはふんだんに使えるし、メモリも1Gあるのでそんなに困らない感じです。メイン開発マシンにはならないだろうけど。
pぁ
2は「未初期化を表す特別な値」が「-1」だから読みづらいのであって、nullにできる型を使えばもう少し読みやすくなるきが。
if (min == null || min > value)
succeed
＞ｐぁ
BigIntegerみたいなのだと、nullにすることになると思うのだけど、あるいはMaybeモナドを使うという手もあると思うのだけど、結局それって同じことでは？
未初期化である可能性がある、というのが不満で、例えばdo{}while()みたいな書き方ができればいいと思うのだけど。
うまくIteratorぶん回せばdo whileに落とせるっちゃあ落とせるけど・・・・
ということで、誰かクックレシピ的なのを希望。
pぁ
nullにすれば-1と違って、まちがって未初期化のまま扱おうとしたら「ちゃんと」実行時エラーになってくれるのは利点だと思うよ。あと、空のシーケンスを渡したとき自然にnullが返るというのもあるので、「Java使うなら」結構まともな落としどころだと思うけど。
それで不満ならパターンマッチが網羅してるか静的チェックしてくれる言語を使うのかな、いやJavaでもできるかもしれないけどclassでエンコードするのは「これしきのことで長く」なるに決まってる(偏見
succeed
うーん。そうかもなあ。
ただ、長くなるのはJavaに限った話ではなくて、「設計をちゃんとすればするほど、たいていの言語は長くなる」と思う。(仕様が増えるからね・・・)。
これを解決する手法って、ライブラリくらいしか思いつかないのだけど、他にあるのかなあ。
pぁ
無名関数がインラインに簡単に記述できる言語なら、このパターンを抽象化した高階関数作って、更新関数を渡すように使えば結構短くできる予感。というかfoldとMaybeでいける気がする。
あとはマクロなら(ry
pぁ
というのは全部ライブラリってことになるか。高階関数ライブラリ、もしくはマクロライブラリ。とはいえminの代わりにmax使いたくなるたびにライブラリを増やさなきゃいけないとかいうことがないのは圧倒的な強み
pぁ
設計をちゃんとするほど長くなってしまうかどうかは、問題によると思う。数年ぶりのOcaml
# let option_fold updater ls =
List.fold_left (fun ox y -> match ox with None -> Some y | Some x -> Some (updater x y)) None ls;;
val option_fold : ('a -> 'a -> 'a) -> 'a list -> 'a option = <fun>
# option_fold max [];;
- : 'a option = None
# option_fold max [1; 3; 2];;
- : int option = Some 3
2010-02-22
■クラウドはよくわからないけど、グリッドはわかるようになった件(JIS X7301について)
SWoPP Announceに小柳先生が投稿されたのだけど、JISでグリッドが定義されたっぽい。
この中で、グリッドという用語の説明が書いてある。
コンピュータ、ストレージおよびネットワークといった資源の物理的位置やハードウェアを意識することなく、必要な資源を必要なときに必要なだけ利用可能なシステムであり、異機種および/または地理的に分散した、複数のコンピュータ資源を仮想化技術を用いて統合したシステム
注記: 提供物がグリッドシステムと一致する場合もあればグリッドシステムの一部に該当する場合もある。すなわち、複数の提供者が提供する複数の提供物が組み合わされてひとつのグリッドシステムが構成されている場合がある。
これを読んだ素直な感想といえば、「これって世の中で言ってるクラウドじゃね？」ってところか。ちなみに、従来僕がグリッドという言葉で解釈していたのはおおまかに以下のような感じ。
コンピュータ、ストレージおよびネットワークといった資源を、必要な資源を必要なときに必要なだけ利用可能なシステムであり、異機種および/または地理的に分散した、複数のコンピュータ資源を統合したシステム
資源の位置やハードウェアを意識しないのは物にもよるけど性能出すのは無理なので、如何に活用しようか、というのがグリッドの主題だと思っていた。あと、仮想化がどのレベルの話かは微妙だけれど、グリッドというときにはその言葉はあまり意識していなかった。てか、このレベルの定義だと広すぎてオンラインストレージとか該当するんじゃなかろうか。なるべく漏れなく、ということなんだろうけど。あと全体的にクラウドって言葉は排除されている。まあ当然か。
まあ、わかったことは、これから「グリッド」という言葉はBuzz Wordじゃなくなるので気をつけて使いましょう、というくらいかな。個人的には世の中のクラウドサービスの半分以上はこの言葉の定義に含まれると思うので、これからはグリッドを名乗ってほしいと思う。
2010-02-03
■java.net.HttpURLConnection が設計ミスを起こしている件
JavaでHTTPクライアントを作ろうと思ったときには、おそらく二つくらいのアプローチがあって、ひとつがApache JakartaプロジェクトのHTTPClientを使う方法、もうひとつがjava.net.HttpURLConnection を使う方法だ。まあもちろん、自前でTCPクライアントの上に乗せてもいいのだが、そんな車輪の再発明するくらいならもっと別のことに労力を使うべきだと思う。
というわけで、そのうちひとつのjava.net.HttpURLConnectionの件。HTTPは最初だけ大文字、後小文字の癖に、URLは全部大文字というよくわからんネーミングセンスについてはとりあえず置いておくとして、設計的によくわからないというか、何がしたいのか意味が不明なところがあるのでそれについて書く。
http://java.sun.com/j2se/1.5.0/docs/api/java/net/HttpURLConnection.html
HttpURLConnectionは、URLオブジェクトからコネクションを張ることで以下のように接続を行う。
URL url = new URL("http://example.com/"); HttpURLConnection conn = (HttpURLConnection)url.openConnection(); conn.setRequestMethod("GET"); conn.connect();
で、その後データを取得する。この際使用するのがBufferedReaderなのはバイナリが帰ってくるかもしれないから仕方ない。
BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream()));
問題なのは、この
conn.getInputStream()
が、throw IOExceptionとなっていることなのだ。これはリファレンスによれば、
と書いてある。これ、実際にどういうときに起きるかといえば、他にもあるかもしれないがサーバがエラーを返したときなのだ。つまり、サーバが4xxまたは5xxのエラーレスポンスを返したときには、なぜかInputStreamは生成されない。nullが返るのではなくてExceptionが飛んでくる。そしてその場合にはgetErrorStream()で取得したStreamにHTTP ResponseのBodyが返ってくる。
あるサンプルソースコードはこのため、こんなことをやっている(http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html)。
try { URL a = new URL(args[0]); URLConnection urlc = a.openConnection(); is = conn.getInputStream(); int ret = 0; while ((ret = is.read(buf)) > 0) { processBuf(buf); } // close the inputstream is.close(); } catch (IOException e) { try { respCode = ((HttpURLConnection)conn).getResponseCode(); es = ((HttpURLConnection)conn).getErrorStream(); int ret = 0; // read the response body while ((ret = es.read(buf)) > 0) { processBuf(buf); } // close the errorstream es.close(); } catch(IOException ex) { // deal with the exception } }
このソースコードは、まあ目的が違って永続セッションを張ろうとしているので(サーバがエラーを返した時点で終了するのがクライアントとして正しい動作なので)これでいいのだろうけども、「とりあえずInputStreamを取得して、Exceptionが出たらErrorStream使おう」とかいう態度はどうかと思う。例外は、正常形で投げられてはいけないのだ。
HTTPClientを書こうとした人間が、サーバの4xxエラーまたは5xxエラーを正常系とみなすか異常系とみなすかは不明である。サーバにとって異常系なのは明らかだが、例えばサーバのエラーやリンク切れを発見するテストクライアントであれば、異常系ではない。
4xxや5xxがクライアントにとっても異常系だと主張するにしても、getInputStream()で例外を投げるのはタイミングがおかしい。エラーはbodyを取得する前にわかっているのだから、その前に例外を投げるべきだ。
あるいは、以下のような実装も考えられる。
conn.connect(); InputStream stream; if(conn.isSuccess()){ stream = conn.getInputStream(); }else{ stream = conn.getErrorStream(); }
しかし、isSuccessのようなメソッドは実装されていない。また、本質的な話としてこのHttpURLConnection#getInputStreamが例外を投げるケースはResponse Codeが何番なのかということはドキュメントのどこにも書いていないことが挙げられる。したがって、このようなisSuccessを自前で作ることすらできないのだ。
実際に正しくやろうと思ったら現状では以下のようにするしかないが、これで正しいかどうかは誰も保障してくれないのだ。
InputStream stream; int responseCode = conn.getResponseCode(); if(responseCode / 100 == 4 || responseCode / 100 == 5){ stream = conn.getErrorStream(); }else{ stream = conn.getInputStream(); }
pぁ
ライブラリ設計の良し悪しはあんまりわかんないんだけど、
> 「とりあえずInputStreamを取得して、Exceptionが出たらErrorStream使おう」とかいう態度はどうかと思う。
例外になっちゃってるものは仕方ないとして、「getInputStreamでの例外」と「その後の入出力での例外」を区別すればいくらかマシになる気はする。たとえばこんな感じで
InputStreamAndException getInputStreamAndExceptionFrom(HttpURLConnection conn) {
try {
return new InputStreamAndException(conn.getInputStream(), null);
}
catch (IOException ioe) {
return new InputStreamAndException(conn.getErrorStream(), ioe);
}
}
InputStreamAndErrorの定義は察して。ほかにもthrows IOExceptionしておいてtryの前にconnectやgetResponseCodeしてみるとか、返値でInputStreamとペアにするのは例外じゃなくてResponseCodeにしてみるとか、工夫できると思う
HIROX
なんか宗教的な話に見えるんですが、例外をいやがる理由が謎です。
「テストするクライアントが〜」とか言い出すと異常系なんてこの世から無くなるのでは？
succeed
＞pla
うーん。これはこれでどうなんだろう。
もし受け取った人が、throw nullとかやったらその瞬間ぬるぽるので危険というか、わけがわからなくなると思う。
reesponseCodeならいいけど、そういうのは最初から取得できるのだから、わざわざ多値返ししてやるほどのことは無いと思う。
＞HIROX
宗教といえばそうかもしれないけど、Javaの設計思想の問題だと思うんだよね。
例えば、例外でも動くからって、1から100までの和の計算で
int i = 100, sum = 0;
try{
while(true){
sum += i;
i--;
int tmp = 1/i;
}
}catch(Exception e){
System.out.println(sum);
}
なんてコードが許されるか、って問題。
検査例外は業務エラーを出力するべきであって、業務エラーじゃないものを例外としてはいけないのだと思うよ。
http://blogs.msdn.com/nakama/archive/2009/01/09/net-java.aspx
で、クライアントにとって業務エラーかどうかを決めるのは、現代のHTTPの使われ方から考えて、サーバじゃないと思う。
HIROX
> 現代のHTTP
JDK1.1からあるクラスに食ってかかっても。。。
互換性もあるし普通はライブラリなんて妥協の産物ですよ。
今回の目的ならこれで十分では。
InputStream stream;
try {
stream = conn.getInputStream();
} catch(Exception e) {
try {
stream = conn.getErrorStream();
} catch(Exception e) {
// disconnected, invalid HTTP response, etc.
}
}
単に叩くのではなく、建設的により良い実装案をキボンヌ。
succeed
> JDK1.1からあるクラスに食ってかかっても。。。
> 互換性もあるし普通はライブラリなんて妥協の産物ですよ。
ダウト。以下を見れば、昔はこんな実装してなかったことがわかる。
http://docs.sun.com/app/docs/doc/816-3973/6ma7ftaqg?l=ja&a=view
この変更の一部として、現在、HttpURLConnection.getErrorStream を使用すると、サーバから戻されたエラーページを読み取ることができます。J2SE 1.4 より前では、getErrorStream は常に null を戻していました。また、メソッド HttpURLConnection.getResponseCode は J2SE 1.4 で正しく動作します。
succeed
後、よりよい案としてならば、書いてあるように単純にisSuccessメソッド追加するだけなんですけど。併せてドキュメントにちゃんと書いてくれればそれでいい。
本来から言えば、HTTPなのにInputStreamとErrorStreamがある時点でおかしいんだけど、そこは目をつぶろう。URLConnectionの中にはそれをサポートするものもあるかもしれないから。
HIROX
確かにInputStreamとErrorStreamの両方があるのは変ですが、一度例外を投げてしまうように作ってしまったのだからこのまま通すのは仕方ないんじゃないでしょうか。何がダウトなのかわかんないです。エラー時もInputStreamで返すようにすると非互換が大きくなりますよね？
InputStreamとErrorStreamのどちらで読むべきかを知るためのメソッドがあってもいいかもしれませんが、上記workaroundで簡単に対処できる＆エラーのレスポンスを読むケースは希なので追加すべきかどうかは微妙ってとこじゃないでしょうか。
少なくともisSuccessだと何の成否を返すのかわからない(connectの成否を返すように見える)ので良くないと思います。
pぁ
> reesponseCodeならいいけど、そういうのは最初から取得できるのだから、わざわざ多値返ししてやるほどのことは無いと思う。
「Response Codeがとれる程度にまともに接続できてるならbody部分のストリームがほしい」という要望だとすれば、Response Codeとペアにするのは結構意味があると思うんだ。値が入っているなら「間違いなく成功した」って分かる。
> もし受け取った人が、throw nullとかやったらその瞬間ぬるぽるので危険というか
nullが返ってくるかもしれないところでnullチェックするのは当然じゃね？もちろんドキュメントはほしいけど。もっというならOptionalみたく静的チェックがほしいけど・・・Javaじゃむりね。
ただこの場合、例外部分にnull入ってるのは「成功したとき」なので、そんなときに何でそこの例外投げようとするかなっていう。
あと、getInputStreamは例外投げないで null 返す方がマシと言っているようにみえるのだけれど、それでいて失敗ステータスとして返す値にnullが入ってるのはだめっていうのはよくわからない。
succeed
＞おｒｚ
某社の依頼を受けてデバッグするだけの簡単なお仕事です。
＞HIROX
ちょっと論点がわからないので書かれてることにのみ反論。
(1) 張ったURLを読む限りにおいては、1.4.2以前は
正常レスポンス→今と同じ動作
エラーレスポンス→InputStreamにBodyが入る
だと思うんだけど。
(2)isSuccessじゃなくて、isSuccessResponseとか、そういう名前の問題を主張している？
(3)エラーのレスポンスを読むケースが稀ってのは経験則の話をしている？
＞ｐぁ
意図を把握。要は、Responseオブジェクトが返ってくればいいのね。
> getInputStreamは例外投げないで null 返す方がマシと言っているようにみえるのだけれど、それでいて失敗ステータスとして返す値にnullが入ってるのはだめっていうのはよくわからない
普通のオブジェクトにnull使うのはやるけど、Exceptionにnull使うって言うパターンを知らなかったので。
まあ、このあたりはどっちかって言うならInputStreamAndExceptionクラスのメソッドの方で適当にカプセル化してインターフェースとドキュメント用意するのが妥当かもね。
それこそ、成功時にgetExceptionを呼び出したらそのときに別のSuccessResponseExceptionが飛んでくるみたいな。SuccessなのにExceptionとはこれ如何に。
pぁ
> 要は、Responseオブジェクトが返ってくればいいのね。
そういうとらえかたもできるかもね。
とはいえ、標準ライブラリにかぶせるラッパーはよほど意味があるとき以外はあんまり厚くない方がいいんじゃないかなと思っていて、ソースみて10秒で理解できるようにできるならそれが望ましい。staticメソッド一個で済むのをわざわざ「オブジェクト指向的に」複雑にしちゃうのって誰が得するんだろ
> それこそ、成功時にgetExceptionを呼び出したらそのときに別のSuccessResponseExceptionが飛んでくるみたいな。SuccessなのにExceptionとはこれ如何に。
死ぬほど使いづらそう
> 普通のオブジェクトにnull使うのはやるけど、Exceptionにnull使うって言うパターンを知らなかったので。
そういう問題かなあ。単に、中で失敗したときExceptionがとれるから、それを失敗ステータス代わりにしてみたっていうだけなんだけど...
あと横レス
> (1) 張ったURLを読む限りにおいては、1.4.2以前は
> 正常レスポンス→今と同じ動作
> エラーレスポンス→InputStreamにBodyが入る
> だと思うんだけど。
貼ってくれたURLによると
> J2SE 1.4 より前では、ファイルタイプが判明しており、応答コードが 400 以上になった場合、FileNotFoundException がスローされます。
であり、かつ
> J2SE 1.4 より前では、getErrorStream は常に null を戻していました。
なので、「ファイルタイプが判明している」ときはエラーのレスポンスを取得する手段がそもそも無かったのでは？
HIROX
なんか反論ありきで事実の認識から違うし何を言っても仕方無さそうなのでもういいです＞＜
(1)はｐぁ氏が書いてくれたとおりです。
succeed
んー、まあいいけど。
最初から最後まで、主張はブレさせたつもりないんだけどな。
1. サーバエラーはクライアントの異常じゃねえ。
2. クライアントの異常じゃないのにException投げんな
3. 100歩譲るにせよ、せめてドキュメントに書け
位の話に対して反論ポイントがおかしいと思ってるんだけど。
それはともかく、ｐぁ氏の案に対してなんで奇妙に感じるかと思ってよく考えてみたら
> とはいえ、標準ライブラリにかぶせるラッパーはよほど意味があるとき以外はあんまり厚くない方がいいんじゃないかなと思っていて
というのを読んでやっとわかった。このクラスが標準クラスの癖に厚くなってないのが問題なんじゃなかろうか。
Responseオブジェクトを返すような実装の標準クラスのラッパとしてHTTPURLConnectionがあるならなんとも思わないし、GJだと思う。
ｐぁ氏の案は、概念的にはラッパというよりデラッパになってるから、気持ち悪かったんだろうなあ。
2009-12-02
■64bit OSによる恩恵の原因
かなりエッセンスだけ書いたところ、当然のようにsumiiさんに突っ込まれたのでちゃんと書きます。というか、本当のことを言うと、64bit OSにしたときに改善される本質が何なのかはベンチマークの結果しかないので実はわからず、結果だけ書いておけば誰かが教えてくれないかなぁと思っていました。でも、そんなに都合はよくないので、ちゃんとその辺考えた結果を書きます。
まず、sumiiさんからの質問にあった、「"n-bit OS" (n∈{32,64})とはどういう定義」という質問ですが、これはx86であればx64命令セットを使用しているかどうか、ということでいいと思っています。つまりは単純に命令セットが違う、と。
その上で、「なぜ速くなるのか」ですが、世の中には誤解も多いと思うので、ひとつずつ考えていきたいと思います。
まず、単純なCPU命令による問題として、よりI/O命令が特化された可能性がありますが、僕の知る限りにおいてはありません。あと、よくある誤解にCPU-メモリバスが太いだとか、太く使用できるようになるとか言うのもありますが、そんなことも「今回の場合は」ありません。そういうCPUがないとは言えませんけど。また、sumiiさんの質問にあった「32ビットで済む整数やポインタまで64ビットになってしまうと、I/O帯域が実質半分になって遅くなる、という話を聞いたことがあるので」とのことですが、これはそういうこともあるでしょうけど、32bitと64bitのベンチマーク比較では関係ないと思うのです。普通はそのあたり、統一してやりますよね？・・・ちょっと不安になってきましたが。
さて、ここまででは特に64bitが速くなる要素がないような書き方をしましたし、実際になぜ速くなるのか、というところは出てきていません。でも、実際にベンチマークは速いんです。ということで、ありえそうなところが二点ほどあります。それはTLBのページサイズです。要は仮想アドレスと物理アドレスの変更機構の話です。
それについて、きちんとしたWeb上の文章はないのですが、以下の記事では同じようなことが言われていると思います。
http://itpro.nikkeibp.co.jp/article/COLUMN/20071016/284680/
64ビット化の最大の利点は，広大なメモリー空間を利用できることだ。32ビット版でもAWE（Address Windowing Extensions）に対応しているので，最大64Gバイトのメモリーを扱える。だがこの方法は，非ページ化メモリーを32ビットのアドレス空間に動的にマッピングしながらアクセスさせているにすぎない。一方，直接64Gバイトのメモリーをアドレッシングでき，リニアにアクセス可能な64ビット版の方が高速にアクセスできる。メモリー・アクセス性能は，仮想化ソフトウエアの処理性能に大きく影響を与える。
つまりは、TLB missが性能低下を起こしているというのが原因ではないかと思ったわけです。・・・それなら最初から32bitでHuge TLBを使えば、Linuxなら何の問題もないのではないかということになったのですが、実際どうなっているのか知っている人 or ベンチマーク取った結果をほしいです。HPLでもMatrix Transposeは入っているのでぜひぜひ。
HIROX
メモリが4GB以下ならばTLB missは関係なさそうな気がするんですがどうなんでしょう？
予想ですが、x86/x64のCPUは命令デコードがボトルネックになりやすいのでx64で命令数が減れば1命令で多くのデータを引っ張って来れて速くなるかもですね。
例えばSSEを使うとmemcpyは速くなります。
ともかく詳しい調査キボンヌｗ
naruto
32bit Windowsで物理アドレス拡張を使ってるソフトは滅多にないと思います。一部のRAMディスクとかくらい? 専用のAPIが要るので。
http://www.atmarkit.co.jp/fwin2k/win2ktips/1125paeon/paeon.html
http://technet.microsoft.com/ja-jp/library/cc775523(WS.10).aspx
本題と全く関係ないですが64bit版Windowsでx86バイナリのアプリをそのまま動かしても多少速くなることがあるらしく
http://www.4gamer.net/games/086/G008641/20091121002/
ドライバとかの恩恵のよう。
sumii
先のエントリの後半はスパコンやSPARC64について書かれていましたが、「64-bit OSのほうが（メモリI/O intensiveなベンチマークが）速くなる」という「結果」は一般的事実なのでしょうか、それともx86かつWindowsかつMathematicaに限った話だったのでしょうか。（ちなみに、脇道かもしれませんが、ポインタも32ビットに「統一」できるものなのでしょうか。今回の数値計算ベンチマークには関係がないかもしれませんが、言語処理系、特にガベージコレクタでは64ビットポインタのI/O帯域が問題になるという話もあるので）
succeed
＞HIROX
> 例えばSSEを使うとmemcpyは速くなります。
SSEであれば32bitでも使えるからなあ。64bit拡張命令にそんな便利なものが存在するのかねぇ。
＞narutoさん
さすがに数値計算系で物理アドレス拡張は無いと思うのです。
っていうか、それやってたらこんな時間差じゃすまないと思うのです。
＞あぼんぬ
それ、いまだにあるのん？
しかも、今は64bitが速いという話をしているんだが。
＞sumiiさん
少なくとも、このデータは現状では一般的事実とまではいえないと思っていて、少なくともx86限定でしょう。
Mathmaticaの実装もWindowsの実装もよくわかりませんが、ともかく何らかのベンチを取ればわかるのではないかと。
例えば、こんな結果もあります。
http://64-bit-computers.com/windows-vista-32-bit-vs-64-bit-benchmark.html
> 今回の数値計算ベンチマークには関係がないかもしれませんが、言語処理系、特にガベージコレクタでは64ビットポインタのI/O帯域が問題になるという話もあるので
それは確かにありえますね。ぜひやってみてください、と丸投げをしてみるテスト。
succeed
あと、Linuxの結果もありました。
http://www.linuxmania.jp/f7_benchmark.html
ただ、
> 円周率計算では、i386(2GB)とx86_64(2GB)で劇的な差が出ました。
> 計算がメインのため、64bitの利点が強く出た模様です。
これ、俺の主張と真逆なんですが。
pi計算って、多倍長整数掛け算みたいなのを繰り返すメモリI/Oがネックの計算だと思ってた(今も思ってる)んですが、間違ってるんでしょうか。
後、HPLでなんでこんなに差が出てるんだろう。中に行列転置とかが入ってたような気もするけど。後でちゃんと調べる。
sumii
（x86では）そこまで差が出る（ことがある）とは知りませんでした。どういう原因なのか＆他のアーキテクチャでも同様なのか、わかると良いですね。どうも有難うございました。
おｒｚ
単にレジスタ本数倍増、バイト数で４倍に増えたからだろ＞豚澤
succeed
つまり、レジスタブロッキングが有効って意図？
否定はできないけどL1キャッシュならそんなにペナルティ変わらなくないか？
おｒｚ
インテルはL1レイテンシかなり小さいのでキャッシュに当たる限りはレジスタ少なくても良い
succeed
じ ゃ あ レ ジ ス タ 本 数 関 係 な い じ ゃ ん
succeed
LinkedIn
------------
I'd like to add you to my professional network on LinkedIn.
- Yuta
Yuta SAWA
Researcher (trainee) at Hitachi, Ltd
Japan
Confirm that you know Yuta SAWA
https://www.linkedin.com/e/-1avdcb-gqahmkc1-2z/isd/3580073857/7Qm8T3bL/
--
(c) 2011, LinkedIn Corporation
succeed
LinkedIn
------------
This is a reminder that on July 19, Yuta SAWA sent you an invitation to become part of his or her professional network at LinkedIn.
Follow this link to accept Yuta SAWA's invitation.
https://www.linkedin.com/e/-1avdcb-gqjc8vq4-1d/doi/3580073857/7Qm8T3bL/gir_852556062_0/EML-inv_17_rem/
Signing up is free and takes less than a minute.
On July 19, Yuta SAWA wrote:
> To: [d-comment+qgi7ygld4k.110400872@hatena.ne.jp]
> From: Yuta SAWA [yuta.sawa@gmail.com]
> Subject: Invitation to connect on LinkedIn
>
> I'd like to add you to my professional network on LinkedIn.
>
> - Yuta
The only way to get access to Yuta SAWA's professional network on LinkedIn is through the following link:
https://www.linkedin.com/e/-1avdcb-gqjc8vq4-1d/doi/3580073857/7Qm8T3bL/gir_852556062_0/EML-inv_17_rem/
You can remove yourself from Yuta SAWA's network at any time.
--------------
--
(c) 2011, LinkedIn Corporation
2009-12-01
■32bit/64bit OSの性能比較とスパコンの性能比較の関係
最近Windows 7とやらが発売され、結構な人が64bit版を導入しているようです。僕は諸事情で32bitですけど。64bitと32bitの違いというと、たくさんのメモリが使えるかどうか、だと思ってる人もいると思います。それはそれで正しいのですが、計算性能でも違います。
ところで最近スパコンの性能というのが話題ですね。例えばGordon Bell C/P 賞を取った長崎大学の結果と比較して、京速計算機がうんぬんという比較です。で、この話題と32bit/64bit OSの性能差というのは密接に関係してるんですよ、というのがこの記事の話です。
まず問題を計算する際には、プログラムを実行するわけですが、プログラム中の命令は大きく2つに分かれます。計算命令とI/O命令です。計算命令というのは、CPUの中で加減乗除などを行うだけの命令で、I/O命令というのはCPUの外部と通信する命令です。I/O命令の例としては、メモリアクセスやネットワークアクセス、GPUへの計算渡し、などが含まれます。プログラム中の命令の中には、計算命令とI/O命令の二つを同時に実行するものもありますが、CPUは実際にはどちらか一方を行っている状態と考えてかまいません(パイプラインとか難しいことを言わないように！)。ここで、計算命令のほうがI/O命令よりも時間がかかっている状況をCPU bound、I/O命令のほうが時間がかかっている状況をI/O boundと呼びます。
さて、32bit/64bit OSの話に戻します。このOSによる違いは何か、というと32bit OSよりも64bit OSの方がI/O boundの問題が速くなる、ということです。具体的なベンチマークは、こんな感じです。例えばData FittingやPiの計算、行列転置などはメモリアクセスがほとんどである、典型的なI/O boundな問題です。一方、このベンチマーク中で若干遅くなっているような、行列積や数値積分問題というのはメモリアクセスが相対的に少ないCPU boundとして知られている問題です。ちなみに一般の数値積分問題では微分方程式の初期値問題などのI/O boundなものもありますが、ここでやられているのはおそらくのような問題だと考えられます。
次にスパコンの話題として、長崎大学のGPUをつないだ話をしますと、N体問題というのを解いているようです。一般のN体問題は、上でCPU boundといった行列積問題とほぼ同じであり、やはりCPU boundです。そしてこういったCPU boundな問題に対しては、GPUが効果的に使えることが知られており、こういう話題をある程度知っている人達は比較的性能に意外な点は無いと捉えているように思われます。ただし、今回の場合はちょっと特殊なとき方をしているので、別エントリで補足します。
その一方で、I/O boundな問題が速くなければ一般の問題というのはほとんど速くならないため、京速計算機にはその点が期待されています。この京速計算機に乗るCPUはSPARC64という、その名のとおり64bit CPUでして、OSも当然のように64bitが使われます・・・多分。で、ただそれでもまだまだI/O boundが解決されない、というのが問題であって、そういう問題はPC clusterなどではとても解決できないのです。
ということで、32bit OSが問題としている点と、PC Clusterや長崎大学のスパコンが問題としている点は実はほとんど同じなんですね。解決案は64bit OSだったり京速計算機だったりと違いますが。
■長崎大学のGPUスパコンのアルゴリズム
エントリを変えて、長崎大学のGPUスパコンで使われたアルゴリズムについてみてみたい。資料はhttp://www.ssken.gr.jp/MAINSITE/activity/sectionmeeting/sci/2009-2/lecture-1/ppt.pdfにある。
このアルゴリズムは、一般的にはTree法とかFMMと言われている物で、詳しくはhttp://www.artcompsci.org/~makino/papers/doboku/doboku.htmlあたりを参照するといいと思う。重要なのは、大体FFTなんかと同じような計算量だという点だ。上の記事にあるMathmaticaのベンチマークの中に、FFTの結果もある。Discrete Fourier Transformと書かれているのがそれだ。これが64bitで高速になっていることからもわかるように、実はこの問題はかなりI/O boundな問題なのだ。Tree法やFMMについても同様の性質があり、やはりI/O boundと考えてよいと思う。
先に書いたように、一般のN体問題であればCPU boundなのでGPUで高速化が容易だったというのは比較的当然だったのだが、今回はI/O boundな問題をGPUで高速化できたという点が非常に興味深い。
sumii
Windowsはよくわからないのでさておき（すみません）、ここでいう"n-bit OS" (n∈{32,64})とはどういう定義で、なぜnが大きいとユーザレベルプログラムのI/O性能が高くなるのでしょうか？（32ビットで済む整数やポインタまで64ビットになってしまうと、I/O帯域が実質半分になって遅くなる、という話を聞いたことがあるので）
おｒｚ
６４ビットＣＰＵだとメモリアクセス速くなんの？＞うんこｓａｗａ
succeed
＞sumiiさん
> 32ビットで済む整数やポインタまで64ビットになってしまうと、I/O帯域が実質半分になって遅くなる
この話は別だと思うのですが、別エントリにします。
＞あぼんぬ
そんなことはないし、言っていない。
メモリアクセスがネックになっているベンチマークが速くなると言っている。
> そもそも、JVMの上で動くからお互いのクラスが使いやすいよってのが半分売りだったんじゃないかと思うんですが、使ってみると全然そんなこと無いなあと。多くのクラスを、わざわざJavaと独立に実装していてインタフェースの互換性のかけらも無い。そのくせ、名前だけは同じだったりするので、本当に使っていて頭が痛いです。Listって言ったらjava.util.List だと思うわけですが、scala.Listって何それと。
Javaのクラスをそのまま使えるってのは、言葉通りそのまま、Javaの型をJavaの型としてScalaから扱えるってことであって、ScalaのライブラリがJavaの標準ライブラリと互換性を持ってるという宣伝文句ではないんです。その点は誤解されていると思います。scala.ListがListなのは、関数型言語で言うところのリストはListなのが普通なので、名前がかぶってしまったのが不幸というしかないなあと思います。また、Javaのインタフェースと互換性を持っていない点ですが、これについては、immutableなコレクションを重視するScalaとしては互換性を持たせるわけにはいかなかった、と思います。たとえば、scala.Listは一度作成したら変更できないコレクションですが、変更可能なリストであるjava.util.Listとのインタフェース互換性を持たせようとするのは、型安全性を犠牲にしないと、ちょっと難しいです。ただし、ScalaのコレクションとJavaのコレクションの相互変換については、2.8で提供されている、scala.collection.JavaConversionsを使えばほとんど自動的にやってくれるようになるので、だいぶ楽になります、というか楽です。
> Javaの BigIntegerの代わりにBigInt作ってみたり、もう何やりたいのかわかりません。
BigIntegerの代わりにBigInt作ってるのは、主として使い勝手のためです。たとえば、BigIntegerは演算子オーバーローディングが無いので、複雑な計算やろうとするとコードが悲惨なことになりますが、BigIntおよび同時に提供されている暗黙の型変換を使えば、かなりコードが読みやすくなります。少なくとも、別のクラスを作って提供する価値は十分にある、と私は思います。
> そのくせ、StringだけはJavaと共通なんだとか聞くと、しっちゃかめっちゃかだと思います。
これに関しては、まあちょっと擁護しづらいのですが、全体としてはScalaはJavaとは別のライブラリ群をJavaの上に構築するという方向で動いています(のはず)。中途半端な部分があるのは確かで(たとえばIOとか)、その点は不満に思われるのも仕方ないですが…。
> 普通、関数型言語ってのはa bと書いたら値bに対して関数aを適用するじゃないですか。Lispだと(a b)って書きますけど、まあそうですよね。それに対してCをはじめとする言語の多くは、a(b)ですよね。
> 手続き型の書きかたって、オブジェクト指向とかなら悪くはないんですけど、関数の適用結果が関数だったりすると破綻するんですよ。(((a b) c) d)はまだわかるけど、a(b)(c)(d)って何ですかこれ。結合順序もわからない感じに。
この辺は主観の問題になってしまうのですが、高階関数を使ってメソッドチェインする場合、たとえば
Scala: list.map(x => x + 1).filter(x => x != 2)
SML: filter (fn(x) => x <> 2) (map (fn(x) => x + 1) list)
になりますけど、Scalaの方が処理を適用するデータの方が先に来るので、自分的には思考順序に逆らってなくて書きやすい(こともある)です。あと、a(b)(c)(d)についてですが、これは単に((a(b))(c))(d)という結合順序なんですけど、そこまでわかりにくいでしょうか。確かに記法は関数型言語の標準的な慣習からは逸脱してますが、結合順序のルールは明確だと思います。
少なくとも、破綻しているという程複雑ではないはず。
> Scalaがこんなぐだぐだになってるのは、Javaって強敵がいたからかもしれませんけど、言語設計を最初からやったのが間違いだったんじゃないかと思います。全体的に見て、明らかにJavaと別言語なんであれば、マルチプラットフォームで動くということを含めてもわざわざScalaを使うメリットは少ないと感じています。
Javaの言語設計はかなりイマイチだし冗長なコードを書かなければ嫌だと思っているけど、Javaのライブラリ資産は使いたい、という自分のような人間にとってはメリットはあるなあ、と思います。OCamlでも悪くないんですけど、Javaのライブラリ資産をそのまま生かせないのが痛いです。
> 結局、僕がほしかったのは関数型が簡単に書けるJavaだったみたいです。Closure作るのにAbstract Classの newとかやるのが嫌だったんです。Java 7が出たらきっと解決されるものだと思ってます。
Java + Closureが欲しい、という話ならScalaはオーバースペック過ぎるので、確かに不要かもしれません。
http://d.hatena.ne.jp/nuc/20051102/p5
http://d.hatena.ne.jp/nuc/20051102/p6
を思い出した。
まず、僕が誤解しているのではないかとのお話ですが、それは誤解です。(自分でもややこしい・・・ｗ)
1. Scalaを使うまで誤解していたことがあり、2. Scalaを実際に触り、また本を読むことで誤解が解け、3. その結果がっかりした、ということです。
これが勝手な期待を裏切られたことによる逆恨みを込めた上での、主観によるバッシングであることは承知した上で、やはりScalaの行く先がよくわかっていないわけです。
以下各論です。
まず、Javaとのクラス共存関係なのですが、これは実際の実装を見れば明らかにJavaと独立にライブラリを定義していくという意思は感じています。この点の認識について、みずしまさんのご指摘と相違ありません。
ただ、結局StringはStringなんでしょうか？List[Char]にする予定はないのでしょうか？JVMの仕様上の問題だとは思うんですが、Javaの言語仕様上最も汚いString実装を見直してもらえないのは非常に残念です。
後、ぶっちゃけNilだとかそういう微妙なクラスを定義されると、Java視点からするとやりにくいなあと思ったり。
僕のやりたいことは、Scalaで全部書くとかではなくて、Interface部分はJavaで書いて、Scalaで一部の関数型が得意そうな処理を書くというモデルです。そういう視点からするとScala側でどんどん新しいライブラリを使われたりすると、結局Scalaのクラスについての知識もたくさん仕入れる必要があって、結局あまりうれしくないという結果になります。
後、メソッドチェインについてですが、要はRubyみたいに書きたいよね、ということですよね。その点は同意します。ただ、それもオブジェクト指向的に書く部分においてはよいのですが、関数型っぽく書くときには微妙だということが言いたかったのです。
なんだろう・・・Scalaの宣伝文句がもうちょっと異なって、僕自身の先入観がもっと少ないような出会い方をしていれば印象は違ったんだと思うと、若干残念ではありますね。
Scalaはいろんなところで妥協している(例えばmethodが第一級で無いとか)と思うし、妥協が必要なのは同意なのですが、その妥協ポイントが僕の好み/感性と異なっていたっていうのも理由かもしれません。
まあ、文句言いながら使うんだろうけど・・・・
あと、括弧が適用演算子なのか優先度を決めてるのか分かり辛いってことだよね。でも式ふたつを単に並べて書く文法が無い状況なら、誤解はしない気がする。だとすると何のためにある括弧なのかよくわかんないので、その意味ではやっぱり同意。
あとJavaのStringってそんなにダメかな？
ついてはおおむねこちらの誤解だった、ということで基本的には了解しました。ただ、さらにコメントしたい事があったので以下に述べさせていただきます。
> ただ、結局StringはStringなんでしょうか？List[Char]にする予定はないのでしょうか？JVMの仕様上の問題だとは思うんですが、Javaの言語仕様上最も汚いString実装を見直してもらえないのは非常に残念です。
少なくとも2.8では、Stringは、implicit conversionによって、他のScalaのコレクションとほぼ同様に扱えるようになっていて、ほとんど不便は感じませんが、それでは不十分でしょうか？実際問題、今からStringをList[Char]にしても利便性はほとんど変わらないと思います。
> 後、ぶっちゃけNilだとかそういう微妙なクラスを定義されると、Java視点からするとやりにくいなあと思ったり。
これはよくわかりませんでした。Nilはクラスじゃなくてオブジェクトですが、それはおいといて、JavaからScalaのListを利用したいときに困るとかいう話でしょうか？
> 僕のやりたいことは、Scalaで全部書くとかではなくて、Interface部分はJavaで書いて、Scalaで一部の関数型が得意そうな処理を書くというモデルです。そういう視点からするとScala側でどんどん新しいライブラリを使われたりすると、結局Scalaのクラスについての知識もたくさん仕入れる必要があって、結局あまりうれしくないという結果になります。
それは理解できます。ただ、そうすると結局Scala自体の利便性がJavaのライブラリに思いっきりしばられてしまいますよね。特に、Javaのコレクションライブラリの設計って、静的型付け重視する人間からするとかなり腐ってるので、その腐ってるライブラリにひきずられるのは、個人的には嫌だなあと思います。
> 後、メソッドチェインについてですが、要はRubyみたいに書きたいよね、ということですよね。その点は同意します。ただ、それもオブジェクト指向的に書く部分においてはよいのですが、関数型っぽく書くときには微妙だということが言いたかったのです。
これもよくわかりませんでした。関数型とオブジェクト指向は自分の考えでは直交する概念であり、相反するものではない(Scalaは関数型かつオブジェクト指向な言語ですし)と思うのですが、この場合の「オブジェクト指向的に書く」と「関数型っぽく書く」はどのような意味合いでしょうか。
> Scalaはいろんなところで妥協している(例えばmethodが第一級で無いとか)と思うし、妥協が必要なのは同意なのですが、その妥協ポイントが僕の好み/感性と異なっていたっていうのも理由かもしれません。
はい。Scalaは実用のために色々な部分を妥協していると私も思います。おっしゃられているメソッドがファーストクラスで無い点もそうですし、その他にも細かい部分を含めるとたくさんあると思います。ただ、その一方でimplicit conversionやhigher-kind generics, implicit parameterなどの面白い機能も取り入れていて、単に妥協しただけの言語ではないとも思っています。