「プログラマーはマシン語を理解しておくべき？」記事へのコメント

言語と目的によるだろ

[hylom (27448)]

Cで書くなら、マシン語とまではいかなくてもパソコンの動作原理（メモリにデータと命令が混在していて、CPUは指定したメモリ位置の命令を読んで・・・とか。いわゆるチューリングマシンの話）は知っておくべきだろうし、JavaとかPerlとかPHPとかだったら別にそんなのよりも必要な知識はいっぱいあるだろうし。

もしかしてJavaとかPerlとかPHPとかでのコーディングははプログラミングじゃねぇ！とかいいたいんじゃ・・・とか思って元記事を見たらそうではないみたいですが。

# 学生時代に実習でマイコンのプログラミングをしたとき、「サブルーチンをアセンブラで書いてもいいですか」と教官に聞いたら「そんな無駄なことする必要はない」とか言われたことをふと思い出した

Re:言語と目的によるだろ

[Anonymous Coward]

Javaならせめてバイトコードを見てみましょう。本当にコンパイラの吐くコードが未だにお馬鹿なことが分かります。ProGuardでも直してくれないので、ProGuardの前にバイトコードを弄るプリプロセッサを自前で作ってます。あと、ProGuardもコンスタントプールの順序がマズくて無駄にwide命令を発っしているので自前パッチして使ってます。

Re:言語と目的によるだろ

[Anonymous Coward]

えーとJVMにおいては最適化はJITコンパイラがやるものであって、javacがやるものでは
無いのですよ。下手にバイトコードレベルでいじって最適化(と思い込んでいる行為)を
やるとかえって遅くなる危険性が高いですよ。

Re:言語と目的によるだろ

[magicalchalk (27784)]

現在のサーバサイド Java の場合、最適化は確率と統計の世界に入ります。

JIT コンパイル自体が実行時間の一部になってしまうので、JIT 範囲を絞り込むためにプロファイリングを行い、HotSpot と判断した部分のみコンパイルします。

なので、同じコードでも、プログラム中での実行頻度によって実行速度が変わる -それも実行の途中から- のです。

こうなるとネイティブ環境での常識が通用しません。マイクロベンチマークを回すと極度に最適化されて良すぎる結果が出るとか。

ルールで最適化の正否を判断できないので、システムの組みように困るというか、悪いと思える場所でも影響がどのくらい有るのか分かりにくいというか。

参照: 日本HP - HP-UX Developer Edge - メモリ・リーク解析とHotSpot JVM [hp.com] (日本HPのサイトですしメモリリークを解説する記事の一部ですが、これが一番端的な解説をしていると思います)