昨日「Ｃでのバッファリングの効果が見られなかった」という主旨のことを書いたところ、早速jzkey氏からご指摘頂きました。有難うございます。 早速、調べてみました。 →参考：「Manpage of SETBUF」 以下、頂いた３点の指摘について個別に書きます。 1) Cの…

Javaでバッファリングをした場合の出力と比較するために、Ｃでバッファリングした出力の場合も見てみよう。 ※以後、比較にはfputsを用いる。また、念のためにメッセージもconst char[]にした。 #include int main(void) { int i; FILE *out; char buffer[819…

バイナリ出力にバッファリングを適用したものを、今度は最適化有で実行してみよう。 結果は以下である。 Flat profile of 3.92 secs (250 total ticks): main Interpreted + native Method 0.4% 0 + 1 java.io.WinNTFileSystem.getBooleanAttributes 0.4% 0 …

バイナリ出力にバッファリングを実装するにはBufferedOutputStreamを用いる。 具体的には、以下のようになる。 import java.io.FileOutputStream; import java.io.BufferedOutputStream; import java.io.OutputStream; class Test { public static void main…

文字列出力よりもバイナリ出力の方が速いだろうと思っていたが、最適化した場合には結果が逆になってしまった。 これはどういうことだろう。 Profileを見比べても、明らかにバイナリ出力の方が処理が単純で、速くなりそうな気がする。 一方の文字列出力は多…

この日記の2004.02.28付けの「Javaの実行時最適化の効果」について、JDK1.3のリリース時期について間違っていましたので訂正しました。

屁理屈太郎氏から性能を比較するときに注意すべき点を教授頂いています。とても有難いことです。→「プログラム言語の速度比較について」 頂いているご意見について、今のところの状況を書いておこうと思います。 ※以下、枠内は屁理屈太郎氏の日記からの引用…

Javaではその仕様上必須となる文字コード変換が実行速度の低下の原因であるという結論から、前回は文字コード変換無しの出力を実際に実行してみた。 その結果は予想通りだったわけだが、こんどは同じ処理について実行時最適化を行った場合を見てみよう。 Fla…

文字コード変換を行わせないような強引なコーディングをJavaで行ってみて、実際にどうなるかを見てみよう。 通常こうした形で文字列を扱うことは、Javaでは推奨されていない。今回は比較のための特殊な場合だと思って頂きたい。 import java.io.FileOutputSt…

今までの実行Profileを見ると、文字コードの変換にかなりの時間がかかっていることが分かる。 以前にも書いた通り今回の検証はWindowsXP上で行っているから、ファイル出力をする際にJavaの内部文字コードからShift_JISへの変換を行っている。その負荷が高い…

こんどは、実行時最適化をした場合のProfileを見てみよう。 Flat profile of 7.46 secs (458 total ticks): main Interpreted + native Method 1.3% 0 + 6 java.io.FileOutputStream.writeBytes 0.2% 0 + 1 java.util.jar.Attributes.read 0.2% 0 + 1 sun.io…

実行時最適化を行わないJavaの遅さは、驚異的なものだった。 では何故、そんなにも遅いのだろうか。 もう一度、Javaが遅い理由として挙げられているものを振り返ってみよう。 実行時のエラーチェックの厳密さ VM（バーチャルマシン）という仕組み 最適化の不…

実行時最適化されていないJavaは、最適化されたＣよりも桁違いに遅い 実行時最適化されたJavaは、ようやくＣと比較できる程度の性能となる それでもまだ、最適化されたＣの方に分があるようだ 今後は「なぜJavaは遅いのか」を中心に、検証して行きたい。

「JavaとＣの実行比較」のＣのソースを、fputsに変えてみよう。 #include int main(void) { int i; FILE *out; out = fopen("c_log.txt", "w"); for(i = 0; i Hello world!\n", out); fclose(out); return (0); } これを以前と同様に最適化オプションを変え…

さて「JavaとＣの実行比較」の結果には、Javaの実行方法にも疑問がある。 Javaの実行時には最適化が為される。 その結果と、最適化されていないＣ言語のそれを比較すること自体、公正な態度ではないのだ。 では、Javaの実行時最適化の機能を切った状態で実行…

「JavaとＣの実行比較」にＫ氏から「Ｃで、Javaのprintに相当するのはfputsではないか」という主旨のコメントを頂きました。 有難うございます。 fprintfを選んだのは、fputsよりもJavaのprintに名前が似ているという理由でした。 内部的な処理としては、ご…

「JavaとＣの実行比較」で、実際にＣとJavaで似たような処理を実行させ、その処理時間を比較してみた。 その結果「Javaの方が速い」となったわけだが、それは本当なのだろうか。 検証してみよう。 まずは屁理屈太郎氏も指摘している、最適化の問題がある。 …

2004.02.23付で書いた「Javaの性能」について、ご意見の表明があった。 こんなところなんて誰も読んでないだろうとたかをくくっていたので、正直嬉しい。 以下、そのご意見の私なりの要約である。（詳細な主張は、リンク先を参照頂きたい）へこり日記「言い…

いまだに「Javaなんて遅くて使い物にならん」とか言っている人がいる。 実際に使ってみて、実測してみてからそういうことは言うものだ。 JDK1.3以降、Javaの実行速度はかなり向上しており、十分実用になっていると私は思う。 Ｃ言語は速い？はぁ？ 下手な組…