>>99
使うAPIによってはAOTコンパイルでも結局2回JNIを経由しちゃうのよ。
Javaなら1回なのに。 これってC♯が優れてるのではなくて
単にネイティブコードとjavaとの速度差なのでは?
>>103
ネイティブコードの対義語はjavaではなく中間コード。 0107名無しさん@涙目です。(家) [ニダ]2017/10/24(火) 22:21:38.75ID:8+C8brV70
速度は速いかもしれないけど
グラフィック系の命令ってどうなってるんだっけ?
.NETでは事務アプリしか作ったことないからさっぱりワカラン
DATA DIVISIONってギャバンで叶和貴子が言いそうだよな
ベンチマーク取るならなんでアセンブラで書いたコードと比較しないんかね。
アセンブラはCの10倍は速い。
>>110
それはないw
今時のCコンパイラは人が下手に書くより速い。 いまどきのコンパイラには最適化と言った冗長なレジスタ操作を省いたり、重複したコードをまとめたりする機能が付いてるんだよなぁ。
だから人間がアセンブラで書いたコードよりシンプルな処理を吐き出して来るんだ。
まあ、おかげでデバッグしたくてもソースとの対応が難しいんだけどな。
LLVMなんて、ある関数呼び出しにおいてその実引数による返り値が一定と判断するとそもそも関数呼び出しコードさえ削除されて即値のコードが吐かれる。
単純な関数ならともかく、複雑な関数だと人間によるリファクタレベルの最適化じゃ太刀打ちできない。
LLVMはコンパイル時に内部で仮想的に実行して最適化判定するんだろうね。
0115名無しさん@涙目です。(京都府) [US]2017/10/25(水) 14:34:56.16ID:Vk0gsmD70
>>113
新し目のgccでもその最適化してくれるで 0116名無しさん@涙目です。(宮城県) [JP]2017/10/25(水) 19:35:05.60ID:Hu0zj09y0
C丼簡単でええやん
0117名無しさん@涙目です。(公衆電話) [TH]2017/10/25(水) 19:42:26.23ID:mNi6ahmk0
>>113
でも実行時のジャストインタイムでのCPU種別毎の最適化ができないだろ
中間コード方式じゃないから一度バイナリにして配布してしまったら
その後でCPUスペックやコア数違う環境では最適実行にならない 0118名無しさん@涙目です。(禿) [PL]2017/10/25(水) 19:43:57.67ID:E/CP2+ka0
Javaクライアントアプリでは遅くて使いモノにならんのは当初から言われてた
結果、サーバーサイドアプリ(サーブレット、JSP)がほとんどになったハズなのに、Android出てからクライアントアプリもJavaでってGoogleが採用しちゃったのが元凶
GoogleがJava以外で開発言語提供してたら状況変わってた
0120名無しさん@涙目です。(大阪府) [CR]2017/10/25(水) 19:45:49.23ID:L//5eWpP0
>>31
「いのうえ」で変換かけたら「#上」で出てくるから上を消せばいい >>117
> でも実行時のジャストインタイムでのCPU種別毎の最適化ができないだろ
そうでも無い。 0122名無しさん@涙目です。(四国地方) [ID]2017/10/25(水) 20:08:09.34ID:ajPTiPWg0
当たり前でしょJavaは無駄が多すぎる
Javaって普及してるってだけでただのゴミだもんな。
>>115
新しめのgccはコアにLLVM使ってたような?
>>117
JITの最適化は都市神話レベルじゃね?
そもそもLLVMはコンパイル時にJITの最適化してるようなもんだし。 0125名無しさん@涙目です。(公衆電話) [TH]2017/10/25(水) 20:18:29.20ID:mNi6ahmk0
>>121
libgccjit.soみたいなののこと?
これが本格的に使えるようになって
C#やJavaのようなGCの仕組みも実装されれば
C/C++もやっとサーバーサイドでJava並みに速くなれるよね UnityでIL2CPP通さなくて良くなってビルドが早くなるみたいな話?
0127名無しさん@涙目です。(やわらか銀行) [SE]2017/10/25(水) 20:39:37.89ID:0a3WHuio0
>>110 >>112
実際に簡単なサンプルコード書いて動かして比べてみ。
Cは簡単なコードでもスタートアップライブラリやスタックオーバーフローチェックライブラリなどが自動的に組み込まれるので
バイナリサイズがかなりでかくなる。アセンブラなら数百バイトのものが数十k〜100kバイトを越えるサイズになる。
これだけ差があるとロードするだけでも時間差が大きい。本来やりたい処理を実行する時間よりロードする時間のほうが長くなる。
サーバ上のアプリのようにたくさんアクセスされて何度も実行される処理ならさらに差が出る。
数百バイトならCPUのキャッシュに入ってしまってディスクからリロードする時間さえ不要になるが、
Cのバイナリならでかいから一々ディスクから読み直さなければならない。 >>128
それはないw
CPUキャッシュの次はHDDとかの二次記憶ってw
一次記憶のSDRAMの存在忘れてねぇ? 0130名無しさん@涙目です。(東京都) [US]2017/10/25(水) 22:29:01.22ID:q2ds1a/20
>>107
CGI+がラップしてあってそれを使える
俺もあまり使わんから詳しくはわからん 0131名無しさん@涙目です。(東京都) [US]2017/10/25(水) 22:36:28.67ID:q2ds1a/20
0132名無しさん@涙目です。(茸) [AU]2017/10/25(水) 22:46:13.40ID:YVhshoZT0
>>128
んでそれでサイズ可変のJSONとかどう処理するんだよ 0133名無しさん@涙目です。(庭) [US]2017/10/25(水) 22:48:05.30ID:S61RVbPI0
どういうこと?Androidアプリが10倍ヌルサクになるの?
>>125
サーバサイドの開発案件はふつーにターゲットに合わせてbuildするだけでしょ。 Javaは言語として悪くはないと思うが普及と引き換えにソースがゴミ化した
>>135
後方互換気にした影響で、言語仕様も美しくないしな。
それもあって、JVM言語乱立してるんだろうね 0137名無しさん@涙目です。(宮城県) [US]2017/10/25(水) 23:57:58.21ID:uxLv1PZH0
考え方はいいんだけどなあ。トロいのは致命的だったな。
0138名無しさん@涙目です。(やわらか銀行) [US]2017/10/25(水) 23:59:18.44ID:cFNNDXPQ0
意味不明
>>68
初期のオラクルの立ち上げに膨大な開発費が掛かっているからしょうがない。
正直、オラクルだけがSQLを満足に叩ける実装だったし、処理系以外にも稼働
中のストレージ処理とかで他に追随できない製品を出していた。
SQL-92./2000 なんかの標準規格も、以降は全てオラクルに倣っている。
オラクルの実装がこなれてきた、Cybaseもオラクルの機能を模倣するように
なっていまMSのSQL Server になっているし、MySQLなんかも出てこなかった。
そういう会社がいまJavaやMySQLを逆に吸収し自社の基盤としてるのは面白いと思う。 0140名無しさん@涙目です。(dion軍) [IN]2017/10/26(木) 11:07:03.74ID:ZJP0ly660
じゃぁJavaしかわからん俺が今から調べながらC#で書くぞ。
10倍早いんだよな?
>>140
やってみること手を動かすことは大事。
とりあえずAndroid StudioとXamarinの環境を作るんだ。 アンドロイドはあれだけの機種の
互換性取るためにJava使わざるを
得ないからね x86サポートなんか
やめたら良いのに
>>142
機種間の互換性はOSやライブラリーで取るもんだろ? >>143
流石にCPUアーキテクチャが違ったら無理w >>144
いや、x86版Androidにはバイナリトランスレータが乗ってるので
ARMネイティブアプリも動く 中間コード→ネイティブにリコンパイルしてネイティブで実行できるようにはならんの?
むしろVMコードを直接実行出来るCPU作るのです。
本当はjavaだってarmはハードウェアアクセラレータあるから
本気だせば遅い訳じゃねぇんだけど
つまるとこ、使ってないだけじゃろ