アカウント名:
パスワード:
ChromeOSでAndroidアプリが動くみたいな感じでならWindowsRTだろうがPalm WebOSだろうが受け入れられるでしょ第三のOSが現れないのは欲のかきすぎなんだよ
あとスマートウォッチは来ないからサムソンはIOTウォッチくらいにしとけスマフォからセンサーが読めたり信号をプッシュできれば十分だっての
問題はむしろJavaの遅さにあるわけで、できれば頑張ってiPhone互換APIを実装してほしいところ。
いまだこんなこと言ってるバカがいるの?AndroidのDalvikは通常のJavaと比べれば抽象度はかなり低いVMによるオーバヘッドはJavaVMとは比べるべくもない加えて、泥の開発環境はJavaだけでなくC++のコードも使える最近のハイエンド向けのゲームはネイティブコードでがっちり組まれとるわ
未だNDKは二級市民という位置付けでして、Javaのレイヤが残るのです。http://stackoverflow.com/questions/13624499/android-ndk-nativeactivity... [stackoverflow.com]>NativeActivity will not give a performance boost to your framework. It still uses JNI to communicate with the System, only under the cover.http://stackoverflow.com/questions/25626919/advantages-of-using-native... [stackoverflow.com]>Keep in mind that even a "native activity" is still heavily jni based - it just uses stock java code rather than custom code written by you.
未だNDKは二級市民という位置付けでして、Javaのレイヤが残るのです。
http://stackoverflow.com/questions/13624499/android-ndk-nativeactivity... [stackoverflow.com]>NativeActivity will not give a performance boost to your framework. It still uses JNI to communicate with the System, only under the cover.http://stackoverflow.com/questions/25626919/advantages-of-using-native... [stackoverflow.com]>Keep in mind that even a "native activity" is still heavily jni based - it just uses stock java code rather than custom code written by you.
(去年のsradコメント [srad.jp]より)
レイヤが残ったから一律で遅くなるわけじゃないんだけどね当然、スナドラはじめ泥向けチップはそのレイヤ特化の命令セットに合わせてきてるしIntelのような互換モードを用意してるような状態ならそら遅くなるが
挙げ足取りだけどDalvikはLolipopで廃止されてARTになってるぞ。
抽象度?
AndroidのJavaが遅い、という意見に対して、全く、なんにも、反論できていないのが笑えた。
Javaは普通の言語と比べて10倍とか1000遅いらしいけど、現状最新ではないiphoneipadで重いとか落ちるアプリやゲームが型落ちでアプデも来ないようなAndroidでさくさく動くような有様でね
何が優れているかは単純には言えないね
JavaやC#の実行速度はC言語の2倍くらいですよ。スクリプト言語では更に一桁上がります。
マイクロベンチマークなら、それぐらいでしょうね。
「速度が2倍」なら「速い」ってことなんだけど、そういう意味で使ってる?JavaはCの半分の時間で処理を終えられるし、スクリプトはその1/10の時間で終わるの?
AndroidはJavaといっても言語だけでVMはJava仕様じゃないからなぁ...以前は、半端なく遅かったみたいで、ARTになってようやくそういうレベルじゃないかなJavaの言語仕様が大量のメモリを扱うのに向いてないというのもある
スクリプト言語の方が速く走るとは魔法のプラットフォームですな#ブレーキかけてるの?
違うよね。平均的にはJavaなんかの抽象度の高い言語の方が処理速度は遅いに決まってる。って言うか速度だけを求めるならアセンブラか機械語で書けば良いだろうに。
ただ、動的言語の動的バインディングが活用できる場面(入力された実データの型に応じて処理を置き換えたり)では、Cのような静的な言語よりメモリ容量、あるいは処理速度面で有利になる場合があるのは確か。JITの最適化技術やプラットフォームの高速化もあって、スクリプト言語が使用される場面で処理時間に不満を感じるケースはずいぶん減ったと思う。
実行する処理によって大きく変わるから、「2倍くらい」とか「10倍とか1000」という値自体にすでに意味がない。
どういう処理でどれくらい遅くなるのかなんて、実行する処理の種類や実行順序等々の変動要素が多すぎて言葉で説明しきれないから、値が1人歩きするのを警戒してJavaの中の人は数値的な話を出さないし。(そもそもチャンピオンデータならCより速いケースも有るし、それも含めて各種VMのJITなどの高速化技術を素人はだしのプログラマ(笑)に説明するのは、原始人に原子力を説明するくらい困難だろう)このあたりの事情はC#もたぶん同じだと思う(よく知らんので単なる推測だが)。
C#も同じと言えば同じだが、JavaやDalvikよりはまし
> 問題はむしろJavaの遅さにあるわけで
ところが現実にはスマホのマシンパワーも十分すぎるほど上昇し今や仮想化のレイヤーを挟んでいたAndroidのほうが過去互換性の面で圧倒的に有利かたやiOSはゲーム以外では散々な状態になってとくに一般人からの信頼を完全に失ったまさに没落一直線状態なんですよね
Apple信者が必死にゲームだけ持ち出してiOSの優位性を叫んでも今日もiOSはバグばかりのボロクソで一般人からは見えてる地雷扱いされてる惨状キチガイゲーム馬鹿以外の大多数の人類は今日もAndroidでのんびり気楽に快適に日常を過ごしています
カジュアルユーザーにしたらそうかもしれませんが、ここはsradですよ…。スマホの性能はまだ足りないし、特に致命的なのはAndroidのレイテンシーの悪さ。GC死すべし。
sradに来るような人間は端末で処理せずサーバ側に処理流すでしょ言っちゃ悪いけど端末に性能求めるの本当にもうゲームくらいっすよ
そんなことはないですよ。ペイントアプリとか、楽器アプリとか、画像編集アプリとか、鏡アプリとかを使わないカジュアルユーザーであれば話は別ですけども。
ほんとに突き詰めると音源はALSAで絵はGIMPでOfficeはAOoみたいなことになってまた違う話になってしまうけどな・・・
むしろその手を小型端末ですマスほうがカジュアルユーザだとおもうけど
何を言っているのかわからないんだけど。もう少し詳しく。
いや、そういう話でしょう。Ubuntu Touchには期待しています。
# 補足するとALSAよりもPulseAudioの方が、PulseAudioよりもJackの方がレイテンシが低いです。 http://stackoverflow.com/questions/29245583/alsa-vs-pulseaudio-latency... [stackoverflow.com] http://unix.stackexchange.com/questions/68772/jack-vs-pulseaudio-how-i... [stackexchange.com]
# SamsungはAndroidでJackを使えるようにしています (Samsung Professional Audio SDK)が、# 他のメーカーが追従しないのは何故だろう?
いや、AndroidのJavaの遅さの話で「音源はALSAで」という話が出てくることが理解できないんだが。それらは違うレイヤーで動いているものだから、排他ではないだろう。Javaが直接音源チップをコントロールしていると思ってるの?
Androidは昔からALSAを使ってますよ。
Alsaのdmixのことです。 >レイヤー
バッテリーで動く携帯端末にとって、マシンパワーが十分だから重くても大丈夫という話は通らないよ。軽けりゃそれだけ同じ処理をしてバッテリーを長時間持たせられるんだから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
Androidが動けばいいんじゃね? (スコア:0)
ChromeOSでAndroidアプリが動くみたいな感じでなら
WindowsRTだろうがPalm WebOSだろうが受け入れられるでしょ
第三のOSが現れないのは欲のかきすぎなんだよ
あとスマートウォッチは来ないからサムソンはIOTウォッチくらいにしとけ
スマフォからセンサーが読めたり信号をプッシュできれば十分だっての
Re:Androidが動けばいいんじゃね? (スコア:0)
問題はむしろJavaの遅さにあるわけで、できれば頑張ってiPhone互換APIを実装してほしいところ。
Re: (スコア:0)
いまだこんなこと言ってるバカがいるの?
AndroidのDalvikは通常のJavaと比べれば抽象度はかなり低い
VMによるオーバヘッドはJavaVMとは比べるべくもない
加えて、泥の開発環境はJavaだけでなくC++のコードも使える
最近のハイエンド向けのゲームはネイティブコードでがっちり組まれとるわ
Re:Androidが動けばいいんじゃね? (スコア:1)
(去年のsradコメント [srad.jp]より)
Re: (スコア:0)
レイヤが残ったから一律で遅くなるわけじゃないんだけどね
当然、スナドラはじめ泥向けチップはそのレイヤ特化の命令セットに合わせてきてるし
Intelのような互換モードを用意してるような状態ならそら遅くなるが
Re: (スコア:0)
挙げ足取りだけどDalvikはLolipopで廃止されてARTになってるぞ。
Re: (スコア:0)
抽象度?
Re: (スコア:0)
AndroidのJavaが遅い、という意見に対して、全く、なんにも、反論できていないのが笑えた。
Re: (スコア:0)
Javaは普通の言語と比べて10倍とか1000遅いらしいけど、
現状最新ではないiphoneipadで重いとか落ちるアプリやゲームが
型落ちでアプデも来ないようなAndroidでさくさく動くような有様でね
何が優れているかは単純には言えないね
Re: (スコア:0)
JavaやC#の実行速度はC言語の2倍くらいですよ。
スクリプト言語では更に一桁上がります。
Re: (スコア:0)
マイクロベンチマークなら、それぐらいでしょうね。
Re: (スコア:0)
「速度が2倍」なら「速い」ってことなんだけど、そういう意味で使ってる?
JavaはCの半分の時間で処理を終えられるし、スクリプトはその1/10の時間で終わるの?
Re: (スコア:0)
AndroidはJavaといっても言語だけでVMはJava仕様じゃないからなぁ...
以前は、半端なく遅かったみたいで、ARTになってようやくそういうレベルじゃないかな
Javaの言語仕様が大量のメモリを扱うのに向いてないというのもある
Re: (スコア:0)
スクリプト言語の方が速く走るとは魔法のプラットフォームですな
#ブレーキかけてるの?
Re: (スコア:0)
違うよね。
平均的にはJavaなんかの抽象度の高い言語の方が処理速度は遅いに決まってる。
って言うか速度だけを求めるならアセンブラか機械語で書けば良いだろうに。
ただ、動的言語の動的バインディングが活用できる場面(入力された実データの型に応じて処理を置き換えたり)では、Cのような静的な言語よりメモリ容量、あるいは処理速度面で有利になる場合があるのは確か。
JITの最適化技術やプラットフォームの高速化もあって、スクリプト言語が使用される場面で処理時間に不満を感じるケースはずいぶん減ったと思う。
Re: (スコア:0)
実行する処理によって大きく変わるから、「2倍くらい」とか「10倍とか1000」という値自体にすでに意味がない。
どういう処理でどれくらい遅くなるのかなんて、実行する処理の種類や実行順序等々の変動要素が多すぎて言葉で説明しきれないから、値が1人歩きするのを警戒してJavaの中の人は数値的な話を出さないし。(そもそもチャンピオンデータならCより速いケースも有るし、それも含めて各種VMのJITなどの高速化技術を素人はだしのプログラマ(笑)に説明するのは、原始人に原子力を説明するくらい困難だろう)
このあたりの事情はC#もたぶん同じだと思う(よく知らんので単なる推測だが)。
Re: (スコア:0)
C#も同じと言えば同じだが、JavaやDalvikよりはまし
Re: (スコア:0, 荒らし)
> 問題はむしろJavaの遅さにあるわけで
ところが現実にはスマホのマシンパワーも十分すぎるほど上昇し
今や仮想化のレイヤーを挟んでいたAndroidのほうが過去互換性の面で圧倒的に有利
かたやiOSはゲーム以外では散々な状態になって
とくに一般人からの信頼を完全に失ったまさに没落一直線状態なんですよね
Apple信者が必死にゲームだけ持ち出してiOSの優位性を叫んでも
今日もiOSはバグばかりのボロクソで一般人からは見えてる地雷扱いされてる惨状
キチガイゲーム馬鹿以外の大多数の人類は今日もAndroidでのんびり気楽に快適に日常を過ごしています
Re: (スコア:0)
カジュアルユーザーにしたらそうかもしれませんが、ここはsradですよ…。
スマホの性能はまだ足りないし、特に致命的なのはAndroidのレイテンシーの悪さ。
GC死すべし。
Re: (スコア:0)
sradに来るような人間は端末で処理せずサーバ側に処理流すでしょ
言っちゃ悪いけど端末に性能求めるの本当にもうゲームくらいっすよ
Re: (スコア:0)
そんなことはないですよ。
ペイントアプリとか、楽器アプリとか、画像編集アプリとか、
鏡アプリとかを使わないカジュアルユーザーであれば
話は別ですけども。
Re: (スコア:0)
ほんとに突き詰めると音源はALSAで絵はGIMPでOfficeはAOoみたいなことになって
また違う話になってしまうけどな・・・
Re: (スコア:0)
むしろその手を小型端末ですマスほうがカジュアルユーザだとおもうけど
Re: (スコア:0)
何を言っているのかわからないんだけど。もう少し詳しく。
Re: (スコア:0)
いや、そういう話でしょう。Ubuntu Touchには期待しています。
# 補足するとALSAよりもPulseAudioの方が、PulseAudioよりもJackの方がレイテンシが低いです。
http://stackoverflow.com/questions/29245583/alsa-vs-pulseaudio-latency... [stackoverflow.com]
http://unix.stackexchange.com/questions/68772/jack-vs-pulseaudio-how-i... [stackexchange.com]
# SamsungはAndroidでJackを使えるようにしています (Samsung Professional Audio SDK)が、
# 他のメーカーが追従しないのは何故だろう?
Re: (スコア:0)
いや、AndroidのJavaの遅さの話で「音源はALSAで」という話が出てくることが理解できないんだが。
それらは違うレイヤーで動いているものだから、排他ではないだろう。
Javaが直接音源チップをコントロールしていると思ってるの?
Androidは昔からALSAを使ってますよ。
Re: (スコア:0)
Alsaのdmixのことです。 >レイヤー
Re: (スコア:0)
バッテリーで動く携帯端末にとって、マシンパワーが十分だから重くても大丈夫という話は通らないよ。
軽けりゃそれだけ同じ処理をしてバッテリーを長時間持たせられるんだから。