2004-04-01 [長年日記]
新年度
今日から新年度なわけですが、だからといってどうという訳ではありません。会社にくるときに新人らしき人がちらほら歩いているのは見かけましたが、会社的には配属はまだ先なので変わった様子もありません。
しっかし、うちのグループにもかわいい(ここ重要)女の子が配属されないかな(ぉ。
Javaの性能
雨谷の日和のJavaの性能からの一連の検証なのだけれど、個人的にはJavaの性能には(Cの性能にも)ほとんど興味はない。
そもそもの言語のコンセプトとして、Javaは速度を求めていない。もちろん高速化の努力がなされていることは認めるし、実際に速くなってきているであろうことはわかっている。しかしそれは第一義ではない。
"write once,run anywhere."の言葉が示すようにJavaの言語コンセプトはその可搬性にある。
それ以外にも、オブジェクト指向な言語仕様や豊富なエラー処理などといった、「Javaの便利な」機能てんこ盛りで、その上で
Cには,プログラマは,自分が何をしようとしているかを知っているという基本哲学は残されている。
[プログラミング言語C第2版より引用]
2004-04-02 [長年日記]
それが分からないとそもそも「速度をあまり求めない場合は機能が豊富な言語を選択すればいいし、速度を求める場合にはそれなりの速度の言語を選択する必要がある」という判断をするための手掛かりが無いような気がしているのですが。
[雨谷の日和より引用]
それはそのとおりだと思います。ただ、私の中の基準は明確で、リッチな環境が使えるならば(そしてその環境に習熟しているならば)、その環境に頼るのが正しいあり方だと思っています。
私ごときの考えるようなことは大概先達が述べているようなので引用します。
Javaは遅い
・大丈夫。Javaがどんなに遅かったとしてもあなたの作るプログラムよりかは十分に速いし、信用できるから。
[真・コンピュータ用語辞典より引用]
2004-04-03 [長年日記]
もちろん、依然として速度を要求するアプリケーションもあるだろう。 コンピュータを使って解きたいと思う問題のいくつかは、 コンピュータ自身によって作られる。例えば、コンピュータで 生成されたビデオイメージの処理は、生成側のコンピュータの 速度に追い付いていなければならないだろう。 さらに、いくらマシンサイクルがあっても本質的にそれを喰い潰してしまう 類の処理というのがある。イメージレンダリング、暗号、シミュレーションといったものだ。
[百年の言語より引用]
- 時間的にクリティカルな処理
- 速ければ速いほどいい処理
2004-04-08 [長年日記]
2004-04-09 [長年日記]
医学都市伝説の、アルカイダ掃討作戦を読んでいて、"村の神社で守り神になってもらいますんや。"というところで笑ってしまった。夢の話とはいえ、実に日本的な気質をあらわしていると思う。
アルカイダということだから当然イスラム教徒なのだろうけど、それを守り神として神社に祀る、つまり神道の神様にしてしまうわけだ。神の元に導かれるはずが自分が神になってしまっては、テロリストの方としてもたまったものではないだろう。
ただ、笑ってしまったというのは、そういう不条理さだけではなくて実際にあってもおかしくはないと思うからである。
さすがに、この現代社会において(そういう意味では、私の地元も相当田舎ではあるけど、こういう感覚は十分に現代的であった)、そういうのはないだろうという気もするのだけど、もしかすると山奥の山村にいくとこういうこともありえるのかも知れないと思ってしまう。
だって、東京のど真ん中で「首塚には背中を向けて座ってはいけない」なんて話があるぐらいだからねぇ。
2004-04-12 [長年日記]
メモリ動的確保
「Cの動的メモリ確保が遅いのかも」ということなので、ちょっと調べてみました。
まず、malloc/freeがどのように実装されているかというと、詳細は説明するのが面倒なので「プログラミング言語C第二版」の記憶割り当てあたりを参照してもらうとして、簡単に言うと二つの機能により実現されています。
- OSからの動的メモリ確保
- リンクによる空きリストの管理
同一の関数の中で可変長配列とallocaの両方を使うと、 可変長配列の領域が解放されるときに、 その可変長配列が割り当てられたあとにallocaによって割り当てられた領域も すべて解放されることになります
[C言語ファミリに対する拡張機能より引用]
というところからの推測です。そして、allocaの実装がどうなっているかというと、多くの場合スタック上にメモリを確保していると思われます。
こうすることにより、関数を抜けたときに領域が開放されるという仕様がより自然に実現できます。
そして、スタックポインタの操作だけですむgccの可変長配列の方がmallocによるメモリの動的確保より速いのは自明でしょう。