Androidアプリ、C#で書くとJavaの10倍速いことが判明　C言語NDKとほぼ同じ速度

**名無しさん＠涙目です。**(北海道) **[JP]** · NG

https://sec.ch9.ms/ch9/de11/2495af1a-6033-409d-983b-c0912b4ade11/WinDev018UWPXamarin_Custom.jpg

Your world is not just one platform nor device. With Xamarin, you can learn to target
Windows, iOS and Android while providing native experiences.

James will quickly deep dive into how to quickly execute this.
He shows how to do build an application that targets Windows, iOS, Android, and even has a web front end as well!

（動画）
https://channel9.msdn.com/Events/Windows/Windows-Developer-Day-Fall-Creators-Update/WinDev018

**名無しさん＠涙目です。**(東京都) **[US]** · 2017/10/24(火) 17:55:25.04

>>99
使うAPIによってはAOTコンパイルでも結局2回JNIを経由しちゃうのよ。
Javaなら1回なのに。

2017/10/24(火) 20:42:57.04

これってC♯が優れてるのではなくて
単にネイティブコードとjavaとの速度差なのでは？

**名無しさん＠涙目です。**(SB-iPhone) **[US]** · 2017/10/24(火) 21:20:38.89

悔しかったらネイティブJAVA作ってみ。

**名無しさん＠涙目です。**(空) **[US]** · 2017/10/24(火) 21:43:09.87

>>103
ネイティブコードの対義語はjavaではなく中間コード。

**名無しさん＠涙目です。**(庭) **[SA]** · 2017/10/24(火) 21:46:40.72

VBでいいじゃん

**名無しさん＠涙目です。**(家) **[ﾆﾀﾞ]** · 2017/10/24(火) 22:21:38.75

速度は速いかもしれないけど
グラフィック系の命令ってどうなってるんだっけ？
.NETでは事務アプリしか作ったことないからさっぱりワカラン

**名無しさん＠涙目です。**(滋賀県) **[GB]** · 2017/10/24(火) 22:22:47.04

もっと遅いかと思った。
JAVA頑張ってんな。

2017/10/24(火) 22:40:49.07

DATA DIVISIONってギャバンで叶和貴子が言いそうだよな

2017/10/24(火) 23:29:26.55

ベンチマーク取るならなんでアセンブラで書いたコードと比較しないんかね。
アセンブラはCの10倍は速い。

**名無しさん＠涙目です。**(東京都) **[US]** · 2017/10/25(水) 06:36:35.87

>>110
それはないw
今時のCコンパイラは人が下手に書くより速い。

**名無しさん＠涙目です。**(東京都) **[CY]** · 2017/10/25(水) 09:57:10.00

いまどきのコンパイラには最適化と言った冗長なレジスタ操作を省いたり、重複したコードをまとめたりする機能が付いてるんだよなぁ。
だから人間がアセンブラで書いたコードよりシンプルな処理を吐き出して来るんだ。
まあ、おかげでデバッグしたくてもソースとの対応が難しいんだけどな。

**名無しさん＠涙目です。**(空) **[US]** · 2017/10/25(水) 10:40:46.40

LLVMなんて、ある関数呼び出しにおいてその実引数による返り値が一定と判断するとそもそも関数呼び出しコードさえ削除されて即値のコードが吐かれる。
単純な関数ならともかく、複雑な関数だと人間によるリファクタレベルの最適化じゃ太刀打ちできない。
LLVMはコンパイル時に内部で仮想的に実行して最適化判定するんだろうね。

**名無しさん＠涙目です。**(SB-iPhone) **[JP]** · 2017/10/25(水) 11:31:54.23

まあ、ハードの論理回路設計の応用なんだけどね。

**名無しさん＠涙目です。**(京都府) **[US]** · 2017/10/25(水) 14:34:56.16

>>113
新し目のgccでもその最適化してくれるで

**名無しさん＠涙目です。**(宮城県) **[JP]** · 2017/10/25(水) 19:35:05.60

Ｃ丼簡単でええやん

2017/10/25(水) 19:42:26.23

>>113
でも実行時のジャストインタイムでのCPU種別毎の最適化ができないだろ
中間コード方式じゃないから一度バイナリにして配布してしまったら
その後でCPUスペックやコア数違う環境では最適実行にならない

**名無しさん＠涙目です。**(禿) **[PL]** · 2017/10/25(水) 19:43:57.67

>>2
配当？

**名無しさん＠涙目です。**(禿) **[ZA]** · 2017/10/25(水) 19:44:44.55

Javaクライアントアプリでは遅くて使いモノにならんのは当初から言われてた
結果、サーバーサイドアプリ(サーブレット、JSP)がほとんどになったハズなのに、Android出てからクライアントアプリもJavaでってGoogleが採用しちゃったのが元凶
GoogleがJava以外で開発言語提供してたら状況変わってた

**名無しさん＠涙目です。**(大阪府) **[CR]** · 2017/10/25(水) 19:45:49.23

>>31
「いのうえ」で変換かけたら「#上」で出てくるから上を消せばいい

2017/10/25(水) 20:04:45.04

>>117
> でも実行時のジャストインタイムでのCPU種別毎の最適化ができないだろ

そうでも無い。

2017/10/25(水) 20:08:09.34

当たり前でしょJavaは無駄が多すぎる

2017/10/25(水) 20:12:48.02

Javaって普及してるってだけでただのゴミだもんな。

2017/10/25(水) 20:16:07.39

>>115
新しめのgccはコアにLLVM使ってたような？

>>117
JITの最適化は都市神話レベルじゃね？
そもそもLLVMはコンパイル時にJITの最適化してるようなもんだし。

2017/10/25(水) 20:18:29.20

>>121
libgccjit.soみたいなののこと？

これが本格的に使えるようになって
C#やJavaのようなGCの仕組みも実装されれば
C/C++もやっとサーバーサイドでJava並みに速くなれるよね

2017/10/25(水) 20:29:31.72

UnityでIL2CPP通さなくて良くなってビルドが早くなるみたいな話？

2017/10/25(水) 20:39:37.89

>>116
Ｃ丼？おいしいの？どんな味なの？？

2017/10/25(水) 20:59:42.90

>>110 >>112
実際に簡単なサンプルコード書いて動かして比べてみ。
Cは簡単なコードでもスタートアップライブラリやスタックオーバーフローチェックライブラリなどが自動的に組み込まれるので
バイナリサイズがかなりでかくなる。アセンブラなら数百バイトのものが数十k～100kバイトを越えるサイズになる。
これだけ差があるとロードするだけでも時間差が大きい。本来やりたい処理を実行する時間よりロードする時間のほうが長くなる。
サーバ上のアプリのようにたくさんアクセスされて何度も実行される処理ならさらに差が出る。
数百バイトならCPUのキャッシュに入ってしまってディスクからリロードする時間さえ不要になるが、
Cのバイナリならでかいから一々ディスクから読み直さなければならない。

2017/10/25(水) 21:28:21.85

>>128
それはないw
CPUキャッシュの次はHDDとかの二次記憶ってw
一次記憶のSDRAMの存在忘れてねぇ？

**名無しさん＠涙目です。**(東京都) **[US]** · 2017/10/25(水) 22:29:01.22

>>107
CGI+がラップしてあってそれを使える
俺もあまり使わんから詳しくはわからん

**名無しさん＠涙目です。**(東京都) **[US]** · 2017/10/25(水) 22:36:28.67

>>130
×CGI+
○GDI+

**名無しさん＠涙目です。**(茸) **[AU]** · 2017/10/25(水) 22:46:13.40

>>128
んでそれでサイズ可変のJSONとかどう処理するんだよ

**名無しさん＠涙目です。**(庭) **[US]** · 2017/10/25(水) 22:48:05.30

どういうこと？Androidアプリが10倍ヌルサクになるの？

2017/10/25(水) 22:58:09.27

>>125
サーバサイドの開発案件はふつーにターゲットに合わせてbuildするだけでしょ。

2017/10/25(水) 23:01:05.90

Javaは言語として悪くはないと思うが普及と引き換えにソースがゴミ化した

**名無しさん＠涙目です。**(庭) **[SA]** · 2017/10/25(水) 23:04:20.52

>>135
後方互換気にした影響で、言語仕様も美しくないしな。
それもあって、JVM言語乱立してるんだろうね

**名無しさん＠涙目です。**(宮城県) **[US]** · 2017/10/25(水) 23:57:58.21

考え方はいいんだけどなあ。トロいのは致命的だったな。

2017/10/25(水) 23:59:18.44

意味不明

**名無しさん＠涙目です。**(catv?) **[CO]** · 2017/10/26(木) 10:01:11.98

>>68
初期のオラクルの立ち上げに膨大な開発費が掛かっているからしょうがない。
正直、オラクルだけがSQLを満足に叩ける実装だったし、処理系以外にも稼働
中のストレージ処理とかで他に追随できない製品を出していた。

SQL-92./2000 なんかの標準規格も、以降は全てオラクルに倣っている。

オラクルの実装がこなれてきた、Cybaseもオラクルの機能を模倣するように
なっていまMSのSQL Server になっているし、MySQLなんかも出てこなかった。

そういう会社がいまJavaやMySQLを逆に吸収し自社の基盤としてるのは面白いと思う。

**名無しさん＠涙目です。**(dion軍) **[IN]** · 2017/10/26(木) 11:07:03.74

じゃぁJavaしかわからん俺が今から調べながらC#で書くぞ。
１０倍早いんだよな？

**名無しさん＠涙目です。**(catv?) **[CO]** · 2017/10/26(木) 11:17:01.10

>>140
やってみること手を動かすことは大事。

とりあえずAndroid StudioとXamarinの環境を作るんだ。

**名無しさん＠涙目です。**(SB-iPhone) **[US]** · 2017/10/26(木) 11:28:49.97

アンドロイドはあれだけの機種の
互換性取るためにJava使わざるを
得ないからね x86サポートなんか
やめたら良いのに

**名無しさん＠涙目です。**(東京都) **[KR]** · 2017/10/26(木) 11:43:44.75

>>142
機種間の互換性はOSやライブラリーで取るもんだろ？

**名無しさん＠涙目です。**(空) **[BE]** · 2017/10/26(木) 12:43:11.86

>>143
流石にCPUアーキテクチャが違ったら無理w

**名無しさん＠涙目です。**(東京都) **[KR]** · 2017/10/26(木) 12:59:11.57

>>144
いや、x86版Androidにはバイナリトランスレータが乗ってるので
ARMネイティブアプリも動く

**名無しさん＠涙目です。**(庭) **[BR]** · 2017/10/26(木) 14:35:18.83

もうインテルが悪いって事で

**名無しさん＠涙目です。**(東京都) **[CN]** · 2017/10/27(金) 02:08:29.45

インテルのコンパイラは

**名無しさん＠涙目です。**(空) **[EG]** · 2017/10/27(金) 03:55:07.93

中間コード→ネイティブにリコンパイルしてネイティブで実行できるようにはならんの？

**名無しさん＠涙目です。**(東京都) **[CY]** · 2017/10/27(金) 08:44:26.53

むしろVMコードを直接実行出来るCPU作るのです。

**名無しさん＠涙目です。**(埼玉県) **[US]** · 2017/10/27(金) 08:53:05.46

本当はjavaだってarmはハードウェアアクセラレータあるから
本気だせば遅い訳じゃねぇんだけど

つまるとこ、使ってないだけじゃろ

2017/10/27(金) 11:01:39.65

>>67
氏にそうな咳してるなｗ

2017/10/27(金) 11:03:17.64

>>96
直近のシェアが落ちてるじゃないか