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

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)は別人なんで

857 名前:デフォルトの名無しさん [2006/08/30(水) 23:31:46 ]
   いや〜、やっぱりここにはいろんな人が来てるね〜
\_____ _______________
         ∨ | 
           | まいど、まいど!繁盛、繁盛!!
           \_ ___________
  __          ∨
/  /|       ∧_∧       
| ̄ ̄|/|       (・∀・ ) (   
| ̄ ̄| | ̄ ̄ ̄|\_(_   )_ (・∀・: )Java は さいきょう じゃ
| ̄ ̄| |___| ∧_∧  ̄ ̄ ̄ ////|
| ̄ ̄| |___|(    )____| ̄ ̄ ̄|/|
| ̄ ̄      ( ○  )      ̄ ̄ ̄|  |
|         | | |          |  |
|           (_(_)          |/


858 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:44:50 ]
ここで思ったんだが、JVM用のC言語を書くってのはどう?

859 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:47:50 ]
>>858
JVMしか作成できない言語を作るの?
どんなメリットがあるの?

860 名前:デフォルトの名無しさん [2006/08/30(水) 23:53:53 ]
ちょっとだけスレを読んでみたけど、
ガベコレ実装しそうな職人とか、
サーバー用ツールと次世代Javaの関係が気になる人とか、
クライアント用(携帯アプリ)の開発者とか、
コンパイラ作る人とか、
CマンセーなのにJavaが気になる人とか、
JVM上で動作するスクリプト開発者とか、
いっぱい居て楽しそうだね〜♪



861 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:55:09 ]
>>859
ごめん言葉足らずだったね
JVM上で動くバイナリを吐くC言語だ

862 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:10:41 ]
>>861
> JVM上で動くバイナリを吐くC言語だ

Cのソースからクラスファイルを作るということ?

863 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:20:12 ]
>>855
ちょいと質問なんだが、JRubyやJPyton、GroovyやJavaScriptじゃだめだったの?
独自スクリプト言語を新規開発するに至る動機はナンデスカ?

864 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:54:34 ]
「独自スクリプト言語を新規開発する」どころか、
「独自スクリプト言語を新規開発するためのフレームワーク」が出て来ているのに、
そんな質問するに至る動機はナンデスカ?

せめてどんな特徴があるんですか?くらいにしてくれよ


865 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:56:48 ]
>>862
そんな感じ
それなら単純にJava言語とC言語の比較が出来るだろ

866 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:01:57 ]
>>861
そんな無意味なものを誰が使うんでしょうか。

性能上の要求が高くて、高級アセンブラを使うリスクを拾わなきゃいかん場合に、
仕方なくCを使うのであって、要求が低くてJavaなり何なり使って手抜きできるな
ら、手抜き言語使うんじゃないの。

867 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:02:58 ]
> それなら単純にJava言語とC言語の比較が出来るだろ

言語仕様そのものを比較するわけじゃないから、意味なくない?

868 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:07:26 ]
>>863 私の野生の勘ですが、javascript かjrubyの開発関係の人ですよ、きっと。もしくは学者先生。だからそそうのないように・・

869 名前:sage [2006/08/31(木) 01:18:44 ]
>>868
なんで2chで書きこみのリアル人生に気を使う必要があるんだと小一時間(ry
大体、そんなエライ人がこんなところでクダまくかいな。

870 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:20:32 ]
>>855
JVM系のスクリプト言語は多くが動的型で、パフォーマンスがJavaに比べて劣るから、
静的型でJavaと同等のパフォーマンスを保ちつつ、手軽に書ける言語が欲しかった
というところ
実際、簡単なベンチマークとってみたら、Javaとほとんど同等の速度が出てた
まあ、セマンティクスがJavaに極めて近いから、速度出るのは当たり前なんだが
とはいえ、予定していた言語仕様はそれなりに実装できたものの、ライブラリをまだ
全然作ってないので、Javaのライブラリを使うしかないという情けない状態になってるが



871 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:27:29 ]
>>870
よくわかりませんが、それって、例えばGroovyみたいな言語
→JVMバイトコードのコンパイラ作ったってことですか?

872 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:27:45 ]
>>858,>>861-862,>>865-867
現時点での実用性で考えると、いらない、意味無いというのは当たり前だと思う。

現状の、Java VMが各OS上のの単なる1サービスや1アプリケーションと考えると
無意味だけど、これとは逆に各OSはJava VM上の1アプリ・1コンテンツと考えると、
状況は変わってくるんじゃないかな?
よく言うところの、ネットワークをでかいプラットホーム見立てて各OSはJavaの環境
で統一って言うやつ。

ちなみに私は>>858じゃないよ。


873 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:28:06 ]
>>869

855だけど

> 大体、そんなエライ人がこんなところでクダまくかいな。

まあ、そりゃそうだわなw
リアルではただの大学院生です
ただ、エライ人でも興味ある分野のスレ見てる人は結構居るみたいですが

874 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:29:30 ]
>>871
そういうことです
しかし、自分が言えたセリフじゃないが書き込みのペースが早いなw

875 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:31:55 ]
>>867
だって、JavaとCの比較ならおかしくないだろ
JITとAOTのどっちが早いってだけの話なのか?


876 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:36:29 ]
なんか知ってるかもと思ったので質問。

Java6のHotSpotコンパイラでエスケープ解析が入るのが売りの一つらしい
けど、スタックにオブジェクトが積めるようになるとそんなに性能上がるの?

世代別GCならヒープへのオブジェクトの確保解放はたいしたコストじ
ゃないし、どうせ短寿命なら初回MinorGCでedenからさようなら〜なので、
なんかイメージつかないんだけど、ナニがどう軽くなるんでしょう?

877 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:43:02 ]
ところで、JVMで動作するC言語の処理系だけど、既にあるよ
JVMで動作するっていうか、C言語 -> Java言語のプログラムへの
トランスレータだけど。C2Jでぐぐってみるといいと思う

878 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:45:47 ]
>>875
静的コンパイルとHotSpotでどっちが早いというのがテーマなのかねえ…
「HotSpotコンパイル」の中身がどんな最適かなのかわからないことには、
なんともかんとも。

879 名前:デフォルトの名無しさん [2006/08/31(木) 01:49:48 ]
もしスクリプト言語作るなら、
個人的には数式処理・代数処理程度で、
それをevelする程度で十分なんですけど。

複素数や行列の独自表記ができたり、(a+b)^2と書けたり
多項式展開や因数分解できたりとかです。

Java VMで動くバイトコードコンパイラ、スクリプトコンパイ
ラ?を作る意義・動機と言うのは、そういう特定用途に特化し
た言語を作るのでもありということだと思うんですけど・・


880 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 03:49:03 ]
C言語厨である>>841はなぜJava似のC++も使いこなせ
なかったんでしょう




881 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 03:50:11 ]
>>844
Javaカードは、
住民基本台帳カード、
大日本印刷が作ったカード、
海外の国民健康保険カードに使われているよ



882 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 04:24:32 ]
>>876
そりゃヒープに取らないで済めば、その分処理が軽くなるでしょう。
ヒープはGC含めてなんだかんだで競合が多いので、
C10Kな時なんかには効いてくる。object poolもしないで済む。


883 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 05:56:41 ]
>>877

そのトランスレータ使える? たった一行のCのプログラムもとんでもない量のJavaになるし、
ポインタ演算している所なんか、酷すぎる。

884 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 07:12:58 ]
>>787
ちょw
まだアプリ間連携もまともにできないJavaなのにw
どうみてもやっと「アプリケーション構成を考えるようになりました」ってレベルだろ?
docs.sun.com/app/docs/doc/802-2112/6i63mn60p?l=ja&a=view
のデリゲートとか
docs.sun.com/app/docs/doc/802-2112/6i63mn62q?l=ja&a=view
のサービスにいつ追いつくのやらw
20年前のフレームワークに負けてるってはずかしくね?

885 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 09:15:02 ]
>>828
> >>807
> >だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
> >>805のような動的実行コード生成をC, C++でもやればいいだけの話。
> >で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
> >OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
> if(SSE2命令が利用可能か?) {
> // SSE2命令を利用したインラインアセンブラによるコード
> }
> else {
> // SSE2命令を利用しないインラインアセンブラによるコード
> }
> これのどの辺りが動的実行コード生成になるのか説明してくれんか?
> 無知は怖いね。

無知晒し上げ

886 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 09:31:54 ]
最近、各種OSは、
securityがらみでdata領域を実行出来なくする方向だけど、
JIT/HotSpotはそれじゃ困るやね。

887 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 10:01:01 ]
>>883
.いや、たぶん実用にはならないだろうなあとは試してみて俺も思ったけど
まだそういう処理系は無いという前提で話が進んでいるように見えたので、
一応そういうものはあるということが言いたかっただけ

888 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 11:34:40 ]
>>884
なんかcocoaとかで見る名前だね。
あたりまえか。

何でこれがSunにおいてあんだ?

889 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 11:44:02 ]
>>885
ドトネト厨笑えるw

890 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 11:59:42 ]
>>888
OPENSTEP



891 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 12:44:51 ]
>>886
デフォルトが実行不可になるってだけで、
別途実行可能な領域を確保する方法は用意されている。
たとえばUNIX系ではmmap()にPROT_EXECフラグを付けて領域を確保すればいい。

というか、IA32アーキテクチャではNXビットがサポートされるようになったごく最近まで
PROT_EXECフラグの有無にかかわらず常に実行可能になっていたってだけで、
他のアーキテクチャでプログラムしていた連中にとっては今更って話だろうね。

892 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 15:09:33 ]
Java6.0っていつリリースされるの?






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

前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