[表示 : 全て 最新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にも組み込まれる予定。

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

831 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 19:08:15 ]
> せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
> 次世代Java環境が気になるJava使いの人はついて来れないと思う。

だろうね。
というか、そういう話をこのスレでやるのがそもそも間違い。
パフォーマンス厨は↓へ行ってくれ。
pc8.2ch.net/test/read.cgi/prog/1153547716/


832 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 19:41:39 ]
>>823
いまどきそうやってCはJavaよりも凄く、
「Cを知っていればJavaを知らなくても偉いんだ!」
と勘違いしてCしか知らず、Javaのことろくに勉強しないのも、恥ずかしいことなのだが。


833 名前:デフォルトの名無しさん mailto:sage お約束 [2006/08/30(水) 19:49:41 ]
いまどきそうやってJavaはCよりも凄く、
「Javaを知っていればCを知らなくても偉いんだ!」
と勘違いしてJavaしか知らず、Cのことろくに勉強しないのも、恥ずかしいことなのだが。

834 名前:デフォルトの名無しさん [2006/08/30(水) 20:04:14 ]
いまどきそうやって技術は一般常識よりも凄く、
「技術を知っていれば一般常識を知らなくても偉いんだ!」
と勘違いして技術しか知らず、一般常識のことろくに勉強しないのも、恥ずかしいことなのだが。



835 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:08:04 ]
>>833
お前よ、餓鬼みたいに>>832のコピペしてるのどっかで見たことがあるぞ。
C#死滅スレのVBとC#を崇拝する、継承嫌いの餓鬼だろw


836 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:08:49 ]
>>834
まてまて技術は一般常識の範疇に入るぞ

837 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:12:42 ]
いつまでたっても馬鹿が釣られまくっとるな
ガキが相手するから正常化せんのだが能無しには分からんか

838 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:29:39 ]
>>828
プ
無知は怖いね。

839 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:54:06 ]
嵐が過ぎた後は誰もいなくなっている悪寒。

お前らCがJavaより早くJavaはCより早いのは分かったから
メソッドリファレンスが何なのか情報提供してくれ。

840 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:01:00 ]
>>837
奴はVBとC#に詳しいアホだよ。
昔、語尾に「嘲笑激藁」「ププ」「ゲラ」「ワラ」「大爆笑」
をつけてた奴、ハンドルが「255」とかつけてた奴に
非常にそっくり。

結局あそこまでC#を持ち上げても、全然はやらなかったな。
どうせ奴は鬱憤晴らしにスレを荒らしてるだけだろう。


841 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:03:33 ]
>>807
つーか、動的生成云々うるさいけど、それってモジュール切り替えでええんじゃないん?
実行時生成なんてしなくても、コンパイルしたモジュールも含めればいいだけの話。

C使いでもめったに使わない技術を得意げに語るのは哀れですらある。

Java厨だってバイトコードの自力生成なんて滅多にしない。

842 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:04:55 ]
レスすんなカス
どこまで脳みそゆるいんだ

843 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:07:33 ]
>>787
いやー盛り上がってるとこ悪いが、20年経ってその台詞恥ずかしくないかw

844 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:13:58 ]
ところでJavaCardって何に使うの?
Java OneとSUNのシンクライアントでつかうくらいしか聞いたこと無い。
Edyのがすごいよ、コンビニ清算最速ってすごくね?



845 名前:デフォルトの名無しさん [2006/08/30(水) 21:15:41 ]
ココの住人には>>823は図星なのか?
みんなずいぶん喰らったみたいけど大丈夫か?

846 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:16:00 ]
>>813
C言語にポインタがあるために、ベクトル化による十分な最適化ができないが、
FORTRAN言語にはそのポインタがないので、十分にベクトル化できると聞いた
ことがある。

Java言語が出たとき、JavaもポインタがないのでFORTRAN並に最適化できる
のではないかという極端な記事が、Cマガジンに載っていたような覚えがある。


今となってはJavaの仕様では、FORTRAN並に最適化は無理なのは自明だが・・。

847 名前:デフォルトの名無しさん [2006/08/30(水) 21:17:28 ]
>>841
バイトコードの自力生成ってできたの?しらなkった。
ところで、どうやってやるの

848 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:19:42 ]
図星ってのもあるが正直どうでもいい
特定環境に最適化されたGCなんて興味ないなって感じ

849 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:20:32 ]
>>830
オイオイ、必死に何か探してきたと思ったらコレだ。
自己書き換えと動的実行コード生成は似て非なるものなんだが。

850 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:32:51 ]
>>847
適当なバイト列を作ってClassLoader#defineClass()を呼ぶだけだ。
そのバイト列はJavaVM仕様に合わせて作ればいい。
BCELやasmなどのバイトコード作成用ライブラリもある。

Java5からはClassLoader側で細工しなくてもバイトコード変換ができるように
java.lang.instrumentパッケージ以下のクラスが追加された。

851 名前:デフォルトの名無しさん [2006/08/30(水) 21:54:51 ]
>>850 しらなかった、あんがと。Jakarta BCELを読んでみる。

852 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:59:14 ]
>>851
正直言って、BCELは設計が古いというか微妙に使いにくいので、
新規ならASMかJavassist使った方が良いかと
他言語 -> Javaバイトコードのコンパイラ作るなら、Javassistはちょっと使いにくいが

853 名前:デフォルトの名無しさん [2006/08/30(水) 22:09:50 ]
今BCEL読んでる最中だけど、これってすげーな。
この技術と言うか概念というか、次のリリースでスクリプト言語を
java vmに取り込むとか言うのより、さらに高次元の話じゃん。

854 名前:デフォルトの名無しさん [2006/08/30(水) 22:32:11 ]
大体概要は分かったけど、すごかった。こういうツールが整備されて
徐々に万人向けに使いやすくなっていくと、これからも OSに依存しな
い Java の環境がより強固なものになっていく予感がする。
昔Sunが目指していたNetworkがどうのというやつなのかな。

> 他言語 -> Javaバイトコードのコンパイラ作るなら
>>852さんはこういう系の人なのでしょうか?
そうとは知らずに、言葉遣いが足らず失礼しました。



855 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 22:50:38 ]
>>854
852だけど、一応そういう系の人です。Java VM上で動作する
とあるスクリプト言語開発してます。超マイナーな言語ですが
一応どんな言語かというと、Javaに似たセマンティクスに
スクリプト言語っぽいシンタックスシュガーをふりかけました
みたいな言語です

> 言葉遣いが足らず失礼しました

?別に特に>>854さんが失礼な言動をしたとは思わなかったけど

856 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 22:54:35 ]
あ、ひょっとしたら誤解してるかもしれないんで一応いっておくと
>>850さんと>>852(= >>855)は別人なんで






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

前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