現世代Javaの動向 1 - 暇つぶし2ch

現世代Javaの動向 1 ..

477:デフォルトの名無しさん
08/03/01 16:46:51
たしかメソッドに渡してしまうとエスケープ解析対象外になるんじゃなかったか？
mat3=MyMatrix.mul　(mat1,mat2);
みたいなの。

でも思うんだけど、クラスが状態変更しないこと（immutable　class）が
保障されているならこのインスタンスもエスケープできるんじゃないか？
実装とか細かい動作はしらね―けど。
例えばclass　Stringとか、class　BigIntegerみたいなの。これと同じく、自作クラスの
class　MyMatrix　みたいなのでも出来て欲しいなと思って。

エスケープ解析とか、多分知ってる人いないし、見向きもしてないと思うけど。
特別に行列とかにこだわってんじゃないけどね。

478:デフォルトの名無しさん
08/03/01 16:53:23
ローカルでnewしてるわけで、メソッドに渡したのにスタックフレームと一緒に解放されたらまずいか。
やっぱimmutableとか関係ないし、無理だな。

エスケープ、やっぱイラネ―よ。こんな無駄な技術に人員割くなよなw

479:デフォルトの名無しさん
08/03/01 17:01:55
やっぱC#じゃないけど、stackallocみたいので一気に解決だな。
で、メソッドに渡すときは、自動でclone()みたいのを呼び出しになる。
たしかどこかの言語でref,　outみたいなのあったけど、Javaだとそういうのカッコ悪いしｗ
stackallocのバイトコードを追加してくれ！

480:デフォルトの名無しさん
08/03/01 17:33:12
リファクタリングしまくるとエスケープ解析と相性悪くなりそうだな。
それでも、短いコードは正義だぜ。

481:デフォルトの名無しさん
08/03/01 19:03:28
そんなことじゃC99コンパイラと同じ運命だろうな

482:デフォルトの名無しさん
08/03/01 19:07:28
バイトコード、並列処理な話題をたのむ

483:デフォルトの名無しさん
08/03/01 19:08:33
エスケープ解析に最適化ってのは、ループ展開の最適化程度のことを大げさに言ってるだけｗ

484:デフォルトの名無しさん
08/03/01 19:57:27
もともとエスケープ解析が役に立つのは世代別GCを意識したコードだろうから
そんなに効果が挙げられないのかも

コンカレントGCのレスポンスが改善されるとそれだけでほとんどいけるんだけどね

485:デフォルトの名無しさん
08/03/01 20:36:31
Nimbusはいったいいつ正式リリースされるのかね

486:デフォルトの名無しさん
08/03/01 20:40:54
Summer/Fall 08じゃないのかね

487:デフォルトの名無しさん
08/03/01 21:33:53
ありがとう。
というかjdk6.dev.java.netにあったのね

488:デフォルトの名無しさん
08/03/02 01:29:35
>>477
実行時に最適化すれば、他のパッケージの関数の解析結果も利用できる。

489:デフォルトの名無しさん
08/03/02 06:12:01
GCの機嫌を取るようなコードを書く必要があるなら、
Javaなんかでやらない、でそもそも他の専用・特化した言語でやるよｗ

native　float　func(float);
とかすると、結局ネイティブ関数呼び出しコストが大きいし、
なんならjava.nioとか使うから別にいいよｗ

490:デフォルトの名無しさん
08/03/02 06:15:58
ただよく考えてみると、あまりに技巧的じゃないか？
例えば100x100の行列計算とか、BigIntegerで100桁の四則演算とsqrt実装とか、
今の計算機なら当たり前すぎる事をやりたいのに、
それをするためにはJavaでは高度な技術(java.nioとかgc)が要求されるから、
Javaは敬遠されるんじゃないかと思う。

本当はJavaがいいんだが、専門学校中退とかおサルなクリエーターはflushとかお気軽な方に流れる。
今のままじゃ、Appletで微分方程式や３Dのデモとかが限界なのかもね。

多分だけど、エスケープ解析とかで技巧を凝らせば２０ナノ秒も速くなるんだろうけどｗ

491:デフォルトの名無しさん
08/03/02 06:35:06
確かに行列計算とかはサーバー側で計算したりさばいたりするものではない罠
せいぜい1ミリ秒速くなる程度だし、forループ内でnewしまくりでいいんじゃね？
さらにUIがGUIなら、ボタンとかのイベント待ちの時にGCすればいいだろ。
これが今のプログラミング・スタイルだと思う。

492:デフォルトの名無しさん
08/03/02 10:34:20
>>490
> Javaは敬遠されるんじゃないかと思う。
> 本当はJavaがいいんだが、専門学校中退とかおサルなクリエーターはflushとかお気軽な方に流れる。

（　ﾟдﾟ）ﾎﾟｶｰﾝ

493:デフォルトの名無しさん
08/03/02 10:40:31
>>492
「技術的に1秒速くできる！」とか、いわゆる技術者のオナニーなんて実際はどうでもいいし、この指摘はある意味的を得てる。

494:デフォルトの名無しさん
08/03/02 11:22:41
>>492
＞（　ﾟдﾟ）ﾎﾟｶｰﾝ　

久々に見てワロタｗ
いつのまにか、こんなスレの主になってたのかｗ

495:デフォルトの名無しさん
08/03/02 11:37:27
誰ともコミュニケーションできないで、研究室で寂しく２CHに書き込んでる雑用見習いあたりだろよ。
やけにAPIとか詳しそうだしｗ

496:デフォルトの名無しさん
08/03/02 12:40:57
>>491
GCのタイミングがコントロールできないのがゲーム等で問題になってる
いつ発生するかわからない1msのGCより発生をコントロールできる10msのGCのほうがましなんだよね
new領域のGCができればいいけど、今のsunのSystem.gcの実装はfullGCなんだよね

497:デフォルトの名無しさん
08/03/02 15:50:20
ゲーム。その話になると思ったんですけど、多分設計上の問題で回避できるでしょう。
別にゲームじゃなくても、アニメーションとかストリーム（とかメディアAPI）でも
単純に作ると一瞬「ピックっ」として止まりますしｗ
GCをコントロールしたいという発想から抜けてみてはどうですか？

498:デフォルトの名無しさん
08/03/02 15:51:07
ストリーミング

499:デフォルトの名無しさん
08/03/02 16:45:17
1ms程度ならいつ発生したって別にどうってことない
60fpsで動かすとしても1フレームあたり16msもあるんだから十分吸収できる
問題は100msにも達することがあるfull　gcの方で・・・

500:デフォルトの名無しさん
08/03/02 16:59:58
60fps、だいぶ大規模なソフトでも作ってるんですね。
まずC++（とかMS)を考えてみて、どうしてもJavaじゃないとダメなんだと考えてから設計してますか？
それともJavaならどこでも動くとかの趣味程度なら、Javaなのにこれを気にすること自体が間違いでしょう。

jdk1.8がどうなるかjdk1.9が何を目指すか、そういうのに合わせるのが吉じゃないでしょうかね。
もし趣味程度なら、メモリとかの先の話は独学や個人で解決できる問題じゃないですよ。

501:デフォルトの名無しさん
08/03/02 17:11:09
60fpsが出せる環境はwin,　mac,　linuxとかに絞られるからグダグダいうなら別にJavaじゃなくていいんと思うぞ。
C++とかで、自分でオブジェクトプール実装とかデストラクタでメモリ管理とかも出来ないのに、GC云々なんて文句垂れてるわけじゃないよなw
ANSICで簡単なGC実装してみろよとまでは言わないからさｗ

502:デフォルトの名無しさん
08/03/02 17:19:23
>>499
FullGCは発生はとめることはできるが、新世代は無理
垂直同期直前でGCが発生すると確実にフレーム落ちするんだよ
これは100マイクロ秒でも同じ

発生をコントロールできる10msは処理が終わった後余裕があるという場合は多いからその間にやればいいというだけ

503:デフォルトの名無しさん
08/03/02 17:30:46
そこまでリアルタイム性が高くてシビアなのを求めるんなら
C で行けって言うのは確かに間違いではないんだが、
俺も出来る事なら Java で書きたいかな。

Java の C++ に比べたときの仕様の簡潔さ・小ささや
エクリプスのコードの書きやすさは今のところ他の言語で同等のものを知らない。

504:デフォルトの名無しさん
08/03/02 17:42:39
JDK6がでてしばらくたってネタがなくなったためいまではおちてしまったが、
ゲームスレではそのGCのコントロールとクラスロードのコントロールと
ジョイパッドがあればCとほぼかわらない物ができるという結論だったはず

505:デフォルトの名無しさん
08/03/02 18:19:45
JavaのGCは想像を絶するほどの人員と金が投資されてるし、
これに比べれば上のエスケープ解析なんかは鼻くそ程度の小手先技でしかない。

GCにグダグダ文句つける奴はさっさと消えてくれよ。

とっても、非常に単純でいいなら個人でGCを実装するのは実はそんなに難しくないんだけどｗ

506:デフォルトの名無しさん
08/03/02 18:25:58
>>504
60fpsとか作ったことないし、イマイチ、どういう原因でGCの起動と処理時間が問題になるわけ？

Graphics.dispose();
Image.flush();
とか手動で解放（を期待する）でいいだろ。

もしかして違うところが話題なの？

507:デフォルトの名無しさん
08/03/02 18:31:49
>>501
そんな大規模なわけでもない・・・期待に添えなくてすまそ。
JOGLが出てきたんで、Javaで作ってみるのもいいかと思ってやってみてるだけの試作品。
もちろん商用でもない単なる趣味。
とりあえず作ってみて、無理そうだったらC++に戻るよてい。
>>501
C++でもいいんだけど、Eclipseが便利なもんで。。。
GCは昔趣味でScheme処理系作ったときに実装したことありますよ。
世代別は面倒くてやめたけど簡単なコピーGCくらいなら。
>>502
FullGCを止めるには、やっぱnewとかallocateDirectを抑えるしかない？
メモリ管理を自前でやるんなら、C++とあんまり変わらない・・・

SoftReference使いまくってGCまかせのリソース管理（テクスチャのキャッシュとか
モデルデータのキャッシュとか）ってのはやっぱりだめですかそうですか。。
ThreadPoolExecutorとかもあるし何気に便利なんだよねJava・・・

508:デフォルトの名無しさん
08/03/02 18:32:45
ゲーム類やメディアっぽいことをJavaでやるなら、ジャンルによるだろ。
ハードよりになるからまだ何年も先だろうし、ライブラリがあっても、今は人柱バージョンだろうな。
スカイプみたいなビデオ・チャットが手軽にできれば
少しはメディア系の開発者が増えるんじゃないか？

509:デフォルトの名無しさん
08/03/02 18:45:17
>>507
きっと君は技術的な興味・趣味でプログラムやってるていう感じじゃないか？
作りたいものよりも技術を試してみる方が優先していると思う。
それだけの技術力があれば一応なんでも作れるから、
自分が作りたいもの・作るものにあわせて使う言語を選び、
言語やライブラリの癖にあわせて使い分けるという発想にそろそろ切り替えたらどうだろうか。

＞GCまかせのリソース管理

多分ですけど、jdk1.9とかになるとjavax.lang.native_resource_and_memoryとかの
パッケージで標準サポートされるから自作しても無駄になる、と期待したい！！

allocateDirect　現状ではやっぱこれになるでしょな。

510:デフォルトの名無しさん
08/03/02 19:27:31
> 多分ですけど～と期待したい！！
自分の期待だけを根拠に予想に昇格させるのは止めたほうが

511:デフォルトの名無しさん
08/03/02 19:48:48
真性機械じゃないし、冗談ぐらいは通じるだろｗ

512:デフォルトの名無しさん
08/03/02 19:56:11
100×100の行列計算とか、100桁のsqrtやりたいのにJavaは敬遠されて、flushとかお手軽な方にながれるのか。
へんなの。

513:デフォルトの名無しさん
08/03/02 19:57:45
flush

514:512
08/03/02 20:07:01
>>490な。

515:デフォルトの名無しさん
08/03/02 20:56:20
>>509
そんな感じです。
面白そうなものを見かけたり思いついたりすると試してみたくなります。
常に最新技術を追ってないと追いてかれるという強迫観念みたいなものもなくもないですが。。
アドバイスありがとうございます。
心に留めておきます。

関係ないけど、flashは開発ツール高すぎ

516:デフォルトの名無しさん
08/03/02 21:28:59
自らが電車でお店に行って、店員にクレジットカードで払って、カバンに入れて、家に持ち帰って、
パッケージを空けたあとに、何十分もインストール画面を眺めながら完了するまで待ち、
さらに自分用にカスタマイズ設定をする。
とかだと、おっしゃるように、これでさらに日本円まで支払うとすれば、高すぎかもしれません。

きっとあなたは、孤独でかつ正直者なんでしょうなｗ
大学とか行かないで独学なのかとおもうのですけど、
freebsdの世界にいる人たちはあなたみたいな静かな人とか技術力が高く趣味の人が多いですよ。

517:デフォルトの名無しさん
08/03/02 22:12:59
>>506
表示されるときは垂直帰線期間中にフリップされる
つまり、垂直同期中直前にGCが発生すると意図せずフレームレートがおちる
一方、処理が6ms以内でおわっていれば10msのGCを指定した場所で発生させても問題はなくスムーズに動く
レスポンスとスループットの違いみたいなもんだ

>>507
SoftReferenceは使い物にならないよ
FullGCなくすならコンカレントGCがもっとも楽な方法だけど、new世代では効果がない

使用するメモリ量を把握することやプリミティブ型を積極的に使ってのオブジェクトプールしかないが
こうなるとJavaの利点が激しくなくなるのでnew世代のGCもSystemクラスにほしいところ

518:デフォルトの名無しさん
08/03/02 23:17:18
もうObject#dispose()でいいよ。

519:デフォルトの名無しさん
08/03/02 23:19:56
そんな糞実装だとJavaの意味ゼロだろう・・・
リソースの開放だけなら別に問題ないけど
コレクションの参照とかどーすんだよ

520:デフォルトの名無しさん
08/03/02 23:44:23
明示的に破棄されなかったオブジェクトはGCで回収されるでいいんでない？
どうせGCを無くすわけにはいかないんだし。

Java開発者側もGCの改善に苦労してるんだったら、プログラマ側に任せられる
ところは任せたほうが双方ハッピーになれる気がする。

521:デフォルトの名無しさん
08/03/03 00:02:39
Object#dispose() で明示的に破棄されたけど、他で強参照してる場合とかはどーすんの？

522:デフォルトの名無しさん
08/03/03 00:17:17
>>521
そんときはException投げる。
って、それちゃんとやろうとしたらNextみたいなシステムレベルの
object poolになっちゃうか。

523:デフォルトの名無しさん
08/03/03 05:17:33
例外を投げられずに、異常動作に陥る時の方が多い。
必ず例外を投げられるようにしようとすると、
普段のメモリ確保、解放のコストも上がる。

524:デフォルトの名無しさん
08/03/03 06:37:31
freebsdは、こいつがやりたい（であろう）uiとか3dとかと無縁の世界だと思うが？
20ナノ秒間の処理をどう扱うかが「本物のハッカーである」ことに変わりはないｗ

525:デフォルトの名無しさん
08/03/03 08:05:56
ここでGCの細かい内部のことを解説してる奴がいるけど、一見凄いことしてそうだけど
実はコンパイラ作成とかGC実装とかしたことないような所詮は専門バカ（研究者）だろな。
そんな俺様研究者の話なんか真に受けんなよ。

研究者ってのは原子・粒子の大きさ（笑）、２００００ピコ秒の限界に挑戦！とかしてるアホだし、
現実からこいつらを見れば、こいつらのようなキモオタ（学者級）のオナニーに付き合わされてるようなもんだろうな。

526:デフォルトの名無しさん
08/03/03 10:15:15
リアルタイム用の仕様は見たのか？

527:デフォルトの名無しさん
08/03/03 10:20:31
>>525
でもそんな変人がいるから世界が進歩するんだよ。

528:デフォルトの名無しさん
08/03/03 10:30:51
研究者も何タイプかに別れるからね。
観察・統計取るの好きな人とか、実験・実証するの好きな人とか。

529:デフォルトの名無しさん
08/03/03 10:59:32
もし一人とか孤独でやってんなら、java.netで世界中のハッカーが集まっておのおのがプロジェクトやってるから、
そっちでみんなでやってると英知が集まってるし役立つだろう。
特にメディアっぽいこととか最先端で試行錯誤中なんかはヒートしてるｗ
英語でもロムってる分には２CHとおなじだしな。

プロジェクトの最終的なゴールは、ライブラリー作ることになるだろうな。
MSの世界で見てるとオープンって何？とかなんだろうけどね。

530:デフォルトの名無しさん
08/03/03 11:02:47
外人も変な要望とか記事かくやついるけど、MSDNとかPerlほどカルトっぽくはない。
URLﾘﾝｸ(community.java.net)

それと、日本のIT記事？はつくづくゴミだって分かるよｗ
そもそも三次四次情報だしｗｗ芸能ゴシップネタと同レベルだろなｗｗ
日本のブログっぽいので、個人のやつは、そもそもゴシップぽいことは書かないし、
word,excel,vba程度の普通の人はそもそも高度な事は書けないし。

531:デフォルトの名無しさん
08/03/03 11:20:37
日本の個人の奴は別にひどくないけど。
IT記事（特にWebのやつ）はほぼゴミ情報でしかない。
Webの記事は、書いてる奴の原稿料も微々たるもんだから、そんなもんだろ。
これを信じるかどうかは別だけどｗ
読むには一見無料かもしれないけど、いつのまにかAJAXのスキル云々講座・・・とか（笑い）

って、文章が尻切れてたｗ

532:デフォルトの名無しさん
08/03/03 12:27:35
>>525
なんかlコンプレックスでもあるの？

533:デフォルトの名無しさん
08/03/03 12:58:38
>>532
定期的にこいつ現れるから無視しとけ

534:デフォルトの名無しさん
08/03/03 14:31:02
>>532
GCの話になるとムキになるようだし、コンプレックスあるのはおまえの方じゃないのか？

535:デフォルトの名無しさん
08/03/03 14:45:17
日本語のIT記事（笑）は半年から既に1年以上前とかで古い。
ニュースなのに半年とかなんだよ。
一番の問題は、その当時の外人の記事を直訳や下手な和訳で日本人記者（なのか？）の
英語や業界などの素質や精通度合いを疑ってしまうのが多いところ。

536:デフォルトの名無しさん
08/03/03 16:00:01
>>521-522
Interface実装することで特別扱いにするとかかな。Iterableみたいなの。
でも既にライブラリ（パッケージ）で、そういう擬似リアルタイム処理可能で
Object.dispose()みたいなことしてくれるようなのがあったし。

537:デフォルトの名無しさん
08/03/03 16:42:39
JavaSE7の登場が近づいてきたこの時期にやっと5.0の記事とかどんだけ・・・というのは確かに多い

538:デフォルトの名無しさん
08/03/03 17:03:57
既に日本の若い情報技術者（笑）は、日本語では情報が少ないので海外にシフトしてますよｗ

539:デフォルトの名無しさん
08/03/05 09:34:58
6u5 が出てるみたい。

540:デフォルトの名無しさん
08/03/08 12:17:47
6u5にしろ、6uN b12にしろ、Windows L&Fのときに、
JFileChooserのコンストラクタで、IndexOutOfBoundsExceptionが出るのは俺だけ？

541:デフォルトの名無しさん
08/03/08 13:32:04
u4では問題なかった?

542:デフォルトの名無しさん
08/03/08 18:43:03
u5でも6uNb12でもでないよ。

543:540
08/03/09 12:54:41
>>541-542
URLﾘﾝｸ(bugs.sun.com)

どうやら、Vista限定バグらしい。StateはClosed, fixedになってるけど、↑のページの
コメントにあるように、fixされてない。

544:デフォルトの名無しさん
08/03/09 13:07:58
JFileChooserの遅いのも結局なおってないからね
ファイル選択でいらいらするのはやめてほしいな

545:デフォルトの名無しさん
08/03/11 04:40:20
JDK6u10 build13
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

In b13, we introduce new Java system properties to support the usage of version download
and Pack200 without any server side requirements.
This addresses the issue that is raised in RFE 6378311.
This increases the flexibility of deploying version download and Pack200 JARs
without using JNLPDownloadServlet on web servers.

Pack200形式のファイルをサーバに置くとき、サーブレットが要らなくなったそうな。
今まで必要だったのがおかしいっちゅう話ですね。
あと、Numbus周りの改修とプラグイン周りにたくさん改修が入ってます。
デモのSwtingSet2が新しくなってるそうです。

546:デフォルトの名無しさん
08/03/17 03:20:20
GC時間を気にしていた人・・・
-XX:MaxGCPauseMillis
は試したかな？

いずれにせよ、New世代のGC時間をコントロールするにはNew世代の
大きさを小さくすることになると思うけどね。
UseParNewGC + UseConcMarkSweep で何処まで行くか・・かな・・・
ただ、いくら時間が短くても
フレームレートいっぱい処理に割り当てると同じ事だからどうしたもんだか。

547:デフォルトの名無しさん
08/03/17 09:21:48
JOGLとかLWGLで実行速度稼いでGC時間は気にしない。

548:デフォルトの名無しさん
08/03/17 14:48:58
本当に困ってんなら、あきらめてフレームレート下げるだけでよい

549:デフォルトの名無しさん
08/03/17 17:31:34
>>546
それやってみればわかるけどうまく動かないよ
あくまでも参考値だし、それに割合のコントロールじゃないから

この期間だけはGCは1msでも発生するな、というだけ
この処理が終わったら（JOGLやJava2Dのフリップ等）10msはGCつかってもいい

>>547
JOGLでもJavaコードが動いている間の問題なので関係ある
ネイティブコードを呼びに逝くときが問題

>>548
原理的に1fpsでも60fpsでも発生するからそれで改善されない
フレーム落ちがはいっていいのならローエンドのCore2Duoでも60fpsとかは余裕

550:デフォルトの名無しさん
08/03/18 02:29:34
で、そこまでの水準を求めて、おまえは一体何をやりたいんだ？

551:デフォルトの名無しさん
08/03/18 02:31:08
てか、そこまで念入りに調べてんなら、おまえがHP作ってみんなで情報共有すればいいんじゃないか？

552:デフォルトの名無しさん
08/03/18 04:10:18
批判は簡単だけど、
自分で形にまとめるのは難しいじゃん

553:デフォルトの名無しさん
08/03/18 05:40:45
↑おまえじゃまとめる事すら出来ないけどなｗｗおまえは黙ってろよｗｗ

554:デフォルトの名無しさん
08/03/18 11:46:14
>>549
そこまでいうなら、ネイティブコードで書いても、OSがフリップのタイミングにタイムスライスを
くれなくてフレーム落ちする可能性がある。RTOS使えって答えになる。
java上だと、OSがタイムスライスをくれないリスクに加えて、GCと重なるリスクがあるから、
ネイティブよりもフレーム落ちする可能性は高いけど、
どっちもゼロじゃないから割り切って選択しろってことになるんじゃないの？

555:デフォルトの名無しさん
08/03/18 23:58:56
>>554
GCが原因になってフレーム落ちするのが頻繁に発生するのが問題
WindowsなどOSが原因となってフレーム落ちするほうはそんなに頻度が高くない
30fpsくらいだとめだたないけど、60fpsじゃないとお話にならないしね

JavaSE7の正式版が出てからソースいじるさ

556:デフォルトの名無しさん
08/03/19 00:23:55
60fps使うアプリって例えば何があるの？

557:デフォルトの名無しさん
08/03/19 01:02:20
まぁ、1フレーム時々落ちるぐらいだったらそんなに神経質になるなよって気もするけど
GC掛かったら悪くすれば10や20フレームぐらいは一気にドロップするんじゃね？

アクションゲームでフルGCなんて掛かった日には悪夢だろうな。

それでも、今ならJavaでゲームって言うのもそんなに悪い選択肢だとは思わない。

558:デフォルトの名無しさん
08/03/19 01:51:22
>>555
お話にならないのはおまえの神経の方じゃね？

559:デフォルトの名無しさん
08/03/19 20:34:09
Full GCはともかくScavenge GCって
フレームがまとめて落ちるほどそんなに激しく発生するん？

560:デフォルトの名無しさん
08/03/22 02:33:30
企業の阿保どもはいつになったらJREをバンドルするという事を学ぶのだろう

561:デフォルトの名無しさん
08/03/22 02:41:06
マイクロソフトの安卸しオプションがなくならないと無理だろ。

562:デフォルトの名無しさん
08/03/22 05:04:53
JREはそんなに普及してないのか？問題にならないほど（jdk1.4相当は）普及していると聞いているが。

563:デフォルトの名無しさん
08/03/22 07:15:38
ニュー速からこっそり誘導して調べた結果は 1.4 以降が起動したのは半数弱だな。
MSJVM すらインストールされていないのが 41% も居た。

564:デフォルトの名無しさん
08/03/22 07:20:44
×インストールされていないのが
○インストールされていないかアプレットオフってる連中が

565:デフォルトの名無しさん
08/03/22 09:49:16
XML出力に特化したBean/XML変換の最近のトレンドって何ですか？
XMLEncoderとかJAXBとかあると思いますが、出力だけでいいので速いものはないかなと。

566:デフォルトの名無しさん
08/03/22 13:33:41
どちらも標準APIになった現在ではシリアライズの結果がどう違うのかだけ考えればいい
出力だけってのがわからんが、入力はせんの？

出力結果を見るとJAXBのほうがはるかに扱いやすいと思う
ただ、アノテーションつけたりクラス構造の制限もあるけどね

速さだけがすべてなら自分で計測してみては?
シリアライズするbeansの種類によって結果は違うかもよ

JAX-WSとかすべて基盤はJAXBにうつったので個人的にはJAXBをお勧めしたい

567:デフォルトの名無しさん
08/03/22 15:55:21
JVMも所詮は一つのアプリだし、半分も動けば十分じゃないか？
PCの台数換算でも、多く見ても数億台って単位だろ。

568:デフォルトの名無しさん
08/03/22 15:56:07
＞ニュー速からこっそり誘導して調べた

ていうかこっちの方が問題じゃないかｗ

569:デフォルトの名無しさん
08/03/22 21:13:00
VMはひとつの環境っていう認識はどれくらいが持ってるんだろうね

570:デフォルトの名無しさん
08/03/23 01:32:19
>>563
MSJVM「すら」というか、今時だとMSJVM入れる方が難易度高いだろ。

571:デフォルトの名無しさん
08/03/23 02:09:25
そういう意味の表現じゃねーっつーの。

572:デフォルトの名無しさん
08/03/23 02:37:34
>>569
おまえ、その環境ってのがどういうのか当然分かってんだろうな。

573:デフォルトの名無しさん
08/03/23 15:52:28
カリカリすんな、サル。

574:デフォルトの名無しさん
08/03/23 21:01:14
さるｗ

575:デフォルトの名無しさん
08/03/23 23:30:03
>>573
こういうこと言うサルは早く退場し欲しい。

576:デフォルトの名無しさん
08/03/24 01:53:29
おまえら >>572 が「その環境」について説明するから静かにしてろ
↓

577:デフォルトの名無しさん
08/03/24 01:53:48
カリカリすんな、ハゲ。

578:デフォルトの名無しさん
08/03/24 02:19:11
ハゲじゃねぇよ、剃ってんだよ

579:デフォルトの名無しさん
08/03/24 04:37:03
>>576
で、おまえは誰だ？

580:デフォルトの名無しさん
08/03/24 14:58:57
URLﾘﾝｸ(japan.cnet.com)
>マイクロソフト、Javaを使ったWindowsアプリ開発でEclipse財団と協力へ
なんか、MS自らVista用SWTをてこ入れするらしい。
この話とJNA組み合わせると、J/DirectでMSが作りたかった環境になるよね。

Javaから締め出されたMSはC#/CLR/WinFormsという世界を別個に作ったわけだけど、
eclipseユーザーに取り入ろうという戦略か。

個人的には、MSにSwingをてこ入れしてもらいたい。
WinFormsとかMFCとか、GTK+のような、Heavy weight widgetなGUIツールキットは
そろそろ時代に合わなくなってるんじゃないかと思う。CPUパワーが上がって、相対的に
ウィンドウシステムのウィンドウ間のメッセージング(Win32でいうとSendMessage)がボトルネックに
なってる。テーブルやリストで大量の項目を扱うときは、いかにSendMessageの回数を減らすかが
チューニングになってて、なんかいびつな感じ。
MSも、大量のコントロールが頻繁にレイアウトされるIEのレンダリングでは、Light weight widgetだし。

581:デフォルトの名無しさん
08/03/24 15:25:20
Swingというクロスプラットフォームを意識したものをMSがいじるとはおもえん
SWTはWindowsの環境を他の環境にも、という意味合いからスタートしてるのでそっちなんだろう

というかSwingは標準APIだからコントロールは難しいんじゃね？
sunががんばってWindowsネイティブにちかいようにはしてるけど

それよりFileChooserの死ぬほどトロイのいいかげん直してくれよと
JavaSE6u2からひどすぎる

582:デフォルトの名無しさん
08/03/24 15:44:23
>>580
それMicrosoft が割り当ててくれる人員ってどんぐらいいるんだろ？
そこまで大規模な話なんか？って気もする。
EclipseはVisualStudioと競合する製品だし。

583:デフォルトの名無しさん
08/03/24 17:22:29
>>580
> eclipseユーザーに取り入ろうという戦略か。
というよりは、開発者にWPF移行を促す戦略の一環なんじゃね？

584:デフォルトの名無しさん
08/03/24 22:45:48
>>583
同意。既にこんなのあるから、これを支援することでWPFを後押ししたいんじゃないかな。
URLﾘﾝｸ(d.hatena.ne.jp)

585:デフォルトの名無しさん
08/03/25 10:59:29
>>580
おまえ、その考え方は治した方がいいよ。キモイ。

586:デフォルトの名無しさん
08/03/25 11:57:48
>>580
> 個人的には、MSにSwingをてこ入れしてもらいたい。

真逆やん
SWTをもっとWindows(WPF)べったりにしようって取り組みなんだから。

> ネイティブのWindows Vistaのようなルックアンドフィールを備えたアプリケーションを
> Java開発者が容易に開発できるように

587:デフォルトの名無しさん
08/03/25 15:51:50
Java SE 6 Update N build 14 is now available
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

b13に比べるとちょっとしか変更はない。
betaが近いな。

588:デフォルトの名無しさん
08/03/25 18:50:13
>>580は確かにキモイな。オナニーのし過ぎだろ？

589:デフォルトの名無しさん
08/04/02 12:59:54
Java 6u10 beta age

590:デフォルトの名無しさん
08/04/11 22:50:12
今回のupdateはずいぶん変わったみたいだけど、実際体感はどうよ？

591:デフォルトの名無しさん
08/04/12 00:15:29
update5はほとんどかわってないぞ

592:デフォルトの名無しさん
08/04/12 00:31:17
URLﾘﾝｸ(java.sun.com)

593:デフォルトの名無しさん
08/04/12 00:55:38
updateNはまだでてないだろ？

594:デフォルトの名無しさん
08/04/18 12:40:18
Java SE 6 Update 10 Build 22 is now available
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

LCD表示周りの修正、あとエラーダイアログの情報が増える。
JavaKernel周りの修正、・・・・
Betaテストの結果が反映しつつあるというところでしょうか。

595:デフォルトの名無しさん
08/04/18 23:41:46
update6登場

あんま修正箇所が大きくない

JavaSE7やupdateNにリソースがいってるんかね

596:デフォルトの名無しさん
08/04/20 19:52:13
>595
・アプレット開始時にブラウザ巻き込んで死ぬことがなくなった
・Windows Live系の一部BHOがあるとアプレットが起動しなくなった

個人てきにはJavaｵﾜﾀ

597:デフォルトの名無しさん
08/04/20 19:54:07
まともなソフトはまずアプレットじゃないからあんまり問題にはならないと思われ

598:デフォルトの名無しさん
08/04/20 20:21:41
アプレットでブラウザが死んだことが1,2度会ったから、よくあるバグなんだろう。

599:デフォルトの名無しさん
08/05/21 13:55:12
synchronizedは気にするほど遅いもんですか？StringBuilderとStringBufferで比べてどうでしょうか。

600:デフォルトの名無しさん
08/05/21 13:58:12
>>599 速度は実測が基本。

601:デフォルトの名無しさん
08/05/21 21:18:44
>>599
速度を気にする用途なら差は出る
StringBuilderが使える環境でStringBufferつかうのはタコだが

602:デフォルトの名無しさん
08/05/21 23:45:33
>>601
synchronizedはそういう問題じゃなんだが？

603:デフォルトの名無しさん
08/05/22 00:30:02
>>599
感覚的に答えるならStringBuffer,StringBuilderの速度の違いは結構あるよ。
synchronizedが求められる部分っていうのは大抵速度的にもキモになる部分が経験的に多かったし、
そこが見事にボトルネックになってしまったことも多い。

synchronizedを書かずにすむ設計でいけるならなるべく避けたほうがいいし、
そっちのほうが見通しもいい事が多いよ。

>>602
どういう問題なのか良くわからないから詳しく言ってくれ。
俺のエスパー能力で最大限意図を汲むと
「StringBuilderが使える1.5系なのにStringBuffer使ってる奴はタコｗｗｗ俺さま流行最先端ｗｗｗ」
って言ってる奴に対して
「いや、どちらのクラスを使うかはスレッドセーフを求められるかどうかとか、そういうことに左右されるんだが…」
って言いたかったのかな？

604:デフォルトの名無しさん
08/05/22 02:18:23
実際のところStringBufferの同期化が必要な場面ってのはVector以上に考えにくい

605:デフォルトの名無しさん
08/05/22 07:13:06
>>603
おまえ、エスパーだなｗ
「関数内で使うの許してもいいが、StringBuilderを戻り値に使う奴は大ダコ」て意味だけどｗ

606:デフォルトの名無しさん
08/05/22 07:16:30
>>604
だからさ、どうれぐらい差があるか知りたいでしょ。
おれはそれでもStringBuffer使うけどね。どうでもいい差でバグ探しする時間のほうがコスト高なんじゃないの？
たぶんVectorのそれと似たような事だと思うけど、StringBufferはプリミティブでしょｗだれか実測お願い。

607:デフォルトの名無しさん
08/05/22 11:17:09
public class Main {
public static void main(String[] args) {
System.out.format("java.runtime.version=%s%n", System.getProperty("java.runtime.version"));
int count = 1000, length = 1000;
for (int i = 0; i < 5; i++) {
// System.gc();
long t = System.nanoTime();
testStringBuilder(count, length);
System.out.format("StringBuilder[%d] %,d%n", i + 1, System.nanoTime() - t);
t = System.nanoTime();
testStringBuffer(count, length);
System.out.format("StringBuffer[%d] %,d%n", i + 1, System.nanoTime() - t);
}
}
public static void testStringBuffer(int count, int length) {
Random random = new Random();
for (int round = 0; round < count; round++) {
StringBuffer sb = new StringBuffer();
for (int i = 0; i < length; i++)
sb.append((char) random.nextInt());
}
}
public static void testStringBuilder(int count, int length) {
Random random = new Random();
for (int round = 0; round < count; round++) {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < length; i++)
sb.append((char) random.nextInt());
}
}
}

608:デフォルトの名無しさん
08/05/22 11:17:40
java.runtime.version=1.6.0_06-b02
StringBuilder[1] 46,349,536
StringBuffer[1] 79,622,829
StringBuilder[2] 40,456,329
StringBuffer[2] 74,662,283
StringBuilder[3] 36,223,249
StringBuffer[3] 72,998,594
StringBuilder[4] 36,400,646
StringBuffer[4] 73,236,472
StringBuilder[5] 36,957,769
StringBuffer[5] 72,561,457

だいたい2倍の違いらしい。

609:デフォルトの名無しさん
08/05/22 11:50:45
>>608
5回では少ないよ
JIT効くまで回してほすぃ

java.runtime.version=1.6.0_05-b13
StringBuilder[1]　158,443,766
StringBuffer[1]　207,692,900
StringBuilder[2]　103,762,950
StringBuffer[2]　234,251,232
StringBuilder[3]　96,471,555
StringBuffer[3]　203,392,112
(略)
StringBuilder[18]　96,870,134
StringBuffer[18]　96,189,123
StringBuilder[19]　106,288,413
StringBuffer[19]　102,384,099
StringBuilder[20]　96,629,241
StringBuffer[20]　95,805,536

610:デフォルトの名無しさん
08/05/22 12:04:12
２倍とか言って、測り方を知らないようだな。笑えるｗｗ

611:デフォルトの名無しさん
08/05/22 12:05:41
C:\Users\------\Documents>java -server -XX:+DoEscapeAnalysis Main
java.runtime.version=1.7.0-ea-b26
StringBuilder[1] 66,886,993
StringBuffer[1] 121,272,397
StringBuilder[2] 46,811,257
StringBuffer[2] 113,352,675
StringBuilder[3] 41,445,770
StringBuffer[3] 43,428,984
StringBuilder[4] 41,599,701
StringBuffer[4] 41,859,789
StringBuilder[5] 42,782,253
StringBuffer[5] 42,855,167

jdk7 + エスケープ解析付きだと、3回目あたりから殆ど差がなくなるみたい。

612:デフォルトの名無しさん
08/05/22 12:57:54
エスケープ解析とかのレベルの差しかないのかよ。
３秒に２倍で６秒は大問題だけど、３０ナノ秒の２倍で６０ナノ秒になんか価値はあるのか？
そもそもchar[]じゃダメなのか？測定ってのは、そういう問題でやるんだよな。

613:デフォルトの名無しさん
08/05/22 13:01:28
>>605
戻り値にStringBuilderは通常問題ないよ
同期化の意味間違えてないか？

>>606
常にJDK1時代のコレクション使う人？

614:デフォルトの名無しさん
08/05/22 13:13:53
WindowsプラットフォームでJavaのランタイムライブラリーは、VBランタイムの様に、
もう問題ないぐらいに普及していて、クライアントのバージョンももう１.５を前提としてよいのでしょうか。

アプレットも考えてるんですが、アプリの方でも普及割合はどうなってるのでしょうか？（そういう調査してるサイトとかあるんでしょうか）

615:デフォルトの名無しさん
08/05/22 13:22:58
>>614
アプリならPrivateJRE使って６前提でいいと思うが
6は大幅な高速化してるからね

616:デフォルトの名無しさん
08/05/22 15:57:53
実際はjavaなんて「名前ぐらいで聞いた事あるな～」ぐらいで知らない人が多いし、
クライアント前提なら今でもappletとか1.1ぐらいしかないよ。騒いでるのは開発者とかだけだ。
運が良くて1.4とかかもしれないけど、1.2やswingだと思っていたほうがいい。

617:デフォルトの名無しさん
08/05/22 15:59:04
>1.2やswingだと思っていたほうがいい。
日本語でおけ

618:デフォルトの名無しさん
08/05/22 16:16:32
日本語でおけ　ってどういう意味？おけ？

619:デフォルトの名無しさん
08/05/22 16:29:19
putJapaneseのことだろ。

620:デフォルトの名無しさん
08/05/22 19:30:46
MSがXPとVistaでがっちりガードしたから
いくらJavaが頑張ってDesktopをうかがってももう無理だろ。
それよりもJavaの市場は組み込みとか（携帯とか新規の方）じゃないのか？

621:デフォルトの名無しさん
08/05/22 19:55:13
>>616のいいたいことがわからん

622:デフォルトの名無しさん
08/05/22 20:30:31
>>621
おまえは日本人じゃないだろｗ

623:デフォルトの名無しさん
08/05/22 21:17:10
まあJavaとJavascriptがごっちゃになってる人は意外と多い

>>614
問題ないって。というかインストールしてもらえばいいよ必要なら。
Java入れたくねーって神経質な人もいるけどかなり少数派。
一般人は、VBランタイムもJREもダウンロード＆クリックでガンガン入れてくれるもの。
JREはバンドルできるから、一緒に入れてしまうアプリもあるよね。

624:デフォルトの名無しさん
08/05/22 21:41:15
Javaで作ったお試しとか、ちょっとしたツールとかだとどうかな。
よくあるでしょ、VBのファイル名一括変換とかそういうの（別にCで作れるけど）。
海外だとゲームも多いけど、日本（のデスクとッぽうアプリ）はしょぼいでしょ。
iriaだったかそういうのに感動した口でしてｗ

625:デフォルトの名無しさん
08/05/22 21:52:05
>>622
あの意味がわかるなんてエスパーだな

ああ芝君だから本人か

626:デフォルトの名無しさん
08/05/22 22:55:25
芝君ってなに？
ん？エスパー？

627:デフォルトの名無しさん
08/05/23 01:12:27
>>612
なんというレベルの低いレスw

628:デフォルトの名無しさん
08/05/23 08:58:52
せっかく速度テストするなら、有用な結果を作れよ。せっかくやっても、この有用であったかなかったかで評価されるんじゃね？

629:デフォルトの名無しさん
08/05/23 09:03:37
そもそもマイクロベンチに有用性を求めるなよ。
最適化具合が変われば結果なんかコロコロ変わるんだから。

630:デフォルトの名無しさん
08/05/23 09:12:04
そりゃマイクロベンチにかぎらんがな

631:デフォルトの名無しさん
08/05/23 09:15:01
実プログラムでホットスポットがわかった場合
その部分の速度上げるような工夫するのは意味があるけど、

マイクロベンチではそんな事やっても意味ないし。

632:デフォルトの名無しさん
08/05/23 09:53:28
じゃStringBuilderイラネ―じゃん。Javaにしては珍しく不用なものを、それもよりによってjava.langに詰め込んだものだｗ

633:デフォルトの名無しさん
08/05/23 10:03:14
要らないのは>>632のアタマだと思うが……

634:デフォルトの名無しさん
08/05/23 11:22:58
エスケープ解析博士はまだ生きてんのか・・

635:デフォルトの名無しさん
08/05/23 17:16:34
BigDecimalとかnewしまくってもパフォーマンスに影響ないんでしょうか。
forでnew　BigDecimalを１０００回まわしたりとか当たり前の世界なんですが・・

636:デフォルトの名無しさん
08/05/23 17:22:40
>>635
そりゃ1回もnewしないよりはパフォーマンスは悪くなるが、
newしなけりゃ機能しないんだったらnewした方が圧倒的にパフォーマンスは良い。
パフォーマンスや最適化を議論したいのならまず実測してからにしろ。

637:デフォルトの名無しさん
08/05/23 17:36:51
まずは、そこがパフォーマンスに影響するかどうかを確かめてからだな。
2：8の法則。

パフォーマンスに影響が出る部分でなければチューニングしてもさして得しない。
1000回回すのがいやなら回さないスマートなアルゴリズムを考える。

638:デフォルトの名無しさん
08/05/23 18:44:10
あのー・・・テイラー展開なんですけど・・

639:デフォルトの名無しさん
08/05/23 21:19:41
javaでそういう高度なこと理解できる人少ないからｗｗ

640:デフォルトの名無しさん
08/05/23 22:29:27
テイラー展開だったら、どこまで扱うか有効数字管理がちゃんとしてるから
ループ回数は決まってるでしょ。
ループ回数云々じゃないですね。アルゴリズムが決まってるんだったら。

641:デフォルトの名無しさん
08/05/23 22:46:45
1000回ってぶっちゃけループの回数としては全然大したことが無いように
思えるけど

本当に1000回なの？
1000回のnewなんてゴミみたいなもんだよ

642:デフォルトの名無しさん
08/05/23 23:54:06
sin(x)を一回起動するだけでループ1000回とか当たり前なんですけど？
偉そうなこといって実装した事ないでしょｗ

643:デフォルトの名無しさん
08/05/24 00:33:01
いや、だから1000回とかでも n 倍のオーダーなら別にたいした事無いって言ってるんでしょ？
最近は処理速度の問題は大抵 n 乗とかのオーダーが存在するかしないかってのが多いんじゃない？

644:デフォルトの名無しさん
08/05/24 00:47:38
10^3ってことじゃないのか？それよりも、newを1ミリ秒の間に1000回やっても（出来たらだけど）、パフォーマンスに影響ないってことを君はいってるんじゃないの？

645:デフォルトの名無しさん
08/05/24 00:50:26
たぶん空想で言ってるんでしょ。あいからわずだけど。
当たり前だけどdoubleと比べると体感では少し気になる。
こういうのは外部プログラムを呼び出して楽できないし

646:デフォルトの名無しさん
08/05/24 00:56:31
遅い速いが重要になるのはアプリの対象領域にもよるだろう。
科学技術計算なんかは許されないだろうし、3Dゲームなんかは結構適当でもいい気がする。
そういう対象領域が特定されていないうちから「BigDecimal は遅いから使えない」なんて言っても無駄だぜ。

double より BigDecimal が遅いのは当然なんだし、
その遅さが許容できるかどうかは状況によるんだし。

647:デフォルトの名無しさん
08/05/24 10:43:11
無理するなってｗ
空想でものもいわなくて言いから

648:デフォルトの名無しさん
08/05/24 11:30:32
>>646
>科学技術計算なんかは許されないだろうし、3Dゲームなんかは結構適当でもいい気がする

関係ないけど、これ、むしろ逆だと思うが

649:デフォルトの名無しさん
08/05/24 11:32:03
はあ

650:デフォルトの名無しさん
08/05/24 12:58:33
>>648
どこの分野にもいるが、使った事もない奴が妄想してるだけっしょ

651:638ではないよ
08/05/24 13:07:27
誤解してる人が居ると思うのでテイラー展開の計算についてちょっと書いとく。
テイラー展開の計算は、nを順に大きくした結果を足していくシグマ計算でもって
もとの式を書き換える手法。

シグマ計算のnが大きくなるに連れて、その足し算の数は小さくなっていく。
つまりどんどん本当の結果に漸近するような感じ。
この形に展開することでnを現実的な数字、例えば1000まで計算することで
近似値を得る事ができるというもの。

で、その式はWikipediaでも見てもらうとして、ちょっとコンピュータ的に書くと
Sigma( f(n)(a) * (x-a)^n / n! )
で、これを見ると毎回の計算でベキ乗オーダの計算が必要に見えるけど
実は、n-1の時に (x-a)^(n-1) や、(n-1)! は計算できているし f(n)(a)も
頑張ればなんとかできる場合がある。つまりそのときはテイラー展開の計算量はo(n)となる
この最適化をするかしないかで議論が分かれてるように思ったのでちょっと説明してみた。

で、まあベキ乗とか計算するとき大変なのが有効数字の管理。
これが計算精度に関わってくるからね。コンピュータで計算する以上それは仕方がない。
なので計算プログラムの設計者は有効数字を見積もらなくてはいけない。
それは翻って、ループの数を増やして意味のある数字を出す為には有効数字を
ちゃんと管理しておかなくてはいけないということ。
なので1000回という数字がどういう意味で提示されたのかはっきりしないと話は発散したままです。
>>638
話の収拾宜しく。

ちなみに、Objectのnewは大してコストかからんですよ。
むしろ、BigDecimalは計算にコストがかかります。そこも話が食い違ってるのがあったっぽいね。

652:デフォルトの名無しさん
08/05/24 13:10:18
シグマ計算てどこの分野の用語だよ？素人は黙っとれｗ

653:デフォルトの名無しさん
08/05/24 13:22:47
元の質問者の口ぶりからすると、計算それ自体が目的で、しかも
高々1000回のループやnewで済む計算処理を、さも大したことのように
想像で語ってるだけのようだから、
そんなことはゴミみたいなもんだから気にスンナでFAだと思うが

それをリアルタイム制御なり60FPSなりの要求時間の枠に押し込めなきゃいかん、
とかだと全然話は違うがな

654:デフォルトの名無しさん
08/05/24 13:23:46
だから、BigDecimalでもうatanとかsinとか実装してるわけ。
で、double（当然native　sin呼び出しだろうけど）と比べるともたついて、sin(x)/xの積分とかに影響出るわけよ。
sin値出すのに数百回、積分もいれて１０００回以上のループは当たり前で。

例えば100ミリ秒に１０００回以上のnewしまくりで遅いんだろうし（たぶん）、
これなら外部ライブラリをjniで呼び出したほうが速いんじゃねってこと。
jniはstackframe使えるし、newしまくりはないしな。

初めから有効精度固定なら固定少数とか外部ライブラリとか別の実装にするよ。

655:デフォルトの名無しさん
08/05/24 13:24:31
それと、計算にコストかかるってのは分からないでもないが嘘だな。
学生なんだし、適当な事グダグダ書いてないで、ちゃんと勉強したほうがいいよ。

656:デフォルトの名無しさん
08/05/24 13:26:04
javaって役に立ちますか？パソコンのプログラミングを始めたいのでアドバイス

下さい

657:デフォルトの名無しさん
08/05/24 13:30:52
>>654
お前は誰だ・・・

どっかで見かけたJavaはGCがフレーム間の任意のタイミングで出せないから糞だって言ってた奴か？
お前の用途にBigDecimalが向かないのはよく分かってるから問題を混ぜないでくれ・・・・

658:デフォルトの名無しさん
08/05/24 14:43:49
リアルタイムとか60fpsの環境でBigDecimalを使うなんて、おまえは全く想像力豊かな奴だなｗ
おまえみたいな奴が知ったかしてもらっても困るし、相手にならないよ。

659:デフォルトの名無しさん
08/05/24 14:53:31
３Dのマトリックスあたりだと実装次第でオブジェクトの再利用できるし、newして再計算で座標出してもそんなに影響はないんだろう。

しかし、BigDecimalで任意桁の初等関数とさらに積分となると、１秒間の間にnew　byte[1024*64]とかが当たり前の世界だろうな。
stack　allocateがない今のjava　jvmでは試験目的ならあるけど、実用的じゃないだろう。
それこそjniとかでcを呼んだ方がいい。
gplライセンスのパッケージを使うわけにもいかないしｗ

自分で再利用できる（ムータブルの）BigDecimal実装がいいだろう。
多倍長のクラス、誰か作ってよｗだけどjavaは変なところで面倒だな。

660:デフォルトの名無しさん
08/05/24 14:56:45
まあ、ByteBuffer使って解決かと思うけどね。

661:デフォルトの名無しさん
08/05/24 15:12:53
で、ここには何人いるんだ？

662:デフォルトの名無しさん
08/05/24 16:36:39
誰もいません
全て幻想です

663:デフォルトの名無しさん
08/05/24 16:42:37
>>658
1048576*745472くらいの解像度の動画でも作ろうとしてるんじゃないか？w

664:デフォルトの名無しさん
08/05/24 17:08:40
Javaでリアルタイムやるのはまだ夢でしょ。それともjsr　1の話なのか。
>>653は幻想に取り付かれてんだろｗ

665:デフォルトの名無しさん
08/05/25 20:42:56
＞ちなみに、Objectのnewは大してコストかからんですよ。　
むしろ、BigDecimalは計算にコストがかかります。そこも話が食い違ってるのがあったっぽいね。　

これの言いたいことがよく分からないんですけど、少し解説してもらえまんせか？

話題としてはjvmとか内部の話で、java言語上の話ではないですよね。java上ならnewはコストがかからないとかで、別に気にしませんけど。
jvmの実装レベルの話にまで言及するなら、オブジェクトプールの技もあるんですけど、結局mallocに行き着くわけでしょ？
jvmなど内部の話題とおもうんですけど、一体どの基準で大してコストがかからないって言うんですかね。

それと、BigDecimalの計算にコストがかかるときはどういうときなんですか？

次ページ