【Java SE 7】 次世代Javaの動向 ７ 【dolphin】
at TECH
1:デフォルトの名無しさん
08/09/04 21:34:07
■■前スレッド■■
[Java SE 7] 次世代Javaの動向 6 [dolphin]
ｽﾚﾘﾝｸ(tech板)
■■過去スレッド■■
[Java SE 7] 次世代Javaの動向 5 [dolphin]
URLﾘﾝｸ(pc11.2ch.net)
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
URLﾘﾝｸ(pc11.2ch.net)
[mustang] 次世代Javaの動向 3 [dolphin]
ｽﾚﾘﾝｸ(tech板)
次世代Javaの動向 ２
ｽﾚﾘﾝｸ(tech板)
【Java】次世代Java・J2SE1.6の動向【Mustang】
ｽﾚﾘﾝｸ(tech板)
■■関連スレッド■■
現世代Javaの動向 1
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
08/09/04 21:36:17
■■■関連スレ
【初心者】Java質問･相談スレッド119【歓迎】
ｽﾚﾘﾝｸ(tech板)
【徹底討論】Java３Dの可能性について考える
ｽﾚﾘﾝｸ(tech板)
Eclipse統合M25【Java/C/PHP/Ruby/Python/Perl】
ｽﾚﾘﾝｸ(tech板)
【Java】NetBeans Part4【Sun】
ｽﾚﾘﾝｸ(tech板)
【Java】Wicket【HTML】
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
08/09/04 22:57:53
乙
4:デフォルトの名無しさん
08/09/05 00:22:41
クロージャーのことがまだ良くわかっていないのだが俺は、
クロージャーのことがよくわかる参考資料はないかね
5:デフォルトの名無しさん
08/09/05 01:01:36
BCPLの仕様とそこからリンクしてあるチュートリアル嫁。カス野郎
6:デフォルトの名無しさん
08/09/05 12:00:40
JDK7 build34
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
7:デフォルトの名無しさん
08/09/05 23:46:52
6u10っていつ頃ですか？
8:デフォルトの名無しさん
08/09/05 23:54:12
>>7
今秋予定。いまRCまできてる。
9:デフォルトの名無しさん
08/09/05 23:56:40
NIO2 のバイナリ ： jdk7build33 + NIO2
URLﾘﾝｸ(download.java.net)
NIO2付きの javadocも来た。
URLﾘﾝｸ(openjdk.java.net)
10:デフォルトの名無しさん
08/09/05 23:56:54
>>8
ありがとう。6u8や6u9が間にあると思ってたけど、すっとばすんだね。
11:デフォルトの名無しさん
08/09/06 16:30:46
演算子オーバーロードーのことを気にする人がかなり減ったけど、あの熱気は一体なんだったんだろうと思う。
もし言語として必要（必須）なら今でも不満が出るんだろうけど、やっぱり一時の浮気心であって実際はどうでも良かったのかな…
この辺りはどう思う？
12:デフォルトの名無しさん
08/09/06 16:35:03
BigIntegerやBigDecimalを除けば、
特に欲しいと思える機能ではないな。
13:デフォルトの名無しさん
08/09/06 17:26:57
それだと、BigDecimalはextendsして自分でメソッドを定義すればいいんじゃない？
14:
08/09/06 17:58:26
JDK 7はいつごろリリースされるの？
さらにEclipseが対応するのはいつごろ？
15:デフォルトの名無しさん
08/09/07 07:10:08
JDK7のリリース予定は、いまのところ来年夏かな？
URLﾘﾝｸ(www.javaworld.com)
これが最新の予定かどうかは知らん。
遅れる事はあっても早くなる事はないと思う。
16:
08/09/07 10:02:40
>>15
ありがとうございます。
まだまだ先ですね。
17:デフォルトの名無しさん
08/09/08 14:48:21
>>11
あれは熱気じゃないだろw ただの荒らしがしでかしたもの。
過去に「C#って死滅しちゃうのスレ」でJavaアンチが散々煽っていたネタの一つw
18:デフォルトの名無しさん
08/09/08 14:58:36
次のJVMではたくさんのスクリプト言語がサポートされるんですが、この選考基準はなんですか？
自分のスクリプトをevalさせるのは簡単ですか？
19:デフォルトの名無しさん
08/09/08 21:59:58
コミュニティの数とか、歴史とかじゃない？
Pnutsのユーザーとかまだ居たりするのかな。
20:デフォルトの名無しさん
08/09/08 23:03:03
>>18
何か追加される予定あったっけか？
今のところ Rhino しか入ってないと思ったが。
後付でスクリプトエンジン入れられるって意味のサポートなら、
自分で ScriptEngineFactory 実装してSPI 登録すりゃいいだけだから、
後はユーザーがダウンロードして使ってくれるかどうかだけ。
こっちは jdk7関係ないし。
21:デフォルトの名無しさん
08/09/08 23:07:52
>>20
つ JavaFX
22:デフォルトの名無しさん
08/09/08 23:31:26
>>20
SPI登録っていってもCLASSPATHにJar通せば終わり
23:デフォルトの名無しさん
08/09/08 23:31:50
JavaFXはRAD環境がないらしいけど、
βから作り始めてる猛者はいるのかな。
24:22
08/09/08 23:32:43
悪い、実装する側の話ね。
25:デフォルトの名無しさん
08/09/09 09:59:47
スクリプトサポートといっても、なんか難しそう・・・
26:デフォルトの名無しさん
08/09/12 23:34:10
JDK7 build35
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
27:デフォルトの名無しさん
08/09/17 02:24:34
ところで、前スレで、ScalaはJavaVMで動かすことを考えられた言語でネイティブにバイトコード対応してるから速いと書いたら、GroovyやRhinoでもバイトコード変換ができるという答えが返ってきてたんだけど、GroovyやRhinoのコードでJava言語よりも速いコードが吐けるの？
28:デフォルトの名無しさん
08/09/17 07:10:27
>>27
バイトコードに変換するコンパイラがどれだけ頑張るかによる。
29:デフォルトの名無しさん
08/09/19 08:45:05
>>28
今どきのJVMのJITは、Javaコンパイラが通常吐き出すバイトコードに、
かなり特化した最適化が行われているから、
いかにJavaコンパイラが吐き出すバイトコードに近いコードを生成するかが、
高速化の鍵になると思う。
30:
08/09/19 09:31:23
Scalaはリフレクションをつかったバイトコードを生成したりするから、それでも遅くなる。
単純なソースならないだろうけど。
31:デフォルトの名無しさん
08/09/19 09:36:41
> 今どきのJVMのJITは、Javaコンパイラが通常吐き出すバイトコードに、
> かなり特化した最適化が行われている
具体的には？
32:デフォルトの名無しさん
08/09/19 09:39:53
>>30
あのへんは InvokeDynamic使えればリフレクション使わなくてもよくなるかも。
33:デフォルトの名無しさん
08/09/21 02:38:40
>>30
んー。Scalaでリフレクションを使ったバイトコードが生成されるのは、やや特殊な場合だけ
だが(配列がらみの変換とか)。通常の数値演算とかメソッド呼び出しはリフレクション
は特に使われていない。コンパイル結果をjavapしてみればわかる。
34:デフォルトの名無しさん
08/09/21 02:41:40
で、Scalaが速い理由は、単にバイトコード吐くからじゃなくて、
静的型付けで、しかもJavaに比較的近い型システムを持っているため、より
直接的にJVMのバイトコードにマッピングできるから。たとえば、scala.Int
型同士の加算は単にJVMのiadd命令になったりする。
35:デフォルトの名無しさん
08/09/21 07:14:05
>>33
structural conformance とかもそうだね。
structural conformance、Javaでも出来るようにならんかねぇ
36:デフォルトの名無しさん
08/09/21 08:19:06
interface MyIn
{
class MyCl {}
}
とすると、内部クラスはインターフェイスの規約どおり必ずpublic static final class MyCl
として扱われるんですか？
37:デフォルトの名無しさん
08/09/21 08:26:45
>>34
そんな紹介記事読めば書いてあるような事を一生懸命書かなくても……
38:デフォルトの名無しさん
08/09/21 08:29:53
>>36
誤爆しました。
39:デフォルトの名無しさん
08/09/24 09:33:15
BeansBindingって7に含まれるのかな？
40:デフォルトの名無しさん
08/10/01 01:12:46
>>39
たぶん含まれると思うけど。
7 のスペックリードの Danny Coward の追っかけでもやらんと最新の動向はわかんない。
そーいや、クロージャの Neal Gafter が Google やめて Microsoft に行ったとか。
41:デフォルトの名無しさん
08/10/01 02:09:09
それ、ハッタリだって。
42:デフォルトの名無しさん
08/10/01 09:15:52
>>40
あれま。closureはどうなるのかな。
43:デフォルトの名無しさん
08/10/26 08:39:07
JDK7 build38
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)
44:デフォルトの名無しさん
08/10/26 08:49:53
おお
JColorChooserにHSLタブが追加されたんだｗ
45:デフォルトの名無しさん
08/10/27 11:05:36
>>42
仕事はdotNetだけど、
バランスのために趣味でJava言語の設計と開発を続けると書いてある。> blog
46:デフォルトの名無しさん
08/10/31 22:34:23
次世代ではないが、6u10はいつになったらダウンロード出来るんだ。
47:デフォルトの名無しさん
08/10/31 22:37:36
英語ページからならはじめから。
日本語ページから落とさなくてもMulilingualだから
どうせ同じバイナリですよ
48:デフォルトの名無しさん
08/10/31 23:52:48
自分も英語ページから落としたけど
日本語ページの放置っぷりに、Sunのやる気の無さが伺えたｗ
49:デフォルトの名無しさん
08/11/01 02:36:38
JAVAって欠陥言語だろ？
本も種類多すぎだし、コードはクソ見づらくなるし
何がいいの？
50:デフォルトの名無しさん
08/11/01 09:14:48
>>49
コボラー乙
51:デフォルトの名無しさん
08/11/01 16:12:45
SwingLabsのJXTreeTableって標準で実装される可能性はない？
これだけは欲しいんだよねー
52:デフォルトの名無しさん
08/11/11 00:06:35
JDK7 build39
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)
53:デフォルトの名無しさん
08/11/21 22:50:59
最近のJVMの進化は凄いね。部分的にだけどJavaがCの処理速度を超え始めてるよ。
URLﾘﾝｸ(shootout.alioth.debian.org)
54:デフォルトの名無しさん
08/11/22 00:13:58
部分的ならかなり昔に越えてるよ。
1.4の頃からアルゴリズムの教科書に載っているようなプログラムは
Javaの方が早いのが結構あった。
55:デフォルトの名無しさん
08/11/22 00:20:34
>>53
それ、最新のJVM使ってないんじゃね？
56:デフォルトの名無しさん
08/11/22 03:14:27
>>54
6.0になると、体感で1.4の倍くらい速いしなぁ。
57:デフォルトの名無しさん
08/11/22 20:53:05
6はGUIまわりが高速化されたイメージが強いな
性格にベンチしたわけじゃないので、あくまで個人的な感覚だけど
58:デフォルトの名無しさん
08/11/22 21:06:44
>>53
Cでオレオレ言語とオレオレVM作って、Javaを巻き返したとしたら
Cが速い事になるんだろうか。それともオレオレ言語が速い事になるんだろうか。
と考えようと思ったけど、よく考える間もなく、JavaだってC製だよなあ。C++かも知れんけど。
なんかもうオレだめだ寝るわ。
59:デフォルトの名無しさん
08/11/22 21:16:15
所詮最後は機械語な訳だから、動的コンパイルの勝利って視点が正しい気がする。
60:デフォルトの名無しさん
08/11/23 01:15:57
gcc-llvmってのがあるから、
そいつがCも速くしてくれるかも知れない。
ただあまり低レベルな記述ができないほうが、
プログラム解析には有利なんだよな。
61:デフォルトの名無しさん
08/11/24 21:44:20
JDK7 build39
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
62:デフォルトの名無しさん
08/11/24 21:57:41
> build39
63:デフォルトの名無しさん
08/11/27 23:02:28
次の目玉機能といえるクロージャや追加スクリプトとかの話題を最近聞かないんですけど、やっぱ止めちゃったんですか？
64:デフォルトの名無しさん
08/11/28 01:40:06
Neal GafterがMicrosoft行ってから、
> Current prototype: URLﾘﾝｸ(www.javac.info) (updated 2008-08-11)
更新されてないからね。
65:デフォルトの名無しさん
08/11/28 01:48:09
なんかこう
ｇｄｇｄ感が漂ってるよね・・・
66:デフォルトの名無しさん
08/11/28 01:52:09
そのニアルってゴスリンの部下じゃなかったのか。
一度MSに行くともうSUNに戻ってもリーダーになれないような感じだけど、SUNの社風はそうでもないのか？
それともいい仕事する割には、ストレスに弱いのかｗ
67:デフォルトの名無しさん
08/11/28 02:06:24
Sunつぶれそうだから逃げ出したんでしょ
68:デフォルトの名無しさん
08/11/28 02:15:37
今のSUNはかなり儲かってんだが。
レイオフはよくあることだし、どっかの大学と提携して順調だろ？
69:デフォルトの名無しさん
08/11/28 02:31:17
ニールはマイクロソフトのスパイだったって話だよ
70:デフォルトの名無しさん
08/11/28 02:32:15
>>68
かなり儲かってる？どこが？
URLﾘﾝｸ(www.itmedia.co.jp)
71:デフォルトの名無しさん
08/11/28 02:39:07
おまえ、営業利益とか経常利益とか言われてもさっぱりで財務とか苦手だろｗ
隠さなくてもいいぞｗｗ
72:デフォルトの名無しさん
08/11/28 02:47:48
Neal GafterはGoogleにいたんだよ。
GoogleのJavaのチーフ。Google Calendar作った。
その前はSunでJavaのコンパイラ。
73:デフォルトの名無しさん
08/11/28 03:34:53
>>71
純損失が16億ドルあって「かなり儲かってる」といえる理由がわからないので、財務とか苦手なようだ。
ちょっと解説してもらえないだろうか？
74:デフォルトの名無しさん
08/11/28 03:38:42
UNIX板にSunスレあるぞ。二人とも行け
75:デフォルトの名無しさん
08/11/28 04:41:40
そういう話じゃないだろ
76:デフォルトの名無しさん
08/11/28 05:02:23
そういう話だろ
77:デフォルトの名無しさん
08/11/28 05:13:23
文脈よめねぇの？
78:デフォルトの名無しさん
08/11/28 05:19:47
つうか、次世代Javaの動向にSunの経営状況が密接に関係あるのわかってないのか
79:デフォルトの名無しさん
08/11/28 09:12:06
SunはヤバいからJDKの実質有償化をゴリ押ししてなんとか金にしようとしてるんでしょ
80:デフォルトの名無しさん
08/11/28 09:21:12
jdk1.4のサポートを有料で継続するって話？
ここ次世代Javaのスレなんで。
81:デフォルトの名無しさん
08/11/28 09:25:41
古いのも次世代も、今後は出てから３年で無償サポート切られるよ
82:デフォルトの名無しさん
08/11/28 09:28:16
新しいのはGPL化されたOpenJDKがあるからやろうと思えば自力で手を入れられるし。
83:デフォルトの名無しさん
08/11/28 11:54:14
一般カスタマー向けじゃあるまないし、３年は早すぎだな
jvmやjdkライブラリも、もともと低額でも有償だったらあまり使われなかっただろうし
XBoxやPSとかみても５年から７年過ぎたらってところじゃないか？
84:デフォルトの名無しさん
08/11/28 12:47:45
ゲーム機w
85:デフォルトの名無しさん
08/11/28 12:55:37
携帯でも成功したので、jvmの次のターゲットはゲーム機ですよ？
86:デフォルトの名無しさん
08/11/28 13:06:08
無償サポートのわけねえw
87:デフォルトの名無しさん
08/11/28 13:41:40
ゲーム機が無償でもらえると聞いて
88:デフォルトの名無しさん
08/11/28 13:59:02
携帯でjavaアプリゲームが実現できたので、次のターゲットはゲーム機器（ハード・コンソールとも言う）に特化したjvm (kjvmなど）を作れば同じ流れで成功するだろう。
ただハード性能を引き出す必要があるけど、もともとコンソールは普通関係者だけで閉じてるからあまり問題ない。というか携帯の方は乱立がすごいし。
java meの延長でcpu 1.0Gなど大コンソール向けとかのプロファイラ切り替えでいけるんじゃないかな。
当然プリンタとかの組み込みとかも視野に入ってくるけど。
SUNは本来ハード会社だし、MSとはそもそも畑が違う。
89:デフォルトの名無しさん
08/11/28 18:20:51
dolphinっているかだろ？どうせなら、グランパスにしてほしかった。
90:デフォルトの名無しさん
08/11/28 20:24:32
>>89
グランパスは8まで取っとくだろ常識的に考えて
91:デフォルトの名無しさん
08/11/28 20:28:42
つまらん
92:デフォルトの名無しさん
08/11/28 20:29:58
コードネームって廃止されたんじゃなかったっけ？
93:デフォルトの名無しさん
08/11/28 20:41:11
相手にするだけ無駄だな
94:デフォルトの名無しさん
08/11/29 16:12:53
>>90
激ウケｗｗｗ
95:デフォルトの名無しさん
08/11/30 13:37:05
>SUNは本来ハード会社だし、MSとはそもそも畑が違う。
javaが動く携帯ゲーム機作ってくれたら買うんだけどなぁ
96:デフォルトの名無しさん
08/11/30 22:22:09
>>88
詳しそうなので聞くけど、
BlurayDisc対応のハードって、Java搭載が必須だったっけ？？？
何かの光Discの規格でそういうのがあったような。。。
で、それって、実際使われているのだろうか、とうのが気になっている。教えて。
97:デフォルトの名無しさん
08/11/30 23:51:37
PS3でjavaが動くと聞いて！
98:デフォルトの名無しさん
08/12/01 00:03:03
>>96
必須ですよ。プロファイルがSEとはずいぶんと違いますが。
ネットで関連グッズ買わせるボーナス画面で既に使われてるはずです。
変わったエフェクトのメニューとか。
99:デフォルトの名無しさん
08/12/01 01:23:00
でも携帯アプリみたく自分で作ったのが自由に転送できないなら、Java搭載かどうかはあまり意味ない。
それなら値段も安いしネットブックでやるし。
少し大きいけど、持ち運び可能な液晶と考えればそうでもない。
100:デフォルトの名無しさん
08/12/02 15:28:15
クロージャもプロパティもサポートされないんですか・・・
101:デフォルトの名無しさん
08/12/02 20:22:45
その代わりにJavaFXがサポートされます！
102:デフォルトの名無しさん
08/12/02 22:15:20
JavaFXってコンシューマJREに載ってこなかったけどいつ出てくるの？
オーサリングツール作ってるってんなら待つけどさ。
103:デフォルトの名無しさん
08/12/02 22:39:19
まだ先だろ。だいぶ待ってろ
104:デフォルトの名無しさん
08/12/02 22:45:52
クロージャはサポートされないんですか。ならc#にします。
105:デフォルトの名無しさん
08/12/02 23:46:15
>>102
JavaFXは今週プレリリース版出すらしいよ。
106:デフォルトの名無しさん
08/12/03 13:33:09
Javaがレガシーだって? 冗談じゃないよ - James Goslingが語るJavaの現在
URLﾘﾝｸ(journal.mycom.co.jp)
107:デフォルトの名無しさん
08/12/03 15:08:46
クロージャは早くて１年半後ってあったから、jdk1.7が出てから追加導入ってことになるかのかな。
SUNにはキャッシュが３０億ドルあるってのが笑えた。
アメリカ本国が破綻することはないけど、タンス預金と同じ。
なんなら森ビルとか日本テレコムでも買収して固定資産化しろよｗ
108:デフォルトの名無しさん
08/12/03 16:02:01
固定資産化ってアホか
109:デフォルトの名無しさん
08/12/03 16:38:35
難しいことにアホが口を挟むなｗ
110:デフォルトの名無しさん
08/12/03 17:31:42
>>108
おまえはそんなところにしか目がいかないのか？ｗ
111:デフォルトの名無しさん
08/12/03 19:43:47
オマエモナー
112:デフォルトの名無しさん
08/12/03 20:35:33
FX 1.0、明日リリースだってー。
113:デフォルトの名無しさん
08/12/03 22:52:55
>>112
Sunがいろいろ頑張ってるのはわかるんだけど、
さっぱり盛り上がってないよね……
114:デフォルトの名無しさん
08/12/03 23:47:17
需要は少ないんだろうが、そろそろSwing上のハードウェア加算合成をサポートして欲しいなあ…
115:デフォルトの名無しさん
08/12/03 23:52:27
名のあるゲームメーカーとかと組まなきゃ無理だろ。
Sun主導ででクライアントサイド技術が大成するとは思えない。
JSFだって結局JSPじゃなくてFaceletsに移ったしね。
Velocityが通った道に何年掛けてるんだって話。
116:デフォルトの名無しさん
08/12/03 23:58:12
Javaで商用アプリケーションはけっこうあるけど、商用のゲームなんか見たこと無いもんなあ。
Quake2エンジンはずいぶん前に移植できてるみたいだから、ポテンシャル的にはそこそこのものが動きそうな気もする。
ただ、ゲームの世界で「そこそこのもの」を作っても、あんまり金を出してもらえないか。
117:デフォルトの名無しさん
08/12/04 00:07:07
まぁでも、6u10以前のアプレットで作ったネットゲーム(RuneScape)で
億万長者になった人もいるにはいる。
118:デフォルトの名無しさん
08/12/04 00:14:17
>>117
そういや、あのころJOGLはまだだろうし、Java3Dで頑張ってたのかな？
119:デフォルトの名無しさん
08/12/04 21:34:40
【サンタクロース、トナカイの酒気帯び運用罪での逮捕に、ﾏｼﾞ逆切れｗ】(ZDNet)
URLﾘﾝｸ(builder.japan.zdnet.com)
120:デフォルトの名無しさん
08/12/05 10:14:34
クロージャの導入にいつまでかかってんだよ
C#との差は広がるばかりだな
121:デフォルトの名無しさん
08/12/05 13:22:41
C#4.0は動的型とジェネリック型共変反変サポートだったっけ
122:デフォルトの名無しさん
08/12/06 23:37:08
JDK7 build41
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
123:デフォルトの名無しさん
08/12/07 00:50:19
JavaFXになっても未だにmp3再生はJLayer頼りなの？
URLﾘﾝｸ(weblogs.java.net)
124:デフォルトの名無しさん
08/12/07 01:49:34
JavaFXって速度はどうなの？
っていうかJavaってなんで遅いの？
ゴスリンはいまはCよりも速いとか言ってるけど、絶対遅くね？
納得のいく説明をマジ期待
125:デフォルトの名無しさん
08/12/07 01:57:19
スレ違い
126:デフォルトの名無しさん
08/12/07 02:13:18
>>124
Cは永遠に不滅だからねぇ
127:デフォルトの名無しさん
08/12/08 02:14:25
起動時の速度が遅い
これは何ともできないね。常駐JVMとかできないと。
だから小さなベンチマークだとJavaは遅い。
実際・・・Jazelle入ってるARMとかで動かしてるLinuxとかで
Javaが速いプラットフォームとかあるのかな？
128:デフォルトの名無しさん
08/12/08 03:30:07
>>124
どういう処理が遅い？
129:デフォルトの名無しさん
08/12/08 23:02:45
>>116
URLﾘﾝｸ(www.getamped.jp)
Java製だったと思う。
130:デフォルトの名無しさん
08/12/08 23:12:30
まじか。本当にそうならすごいな。
どうもインストールのとこ見るとJREのインストール促すような文章もなかったけど内包してるんかね。
131:デフォルトの名無しさん
08/12/08 23:24:26
国産じゃないけどこんなのもあるね。
URLﾘﾝｸ(tribaltrouble2.com)
132:デフォルトの名無しさん
08/12/08 23:30:14
今までjavaがゲームに向かないって言われてたのは、javaの精神からネイティブの個別対応に消極的だったからでしょ。
だからgcもかなりよくなってるし、ライブラリもかなりそろってるし、javaなら当たり前かなって感じはする。
133:デフォルトの名無しさん
08/12/09 01:00:38
あれ？JInputってMacやLinuxにも対応してるのね。
これだとWebStartあたりでMMO作るのが一番楽かも知れん。
今ならサーバもクライアントもJavaでいけると思う。
134:デフォルトの名無しさん
08/12/09 03:07:27
ベクトルユニットを使わずCPUで全部計算させていい程度のゲイムならjavaでもrubyでも実際のところ比べるほどの差はない。
ただ、無理して昔のPS１のような３D使うなら普通にクラッシュバンデブーとかの２D化とかスプライトの方がいい感じはする。
135:デフォルトの名無しさん
08/12/09 14:13:45
微妙な違いが気持ち悪いがクラッシュバンディクーだよな？
2Dか？
URLﾘﾝｸ(jp.youtube.com)
136:デフォルトの名無しさん
08/12/09 20:35:40
いや、言いたいことはテクスチャをピクセル毎に計算するんじゃなくて、アニメのように精密なセル画を毎々用意してはってけばいいってこと。
影とか屈折とか３D特有の計算がなくて、せいぜい多色のべた塗りの画像を貼り付けるだけだからやってるとことは2dとほとんど同じ（３次・４次のベクトル座標計算程度）。
もしopenglとかのGPUユニット使わずCPUだけで画像処理やるなら、どんなに頑張っても今のPCの限界はこのへんじゃないか？
個人的にはマルチコアでやっぱりCPUで何とかなっていっちゃうのが次の流れかなって思うけど。
ナルト
URLﾘﾝｸ(ps3navi.com)
137:デフォルトの名無しさん
08/12/09 21:36:08
そんなこと言うなら、ゲーム3Dは屈折とかちゃんと計算してないし、ピンボケも2Dでのぼかしと同じで、ほとんどは2Dのフィルタ処理と同じじゃないか。
CPUとGPUの区別をどうするか知らんが、しばらくはCPUのようなでかい演算装置で超並列できるようにはならないと思うよ。
結局Direct3Dをどれだけ使えるかって話だろ。
138:デフォルトの名無しさん
08/12/09 22:51:12
＞ゲーム3Dは屈折とかちゃんと計算してないし
上に書いてあるのを読んで、屈折自体を計算する必要がないってことに気がつかなかったか？
それに計算の話じゃなくて、アルゴはいくらでも考えられるけど、実際はソフトで行える限界・その計算が視覚に耐えられる限界・協調同期の限界があるわけだから、
１０年前のFF7ポリゴンみたいなことして技巧的にならないで、アニメっぽいテクスチャ述べた塗りでいいんじゃないのってこと。
それだとナルト並なら、動きの滑らかなのとか抜いても、分担して３人ぐらいいれば作れるし（１ステージだけとか）。
nvidiaとか最先端技術のデモ見てるとよだれでるけど、それが世に広まるのは5-7年先のことでしょｗ
やっと１０年前のFF７並みのポリゴンがjavaで手軽に作れるほど世に広まったわけだし。
139:デフォルトの名無しさん
08/12/09 22:58:14
マルチコアについてはハードを持ってないからあまり知らないけど、
gpuとかopengl/directxとかで計算を肩代わりさせるよりもよりもスレッドとマルチコアが主流になると思う。
個人的にはグラフィックカード(gpu)に２万も３万も出すよりはバックアップ用のHDDとかデジカメとか買うけどねｗ
140:デフォルトの名無しさん
08/12/09 23:05:13
これ(>>138)人工無能だよ。多分。
似たようなのが前にもJava初心者スレに湧いていた。
141:デフォルトの名無しさん
08/12/09 23:08:08
JVM自体の拡張は無いものかな？
そろそろSIMDをサポートしてもいいような気もするんだが。
JVMの命令レベルでサポートしてくれれば、標準ライブラリにも反映されるだろうし。
142:デフォルトの名無しさん
08/12/09 23:37:07
>>140
知らない話になるとすぐ人工無能とかいっちゃうあたりは、その人工無能は君のことじゃないの？
143:デフォルトの名無しさん
08/12/09 23:48:49
仮想スタックマシンとベクトル計算は相性いいからそれはありえるかもね。
ただ、プリミティブの128bit型(dot netだとstruct Decimal)を入れて欲しい。
add,subとかの演算はなくていいから、int,longへのキャストだけでいい。
といよりも、jvmヒープではなくてスタックフレームにメモリ確保する
struct, stackallocを導入すればいいかなって感じはする(当然値渡し）。
144:デフォルトの名無しさん
08/12/09 23:52:33
>>141
つ invokeDynamic
145:デフォルトの名無しさん
08/12/09 23:58:13
>>141
そういう計画は次期JVM本流では全くないです。
そもそもGPUをフルに使いたいのに、
バイトコード設計に制約を受けていては元も子もない。
リッチなAPIをネイティブで実装するのがいい。
146:デフォルトの名無しさん
08/12/10 14:10:58
あと２−３年もすればマルチコア一色になるからダイレクトXを使いこなせるって考え方も変わるんじゃないか？
そりゃGPU使えればかなり魅力的だけど、べつにGPUの機能やライブラリを使わなくてもある程度同等ならもう十分だし。
ただ（東工大の例も考えれば）GPUは並列にしないとあまりうまみがないし、個人のPCでGPUを多段式（予算６万として３枚以上）にする人は滅多いにいないだろう。
147:デフォルトの名無しさん
08/12/10 15:13:57
URLﾘﾝｸ(blogs.sun.com)
URLﾘﾝｸ(www.jroller.com)
なんつーか、既存のプロジェクト(kijaro)とモメてる？
148:デフォルトの名無しさん
08/12/11 00:42:57
>>138
屈折自体を計算する必要がない？3Dグラフィックわかってる？
アニメっぽいテクスチャのべた塗りでいい？それほんとにやったらどんなしょぼいもんができるかわかってる？
バーチャファイター１だぞ。
カートゥーンレンダリングのこと言ってる？
149:デフォルトの名無しさん
08/12/11 00:44:56
マルチコア一色？あと10年は掛かるな。
アップデートしなくちゃいけないのは人間だて。
150:デフォルトの名無しさん
08/12/11 00:53:58
マルチコア一色？Larrabeeのことか？
151:デフォルトの名無しさん
08/12/11 00:55:52
ゲーマーと同じ発想のようですけど、デテールにこだわるなら勝手にどぞ。
デテールにこだわるあまり３Dを熟知しているゲームPGを２０人も雇うなら人件費の方が大きいよね。
152:デフォルトの名無しさん
08/12/11 01:05:50
open glがデフォで使えるようになったのは1995-1998頃から普及しだして3年ぐらいじゃなかったか？
PCと一緒にグラフィックカードも買ってくれるようになってからだったしな。
ただライブラリが貧弱で実際プログラムする敷居は高かったけど。
短絡で考えればメインPCを買い換えるは無いだろうけど、
マルチコア（CPU)はサブPCとかサブノートとか追加で導入されていって普及していくんじゃないかな。
俺の開発用PCは確か８年前でintel 1.4Gだし、別にゲームの専門・職業でやってるわけじゃないからね・・・
153:デフォルトの名無しさん
08/12/11 01:09:20
（Sunが真面目に取り組む気があるなら）将来的にはJOGLよりJava3Dのが速いんだろうな。
154:デフォルトの名無しさん
08/12/11 01:34:28
JOGLよりJava3Dのが速いかどうかは、ハードの問題でライブラリ（アルゴ）はあまり関係ないんじゃないの？
それよか、自分で実装するのも面倒だし、特定ハードの機能に依存しないアルゴがあればいいよ。
遅いかもしれないけどそれは先も書いたとおり、速いか遅いかはハードの問題。この辺りは、古参兵だと今だにごっちゃなんだろうけどｗ
155:デフォルトの名無しさん
08/12/11 01:43:42
抽象度が高い方がハードウェア特性を吸収しやすいってことだよ。
結局の所ソフトウェアのボトルネックは大抵が人間系だ。
156:デフォルトの名無しさん
08/12/11 01:49:07
ただ、マルチコアだと速いくなるってことはないだろうと思う。
OSが握ってるわけで、未だとプロセス(os thread)管理が主体みたいで、PGが直接制御するような代物でもないようだからな。
CPUに入ってるFPUユニット(sse)を常時乗っ取れるかどうかとかもあるけど、そういうのはライブラリの仕事でしょ。
ただPGは、gcのようにストレスなく並列計算でき、memory管理とかも気にせず、float[][][]使いまくりで2d(と擬似3d)プログラムできるんじゃないか？
現在要求されるハードを全部解決できるからな・・・
擬似的じゃなくて、3dバリバリ使いたい（PGやゲーマ）なら普通にGPU導入するだろうし、3dの表現効果とかカード１枚でやる程度のベクトル計算はGPUの畑だろう。
3dは、表現効果を全く考えないなら、ただの座標計算でしかないし（ワイヤーをクルクルみたいなアレ）、gpuとか不要じゃない？
157:デフォルトの名無しさん
08/12/11 01:50:05
ところで >>151はゲーム作成のコスト削減の話をしてただけなのか。
158:デフォルトの名無しさん
08/12/11 01:51:13
わかったことは、「アルゴ」なんて言葉つかうやつは、信用できないってことだな。
159:デフォルトの名無しさん
08/12/11 02:31:58
ナルトのレンダリングってかなり高度だと思う。
160:デフォルトの名無しさん
08/12/11 02:40:31
>>158
ALGOLの作者に謝れ!
161:デフォルトの名無しさん
08/12/11 03:11:40
>>157-160
おまえらの相手なんかしてたからageちまったじゃないか！どうしてくれるんだよ！
３Dでよくある何チャラ法とか知ってます！ってのじゃなくて、アルゴをちゃんと勉強したことあるなら>>155みたいな思想は持ってないな。
たとえば、座標上の点を推定するために補間関数を考えたとき、
そのアルゴ・関数では端点（極点）での精度が著しく悪くなるアルゴなら、
この問題はいくらハードが速くなったところで解決できない。
こういうのはアルゴ（ソフト）の問題じゃないの？ｗ
これは光（法線）と影（ブレンド）の従来３Dの理論上の計算方法と同じ問題で、ソフト（例えばダイレクトXとか）ではいくら技巧的にやっても解決できるはずはない。
jvmにSSEやgpuユニットとかの計算専用（ベクトル計算）FPUを呼び出すbytecodeがあってもいいってのは面白いと思う。
162:デフォルトの名無しさん
08/12/11 03:30:07
それにはJava VMの仕様の一部としてバーチャルSIMD演算器を
定義する必要があるだろう。
163:デフォルトの名無しさん
08/12/11 05:34:41
URLﾘﾝｸ(weblogs.java.net)
そろそろ来るのか？
164:デフォルトの名無しさん
08/12/11 05:36:43
>> 161
なんか、がんばって知ってる難しい単語ならべたようにしか見えない。
座標の補完で精度が悪くなるアルゴリズム？
補完で繰り返し収束するようなアルゴリズムなら、ハードが速くなると解決するね。
というか、座標の補完で著しく精度悪くなるようなアルゴリズムって何？
どういう座標補完を前提にしてる？
ソフト(ダイレクトX）って書いちゃうってことは、DirectXわかってないことバレバレだし
165:デフォルトの名無しさん
08/12/11 05:49:51
その定義はそんなに難しくない。and or xor の配列へのapplyでいいだろう。例えば
void xor (arrsrc, off, arrdst,off, count);
するとベクトルの内積（算術・論理演算）が定義できたことになる。スカラー倍もしかり。
だから最低[Bでand or xor だけあれば、後はライブラリでコピーと変換するだけ。
add,mulとかも論理演算があればライブラリで何とかなる。
仕組みについては多倍長BigIntegerを自作してみるとわかるんじゃないか。
この辺りの合理的な設計（十分条件）はハードの専門家（SUNとかIBMとか）の方が詳しいんじゃないのかな？
166:デフォルトの名無しさん
08/12/11 05:53:45
個人的には、struct,stackallocの方が優先順位は高いけど、このsimd呼び出しも面白そうだなぁ。
どうしてかというと、jvmプラットでサポートされてるってことになるから、
例えばintelでasm使ったりintel製コンパイラ使ったりせず、またjniでmmx,sseゴリゴリしなくてもすむし、
javacだけでなくjrubyやjavafxでも言語仕様やライブラリでサポートできるから。
ただjvm bytecode眺めてみたんだけど、配列のコピー(arraycopy)のbytecodeはないから、
この内積論理演算はarraycopyの代用にもなるんだよね。実質的に演算子だし、追加されてもいいんじゃないのか？
167:デフォルトの名無しさん
08/12/11 05:55:51
>>164
知らない話題になると揚げ足取りに変身するのは、どの分野にもいるね。
君みたいなゴミはうん千うん万と見てきたよｗ
168:デフォルトの名無しさん
08/12/11 05:58:51
>>164
昔からいるスレ主だろうけど、君は知らない話題に首を突っ込まないでエスケープ解析だけを頑張ってればいいよｗ
169:デフォルトの名無しさん
08/12/11 06:05:01
>>167
受け流すヒマがあれば、合理的な反論の一つもしてみたらどうだ？
170:デフォルトの名無しさん
08/12/11 06:05:29
>>164
人の批判をするなら
まずはアンカーぐらいちゃんと付けられるよ
うになってからじゃないの？ダサｗw
171:デフォルトの名無しさん
08/12/11 06:15:29
補完とか漢字も分かってないのに批判しだして調子に乗ってるのは笑えるｗ
ていうかどの分野でもこういうゴミが沸いてくるから何にも教えたくなくなるよな。
こういうゴミが一つでもいると、逆にスレを徹底的に荒らす実験でもしようかと思うww
ま、スレが荒れるのも自業自得なんじゃね？ｗｗ
172:デフォルトの名無しさん
08/12/11 06:20:27
合理的な反論とか意味分からんｗｗ
>>164を見るに、全くわかってないお子ちゃまじゃんかｗｗ
あまりのお馬鹿に笑いが止まらないし鼻くそが吹き飛んだじゃないか！
173:デフォルトの名無しさん
08/12/11 06:24:54
>>166
リアルでは「ジャバしかやったことありませーん」とか言うレベルだろ。
だから話についていけないし、java.netのキチガイブログを読んでばかりで、次から次と最新技術の追っかけやってるしか能がない。
おまえなんか厨房レベル、つまりジャバ・アイドルの追っかけと同じだろ？ｗｗ
174:デフォルトの名無しさん
08/12/11 06:25:43
アンカー間違えたｗ
>>163
早く死ね
175:デフォルトの名無しさん
08/12/11 06:37:37
>>172
朝から顔まっかにして・・・
結局どういう補間が精度わるいか書かないし、DirectXもわけわかってないし。
連投してレス先間違えまくるほど、痛いところつかれたんだな。
176:デフォルトの名無しさん
08/12/11 06:41:18
あまりに高度・技術な話題に、このスレの住人はついて来れないって落ちだろ。
この程度のスキルで調子に乗るなら、このスレは国内外のリソースとかブログ紹介とかの路線でいいんじゃね？
177:デフォルトの名無しさん
08/12/11 06:48:00
頑張って難しい単語を理解しようとするのは良い心がけですが、難しい単語が理解できないからといって人のせいにするのはいけません。まず「補完」の漢字すら言われないとそのまま間違って覚えてたでしょｗｗ
人のことを「ソフト(ダイレクトX）って書いちゃうってことは、DirectXわかってないことバレバレだし」なんていってるヒマがあるなら、そういう癖はすぐに直した方がいいですよ。
178:デフォルトの名無しさん
08/12/11 06:54:04
>>175
連衡てなんだよ。おまえはさ、妄想もいいかげんにしたらどうだ？おまえがいるとスレが荒れるだろ。
179:デフォルトの名無しさん
08/12/11 06:55:30
>>175
補間の漢字も知らなかった奴が「書いて欲しい。分かってない」とかマヌケなことぬかすな。ゴミｗ
180:デフォルトの名無しさん
08/12/11 07:14:06
人工無能君に一人芝居モードでも追加されたのか？
そういや元からあったっけか。
181:デフォルトの名無しさん
08/12/11 07:24:02
>>164
＞補完で繰り返し収束するようなアルゴリズムなら、ハードが速くなると解決するね。
人工無能君のこの発言の意味がわからないんですけど、たとえばどういうアルゴリズムで補完することこのような現象になるんですか？
それと座標補完ってなんのことですか？
182:デフォルトの名無しさん
08/12/11 08:00:22
はい補間と補完まちがえました。スミマセン。
で、アルゴリズムわかってないみたいだから説明してやるよ。
>>161のいうような精度の悪い補間は知らないから推測な。
その補間に連立方程式を使うとする。複数点を指定して補間するとすれば、連立方程式解く可能性は高いな。
連立方程式を解く場合には、適当な値を答えとして連立式に当てはめて計算すると、少し正しい答えに近い値が求まる。
さらにその値をもう一度連立式に当てはめると、もっと正しい値に近づく。
つまり繰り返すたびに精度が高い値に近づく。
そうすると、ハードが遅いときに十分な精度まで求められなかったのが、ハードが速くなると繰り返しを多くして十分な精度が求めれる。
連立方程式だけじゃなく、いろいろな計算で、繰り返し回数を多くするほど精度が高まるものがあるから、そういう計算を使うアルゴリズムなら、ハードが速いほうが精度をあげやすい。
だから、繰り返しで正しい値に収束するようなアルゴリズムを使った補間ならハードが速くなると精度の問題が解決する。
わかったかい？
183:デフォルトの名無しさん
08/12/11 08:09:17
アルゴリズムをちゃんと勉強したことあるなら、>>161 みたいにアルゴリズムの問題がハードが速くなったところで解決できないなどという思想は持ってないな。
184:デフォルトの名無しさん
08/12/11 08:20:32
>>166
そういうのはJITの仕事です。
185:デフォルトの名無しさん
08/12/11 08:21:35
ゲーム屋って近視眼の馬鹿が多いね。
186:デフォルトの名無しさん
08/12/11 08:24:06
>>182
もしナンチャッテじゃなくて少しでも勉強したことがあるなら、そのアルゴに名前とかあるんじゃないの？
O[n log[n]]がハードの性能によってO[n]になったりすることは無いんじゃないかな。
難しい話題に飛び込んで赤っ恥をかく性格だし、ここらへんが人工無能君の限界だったかｗ
187:デフォルトの名無しさん
08/12/11 08:29:48
＞そうすると、ハードが遅いときに十分な精度まで求められなかったのが、ハードが速くなると繰り返しを多くして十分な精度が求めれる。
こういう発想は根っからの技術者ってところかｗ
それに、有効桁（精度）とアルゴリズムの区別もついてないみたいだし、アルゴうんたらよりもハードでごり押しタイプか。
ダイレクトXのAPIは熟知しているMS信者だとしても、所詮ダイレクトXがなければただの素人だろｗ
188:デフォルトの名無しさん
08/12/11 08:31:00
>>182
それで、あなたの脳味噌は補完されましたか？ｗｗ
189:デフォルトの名無しさん
08/12/11 08:39:23
所詮ゴミなんだし、いじめるのもそのへんで・・・
190:デフォルトの名無しさん
08/12/11 08:47:07
お母さんがゲームばかりしていると馬鹿になりますって言ってました。
191:デフォルトの名無しさん
08/12/11 09:26:50
がんばって煽ってみたけど逆に恥じかいたって落ちか。
お父さんが言ってたけど「知らないことに頭突っ込んじゃいけない」典型例だな。
192:デフォルトの名無しさん
08/12/11 09:53:50
>>182
こういう人が他のスレで暴れてスレが荒らされるんでしょうね。
どんなにスキルが上がってもコメネケーション・スキルは中学生レベルですか。
育ちが悪く、どこにいってもいじめられてたんでしょうね・・・
193:デフォルトの名無しさん
08/12/11 09:57:56
論理的思考力が中学生以下の大人よりましだ
194:デフォルトの名無しさん
08/12/11 10:20:50
論理的思考力ｗ
195:デフォルトの名無しさん
08/12/11 10:38:32
スルー出来ないのは厨房だからｗ
よっぽど悔しかったんだろ？ｗｗｗ
196:デフォルトの名無しさん
08/12/11 11:20:30
>>186
俺は>>182じゃないけど、なんでアルゴリズムの速度の問題がいきなりアルゴリズムのオーダーの
問題にすり替わってるんだか…まあ確かに指数関数オーダーのアルゴリズムはハードウェアが
いくら速くなったところで大して速くならないが、O(n)とかO(n log n)程度のオーダーのアルゴリズム
ならハードウェアの性能向上による恩恵は十分受けられるでしょーに。しかし、アルゴなんて
奇怪な略語をいつまでも使ってる辺りまともな技術者には見えんなあ。
197:デフォルトの名無しさん
08/12/11 11:44:21
マッキントッシュといっても最近の若いもんには通じません＞＜
198:デフォルトの名無しさん
08/12/11 12:08:30
アイマックってのはビックマックの友達か何かですか？
199:デフォルトの名無しさん
08/12/11 13:19:19
>>198
Wikipedia項目ﾘﾝｸ
200:デフォルトの名無しさん
08/12/11 13:36:46
>>186
連立方程式の解き方なら、ガウスザイデル法だろ
「有効桁（精度）とアルゴリズムの区別もついてない」って何言ってるの？
がんばってオーダーの話もちだしたようだが、精度の問題がハードの速度改善で解決できる例をあげただけだろ。定数項の問題。
201:デフォルトの名無しさん
08/12/11 14:32:06
>>136 が単純なCGの例としてあげてるのであろうナルトのムービー見たらかなり高度なCGで、PS3のCellじゃないとできないような負荷がかかっていそうで笑った。
202:デフォルトの名無しさん
08/12/11 23:15:05
>>200
がんばって勉強したみたいだね。
おこちゃまは早くおうちに帰りなｗ
203:デフォルトの名無しさん
08/12/11 23:18:52
>>200
端点の近くで大きく振動する補間関数といわれてすぐ思いつかないならモグリだな。
おまえも大恥かきに来たんだろ？ｗ
204:デフォルトの名無しさん
08/12/11 23:21:51
ここ何のスレだっけ？
205:デフォルトの名無しさん
08/12/11 23:26:45
いまだにアルゴの話で負けて悔しがッてる奴がいるんだろ。
どうせ一日中wiki読んで勉強でもしてたんじゃないか（笑）
>>201とかみても妄想癖強そうだし、こいつの人生は一生負け組ｗ
206:デフォルトの名無しさん
08/12/11 23:28:19
そもそも連立方程式とかいいだしてる辺りから分かってないよねｗ
207:デフォルトの名無しさん
08/12/11 23:29:20
同じ奴が何度もレスしてファビョってるだけだな
そろそろ正常化したいんでよそでやってくれ
208:デフォルトの名無しさん
08/12/11 23:30:59
なんか、「ドンキホーテ」って感じだよね。どの板（分野）にもいるんだろうけど。
負け組みに人はどんなにスキルが向上してもやっぱり負け組みなのかｗ
209:デフォルトの名無しさん
08/12/11 23:32:58
変な流れなので無理やり次世代Javaの話に戻すと、
上の方で話題になったJVMレベルでのSIMD演算器実装はやって欲しいなあ。
で、Mathライブラリの増強かMatrixライブラリの新設で、ベクトルと行列の計算メソッドを作って欲しい。
現状だと自分で組んでるけど、forループ回してfloatなりdoubleなりの計算をさせてるんでスマートじゃない気がするし、
といってそのためだけにシェーダー勉強するのもしんどい。
もっとも、JVMでSIMD演算器を持ってなくても、Hotspotで検出してネイティブSIMD命令に変換してくれれば
それはそれでかまわないともいえるけど。
210:デフォルトの名無しさん
08/12/11 23:36:16
次世代Javaの話題なんてこのスレはやってないじゃん。
ただの英語ブログの紹介でしょ。サルでも出来るｗ
211:デフォルトの名無しさん
08/12/11 23:37:40
哀れな男だ
212:デフォルトの名無しさん
08/12/11 23:39:15
「補完」も知らなければ「連立方程式」を持ち出したりして、頑張って食いつこうとしてるだけの厨房だったか。厨房なのに変な自尊心があるんだろ。無能のクセにｗ
213:デフォルトの名無しさん
08/12/11 23:39:19
>>209
文脈で検出ってできるのかね? 積和が連続してるっぽかったら変換とか?
214:デフォルトの名無しさん
08/12/11 23:42:57
ゴスリングも指摘してたが未だに1.4.2とか使って、
Java5以降の構文が使えない環境とか今後どうなるんだ？
SE for Businessとか契約する日本の企業なんてほとんどいないだろ
215:デフォルトの名無しさん
08/12/11 23:46:19
イメージ加工処理でループ使って配列アクセスする実装が多いし（当然だけど）、それに満足しない人はjniとかでmmx,sse使いたくなる。
ただdot netやcではなくて、javaでプログラムやる人はそこまでネイティブ機能に関心を示すかどうか疑問だからjvmでサポートするのが妥当だろう。
これはjavacの話ではないし。他には動画コーデックとかも負担激減になるだろうな（処理も速くなると思うけど）。
216:デフォルトの名無しさん
08/12/11 23:57:28
>>213
分岐命令が入らないで積和が連続している部分を見つけられれば、SIMD命令への変換はできそう。
ただ、for文の積和をSIMD化しようとすると、ループアンロールをかけないとマッチングしないような気がする。
Hotspotではループアンロールもやるみたいだけど、ループ回数が可変だったりすると、
プログラマが処理を組まないと自動で効率よくやるのは難しい気がするなあ。
自分の場合、ほとんど3ｘ3と4ｘ4しか使わないから、定数ループにすればアンロールはやりやすいと思う。
217:デフォルトの名無しさん
08/12/12 00:00:14
>>214
1.4.2なコードなんてゴロゴロしてるよ。
つか、俺はまだ5.0以降が使われてる仕事のコードは見たことがない……。orz
218:デフォルトの名無しさん
08/12/12 00:01:06
＞気がする
ってなんだよｗ
仕様とかはちゃんと読んだけど、ただの一読者・ただの理想論と同じだな。
こんな糞スレにいるやつの妄想を信用する奴も哀れだ
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5157日前に更新/182 KB
担当:undef