[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 22:28 / Filesize : 289 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

次世代Javaの動向 2



1 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:03:42 ]

前スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/

関連スレ
【JavaFive】C#からJ2SE5.xへ進化【TigerShot】
pc8.2ch.net/test/read.cgi/tech/1094891986/

www.itmedia.co.jp/news/articles/0404/07/news018.html


マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン(JVM)のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。

米Sun Microsystemsは、Javaバーチャルマシン(JVM)内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。

SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

 またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。

730 名前:デフォルトの名無しさん [2006/08/29(火) 11:38:05 ]
みんな自分の信ずる言語・環境を支持すればいいだろ
どうしてJavaスレには他の奴らが荒らしにくるんだ?
他の言語・環境がどんなに素晴らしいのかしらんがスレ違いだ
巣に帰れ!

731 名前:デフォルトの名無しさん [2006/08/29(火) 12:23:15 ]
次世代を語るところだから、どうしても他の言語と比べた改善点とか要望が出るんじゃない?

732 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 13:08:47 ]
>>728
言葉が足りなかったかな
すでに実装されている話なんだし次世代の話題じゃないだろうということ

>>716は細かい制御したいのに5.0のコンカレントAPIすらさわってないんだろうなーとかおもっちまう


733 名前:デフォルトの名無しさん [2006/08/29(火) 13:53:56 ]
>>731
お前はネイディブコンパイラとのパフォーマンス比較を改善点や要望とでも言うのか?
だたの攻撃だろ?違うのか?

734 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 14:04:44 ]
>>730
昔懐かしい「C#って死滅しちゃうの?」シリーズスレで
大暴れしていた例のM$厨では?


735 名前:716 mailto:sage [2006/08/29(火) 14:10:20 ]
>>732

nanoTimeだけじゃアニメーションできなくない?
nanoTimeはsleepの分解能チェックや誤差の補正に使うものかと
結局sleep使わなきゃだめなんじゃないか?
それかObject.waitか。

J2SE6ではDoubleBuffer関係で何らかの改良があると聞いたかが。

そうそうConcurrentは使ってないな。まだ。そんなに必要性も感じてないが。

736 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:08:29 ]
>>727
> > JVMがCでできてるんだから、CでJVM(もしくはサブセット)を実装して
> > その上で実行すればJavaより遅くなるわけが無い。
> こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
> 騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない

進化とか古いとか関係ないだろう。CでJavaコンパイラを実装してclassコードを実行するという話をしているのだから
「Javaの方が速い」とならないことは自明なのだが。
恐らく「Javaは実行中にコードの最適化するから速い」とか言いたいんだろうが、
その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
ただ、CでわざわざJVMを再実装するのはコストがかかるから現実的ではないというだけ。

別にそこを認めてもJavaの優位性は変わらないと思うんだけどね。
いつものことだが、JavaしかできないやつはJavaを否定されると自分自身も否定されたような被害妄想を抱くよな。
どっかの宗教団体みたいで嫌だ。いろんな言語触れよ。次世代Javaの議論にも役立つぞ。


737 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:32:33 ]
とんでもない勘違いをしている奴がいるぞw

738 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:40:53 ]
痛い子が居るなぁ。




739 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:43:39 ]
>>736 → 737,738

740 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:48:26 ]
>その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。

この意味が分からない。絶対と言い切れる根拠はなんなんだろ?

741 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:51:25 ]
Javaで作ってスーパーコンピュータで動かせば速い。


742 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:54:16 ]
>>740
馬鹿には つ き あ う な

743 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:57:28 ]
>>740
> その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
> この意味が分からない。絶対と言い切れる根拠はなんなんだろ?
極論を言えば、
int main(){JavaVM *jvm;JNI_CreateJavaVM(&jvm);jvm->DestroyJavaVM();}
と書けば少なくとも速度は同じになるというだけのこと。
そんなにややこしいことは言ってない。
「JVMがCで書かれている」というのをもうちょっと考えろよ。


744 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:59:54 ]
>>741
JVMの役割を知っていれば、わざわざスーパーコンピューターでJavaを使おうなんて考えないよ。

745 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:01:56 ]
>743の続き
で、JVMのソースコード中から、実行に不要な部分を削除していけば、
JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
実際にはそんなところに開発コストをかけるのは無駄だから現実的ではないと言ってるだけ。

頭が悪いのか、それとも宗教にはまってるからなのか。。。

746 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:05:00 ]
>>735
nanotimeはポーリング用

定期実行にはTimer方面つかえといっておろう


747 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:06:08 ]
> JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。

JVMはCのライブラリィではないよ(笑)

748 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:46:20 ]
>>742
あい、了解したw



749 名前:716 mailto:sage [2006/08/29(火) 17:51:39 ]
>>746
アニメーションとかの20msecとかそういう間隔の話をしているつもりだったんだけど、
Timer? ありえなくないか?

750 名前:デフォルトの名無しさん mailto:age [2006/08/29(火) 17:54:46 ]
 

751 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 17:55:17 ]
747はとても親切だ。
暴れてるやつは声を出して読むように。

752 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:00:01 ]
>>749
どういう動きかわかってないんじゃない?
基本から勉強したほうがいいよ

753 名前:716 mailto:sage [2006/08/29(火) 18:07:25 ]
>>752
教えてくれ。
Timerも結局waitを使っているとドキュメントされているが、
waitは正確性を欠く、それをnanoTimeとかで確認してスケジュールを補正するのが教科書とおりなのだが、
Timerを使ってしまうと補正ができなくないのではないか?

次世代になってもwaitとかの精度はそんなに変わらないんだろうな

754 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:15:40 ]
そこまでわかってるなら問題あるまい


垂直同期にこだわらなければ60fpsにする必要もあるまい
垂直同期にしたら自動的にリフレッシュレートであわせられる

Win32ネイティブでやってるのと状況はかわらんよ

755 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 19:20:49 ]
Windowsのマルチメディアタイマーは1msで寝れたと思うが

756 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 19:50:44 ]
malloc/freeはどうした?>最速厨
JVMは都合のいいタイミングまでガベコレを遅延できる。
これをやると、特にSMPで差が開く。

757 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 20:03:09 ]
蒸し返すな

758 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 20:09:11 ]
>>756
性能を重視するならmalloc/freeをそのまま使ったりなんてせず、
普通は独自アロケータを定義するでしょ。



759 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 20:54:34 ]
>>720は、ぐぐってみたところ、
Javaの方が実行速度が速い例がたくさん見つかったので、
>>736>>743でごまかそうと必死w


760 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 22:55:04 ]
Javaがなんでもかんでも速いというつもりは全然無いんだが、Cで組んだっ
て結局実装の仕方次第だろ。malloc/freeを何度も繰り返すような素のCの
組み方したら、JVMの「そもそもメモリ解放自体めったにしないで確保してる
メモリを使い回す」ような実装より遅くてあたりまえ。

例えばObjective-CはCのサブセットで、コンパイルすれば完全なバイナリに
なるわけだが、メソッド呼び出し速度とメモリ取得・解放速度でJavaのほうが上回る。
これはオブジェクト周りの実装の仕方の差だろ。

そこを意識して力技なパフォーマンスチューニングを組み込んでCでゼロから
作れば、速くなるのも当たり前。

JavaがCより速いとかいう話は、「Cで普通に組んだものより、Javaで普通に
組んだものの方が速いことがある。なぜなら、JVM自体にすでにパフォーマン
ス・チューニングがされているから」という意味だってことがわからないのだろうか。

普通に組んだ時のパフォーマンスの差には意味があると思うけどねえ。

761 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 22:55:23 ]
>>736
C言語原理主義者の言い訳ごくろう。
また「Javaしかできない奴」とステレオタイプ貼り付けとは。
Javaで飯食ってきたかったらJavaしかできないなんてありえんからね。




762 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 22:57:39 ]
>>758
その独自アロケータとやらは、Javaの世代別GCを超えられるのか?
ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
とってるよ、あれ。フリーリスト管理独自実装とか、ショボイことしてい
る間は越えられんでしょ。

763 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:03:03 ]
コンパイラやVMの性能次第で、幾らでも早い言語・遅い言語になるわけだが。

言語の特性とコンパイラ最適化技術辺りは最低限踏まえて議論しような。

764 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:10:49 ]
マイクロベンチしにくい言語だなぁと思うことはよくある。
例えばN秒間の実行回数が4400〜5200とか異常な数値を出すこともしばしば。
ヒープサイズは-Xms -Xmxともに同じサイズにしても起こすから原因がつかめない

765 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:12:15 ]
結局、学生とかによくある卓上理論ってやつじゃないのか?

766 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:22:36 ]
机上だと思う。

767 名前:758 mailto:sage [2006/08/29(火) 23:46:35 ]
> その独自アロケータとやらは、Javaの世代別GCを超えられるのか?
越えられるよ。
つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
満足できないから独自実装するわけで。

> ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
> とってるよ
それは独自アロケータでも同じ。
そもそも、あるサブシステムでは特定のサイズのメモリを大量にアロケートするとか、
そういうプログラム固有の事情も考慮した上で最適なアロケータを設計するんだよ。

一般道から高速道までいろいろな状況でもそれなりに速く燃費の良いエンジンを作るのと、
サーキット上での速さの極限を目指したエンジン作りとを比較するようなもの。
そもそも設計方針から全く違う。

768 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:52:47 ]
いずれにしても現実にあるjavaのOOなプログラムは速度の最適化は難しいんじゃないか?
javaだからっていうか、OOだから。

例えば、java3dとか、hibernateとか、



769 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:04:22 ]
じゃあ、比較すんなよ。

770 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:06:31 ]
>>767はなんかすごそうな職人さんのようですね。
必要に迫られて独自にそういうすごいのを作ったのでしょうが、
凡人・汎用ではjava vmぐらいでいいです。ruby gc thread とか遅くても
ちゃんと答えを出してくれればいいです。

771 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:07:08 ]
>> その独自アロケータとやらは、Javaの世代別GCを超えられるのか?
>越えられるよ。
>つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
>満足できないから独自実装するわけで。

このように、独自実装厨はチューニングが重ねられた汎用アルゴリズムに
劣る糞コードを生成するわけだ。乙

772 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:08:40 ]
Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
Javaならある意味JVMが勝手にチューニングしてくれるし。

773 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:09:33 ]
生産性を意識すりゃなんだって「それなり」の速度だっての。
うざいから他所でやってくれ、マ板でやることじゃないだろ。

774 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:23:50 ]
>>768-774 みんなから一斉にツッコミのあらし。なんか知らないけど、笑いが止まらねー

775 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:30:06 ]
次世代Javaに速度は強くもとめないということで。

おもいらそれよりSE 6のどこが素敵なのかまとめてくれんか?

776 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:38:07 ]
ヒープ共有とタスクトレイはツール促進に繋がると思う。

777 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:48:00 ]
Java 5.0 で既に十分高速なので議論しても仕方が無い。
それより、Java 6.0 Java 7.0 に予定されている言語拡張・ライブラリについて語ろうぜ。

778 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:08:56 ]
>>11
>プロパティのサポート
>メソッドリファレンスのレポート
>クロージャのサポート
>言語レベルでのXMLのサポート
>JVM上で動作する動的言語のサポート
>スクリプト言語サポートの拡張
>モジュール化のサポート
>Swingアプリケーション開発のためのツールの充実

のうち、今回出てきたのは「メソッドリファレンス(たぶんローカル・ファンクションのこと
だろう)」と「クロージャのサポート」なわけだが、
「プロパティのサポート」はまだ具体例が出てきてないね。

最後のSwingアプリケーション開発のためのツールって
のは、たしかSwingをベースにしたアプリケーション・フレー
ムワークを作るとかだったっけ。



779 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:17:25 ]
最後のはただのNetBeansプラットフォームだったりしてな


780 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:27:48 ]
# クラスパスのワイルドカード指定

これなw これが一番重要な更新だったりしてw

781 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:48:38 ]
ttp://weblogs.java.net/blog/hansmuller/archive/2006/06/jsr_296_bows_sw.html
ttp://weblogs.java.net/blog/hansmuller/archive/ts-3399-final.pdf

782 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 02:59:33 ]
つ ttp://pc8.2ch.net/test/read.cgi/tech/1150286189/

783 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 03:04:55 ]
Swing Application Frameworkって具体的にはどんなの?

784 名前:デフォルトの名無しさん [2006/08/30(水) 03:25:08 ]
>>758,>>767 その経験は選ばし者のみ体験できることぞよ。そこから習得した業をこれからも存分に発揮するが良い。わははははは

785 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 04:34:32 ]
まずJavaをCたらしめているcloseメソッドをなんとかしろよ
まず名前をdeleteに変えてバカに気づかせろ

786 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 06:11:40 ]
>>781
ktkr
いったいここまでたどり着くのに何年かけてんだ?
こんなのNEXTSTEPをSolarisにポートした連中なら最初に気が付いてるだろ

787 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 08:30:02 ]
いやー、これなかなかいい設計だぞ?
今の基準でみると糞みたいなNEXTSTEPのフレームワークと違ってw

788 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:15:32 ]
>>756
> malloc/freeはどうした?>最速厨
> JVMは都合のいいタイミングまでガベコレを遅延できる。
分からん奴だな。そのガベコレをCで実装すればいい。
>>759
> >>720は、ぐぐってみたところ、
> Javaの方が実行速度が速い例がたくさん見つかったので、
Javaの方が速いっていうのは、C側ベンチでJavaと同じ事をしていないだけのこと。
Javaの挙動全てをCで実装すればJavaと同じ速度になるのは当たり前だと言ってるだけだ。
>>772
> Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
.classファイルを読み込んでJVM上で実行(もちろんJIT付き)するようなCプログラムを書けば、
Javaの方が速くなるなんてことは無いと言ってるだけなのに何で分からんかな。



789 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:18:19 ]
必死だな。

790 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:22:30 ]
こんなに頭悪い奴だとは思わなかった。

791 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:24:23 ]
>>788
いいたいことはなんとなく分かったが、それを言うことで
あんたが何をしたいのかがさっぱり分からん。

792 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:28:24 ]
自分の無知の隠蔽

793 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:34:40 ]
痛い子が粘着してるな
明日までの辛抱かの


794 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 10:08:05 ]
>>775
しかし、バージョンアップするたびに高速化してるみたいなんだけど。
次期バージョンJava6もPreJITによってかなり高速化が期待できるんでない?
二回目以降のアクセスからはCのネイティブと同じ扱いになってかなり高速化する、みたいな。

795 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 10:10:16 ]
>>792
面白すぎる。
マ板で必死にJava叩きしてるおっさんどもを思い出すw

796 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:11:25 ]
>>791
> >>788
> いいたいことはなんとなく分かったが、それを言うことで
このスレで頭がいいのはあんただけのようだな。
> あんたが何をしたいのかがさっぱり分からん。
>>720を理解できない奴が多かったから説明しただけ。
あんたみたいに理解力のある奴ばかりだったらいいんだがな。
>>736に書いた通り、Javaをけなそうとしているわけではないし、Cが素晴らしいなんて言うつもりも全く無い。


797 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:16:38 ]
JVMはCで実装しなきゃいけない決まりでもあるの?
Javaチップ上でベンチ比較する場合についてはどう考えてるの?
この場合Cの処理系をまず用意しないとダメだけど…

798 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:45:08 ]
>>796
どっかの宗教団体みたいなのはお前のほう。
お前の主張がいったい何になるのか説明できんだろ。
お前の意見が何もプラスにもならないならどっかの宗教団体と変わらない。





799 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 12:46:01 ]
わかったから、アセンブラで書くと最強!
Cはその次!
で良いだろ
実の無い議論しても無駄だろ

800 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:19:58 ]
こいつら一体何なんだ・・・

801 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:34:54 ]
> JVMはCで実装しなきゃいけない決まりでもあるの?
> Javaチップ上でベンチ比較する場合についてはどう考えてるの?
はいはい、机上の仮説はどうでもいいから、
まずはC,C++で実装された現行のJVMにも性能面でひけを取らない
Javaチップを開発してからまた来てね。

802 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:36:25 ]
>>800
Cで1からjvmもどきを書くと現行のJITより高性能をたたき出せる天才プログラマ様らしいよ


803 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:37:01 ]
もうお前等来なくていいよ!

804 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:41:37 ]
>>720 が悪い。

805 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:51:17 ]
> > Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> > Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
> そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
まあ、CPUのサポートする命令セットに合わせて実行時に自己書換する、なんて
テクニックは大昔からあるよね。
今だって、多くの動画コーデックはSSE等の拡張命令の有無を実行時に調べて
動的に実行コードを生成したりしてるし。

そういう古くからあるテクニックの一部がJVM実装にも取り込まれるように
なってきた、ってだけの話。

806 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:06:40 ]
俺よー、JVMの仕組みよく知らないんだけどJavaって実行時に
何度も実行される箇所はコンパイルしてネイティブコード生成するんだよな?

だから

コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間

この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)

なんかJavaはCを越えられないと言ってる奴はどうも
ネイティブコード生成後もJVMで解釈して実行してると思ってそうなんだが…?

CでもIntelMacのユニバーサルバイナリみたいに全CPUに最適されたコードを含んだ
バイナリを持てばJavaを上回るのは明らかだけど、そんな事してる奴いないよね。

807 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:23:54 ]
> コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
>
> この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)

だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>805のような動的実行コード生成をC, C++でもやればいいだけの話。
で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。

808 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:32:31 ]
>>807
>> >805のような動的実行コード生成をC, C++でもやればいいだけの話。

必ず同じ事ができるとは限らない。



809 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:34:51 ]
「JavaがCより速い場合がある」ってのは、同じようなアルゴリズムでコードを書いた場合ってことだろ。
そりゃ、最適化したコードで比べればどんな場合でもCの方が速くなるだろうよ。
でも、その最適化したコードをCで書くのは、コストや能力を考えると現実的に不可能だ。

810 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:37:58 ]
> >> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
>
> 必ず同じ事ができるとは限らない。

その理由は?
Cで書かれたJVMにできて、Cで直接書かれたプログラムにできないことって何?
それともJavaチップのことでも言ってるの?(笑

811 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:51:14 ]
>>806

コンパイル時間 << ε

ならば、誤差の範囲内として無視できる。

すると、JavaとCとでは速度はさほど変わらなくなる。


また、
Java実行速度 - C実行速度 << ε

なら、ますます無視できる。

ここでεとは非常に小さな値を表し、 <<は<よりもうんと大きな差があることを意味する。
つまりうんと小さくなるという意味。

812 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:55:54 ]
で、Cでできるからなんだよ?

813 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:57:04 ]
>>810

実例を出すと、ベクトル型スパコン。
Cで書かれたプログラムより、FORTRANプログラムの方が速いとされる。
コンパイラはどちらもCで作られている。

これは、ソースレベルでは同じアルゴリズムであっても、FORTRANで記述
されたプログラムの方が、Cよりも最適なベクトル化できるからである。

コンパイラを同じCで作っても、どこまで最適化できるかは、各言語仕様も
関係してくる。


814 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 15:48:19 ]
あれ、いつの間にここはFORTRANスレになったのかな?

815 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 15:49:14 ]
>>813
だから、{Cで書かれたFORTRANコンパイラ+.Fのソースファイル}を合わせて、
一つのCで書かれたソフトウェアと見なすって話が延々と続いているわけだ。

論理的には正しいが、実効的な意味はない。
ってのが>>736の最後のパラグラフの意味だと思われ。

816 名前:602 mailto:sage [2006/08/30(水) 16:04:51 ]
>>778
メソッドリファレンスって俺待望の >>602 で書いたようなことじゃないのかね?

だとしたら、あと5年はjavaを使おうかと思うな

でもSE7からなのか。。。

817 名前:デフォルトの名無しさん mailto:age [2006/08/30(水) 17:09:12 ]
>>788
> >>756
> > malloc/freeはどうした?>最速厨
> > JVMは都合のいいタイミングまでガベコレを遅延できる。
> 分からん奴だな。そのガベコレをCで実装すればいい。

不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
メモリ関数の使用を禁止すれば、ソースを書き直さなければならず、
もはやCのプログラムではなくなる。だから、JavaやC#のような新しい
言語ができたことを理解しろ。

818 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:15:04 ]
>>817
へー、Boehm GCを使ったCプログラムはCのプログラムではないんだ。



819 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:25:20 ]
>>818
ベタベタなコードにコンサバなGCで体裁繕ったらパフォーマンスでないぞ
いい加減みっともないまね続けるなよな



820 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:31:01 ]
>>817
> 不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
JVMはどうやってガベコレを実装してるの?

821 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:33:30 ]
>>807
つまり、普通の人はそんなの作らない&作れないから、
凡人が高速なプログラムを作ろうとしたらJavaで書いて実装した方がいいって事だよね。

理論的にCオンリーの方が早くなるっていうのは別に、誰も否定しないと思うけど
現実的にJavaの方が早くなる【場合がある】っていうのを認められないのは厨房だと思うな。

822 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:34:27 ]
>>820
メモリ関数使ってるに決まってるだろ。馬鹿じゃねぇの?

823 名前:デフォルトの名無しさん [2006/08/30(水) 17:38:48 ]
Javaの人は、Cはほどほどに教養程度なんじゃない?
詳しかったらJavaの環境に居ないで、Cの環境(Win32やUnix)に行ってるでしょ。

せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
次世代Java環境が気になるJava使いの人はついて来れないと思う。

824 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:42:27 ]
>>823つまり冷やかしもほどほど程度にしとけってことかな?

825 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:47:11 ]
言語仕様も関係するが、それよりも実行形式の抽象度の違いによるんだよ。

826 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:50:09 ]
>>823
当然、おまいはGCの実装経験がある or 実装できるのだな。
各種GCアルゴリズムについて語らないか?

827 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:54:35 ]
>>822は叩かれてる人?泣きそうになってるみたいだけど

828 名前:デフォルトの名無しさん [2006/08/30(水) 18:09:04 ]
>>807
>だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>>805のような動的実行コード生成をC, C++でもやればいいだけの話。
>で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
>OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。

if(SSE2命令が利用可能か?) {
// SSE2命令を利用したインラインアセンブラによるコード
}
else {
// SSE2命令を利用しないインラインアセンブラによるコード
}

これのどの辺りが動的実行コード生成になるのか説明してくれんか?
無知は怖いね。



829 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 18:52:56 ]
高速化高速化いうてるけど
1.4.2のが5.0より速いらしいぞ
SUNのベンチ鵜呑みにするなや

830 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 18:56:32 ]
>>828
ほらよ。
ttp://mkosaki.blog46.fc2.com/blog-entry-104.html






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<289KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef