最近のJavaって軽くね？

>>571
ソースコード見たが
JavaのRandomクラスはもともと遅いんだよな。
それから一回実行したら二度と生成し直さなくていいものは
staticにして欲しいな。

配列もBufferクラスを使えば早くなる。
それすら使ってないからどうも怪しい。
最大ヒープメモリサイズの指定もしてなさそうだし。
JVMに-serverオブションつけて実行した結果もないのは
自分の都合にあわせてわざとやってるのか？　って思うんだが。




それにしてもJava One Tokyoで発表された資料と結果が全然ことなるな。
JavaOne TokyoではJava5からはSun製JVMのほうが高速、あるいは同等である
ケースが紹介されていたのだが。
今では低速であるケースはほんの一部になっている。

http://www.shudo.net/jit/perf/Linpack-1000-P4.png
をよくみるとJavaは非常に早いところに位置しているものだな。
あとはBufferクラスやReferenceインターフェースの使いどころ、
最大ヒープメモリサイズの指定どころによって
速さがかわってくるものだな

>>571
# Slashdot での大論争。これは今までで一番愉快な
Java 対 C++ の議論に違いありません。
C++ 愛好家は必死に「不公平だ、こっちはメモリ管理を
手動でやらなきゃいけないのに」と主張しています。
公平を期するための彼らの提案は - System.gc() の
呼び出しを山ほど突っ込んで Java 側を遅くするというも
のでした（お気づきでない方のために。Java は System.gc()
を呼び出さなくてもメモリを回収します。 System.gc() の呼び
出しを追加してもメモリ回収の速度が遅くなるだけです）。
続く抗議もすべて、このベンチマークが Java をひいきしてい
るという一点に集中しているようでした。しかし奇妙なことに、
３年前までは当時の JVM をテストしても C++ の方が速いとい
う結果が出たものです。このノイズの山を掘り返せば、有意義
なコメントが見付かるかも知れません

# さらに続く議論。この事件から生じた騒動（または余分なキャラ）
で大儲けできた人がいるかも知れませんね

# Java と .NET のガベージコレクションに関する調査
# WebSphere は自動的に負荷分散の最適化を行うことで、ハードウェア要件の低減をねらいます
#
# Java 1.5 は 20% 高速化した模様
http://www.javanews.jp/javap/newsletter043.html

>>572
Sun JDK 1.4.2 Server VM, Sun JDK 1.5.0 Server VMってあるじゃん。
あと、Bufferクラスの使い方教えてくれ。

>>572
IIBM とか Sun の JDK でも Server VM では
C++ と遜色ない性能をだしているわけだから、
そういう問題ではないのではないかと思うけど。

テストの内容が Sun の Client VM にだけ不利な内容だった、
という解釈は無理があるような・・・

ちゃんと自分の環境を調べてみると、JDK とは別に何かと一緒に入れた
JRE 1.5 があって、eclipse 起動するとそっちを使って動いていますた。

速いという話の IBM の JRE を入れて、そっちで eclipse を起動すると･･･
んー確かに起動が少し速い。pluginの読み込みってI/O boundsな処理かと
思っていたら案外そうでもないのか。感覚的には1.5倍くらい。

IBM はもっとこれバラ撒いてくれればいいのになぁ・・

>>575
スキンヘッドの櫻庭でぐぐれ

>>578
Bufferクラスの使い方はわかってたんだ…言い方が悪かった、すまん、言い直す。
Bufferクラスで配列より早く操作する方法を教えてくれ。
サンプルコードを書いてくれるとさらに嬉しい。

>>579
「配列より速く」っていったって、
適当な配列とその配列内での有効な要素の個数とのペア
　ex.
　class DataHolder { public byte[] buffer; public int count; };

なんかを用いれば、Buffer で出来る操作はだいたい似たようなコストで
実装できるよ。でもいつもいつもそんなの自前でやってられないから
Buffer 使ったほうが早いし同じくらい速い。

>>579
お前の目は節穴か？
スキンヘッドが作ったサイトにサンプルコードも載ってるだろ。

>>580
>>572が "配列もBufferクラスを使えば早くなる。" と言っていたから、
>>579で "Bufferクラスで配列より早く操作する方法を教えてくれ。" と書いたんだが…

>>581
普通にBufferクラスを使うことは出来るんよ。
で、普通に使ったら(俺のコードが悪いのかもしれないが)配列よりBufferクラスの方が遅いから、
配列より早く使う方法のサンプルコードを書いてくれと…>>579は言葉が足りなかった、すまん。

俺も知りたい

チャネルでどうにかしろってことでわ

(￣ー￣)ﾆｯ、ちゃねらー

教えてクンが必死過ぎるスレはここですか？

そうですが何か？

教えて君にはすでにヒントを与えてヤッタがな

どれがヒントなのかもわからない

どれがヒントか明示したれや！暗黙の宣言なんて、Fortranじゃあるまいしｗ

知ったか君と教えて君の取り合わせは不毛だと思う今日この頃・・・

カマトト君はw

Channelがヒントじゃん

>>592
DatagramChannel
FileChannel
Pipe
SelectableChannel
ServerSocketChannel

これらでどうしろと？

見事に止まってる

軽いから

皆さん、注目してください！！！！！！！！！！！！！！！！！
　
C言語厨の正体は高卒であることが発覚しました！
さあ、Java叩きに必死になっているC言語を思う存分報復し虐めてあげましょう！！！


専門卒や高卒でPG/SEの人っているの？Part2
http://pc8.2ch.net/test/read.cgi/prog/1141003614/

マジで？
高卒がJava叩きしてたの？
サイテーだね

（・∀・）ｲｼﾞｮｳｼﾞｻｸｼﾞｴﾝﾃﾞｼﾀ

>>582
Buffer使えば速くなるとか言ってるのは、あのページの内容がJVMが変わっても
結果は変わらないと信じてるピュアな奴等だから、ここらへんで許してやれ。
結論としては、DirectByteBufferは遅い。

java.version=1.4.2_11
普通の Buffer オブジェクト
Total time = 750
byte[]
Total time = 312
Direct Buffer オブジェクト
Total time = 1047

java.version=1.5.0_06
普通の Buffer オブジェクト
Total time = 781
byte[]
Total time = 296
Direct Buffer オブジェクト
Total time = 1688

java.version=1.6.0-beta2
普通の Buffer オブジェクト
Total time = 703
byte[]
Total time = 328
Direct Buffer オブジェクト
Total time = 766

IntetgerBufferやDoubleBufferなどの
クラスでのベンチも提供してくれ

DirectByteBufferだけじゃつまらぬ

よくわからないんだが、I/O以外で使うの？

【IT】米Red Hat、JavaアプリケーションサーバのJBossを3億5000万ドルで買収へ
http://news18.2ch.net/test/read.cgi/bizplus/1144700222/

軽い軽い
問題ない

とりあえず起動が遅いままでは軽いとは呼べないし
誰も納得しない。

そのうち、PCだとJAVAのシステム自体がC++/CLIで書かれるようになるんだろ？
そうすると、JAVAの実行は
おまいらのかいたプログラム＞JAVA仮装マシンコード＞JAVAVM＞CLI＞CLI実行エンジン＞機械語　という複雑きわまりない仕組みを通ることになるな。
　　　　　　　　　　　　　　　　　　　　（　　　　こ　こ　じ　ゃ　ま　　　）

>>605
言語と実行形態を混ぜて書くな。何を主張したいのかよくわからん。

＞そのうち、PCだとJAVAのシステム自体がC++/CLIで書かれるようになるんだろ？
本当？
位置づけ的には
　JAVA仮装マシンコード=IL
でしょ？

 これからはVistaになる。
 Vistaの標準コンパイラはC++/CLIだ。

 いやおうなしにJavaコンパイラもJVMもVistaで動かすならばCLIになる。
 つうことは、２重の仮想マシンで動く劇的に重い時代遅れのものになる。

 糞高いLinux専用サーバ上ででも金持ちが動かす道楽者専用になるな。
 本来、JavaとSolarisとSPARCという閉じた世界があって、その閉鎖性を強引に
 クライアントであるPC側に吸収させようというのがJava啓蒙の理由なんだが理解してるか？
 PCベースで無償のJavaつかってるということは、ただの道化なんだよ。
 パフォーマンスが悪い？ではSolarisをどうぞ。
 まだうまくいかない？それはｘ８６のせいです。SPARCをどうぞ。

 これがSUNの戦略であり実態でもある。
 お先棒担いでるJava厨房はおぷそ厨房にも似て哀れそのもの。
 無償で宣伝の手伝いm9(^Д^)ぷぎゃー

>>607
馬鹿でしょVistaになろうとC++/CLIでVMを書き、アプリレイヤーで実行する必要は無い
CLI VMと並列なレイヤーにJavaVMを置けば良い

C++/CLIでVM書いた時点で、VMはCLIで生成されるわけだが。
JavaVM自体をどうやって生成するのか詳しく教えてくれ。

多分そのうち、ネイティブｘ８６コード生成はやめるだろうからな。
M$様の都合で。

>>604
0.0001秒程度しか遅くないなら
問題ないじゃん

>>605
> そのうち、PCだとJAVAのシステム自体がC++/CLIで書かれるようになるんだろ？

ﾌﾟ そんなネタを吹聴して騙されるエンジニアがどれだけいると思っているんですか

VistaにはJavaじゃないことぐらい小学生でも知ってるぞ？

小学生は知らないと思います

>>612
日本語でおｋ

>>609
という事はアセンブリで書くとアセンブリのコードができて、Cで書くとCのコードが出来るんでしょうか

>>615 どう答えてやったらいいか途方に暮れる質問するなよ・・・

>615
基本を学んでから出直してくれ
レベルが低すぎてもうだめぽ

C++/CLIなんて使っている人いるの？

OSネイティブの文字コードでどう高速処理するかが今後のテーマだな
UTF-16BEにいちいち変換していては巨大なログファイルは管理できない

UTF-8のほうがUTF-16より表現できるコード範囲が広い。
と、当たり前のことがいま頭に浮かんだ。処理はどっちが早いのかね。
本当なら16のほうが固定長で早いんだけど、エンディアンのことまでからむと、さてどうか

ﾌﾟﾌﾟﾌﾟ Java嫌いなC言語厨は情報処理学会にすら入会できない低脳なのですね

情報処理学会＝プログラマの権威
http://pc8.2ch.net/test/read.cgi/prog/1141487104/

>>620
UTF-16もサロゲート使うから同じだろ

ソフト多層化という方向はその歴史始まって以来、ずっと続いている。
javaの発生もその一つだろ。
そういう文脈の中で重いとか軽いとか議論していて楽しいのか？

おじゃば様が乱立させた煽りスレに対するレスなのかそれは？

>>618
何いってる。サイコーだぞ。

＞UTF-8のほうがUTF-16より表現できるコード範囲が広い。

>>626
ん？どうかしたか？

?

原子力発電所 ( 以下、原発 ) についてもっと知ってほしい
http://members.at.infoseek.co.jp/genpatsu_shinsai/hirai/pageall.html

・原発は地震が発生すると壊れて大事故がおきる。
・原発は放射能を海に流している : 原発を冷やすための冷却水は放射能を含むようになり、それを海に捨てている。
・原発は放射能を海に流している : 放射能がついた放射能防護服を水で洗っている。
・日本ではチェルノブイリに匹敵する大事故が起きそうになった ( 最高に運がよくて助かった ) 。
・原発で発生する放射性廃棄物を捨てるところがない。
・原発で発生する放射性廃棄物は昔は海に捨てていた。
・原発で発生する放射性廃棄物はドラム缶に詰めているがドラム缶の耐久性は低い ( いつかは崩れて漏れる )
・放射性廃棄物を管理するのに原発で生み出す以上の電力 ( そして石油 ) が必要になる。
・そしてその放射性廃棄物は日に日に増えている。
・放射性廃棄物を詰めた「ドラム缶の近く」にいただけでも数時間で死ぬ ( 数秒で死ぬほど高レベルのものもある ) 。
・原発の煙突から放射能は漏れている。

http://members.at.infoseek.co.jp/genpatsu_shinsai/hirai/pageall.html

Javaﾌﾟ

javap.exeのことか？

もうJavaは十分軽い軽い

昔に比べたらな

java だから重いって言ってるやつは何で作っても結局重い。

「Javaの存在自体が軽視されてるから」
とか、下らない煽りを思い付いた

>>635
「お前の存在自体が無視されてるから」
とか、下らない煽りを思い付いた

ホント下らないな