Android NDKを使用してJava言語とC言語で速度比較をするへのコメント

匿名より

匿名 — Wed, 11 Jan 2012 02:08:19 +0000

JITやhotspotに言及してる人居るけど、この記事の2010/3てまだ2.2も発表してない頃なんだし
そのころのDalvikには無いんじゃねーの？

匿名より

匿名 — Tue, 06 Dec 2011 01:21:46 +0000

性能比較になってないね。
クラスライブラリを読み込む時間の考慮が無いし、
実行時コンパイルが効く前で性能計って意味があるか？

実行時コンパイルが効けば、Javaプログラムもネイティブコードで動作するので、
レイテンシもスループットもC++プログラムとそん色ないが、

匿名より

匿名 — Tue, 09 Aug 2011 15:12:39 +0000

long について勉強すべき。(C->32bit, Java->64bit)
でもまぁ世の中のプログラマーはみんなこんなレベルなんだろう。
あと HotSpot も考慮してあげるべき。
関数化して何回か事前に呼んであげる。
実際のアプリでも HotSpot の効果は高い。

匿名より

匿名 — Mon, 07 Mar 2011 01:51:19 +0000

なかなか興味深いですね。
一つ気になるのは（JavaもAndroidも詳しくないので）

> System.loadLibrary(“calculate”);

この部分のオーバーヘッドは影響無いのでしょうか？
まぁこれを含めても十分速いみたいですが。(^^;)

匿名より

匿名 — Tue, 01 Mar 2011 06:05:57 +0000

たぶんこれ、classファイルがJVMにロードされる時間も含まれてるんじゃないですか？
これじゃ実行時間（演算速度です）は比較できませんよ。
ターンアラウンドタイムの比較でしたらこの記事の通りですが。

Javaが速いケースってーのはWEBみたいに常にJVM（メモリ）上でスタンバイされているとき。

匿名より

匿名 — Sun, 02 Jan 2011 03:04:37 +0000

　おそらくCの方のsizeof(long)をしたら32bitになってんじゃないですか？
　32bit CPUでlongの演算するときFPUを使ったり(CPUによって色々)するんで結構
その差が激しいと思います。

　せっかくネイティブキットを使うなら単純な演算より、SIMD(CPUにあるなら)や
スタック変数とポインタの駆使でしょうね。この辺りの差はPCでやっても体感出きるので
デカいと思います。

k より

Mon, 24 May 2010 05:44:04 +0000

longだからじゃない？

参考になりましたより

参考になりました — Tue, 04 May 2010 22:57:57 +0000

おっと。お礼を忘れておりました・・失礼しました。
ありがとうございました。

参考になりましたより

参考になりました — Tue, 04 May 2010 22:57:15 +0000

参考にさせていただきました。
結果が１０のほうですが、Xperiaで走らせたところ軒並み１０倍～２０倍程度高速でした。

乳牛より

乳牛 — Fri, 23 Apr 2010 15:54:48 +0000

最近のJVMだとHotSpotで最適化なので、呼出が１回こっきりだと最適化されていないのかもしれません。。。
と、いいつつDalvikVMはJITすらまだ未実装（いまチャレンジ中みたいです）なので、HotSpotが載っているとは思えないので、上記の実験結果通りバイトコードをインタープリタ実行されるJavaのパフォーマンスがネイティブに比べて圧倒的に悪いという事なのでしょうね。

ちょっと複雑なことをやるとNDKが必要になってきそうですね。勉強になりました。

Android NDKを使用してJava言語とC言語で速度比較をする へのコメント

匿名 より

匿名 より

匿名 より

匿名 より

匿名 より

匿名 より

k より

参考になりました より

参考になりました より

乳牛 より

Android NDKを使用してJava言語とC言語で速度比較をするへのコメント

匿名より

匿名より

匿名より

匿名より

匿名より

匿名より

参考になりましたより

参考になりましたより

乳牛より