JavaでC++並みの実行速度を出すPGを組むスレ

JavaでC++に近い、より速い実行速度を出すプログラムを組むには、
どういう技術を駆使したり、どういうことをすればいいか考えるスレです。

まずベースはJavaSEになるのかな？

大部分をJNIでやる

超高速CPUでもつむか

クライアントアプリもサーブレットにして常駐しとけばいんじゃね

逆に考えるんだ。
Javaで速いプログラムを組むのではなく
C++で遅いプログラムを組めばいいのだと。

そうだC++をVMで上で動かせばよかったんだよ！！！！！１





あれ？

C++で作られたAPIを呼ばなければ勝てるよ

Javaマシンを作って良いハードウェアを積む

いまさらアプレットやアプリでも作る気か？
VMつむって

姉妹スレ
JavaやるとC++は有害に感じる　int 2
http://pc10.2ch.net/test/read.cgi/tech/1171173223/

綺麗なクラス設計や拡張性の重視に拘らない。
エスケープ解析によるオブジェクトのスタック割り付けが効きやすいように書く。

いろんなサイズのオブジェクトを new delete しまくるプログラムなら Java のほうが速いよ.
まあ、C++ は大半はスタック割付ですむから(ry

PGってもしかしてPro Gram?

プロスタグランジン

PropaGanda

つか、「プログラムを “組む” って言っちゃう奴は使えない」 という経験則。

>>16
それはない.
プログラムは組むものです.
ソースは書くものです.

使えなくてもいい
逞しく育ってほしい

頭悪いのに逞しい奴...


余計性質が悪いと思うぞ。(w

ﾌﾟﾛｸﾀｰｱﾝﾄﾞｷﾞｬﾝﾌﾞﾙ

バイトコードで保持してて、実行時に他にリンクされたモジュール
とあわせて最適化した方が、古典的なC++よりは速くなる。
VC8みたいに、構文木を.objに保持して、リンク時にグローバル最適化
かけられるならC++でも似たようなことはできるけど。
モジュールの再利用性を上げるために、C++の実行効率が落ち、最適化の余地を
削ってるってのはあるだろう。

てゆうかここ流行りそうなんだけど

>>21
どれくらい速いのか見てみたいから
サンプルコードと使用するコンパイラのバージョンやら
コンパイル方法等確認する為の情報一式を提示してくれませんか？

それ(証明)ができないのにC++よりは速くなるなんて
言ってんだったら、VB厨にすら嗤われますよ。

>>23
お前は日本語も読めない/理解できないのか。
これだけの情報があったらVB厨でも確認できるぞ。

>>24
VB厨がそんなに高等だと思ったら大間違いやで.

>>24
言い方が悪かったみたいでごめんなさい。

意訳：
屁理屈・御託を好きなだけ並べて妄想するのはお前らの勝手だけど、
JavaがC++より速く動作する実例をひとつでもいいから示せよ、バカw

開発が速い

>>26
ググったらこんなのあった
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml

>>27
俺、C++厨。でも、それ、否定しない。

>>28
冒頭の malloc 云々のところからして眉唾な情報で始まるけど、
面白そうな情報なんで後でじっくり読んでみます。情報thanks!

>>28
全然新しい話しじゃないよ。
８０年代のオブジェクト指向黎明期の本で、オブジェクト指向と言いながら、実はVMのGCの
話ばかり書いてるのを持ってたな。世代別GCとかは普通。
昔、mallocとfreeはコストが高いから大きく取って小分けして使え教えられたな。
某C++処理系のランタイムライブラリを読んだ時、newする際、あるサイズ以下のオブジェクトは
直接mallocをよぶんじゃなくて、mallocで複数個分取って小分けにしてたよ。

>>26
ttp://www.shudo.net/jit/perf/#scimark2

>>32
これそのまんま信じるようなヤツは簡単に情報操作にひっかかるようなヤツだけだろ。
パッと見ただけでも少なくとも致命的であるJVMの起動時間が無視されているし。
あと、C#にすら負けてるからってC#のDEBUGビルドでのスコアを乗せてるのにワラタ。

>>33
>これそのまんま信じるようなヤツは簡単に情報操作にひっかかるようなヤツだけだろ。
お前にとっては、
　自分の信念に沿った情報→正しい情報
　自分の信念に反する情報→情報操作
なんだな。これが、人は見たいものだけを見て、聞きたいものだけを聞くってやつか。
成長の見込みなし。

SciMarkって数値計算のベンチマークだろ。
数時間かかるのがザラの処理でVMの起動オーバーヘッドなんてゼロに等しい。

>あと、C#にすら負けてるからってC#のDEBUGビルドでのスコアを乗せてるのにワラタ。
ベンチマークの作法すら理解してないし。

>>34
>SciMarkって数値計算のベンチマークだろ。
>数時間かかるのがザラの処理でVMの起動オーバーヘッドなんてゼロに等しい。

そのすぐ下のLinpack benchmark でもみてみ。1秒とか２秒の世界だから。
この時間でのVMの起動オーバーヘッドは無限に等しい。

>>26
お前は日本語も読めない/理解できないのか。
これだけの情報があったらVB厨でも確認できるぞ。

意訳：
この程度の簡単なことさえもさっと確認できないレベルでは、
このスレやこの板に存在することさえも無意味。

コンパイル時間も調べたら面白いことになりそうだな
最近古いMFCのコードコンパイルしたら速くて驚いた記憶がある
Boostなんてサンプルプログラムでもお茶が飲めるのに

とりあえずソース貼ってくれ

javaのネイティブコンパイラ作ればいいじゃんｗ

gcjか？

>>35
VMの起動時間を含んでいるの?

あの首藤さんが、そんな間抜けなことをするとは思えないのだが。

Excelsior JET てどうなんだろう？

結局Javaはクライアントアプリには向いていないのか？

HotJavaを今のjdkで動かせばあるいは、、、動くといいね

Javaでクライアントを作ってるのは見たことあるよ。
業務計は、まあ、スピードは要求されない場合が多いし。

GCが問題なら、オブジェクトをとっといて、使いまわせばオッケー。
プーリングするとnewでオブジェクト作るんじゃなくて、メソッド呼び出しの形になってしまうというのが嫌といえばいや。
コンストラクタのメモリアロケータを拡張できればいいんだけど。

クライアントの起動が遅い問題はJVMを常駐させるためフレームワークがあればいいんだよ。
http://hp.vector.co.jp/authors/VA027994/blanco/blancoservice.html
こういうののクライアント版。
どっかにないのかねぇ。作ってみようかなぁ。
System.setPropertyとかでclasspathの設定って出来るのかしら？？？
jjava -classpath c:\hoge\fuga.jar ugo
とかやって起動できればいいんだよなぁ。

java.net の誰かが、Multi-tasking VMっぽいものを
クラスローダを駆使して作成していたと思う。

Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml

Javaの理論と実践: 動的コンパイルとパフォーマンス測定
http://www-06.ibm.com/jp/developerworks/java/050114/j_j-jtp12214.html

ab（とかの負荷テストツール）で結果出せば済む話じゃね？

Java 対 C++ のベンチマーク
http://www.javanews.jp/javap/newsletter043.html

c++の比較はともかく、下記の記事では、Javaデスクトップ・アプリの例として
次のようなソフトが挙げられているね。

http://journal.mycom.co.jp/articles/2005/11/09/javaone3/
Hans Muller氏はJFC/Swingを活用して作成されている有名なアプリケーションとして
LimeWire、Grokker、map24.com、Yahoo! Sitebuilder、pogo.com、Quantrix、Maple、
!QNext、BlogBridge、JPodderなどを紹介し、人気のあるアプリケーションの多くが
すでにJFC/Swingを使って作成されていることを強調。

あらためてクローズアップされるJavaデスクトップのメリット
http://www.computerworld.jp/news/sw/60130.html

ネタよりコードをはってちょ

JavaでもAoSよりSoAの方が高速に動くの？

>>5
y

？？
Javaのコードからネイティブな実行ファイルを作れる
コンパイラ作れば良いんじゃないの？？？？

>>57
そんなことしたら、Javaの速度的な優位性が損なわれますよ。

>>58
C#でさえngen.exeがあるんだぞ。Javaにあってもよかろう。

SE6のJavaは、相当に速くて、ネイティブにすれば
速くなるという常識は通用しなくなりつつあるからなぁ。

現に、ネイティブを利用してるEclipseよりSwingを使う
NetBeansの方が速いとたいていの人が言っているわけだし。

問題は、そういう状況になったのがついこの間ということで、
これから変わってくるんじゃない？

成果が現れてくるには、少し時間がかかるよ。

SWTはともかくJava1.3あたりの時代からずっとそんな状況だったはずだが

1.3でHotspotが登場して劇的に速くなったとは思うけど、
Swing が SWT と同等かそれ以上に速くなったといえるのは、
本当にごくごく最近のことと思う。
1.4 1.5 1.6 と少しずつ速くなってきて、ようやくネイティブでなくても
なんとかなりそうだ、と思えるようになってきたと思う。
そんなもんだよ。

>>62
SWTって、元からあんまり速くないよ。ネイティブって連呼してるけど、
Swing も AWT とか Java2D レベルではネイティブ呼び出し使いまくってるんだし。

どっちかっつーと、Swing は速度よりも見た目の改善の方が大きいような。
フォントがサブピクセルレンダリングをサポートしたりとか。
つっても、未だにベクトルフォントだと汚いって声も聞くけど。

>>63
SWTが早いのは起動が早いって意味じゃないの？
Swingが遅かったのは立ち上がる時間だけだったと思う。
立ちあがった後の体感速度はEclipseもNetBeansもそれほど違いを感じないもの。

>>64
SwingアプリよりC++とかで作ったネイティブアプリの起動が早いってんならともかく、
SWTアプリだと結局VM起動に時間取られるので起動時間も大して変わらない。

そもそも、VMの起動に時間がかかる、というのが変だ。

起動した後のVMのスナップショットを保存しておいて再利用すりゃぁいいじゃないか。

心配しなくても、VMの起動速度はどんどん早くなってるし。

その分ディスクもメモリも昔より遙かに食らってないか？
それで起動速度が速くなってもあんまりありがたくない。

>>67
そうそう、もうネイティブより速くなるのも時間の問題v(^o^)v

ネイティブより速くなってから出直しておいで

>>70
もうスピード的には問題ないよ。
君の頭は、５、６年前のままでは？（もしかしたら、それ以前？）

しかも、Intelはじめ次世代CPUにはJavaアクセラレータが
搭載されることになっている。（Intelは正式に発表ずみ）

この時点で、ネイティブとほとんど遜色ないという今のレベルから、
Javaの方が速いという時代に突入すると思うよ。

>>71
そういう未来展望なんてどうでもいい。
Javaのほうが速くなったらJavaを使えばいいだけのこと。

>>72
Javaがネイティブより速くなるのが確実なら、
いまからその時代に備えておくのが筋だろ？
時代の先を読め、とか、よく聞く格言を知らんのか？

ぐぐったら、Javaアクセラレータの次世代cpu搭載はAMDも
正式発表していた。
遅くとも、２、３年のうちにJavaアクセラレーターが普及してくる。

ありがたがっていたC++ のコードが、負の遺産呼ばわりされる時代が
すぐそこまできている。世の中に大きな動きがあるんじゃないかな。

Winで作ってLinuxで動かすというJavaアプリが増えるのかな。
それが続けば、Winも不要ということになるのかもしれん…。
そこまでは分からんが。

Javaアプリ普及の時代が来れば、ことはJavaだけの問題じゃなくなるよなぁ。

Javaアクセラレータか何かしらんが、Itaniumの二の舞になると予想。

そのJavaアクセラレータとやらが普及するまでPHPの天下ということで

>>73
シビアに速さが要求される用途では、
将来的にJavaがネイティブよりも速くなるのが確実だとしても、
「いま」速さがが要求されているので、Javaを使うわけにはいかない。

速さが要求されない用途では、
今でもJavaとネイティブの速度差は問題ではないので、
将来的にJavaがネイティブよりも速くなるかどうかなんて、どうでもいい。

将来的にネイティブよりも速くなるというのは、
Javaの魅力として語るべき話のなかでは、
かなーり順位が低いと思う。

だから、Javaがネイティブよりも速くなったところで、
「世の中に大きな動き」なんて、ないんですよ。


ちなみに、Javaアクセラレータというのは、
マイクロソフトの.NETのアクセラレータにもなるだろうから、
Javaだけが速くなるわけではない。

C++のコードの蓄積が負の遺産だと言うのであれば、
Javaのコードの蓄積もまた負の遺産だと言える。

一度書けばどこでも動くというお題目は、とっくの昔に嘘になっていて、
過去に書かれたJavaのプログラムに苦労している人が大勢いるという現実を見ようよ。

既に登場したJavaアクセラレータの現状を見れば後2、3年じゃ無理だろ。
大体物が出るのが2、3年後だろ？
どうせその頃には効率的なJavaプログラムの組み方はまた変わってる
>>72の方が正しい姿勢だと思うぞ

それとC++のコードが負の遺産とはよくJavaプログラマが言うが
Javaの遺産と言ったらランタイムとその時々で誰かが流行らせたクラスライブラリだけじゃん
自前で遺産を持たない/持てないからといって他の言語のコードを負の遺産呼ばわりするのは見苦しい

たぶん、
IntelのTolapai や、AMDのTorrenza のことを言っていると
思うが、まだどちらも詳細が分からないからなぁ。

AMDのTorrenza の方が比較的知られてるかな。
ただ、まだどちらも誰も詳細を知らないわけだから。

http://ascii24.com/news/i/topi/article/2006/06/08/print/662734.html
Torrenzaは米AGEIA Technologies社が開発した物理演算用プロセッサー
“AGEIA PhysXプロセッサー”のように、特定用途の高速処理を行なう
プロセッサー(アクセラレーター)を、CPUに直結する形で接続することで、
CPUとアクセラレーターによるパフォーマンス向上を実現しようという技術だ。
用途としては物理演算やグラフィックス処理で多用されるベクトル浮動小数点
演算のほかに、ストリーミングメディアの処理、JavaやXMLの実行などが
挙げられている。

レジスタに対する処理なら、違うレジスタに対する処理なら並列実行可能だけど
JAVAも.NETもバイトコードはスタックに対する処理なんで並列実行が難しいだろな。

やるとすればスレッドの超並列化で対応するとかだろうから、
高速化を考えるなら、今からそういう手法を取り入れるか？　やらないだろ？

JITコンパイルで十分じゃん。

ベクトルなり行列なりの概念を持ってる言語で　ベクトル積や行列積をそのまま表現してるなら
並列演算ユニットとかを扱い易いと思うんだけどね。

早いとか遅いとかチンコの話じゃねーんだよー

自分は専門家ではないので、何か書けば恥をかくだけだが・・・

プログラムの表側に見えている処理をさらに高速化するだけでなく、
見えていない処理のうちネックになっているものを改善するのも手かと。

あるプログラムのCPUクロック消費のうち、
目的の計算自体は16%しかなかったりすると、
たとえSIMDで計算自体を4倍の速度で行っても、
16%だったものが4%に減るだけで、
全体としては1.14倍の速度向上にしかならない。

80:20の法則

JavaでC++並みの実行速度と言うが、無意味な議論なんじゃないかね。
そのJavaで高速化した技術や努力と同じことを、C++でもやれば、C++並みの速度
に追いつくことはあり得ないと思うが。

>>85
それこそ、そんなこと言っても無意味。
なぜかは知らんが、Java脳なヤツらはそんな簡単なことも理解できんから。

> 見えていない処理のうちネックになっているもの

ここを具体的に書かないと >>83 は単なる日記にしかならないわけだが

抽象論に具体性を求める愉快な人が……

>>79
C#でもJVMでも、バイトコードを静的解析すれば、
どの部分とどの部分を並列実行できるかってのは容易にわかるはず。

やってないとしたら解析にかかる時間とか解析ルーチンによるVM肥大化と
パフォーマンス上昇のトレードが上手くいってないんじゃないかと。

>>88
どういうこと？
具体的に教えてよ。

いいから早くバグ取りしろ

>>85
> そのJavaで高速化した技術や努力と同じことを、C++でもやれば

それがね、
C++では出来ないことによって、C++よりも高速化する
という話があるんですよ。

>>87
素人考えよりも、Javaアクセラレータの詳細が明らかになるのを待ったほうがいいかと。
そこにはJavaの実行速度を向上させるためのノウハウが入っているだろうからさ。

>>89
バイトコードの大半は動的に生成されたりはしないので、
解析は一度だけやればいいわけで、
にもかかわらず、やっていないのであれば、
それは、解析がネックなのではなさそう。

実は、既にやっている、という答えがあったりしてね。

（a+b)*(c+d) という計算を
レジスタマシン
1 mov r0,a
2 mov r1,b
3 add r0,r1
4 mov r2,c
5 mov r3,,d
6 add r2,r3
7 mpy r0,r2

スタックマシン
1 push a
2 pusu b
3 add
4 push c
5 push d
6 add
7 mull

どちらも　123　と　456は並列に実行出来、７は両方が終わらないと実行出来ない
レジスタマシンならレジスタをロックするだけで判断する必要がない。
スタックマシンは命令の並びで判断する必要がある

>>85
ほらね、>>92 を見てごらん、こんな自明なことでもJava脳なヤツらには
なぜか理解できないんですよ。

>>94
仮定が間違ってる。

>>95
いったいなにが仮定でどう間違ってるんだ？

>>96
Javaで高速化した技術や努力と同じことを、C++でもやることができる
という仮定が偽なのですよ。

>>97
ごめん、それが仮定だと思うような猿にそれが真だとうまく説明する時間も労力も俺にはない。
猿に言葉を教えるようなモンだけど、誰かこの猿にそれを教えてあげて。

真のJava厨はパフォーマンスなんぞ二の次（かなり乱暴だが）

「真の」とか書く奴は厨。

>>99
俺はC++厨だが、それでいいと思う。別にパフォーマンスが悪くたって
JavaにはJavaのよさがあるんだから得意な分野で頑張ればいいのに。

そう。
それは既に>>76で指摘されているんだよね。

>>98
C++はJavaほどコードの意味が明瞭ではないため、
コンパイラやランタイム環境でパフォーマンスを改善できる範囲が限られてしまう。

とくに、ポインタという、コンパイラの最適化にとって厄介な代物があるために、
言語仕様を変えてでも意味を限定しようという事態になってしまっている。

やっぱり猿だ。俺には説明すんの無理。誰か助けて！

>>103
自分に出来ないことを人にやれと言うな。

>>104
自分にできないから人に頼んでんじゃないか。
お前ニートか？　社会人(なんらかの組織の一員)になったら自分でできないと思ったら
一人で抱え込まずにまわりに助力を求めることって叩き込まれるもんだし、これは鉄則だぞ。

>>105
頼むにも態度ってものがあるだろ
社会人の常識として

>>106
正直すまんかった。

>>105
仕事ではなく、各人が趣味で参加しているところで、
> うまく説明する時間も労力も俺にはない。
と書いたら、そりゃぁ、

めんどくせーから、誰か代わりにやってくれよ

ということなわけで。

>>92>>102は痛いな
批判するなら理解してからにしなよ

ようするに、「見えないものは無いのと同じ」という事だ

PC上で低レベルの記述が出来る＝アセンブラが使えるような言語は
ASM/C++/Delphiくらいだが、
どんな高級言語も結局は低レベルに翻訳されて実行されることを考えれば
ASM/C++/Delphiが最高速という事になる。

しかし、では実際にそういうコードを人間が人力で作れるのかどうかという事になる
特に大量の数値演算のコードは　数学的な知識が無ければアルゴリズムを作る事さえ出来ないし
その文献を与えられても理解出来ない。

そして、アルゴリズムが理解できたとしても
C++/Delphiが提供してるのはせいぜい四則演算とsin/cosのような関数くらい。
この組み合わせにまで自前でアルゴリズムを展開する能力も必要だ。

というわけで、誰も作れないなら無いのと同じって事さ。

>>102
C99 にあるような restrict ポインタが今の C++ にない、ってのもあるが
もっとキツいのは「言語仕様にスレッドの概念がない為に、
コンパイル単位を跨った最適化が不可能」って点だろ。

>>110
Javaと同じことをC++でもやれば・・・という話は、
あくまでも、
アプリのコードを書く人間がガンバレば・・・というのではなく、
コンパイラやランタイム環境などを作る人間がガンバレば・・・という話しだよね。

そこいらの平均的なプログラマが、
同じ内容のプログラムを、
JavaとC++の両方で書いた場合に、
どちらが速く動くのかという話。

>>112
>そこいらの平均的なプログラマが、

最高レベルのプログラマもケースとしては考えるべきじゃね？　どっちでも結果はかわらんとは思うが。

1からコードを起こすんだったら比較してもしょうがないんじゃないか？
C++側も存分に最適化をかけれるだろ？
古いライブラリをリンクしてやれとかいうならまた話は変わるんだろうが。

おっと形勢逆転？

いいからC++より早いJavaのコードをうｐしルー

>>114
だからさ、C++ではコンパイラの最適化にできることが、Javaほど多くない、という話なのだが。

>>117
だからさ、↓これに対してレスしたのにどうしてそんな話に戻るの？
>JavaとC++の両方で書いた場合に、
>どちらが速く動くのかという話。

坊やだからさ

いいから両者ともコード出せ

>>120
この場合は >>117 が出すのが筋だろ。
C++ に勝る最適化ができると主張する >>117 がその実例を挙げてくれなきゃ話にならん。

でた────！！！

>>117
その理論で行くと人力以外での最適化が困難なアセンブラは
Javaに速度で勝てない上人間には分かり難い超糞言語だなｗ

C++派の俺が答えてやるのも何だが
Javaが得意と思われるものは動的な最適化だろ。

何重にも複雑に絡み合った仮想関数のベンチマークでも取ればいいんじゃね？
静的に最適化されないように、どの派生関数が呼ばれるかはファイルなりキーボード入力なりで決めるようにしてさ。

グラフィックみたいな処理を想定して、
たった一つの入力に対して同じ構成の呼び出し手順を何万回と繰り返せば動的にインラインになっていくんじゃないか？

>>118
話を戻しているのは>>114だぞ。>>112を読み直して。

>>123
今では、
アセンブラは、
人力以外での最適化が困難
なのではなく、
人力での最適化が困難
なのです。

平均的なプログラマにアセンブラで書かせた場合、
そのプログラムの実行速度は、
C言語で書いた場合を下まわってしまう。

皮肉なことに、
アセンブラで書いたものを直接アセンブルしたバイナリよりも、
C言語のインラインアセンブラに書き直してCコンパイラにバイナリを生成させたほうが、
速いコードが出力されるんですよ。

そらそうだろな

>>125
戻ってないよ？

っていうか平均的なプログラマは
アセンブラなぞ書けんだろ

>>126
そういう意味で言ったんじゃないんだが

誰かが実証コードを貼ればいい

そうだそうだ

>>126
確かにある狭いスコープでの最適解は確実に存在するからな。
これからどんどんアセンブラより高級言語の方が速くなるだろう。
同様に十年二十年後には殆どの場合でC言語のようなネイティブよりVMの方が速くなるんだろう。
実際x86自身が内部命令に変換した後で最適化をかけるVMみたいな機構になってきてるしな。

eclipseなんかよりnetbeansに流行って欲しい

C++プグラマーはJAVAできるけど
JAVAプログラマーはC++できない

JVMが理解できるバイトコードをC#から生成できればいいじゃん

>>135
そうとは限らないよ。　
C++やDelphiならまだライブラリを自分で創ったり実際にライブラリを見る事が出来るが
中間言語方式だと、どうしてもライブラリが強力になりがち。
時間と共にライブラリが強力になり、やがてプログラミングは
ライブラリの組み合わせに技術と変質してしまう。

強大なライブラリからの検索組み合わせ技術と、創作技術は同一じゃないと思うんだが？

今のところJavaは計算に向かないのがな。
SIMDなんて自動ベクトル化にせよint4やfloat4を用意するにせよやる気になればすぐ対応出来そうなもんなんだが。

Javaはエンタープライズなアプリケーション向けだからなー

>>135
C++プログラマは、Javaの言語仕様を理解するのに要する時間が短くて済むが、
Javaプログラマは、C++の言語仕様を理解するのに要する時間が長くかかり、少なくない人数がギブアップする。
というくらいのほうがいいかと。

でも、
言語仕様を理解したからといって、
ライブラリを一切使わないようなプログラムであっても、
うまく書けるとは限らないわけで。

>>136
C#というか.NETは、ぶっちゃけ、
マイクロソフトがJavaを独自拡張することが許されなかったので、名前を変えて出したもの
なわけで、マイクロソフトがそれをやるとは、思えないのだが・・・
そういやJ#ってどうなったんだっけ。

>>137
C++で、車輪の再発明やりまくっているプログラマなんて、もうそんなにいないっしょ。

C++は糞言語だからなｗ

言語仕様ならC++の方が覚えやすいだろうなー
１＋１＝２みたいに機械的に覚えられるからなー

>>140
言語仕様のページ数自体も違うしね……

まぁそもそもJavaとC++を同じ物差しで比べるのが間違いだろうな
C++は言語仕様だがJavaはプラットフォームだからなぁ
Javaの言語仕様はその中の一部だからなー

>>143
洗練されていない分、余計な説明が多くなってるんだよｗ

C++の言語仕様ってどこで読める？

>>145
俺はつまみ食いで読んでくから、どっちかっつーと洗練よりも冗長の方がいいんだけど。

>>141
C++厨としてそれに関しては一切否定しないし、むしろ肯定する。
が、C++よりJavaのほうが遥かに糞言語だと思うぞ。

その心は？

>>146
ANSI C規格(ANSI X3.159-1991)とか言うのがそうなんじゃないの？
どこでみれるかしらんけど

>>150
それ C言語の規格じゃないか？

ANSI のサイトで検索かけたけど、
INCITS/ISO/IEC 14882-2003 と ISO/IEC 14882:2003 って何がちがうん？
値段が随分違うんだけど。

だいたいC/C++て、標準仕様ないでしょ
Javaみたいに

オレがその昔C++中だった頃、C++の仕様は？といえばこの本を見た
仕様とは違うと思うけど

ttp://www.amazon.co.jp/o/ASIN/475611895X/250-9402494-2345013?SubscriptionId=1CVA98NEF1G753PFESR2

>>151
それのC++版があるんじゃないかと・・・・

>>152
第3版なら持ってる。けど、仕様書じゃないね。

あと、それで仕様を確認する奴は殺しといた方が良いぞ。

>>154
じゃあC++の仕様といえば何をみるのさ

ISOかどっかに標準化した規格があるはず。

C/C++は、同じ名前が付いてても互換性がないから、
それに嫌気を指した香具師等がJavaという標準仕様を作ったんじゃなかったか？

×同じ名前が付いてても
○同じC/C++というのが付いている処理系でも

ひきつづき、>>151 の後半の疑問に答えてくれる人を募集中

オレはギブ

C++厨がんばれ

とりあえず、JIS X 3014 だと閲覧だけはタダで出来るみたいだから、そっち見るわ。

いちおー、>>151 の後半の疑問に答えてくれる人も継続して募集中。

>>162
残念ながら自分で解明するしかないようだ
つーかそんなの知ったところで意味ないだろｗ

>>163
pdf買うときに値段が 10倍ぐらい違うんだけど。

>>146
http://www.jisc.go.jp/app/pager?%23jps.JPSH0090D:JPSO0020:/JPS/JPSO0090.jsp=&RKKNP_vJISJISNO=X3014
このJIS X 3014:2003は、ISO/IEC 14882:2003の翻訳。

>>164
かってどおするよ
処理系の仕様を見ればいいんじゃねーの？

>>166
処理系の仕様ってどこにあんの？

処理系ってなんだか知ってる？

>>167
あったとしても、コンパイラオプションとか
処理系依存のマクロ(__HOGE__)とかについてしか書いてないんじゃね？

>>167
知りたい事は自分で調べろ

ここのC++厨って、実はC++の仕様ちゃんと知らないんじゃね？
と、思わなくも無い。

まぁ、場末のスレだしレベル低いのしか集まらんよね。俺も含めて。

大体レスしてる大半はオレJava厨だし

C++できる人、消えちゃった？

終わったな・・・・・

>>167
166が想像していたものかどうかは知らないが、例としてVisual C++のやつ。
http://msdn2.microsoft.com/en-us/library/dtefa218(VS.80).aspx

無論、規格が処理系定義と定めている事柄について、Visual C++の場合はどうなのかということも書いてある。
例）符号有り整数型の式に右シフト演算を行った場合の挙動
http://msdn2.microsoft.com/en-us/library/336xbhcz(VS.80).aspx

また、独自仕様の解説も当然付いている。
例）__if_exists キーワード
http://msdn2.microsoft.com/en-us/library/zxk0tw93(VS.80).aspx

ただし、全ての独自仕様がそうだと明記されていないのが玉に瑕。
例）整数リテラルに対する接尾辞の1つ「i64」
http://msdn2.microsoft.com/en-us/library/00a1awxf(VS.80).aspx

親切な方だな

C++コンパイラを作ろうというのでなければ、
C++の標準仕様を知ろうとするのは無駄だよ。

標準仕様に合わせて書いたところで、
皆が使っているC++コンパイラが、
標準仕様に100%対応していないんだから。

高い移植性を要求される場合には例外を使うな
なんていう話もあるしさ。

標準仕様よりも、
使おうとしているC++コンパイラの癖を知ったほうがいい。

>>142
んなわけない。
ルールが大杉。

>>145
すでに土台が継ぎ接ぎだらけだから、ゼロから作り直さないとダメでしょう。
ダメなものは、いくら磨いても手直ししても、ダメだよ。

C++が糞なお陰でJavaができたわけだから
ある意味C++ありがとう

いや、Javaは単にお遊びでできたんだろ、最初は。
だから、初期仕様のメモリ管理はグダグダ。

javaって本当に速くなってるのか？
実行環境が速くなってる分を引いたら、どのくらい速くなってるんよ？

言語仕様が複雑で洗練されていないのは悪いわけではない。
C++は必要に応じて何でもできる、その何でもありがいいんじゃないか。

別に何でもやるつもりはないし

っていうかC++の言語使用なんてどーでもいーんじゃー
早くC++より早いJavaのコードをうｐしろー

>>181
必要に応じて何でもできる
裏を返せば
必要に応じて何でもしなきゃいけない

Windowsローカルの話で恐縮だが、
マイクロソフトのActiveXとかの土台になっているCOMに対応したプログラムを、
C++で書くと面倒くさいのよ。

Javaと同じことをするのに、大量のコードに注意を払う必要が出てくるのよ。

＞Javaと同じことをするのに、大量のコードに注意を払う必要が出てくるのよ
当たり前だハゲ
っていうかCOMとJava比べてどーすんだよ

>>177
> C++の標準仕様を知ろうとするのは無駄だよ。
標準規格を読んだ事がある人の発言だったら説得力もあるかもしらんけど……

ちなみに、
> 使おうとしているC++コンパイラの癖を知ったほうがいい。
の癖ってのも、どの程度知ってるん？

↓こっちでやれや

JavaやるとC++がセピア色に見える
http://pc11.2ch.net/test/read.cgi/tech/1172317252/

突然ですが、アセンブリ、C言語使いの、35歳定年説って
本当ですか。これ聴いて、Cを読む気になりません。

すれ違い

>>187
いってらっしゃーい。もう帰って来なくて良いよ。

むこうはC++厨が優勢だからJava厨はこっから出れまいｗ

>>191
両方とも厨しかいないから、ぶっちゃけどっちでも良いっす。

隔離スレとして機能してくれれば。

もう少しまともな人はC++0xスレとか見てるんだろうし。

>>188 は　すれ違い でした。
スルーでお願いします。

…ｺﾞｸﾘ
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　　 >>192　両方とも厨しかいないから・・・
　彡､　　　|∪|　　 |　　　 >>193　もう少しまともな人はC++0xスレとか見
/　　　　 ∩ノ ⊃　 ヽ　　　　　　Ｊ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／
　　

>>185
C++でJavaに近いことをやろうとすると、COMのような仕組みが必要でしょ。

Windows向けにC++でプログラムを書く場合、
人様に使ってもらうDLLでは、C++のクラスをExportしてはいけない
という作法があるわけでさ。

>>186
↓の程度は知ってるよ
ttp://www.mozilla.org/hacking/portable-cpp.html

Java使えよ
ActiveX使えよ

仕様だけみててもやはり実装を見ないとなんともいえんのは
Javaの世界も同じだがな

　

スレが立って数ヶ月経つのに未だ自説だけしか書いてない時点でここのJava厨の程度が分かるわな

…ｺﾞｸﾘ
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　　 >>200　・・・ここのJava厨の程度が分かるわな
　彡､　　　|∪|　　 |　　　 　　　　|
/　　　　 ∩ノ ⊃　 ヽ　　　　　　Ｊ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／
　　

いい具合に隔離ス(ry

>>201
じゃあ何かコードはってよくまさん

…ｺﾞｸﾘ
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　　 >>203　じゃあ何かコードはってよくまさん
　彡､　　　|∪|　　 |　　　 　　　　|
/　　　　 ∩ノ ⊃　 ヽ　　　　　　Ｊ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／
　　

工エｴェｪ(;´Д｀ )ｪェｴエ工

ぼくはくま
くま
くま
くま

クマ膜

・起動時間
・消費メモリ
をどうにかしてくれ

起動時間：起動させっぱなしにしとけ
消費メモリ：メモリ増やせ

つ　高速CPU
つ　高速HDD　or　大容量フラッシュメモリ
つ　増設メモリ

ソフトはタダで与える代わりにハードで金を巻き上げる・・・サンの思惑通りだな。







ただ、実際に買われるハードがサンのモノじゃないところが、m9(^Д^) ﾌﾟｷﾞｬｰ！！ ってとこだけどｗ

今のサンはJavaはワシが育てたくらいの栄光しかないよね

.Netにすりゃほぼ確実に金が入るMSに比べて勝ったか負けたか・・・・

JavaFxがこけたら本格的に無償のJava保守要員だよね。

サンは試合に勝って、勝負で負けたってとこか？

ある意味MSには勝った
IBMには…惨敗だろうな

自分はC++屋だけど、Javaって速いな! と思うことはあるよ。

まず、コーディングが速い。
C++よりも自由度が低いということは、考える余地がないということで、どんどん書ける。

次に、実行速度が速い。
まず、Javaの内蔵の文字列クラスが良くできていて速かった。
C++で参照カウンタを使って寿命を管理するオブジェクトを大量に構築・破棄するようなものも結構速かった。
そして何よりも、コーディングが速いので、その分、アルゴリズムを工夫するのに時間が使えて、より速くできた。

だんだん宗教体験談みたいになってきた・・・。

自分はC++屋だけど、Javaを使うと健康になるよ。

彼女も出来たし。C++屋だけど。

そりゃそうだろ

C++は健康的じゃないからな
いろんな意味で

Javaを始めたら残業代が増えてお金持ちになりました

JAVA VM も JAVAで書かれてるんだろ？

VMそのもはJAVAでは書けないだろな。　JITとか、コンパイラなら書けるかもしれないが

>>224
ネイティブのVMはJavaで書けないがJavaで書いたVMは可能だろ？

親亀に小亀が……

JDKにネイティブコードを生成できるコンパイラが付属するようになればC++並に高速化できる。

>>225
確かに、x86で動くx86エミュレータみたいなもんか。　単に殆どの命令はそのまま実行させるという

>>225

確かに可能だろうが、それってメリットあるのか？
デバッグ専用に作れば使いようはあるかもしれないが

>>225
事実上は不可能じゃないか。
ＶＭの上にＶＭを乗せて、メモリ管理やＧＣはどーするのよ？

>>227
すこし上のほうで、
静的な最適化よりも動的な最適化のほうが速くなる
という話があったろうに。

ていうか、
そんなにC++が速いと思うのなら、
JavaからC++へのコード・トランスレータを使えよ。

>>230
作れるか作れないか、だけで言えば
Java+極一部アセンブラでOS作ってる人がいるんだから、
Java+極一部アセンブラとかでVM作れそうな感じもするけど。

>>227
そんなあなたにGCJ

ここって微妙に話噛み合ってないよな
隔離スレだから仕方ないが

>>231
x86上で比較すると、まだインテルのコンパイラで最適化した方が速いと聞く。

ばーかJVMが実行時に吐き出すのはアセンブラだろ

アセンブラならさらにアセンブルとリンク・ロードパスが必要になる。
機械語モジュールだろ

携帯のJavaは遅いぞ

>>239
当たり前だろうに。

>>234
GCC自体が遅いからイヤ

VSで普通のJavaが組めない限り眼中に無いな

C/C++やマシン語の最適化手法が限界なら
VMの変換するマシン語の最適化も人知では限界ということ
ｼﾞｬﾜ厨の理論はそもそもから破綻しとるがな

>>236
Intelの場合命令の並び替えは自分のCPUに特化出来るんだしJavaはMMXとか使えないんだから当然。
そうじゃなくて、もっと計算からかけ離れた業務アプリには向いてるんじゃないの？

ポリモフィズムを駆使したら、スコープ内で継承先が見えるような小さなルーチン以外はどうあがいたって静的には最適化出来ないの。JITでなければ不可能。
Expression Templateを動的にしてみれば分りやすい。

だからなんだってゆ ── んだよ ───────────！！！！

>Intelの場合命令の並び替えは自分のCPUに特化出来るんだしJavaはMMXとか使えないんだから当然。
こんな程度で最適化を語られてもねー。
バイトコードがそのまま動いてるとでも思ってるの？

いいからC++よりはやいJavaのコードをうｐしろおおおおおおおおおお！！！！

俺はJITがどこまでやってくれるか知らないが、246はJITが自動ベクトル化や自動スレッド化までしてくれると思ってるの?

248はJITが何で出来てると思ってるの？

電気じゃね？

>249
機械語で出来てると思ってる。
C++で書かれていると思ってる。
それが何か関係してくるの？

Perlでバイトコードを解釈してJITしてもいいんじゃないの？
まあ解釈が遅過ぎて足引っ張ると思うが。

プログラムを組んでいる時間まで含めたらJAVAのほうが速いんじゃね？ｗ

メンテナンス時間も含めたらなおさら

Java屋は JAVAって書かないよね。

でもメンテナンスしないよね

プログラマーはみんなそうよ

メンテするのは下請けだもんな。

Javaさんのおかげで背が３センチ伸びました。
本当にありがとうございました。

わはは　ジャバとサン　をかけて Javaさん　か、これは面白い。　あんた天才だよ！

>>251
＞Perlでバイトコードを解釈してJIT
機械語生成ができたとして、Perlだとそこへジャンプする
方法ってあるの？

>>260
知らない。考え方を分ってもらう為に例を挙げただけだし。
どうしてもやりたきゃ、メモリに実効権限与えてジャンプするモジュール作れば出来そう。

>>243
だからさ、重要な要素を見落としている、っつーの。
ミクロな小手先の最適化の問題じゃないんだよ。

TLBから溢れまくっている場合に、
GCしてTLBに納まるようにする処理を、
C++コンパイラとそのランタイムライブラリが、
やってくれますか、と。

Javaでやっていることを全てC++でやればいいんだからC++のほうが速くできる
なんていうアホは、
C++でやっていることを全てJavaでやればいいんだからJavaのほうが速くできる
ということも暗に言ってしまっていることに気がついてない。

ただのプログラミング言語でしかなく、標準ライブラリが最低限しかないC++と、
様々なものを統合してブクブクに太ったJavaを、単純に比較することが間違ってる。

比較するなら、
新卒入社したばかりの新人が書いたコード
などといった条件を付けてやらないとね。

> 新卒入社したばかりの新人が書いたコード
なにその抽象的で曖昧な条件

儲かる言語、ライブラリが正義。

>>C++でやっていることを全てJavaでやればいいんだからJavaのほうが速くできる

VMなので不可能

>C++でやっていることを全てJavaでやればいいんだからJavaのほうが速くできる

C++派の自演だろ。こんなアホなこと言うのは。

C++ 派がなんでそんな自演をする必要があるんだ？

馬鹿ですか？

煽りあいしても面白く無いよ。
低レベルな妄想でもいいから技術に沿った話しようぜ。
実証コードがあると一気にレベルが上がるんだけどな。

そんなに実証コード欲しいなら自分で書けばいいじゃない。
と、思わなくもない。

自分で書くのは面倒臭い。理由はこれ。
http://www-06.ibm.com/jp/developerworks/java/050114/j_j-jtp12214.html
リアルタイムな用途ではウォームアップの時間もベンチに入れないと横やり入れられそうだし
公平なベンチマークは難しい。

>>264
現実的な条件だろ?

>>266
> Javaでやっていることを全てC++でやればいいんだからC++のほうが速くできる
というのは、コンパイラに手を入れることを暗に前提にしているのだから、
> C++でやっていることを全てJavaでやればいいんだからJavaのほうが速くできる
というのも、VMに手を入れることを暗に前提にしているのだろう。

ていうか、
Javaのほうが速いなら、同じことをC++でもやれば、C++も同じだけ速くなる
という話はさ、

C++の仕様をJavaと全く同じに変更してしまえば同じになる

ということで、無意味だと思うんだ。

何でわざわざ無駄なVMの真似するのさw

だからみんなJavaやめろよ
俺が一手に引き受けてやるからさ〜

>>275
いや俺が！

VMはネィティブコードで動いている
この一言であらゆるジャワ厨は論破可能

>>276
じゃあ半分ずつにするか〜

>>271
おーい。
> 現実的な条件だろ?
だそうで。

>>272 のところの新人さんがコード提供してくれるらしいぞ。

ていうかさ、どんなJavaのフレームワークを使っても
C#で書いた方が早いのは、C#がすごいのでしょうか？
私のC#のコーディング能力が神なのでしょうか？

どっちもウンコ

>>272
C# のコードも追加でよろ。

>>280
Winとの相性がよいからｗ

>>280
「早い」のは、IDEのおかげと、該当する方面のフレームワークが充実してるからだと思う。

スレタイ的には、速くないとダメなんだがな

スレタイ的には、Javaで速いコード書かないと。
C++はあくまで比較対照としか読めないし。

スレタイ的には人工知能に類する課題かなと。

>>277
100% pure Java 狂信者なんて、少数派だろう。
VMが何で作られていようと、どーでもいいんですよ。

>>279
仕事なんだから、タダでは提供できないぞ。

ちゃんと開発案件として営業を通してくれよ。

J#最強

>>289
結局現実的な条件じゃなかったわけね。

>>291
現実的だろ?

コードが欲しければ金を出せ、というのは。

金を払う価値があるかどうかは
見てみないとわかランナー

>>292
どこが現実的？ 匿名掲示板で誰が金払うん？

つーか仮想現実なインターネッツで（ｒｙ

>292が自腹切ってくれるんじゃね

釣られてるなぁ。

新人が書いた場合に、どの程度の出来になるのか
というのは、
数値化が難しいものの、評価基準としては実戦的だわな。

新人の力量自体に左右されるから基準になんぞならんわな。

年齢3X歳、プログラム歴20年↑の新人ですがなにｋ

Java で 2ch に書き込むプログラムを創るのが夢です

>>300
2chに書き込むのは難しくないぞ？

そこにActionScriptの実行速度で悩むオレがきましたよ

だれか何とかしてくれ！マジで！

>>224

jikes

http://jikes.sourceforge.net/

はJavaベースのVMだよ。　主に研究目的で使われていて折れの知り合いもこれをハックして論文書いていた。
SunのHot SpotとかだとC++でなかなか手が出せないらしい。

URL張り間違えた、

http://jikesrvm.org/

です。　VMの勉強するには良い題材だと思うよ。　いきなりHotSpotだとまず挫折だw

バイトコードに落とすVMは書けても
ネイティブに落とすVMはjniとか使わないと無理じゃね?

バイトコードに落とせばHotSpotがネイティブに落としてくれるだろうが
インタプリタやらコンパイラが二重になってウォームアップ中の効率が激しく悪そう。

だからー今の時代VM自体がネイティブより速いんだって。

Winですべてのプログラムが
JAVAやら.NETだとゾッとする。

まったくだ。ぞっとするどころか、小便漏らす。

>>306
じゃぁ、そのVMの上でVM走らせようぜ！
さらに速くなるぞｗ

今時のCPUはx86命令を独自命令に変換して処理しているわけで
入力をJavaのバイトコードに置き換えても問題ない。

>>310
x86は性能向上を犠牲にしてまでコードを一致させてきたんだぞ
いまさらJavaマシンはないと思われ

出るとしたらx86と無関係な話。

JAVAのバイトコードなんて可変長命令とかあるから、ハード実装は
x86以下のプロセッサーになるよ。というか、命令セットはかなり最悪な
部類に入るかな。
デコードフェーズが無茶苦茶面倒になるし、パイプ組みにくいし。
すくなくとも最近のx86系の下に居るμOpsのかわりなんてならない。
逆に非効率になるって。バイトコードをx86プロセッサみたいにRISC命令
に分解するやりかたなら意味が分かるけど。

ソフトでjava→x86→ハードでx86→内部実行コード
よりは速いだーろ

>>307-308
Vistaは大真面目にそれ(.NET)をやろうとして頓挫したわけだが。

>>313
ソフトでやる場合は大域的に分解出来る。
ハードでは、やはり難しいと思うよ
JAVAのバイトコードはスタックマシン　>>93のように
ハードで実行してしまうと、並列出来るかどうかの判断が難しいのさ

>>313
ほんとに?

現実に作られたJavaチップの性能を、当時のx86なCPUと比較してみようよ。

>>307-308,314
いずれはそうなるだろう
もうＣ＋＋厨の領域はデバイスドライバやＯＳの分野しかなくなるだろうな

>>316
だからJavaチップとx86は無関係だから比較すんなって

>>317
例え、C++の適合領域がそうなったとしても、
C++厨自身はこの業界全般どの分野でも通用するだろ、常識的に考えて。
C++厨の適応能力の高さをJava厨の次元で考えたら大間違いだよ。

> C++厨自身はこの業界全般どの分野でも通用するだろ、常識的に考えて。
無理だと思う。このスレで管を巻いてるC++厨に関して言えば。

>>320
それはいくらなんでもC++厨を舐め過ぎ。

やれるとしても、C++だったらこうできるのに……、と文句たらたらなのは見え見え。

>>322
それは否定しないｗ

能書き多い割りにプログラム作れないからウザイ希ガス

ゴリゴリ書きまくりそうな希ガス

>>324-325
能書き多い割には
ゴリゴリと無駄なコードばっかり書きまくって
マトモなプログラムかけないから
ウザイ希ガス

Java厨ってどうして偉そうなの？

ここのC++厨って自分で煽る癖に耐性ないの？

>>327
馬鹿だから。

>>329
だよなあ
Javaみたいな糞言語触って一丁前に自分はPGだと思いこんでる
痛い香具師ばっかりだしな

>>325
そりゃそうだ
今使っている言語にはHOGEという機能がないからそう書くしかないだろ、てな調子

C++厨は自分たちは頭が良くて仕事が出来るが
Java厨は馬鹿で仕事もできないと思ってるから

>>330
JavaコンパイラもJavaVMも一般的にC++で作られる
現実から目を背けて、C++批判を展開したりするところが特に馬鹿だと思う。

まだ、そのへんのことをちゃんと受け止めてC++に敬意を持ってるような
Java厨ならたとえC++批判をしようが俺はそいつを決して馬鹿にはしない。

> JavaコンパイラもJavaVMも一般的にC++で作られる
釣れる？

＞現実から目を背けて、C++批判を展開したりするところ
誰がそんな事を・・・・

C++厨って単細胞が多いんか？

>>334
言ってるそばから、これだし。Java厨はやっぱり馬鹿だとつくづく思う。

>>336
どうやらそのようだ

>>334
沢山、釣れたみたいだよ。('A`)

【釣れた】
相手にうまく言いくるめられて議論に負けた時の決まり文句。
こう言えば相手より上の位置から発言しているように一見見えるが、
実はさらに自分のバカを晒しているに過ぎない。

>>319
> C++厨自身はこの業界全般どの分野でも通用するだろ、常識的に考えて。

そうとも言い切れない。

JavaはC++の1/3のコード量で済む
JavaはC++の3倍の速度でコーディングできる

ということは、

C++はコーディング時間の2/3を無駄に費やしている

ということであり、

C++を5年やった人よりも、
Javaを5年やった人のほうが、
より多くの経験を積んでいる

ということになる。


実際、新人に試行錯誤を通してコツを掴ませる課題をやらせると、
C++でやらせるよりも、Javaでやらせたほうが、圧倒的に成長が速い。

いい事言うな

>>341
そうは問屋が卸さない。
Javaのコーディング量が少なくて済むのは豊富なライブラリが揃っている
からであり、一から作らなければならないC++はそのライブラリのコーディング
の必要もある。

だから、即座に

>C++を5年やった人よりも、
>Javaを5年やった人のほうが、
>より多くの経験を積んでいる

は否定される。

ちがうな
根本的に

>>343
たとえライブラリを使わずにフルスクラッチで書いても、JavaはC++の1/3だと思う。

そもそもライブラリの豊富さはJavaとC++で大差ないと思う。

思うのは自由だよな、と思う。

>>345
>たとえライブラリを使わずにフルスクラッチで書いても、JavaはC++の1/3だと思う。

Javaって同じロジックのコードの量をC++の1/3にできるような機能なんかあった？

むしろC++は簡単な表現が出来る場面でJavaは厄介な予約語を
たくさん使わないといけないんじゃなかったっけ？

>>345 が事実ならC++厨の俺もいますぐJavaの勉強を始めるとこなんだが。

>>348
C++の「簡単な表現」は、メンテナンス性を書くからなー

>>345
この大嘘つきめ。
俺は仕事でC++とJavaの両方をやらなければならないので
お前の嘘はよくわかる。

>>348
そのハズなんだが、>>345の話ではJavaのほうがC++に比べ1/3程度のコード量で済むらしい。

コード量が1/3になると中身も1/3になるってオチだろう。

>>350
具体的にどうぞ。
どう「メンテナンス性」を欠くのか。

それと、欠くの漢字が違ってるよ。

＞欠くの漢字が違ってるよ
本気で厨か？

　　　　　　　　 ,..-─‐-..､
　　　 　 　 　 /.: : : : : : : .ヽ　もう神頼みか
　　　　　　　 R: : : :. : ｐq: :i}
　　　　 　 　 |:.i} : : : :_{: :.ﾚ′　　　　　コ　　ツ 　 　 　 　 , -─弋¬、
　　　　 　 　ﾉr┴-＜｣: :j|　　　　ポ　　　　　　　　ン !!　/　　 　　 ｀Ｙ
　　　　　　/:r仁ニ= ﾉ:.ﾉ|! 　 　 　 　 　 _　　　　　 　 　 | {、 　 　 　 |　
　　 　 　 /:/　＝　/: :/ }!　　　　　　　 |〕）　　　　　　　从＼ |） 　　｜
　　　　　{;ﾊ＿＿,ｲ: :f　 |　　　　　 　／´　　 (〔|　　　　　 ヽ__j儿从八_　神頼みか
　　　　 /　　　　　}rﾍ　├--r─y／　☆、　　｀＼　　　　　 i⌒ヽ￣￣＼
　　　／　　　　　r'‐-|　├-┴〆　　　　_, ､_⌒☆ ＼　　　　|　 | ｀==＝ﾍ
　 　 仁二ﾆ_‐-イ　　|　｜　　　　 　 ∩ﾟω ﾟ） 　 　 ﾞと[l￣|　 |　　　　　＼
　 　 | l　i　　厂 ￣ニﾆ¬　　　　 　 ﾉ 　 ⊂ﾉ　　 　 　 　 ￣|　 | 　 　 　 　 ヽ
　　 ,ゝ､ ＼　＼ 　 ＿＿厂`ヽ　 　 （__￣） ）　 　 　 　 　 　 |　 |＼　　　　　 }
　 _/　/＼_i⌒ﾄ､_　　　ノrr-　}　　　　 し'し′　　　　 　 　 /{_〆￣｀ｰｰ=='＾┤
　└-'￣ ｀|　 |＿二二._」｣__ノ　　　　　　　　 　 　 　 　 　 {｜　-‐　　／　| | }
　　　　　 └ｰ′　　　　　　　　　　　　　　　 　 　 　 　 　 └─-二＿／⌒Y￣｝

>>350=>>355=>>356 が必死ですｗ

>>355
いやあ、普段からそんなに漢字を間違ってるんじゃ、
さぞかしお仕事の方も間違いだらけだろうねって思っちゃった。

2ｃｈのふいんき（どうしても変換できない）になじめないようですね

>>359
必死にならなくてもいいんだよ、坊や。

>>359
２ちゃんでそういうことをわざとやる文化の始まりは
素で間違えたヤツをバカにして真似してるんだってことをわかってるか？
お前は最初に素で間違えたヤツに相当してるんだぞ。

お決まりのレス乙

どっちが必死だｗ

>>361
どこがどういう風に素で間違えてるか説明できる？
説明してからその言葉を言いましょう。
さあ説明して下さい↓

うんこ

もう寝よ
早くバグ取らないと終電なくなっちゃうよ

逃げるしかできない厨乙

うまいこと >>345 が話題を逸らすのに成功しました。オメデトウ！

全然話題逸らしに成功してないんだがな
話をどんどん意図的にずらしていっただけ
痛い点を突かれると逃げるだけ

煽り合うのが目的の人は退場してね。

>>347
ロジック自体のコード量は変らないが、付随して必要なコード量が違う。

> 煽り合うのが目的の人は退場してね。
……。 >>345 自身が退場した方がよくね？

>>370
それって結局ライブラリ関係のことじゃないの？

>>371
>>345 は釣りが目的の人だから、退場しなくておｋ

>>372
違う。

>>370
どう違うのか具体的に書ける？
書けないのならお前の妄想だとしとくが。

たとえば、

コード量の差がが出にくい、
シングルスレッドで他所様と動的にリンクしたりしない完結したプログラムの、
7-Zipの中の人(LZMA-SDK)では、C++による実装はJavaによる実装の2倍くらい。

>>376
よくわかんなぁ。それって単に最初C++で組んでJava版作るときは
C++版作った時の経験を活かして簡潔に済ませたとか、もしくは逆に
C++版作る時に手動での最適化を意識し過ぎて変にゴテゴテコード
書いたかのどっちかだろ。

普通なら言語の機能的にはC++よりJavaのほうが短くかける・・・しかも
1/3もってのはありえん話なんだけど。

まだ、マルチスレッドまわりとか限定ならJavaは言語仕様でマルチスレッド
が考慮されてるから多少簡潔に記述することが可能になるってんなら
少しは判るけど、シングルスレッド？　ホント、意味がわからん。

やっぱり 釣りがしたいだけ？

っていうかネタスレじゃないの

*.h と *.cpp でクラスメソッド宣言を二重に書いたりすると C++ のが膨れるよねぇ……
後は複数のコンパイラ対応のために #ifdef 強制されると膨れる可能性があるぐらいか？

っても、このスレって C++ と Java を比べるスレじゃないと思うんだけど。

C++が長くなるのは、移植を考える為に#ifdef スイッチ一杯使うからだろな
特に圧縮伸張なんかではエンディアンやnt型のサイズの差の吸収が必要だからね。
あと、圧縮伸張ではキャリーフラグを使いたいからインラインアセンブラも良く使われる
だから、コードが長く見えても、そんなに実質が長いわけじゃないだろ

業務アプリの実装には不要なコードが多いってことだろ？

>>380
移植のための #ifdef はあんまし使ってないような……

ちょっとコード書いたり調べたりして判ったこと。

○C/C++風なHelloWorldのコードだと動的にコンパイルされずインタプリタで実行される。
○Java実行中に頻繁にメソッドのプロファイリングとコンパイルしている。
この為、GUIの初期の応答が遅延。
○Javaのクラスライブラリの一部はネイティブコードで書かれている。(Math,zip,etc)
○Java/.NETのJITはSSE2や3DNow等が理解できる。
○メソッド単位でプロファイル&最適化を行うので、C/C++とコードの書き方が違う。

Java厨ってやっぱり頭悪いな。論理的に相手を説き伏せる事が
全然出来ないでやんの。

所詮Javaは土方PGだからな。主婦のアルバイトも多いし。

そんなにJavaとC++の違いがないなら、なぜJavaが必要なんだい?
JavaをC#で読み替えてみると、もっとわかりやすいかな。

C++厨はその現実から逃げるために必死になってるんだから
核心を突いた事を言ってはいけない

C++厨 = 車輪の再発明というオナニーにかまけて前身しない人達

ってことでFA?

JAVA厨 == 車輪の設計も出来ない人達

です。

どうしてVMの癖に偉そうなの？

「偉そう」に見えるんだ

>>386
全世界に出ているCPUの性能を１／２に落とすためです

>>390
少なくともJava厨にそれを聞くの無駄だよ。
Java厨は馬鹿だから自分たちが偉そうにしてることを自覚することすらできないんだから。

C++厨はなんでそんなにひがみ根性まるだしなの？
自分達が愛するC++が否定され続けてきた歴史が
貴方達の性格を曲げてしまったのですね・・・・

よかったね、>>394 の性格は曲がってなくて。

C++？ああーあのまともにやってんのM$しか居ない糞言語ね。

つまり9割のPCでC++が主流と

>>396
C++厨と違ってひがみ根性もなければ、性格も曲がってないすばらしいカキコですね。

Win32は単なるCじゃんw

っ COM

COMもCで組めるし

Windows以外のOSが特定の言語推奨したりしてないだけだろ。

>>389
当たり前だ。

Javaで文字列クラスを自作する輩は少ないが、
C++で文字列クラスを自作しちゃう輩はたくさんいる。

そんな無駄なことに時間を使うよりも、
もっと他の事に時間を使ったほうがいいだろ。

>>401
それは随分とマゾだな。

そんな極端なことを言うのは建設的ではないよ。
Cで頑張れば・・・ということを言い出したら、アセンブラで頑張れば・・・となってしまう。

>>402
Cの標準ライブラリがOSの一部分になってるLinuxに比べれば、
Windowsは言語に対してニュートラルだろ。

>399
Win32 はパスカル。Cではない。

パスカルで書かれてる訳じゃない。　API引数のスタックの廃棄についての約束がパスカルスタイルだというだけで

正確に言えばそれは過去の話
Win32からはstdcallなるものになっている

>>386
逆に「なぜC++が必要なんだい？」と聞かれてもおかしくないぞ

つデバイスドライバー
つOS
つVM

>>407
お前さん、話の流れが読めていないぞ。

JavaとC++の違い = すでにC++があったのにJavaが必要な理由

>>409
生産性のアップ、これしかないだろ
後はどこを取っても糞なJavaだもんな

>生産性のアップ

それは思いっきり後付な理由だと思うんだが。

C++よりも後発なんだから、C++よりも生産性が高くないと。

その名前が「Java」ではなく、「Managed (C++)++」だったら、と考えてみれば自明だろう。

Javaが(C++)++だって？冗談言っちゃいけない。

(C++)--。

おいおい。

Java = (C++)-- ;
だったら、
Java = C ;
になってしまうじゃないか。

C++++ → C# だよ

何十億規模の開発でJavaが採用されている事実はなにか？
って所を考えるといいだろう
C++メインでそういう案件ある？

>>415
そうですね。さすが本体の性能を１／２しか引き出せないJavaですね。

>>415
C++メインにするとデスマが加速してしまうからだろ

windowsの開発なら何十億程度で済まないな

>>416
その1/2という数字に根拠あるのかな。

低スキルの大人数で案件ごとに作るようなものは、
もしC++で作ると、
その実行速度はJavaで作った場合を下まわると思う。

重要なものは全部COBOLだよ

ひと昔前は、　大人数で作るようなアプリは
低スキルの人海戦術部分はVBで　技術が必要な部分はDLLやActiveXが作れる C++やDelphi。
そういう分担で全体は巧くまとまっていた。

Web回りならデザイナーがフラッシュまでと分担は巧くいっていた。

今や混沌の時代。　

そういう意味では、Ｊａｖａは低スキルの人海戦術から
スキルが必要な低水準レベルの開発までこなせる
オールラウンダーなところがいいね。
１つのシステムでいろんな言語を使うと、メンテが大変。

Javaで低水準レベルが書けないからいいんだろうに
低水準はメーカーにおまかせして、「低スキルだけで開発出来ますよ」　ってのが最近の言語の流れだろう。

ただ、この流れは諸刃の剣。　使い捨てされるのが見えてちゃホントにまともな人材集まらないさ

>>423
＞Javaで低水準レベルが書けない
「低水準」の意味がかみ合ってないようだね
C++とか使わなきゃいけないような、OSのAPIやもっと低水準の部分を
じかに触ってゴリゴリ書かないといけないようなところは除いてって事だが、
大体ミドルウェアとか使ったりするけど、Javaでじかに書くことも出来るって事。
で、そもそも言語スキルが必要になる部分て言うのは、ぶっちゃけどんな奴が
きてもそんなに困らないように出来るから、言語スキルが必要になってくるって事
自体が問題なのだよ。

それを除くのかよ・・・・　結局自分達の中にも階級があるんだってことだな。

Javaで表現出来ない高水準もあれば、Javaでは書けない低水準もあるけど
それは除いて、俺達最高ってわけかい？

っていうか、C++の活躍する部分てそれくらいしかないって話

逆にJAVAが活躍できるのも中途半端なアプリレイヤーだけだし。

なんで、道具を貶しあってるの？C++とJAVAの比較なんて、
土方がシャベルとツルハシ比べるよなモンだよ。

C++って言う道具の方が優秀だといってきたのはC++厨ジャマイカ
だが優秀かもしれないが使う領域が狭いC++の事を語るよりは
使える領域が広いJavaのパフォーマンスを向上させる話のほうが
よほど意義がある
という事じゃろ？

別にJAVAの領域は広くないし。

高速化の話は結局アルゴリズムの話になるから、別にJAVAに限定した話じゃない。
しかも、道具の再発明を否定しているJAVA厨の話だと、「新しくて高速な探索アルゴリズム」って
JAVAじゃ組まないんじゃないの？そういうクラスライブラリを誰かが組むまで待つんでしょ？

その辺の話は、「狭い、低レベル」なC、C++厨の領域ってことになるし。
JAVA厨の言ってるJAVAのメリットとJAVAでパフォーマンスを向上させるっと事は相反するわけ。

どんな言語でも、パフォーマンスを追及すれば、多少なりとも泥臭くて「再発明」をあえて
行う必要も出てくるけど、それを否定しちゃってるから回りと話がかみ合わないのよ。

>>429
> 高速化の話は結局アルゴリズムの話になるから、別にJAVAに限定した話じゃない。

アルゴリズムで決まるからこそ、
コーディングが速いJavaのほうが、
アルゴリズムを突き詰めるのに使える時間が多く、
有利になるんですよ。

> しかも、道具の再発明を否定しているJAVA厨の話だと、「新しくて高速な探索アルゴリズム」って
> JAVAじゃ組まないんじゃないの？

大抵はJavaで組みますが?

> そういうクラスライブラリを誰かが組むまで待つんでしょ？

待ちませんが?

C++厨ってホント必死にC++の必要性を訴えるんだな
じゃあ早くC++で高速なJavaのライブラリ作ってよ
使ってやるからｗ

アルゴリズムを素直に書くには、やっぱりポインタを明示的に使えないとな

ﾊｲﾊｲ
だがスレ違いだぞ

>>432
C++のポインタで、
*p
というのは、
0[p]
ということなわけで、
Javaで配列の添え字を変数で指定するのと同じだと思うのだが・・・。

ようするに、Javaしか知らないから「Java最強」でないと困るって話？

>>435
違う。

このスレには、
Javaしか知らないJava厨
Javaを知らないC++厨 あるいは、知っていてもあえてC++原理主義に走る者
C++とJavaを適材適所で使い分けてる人
がいる。

違うよ
例えば字句解析をするような場合、ポインタは１つでいいが、
配列の場合は配列名とindexの２つを渡さなければいけない

リストなどは参照で十分だけどね

>アルゴリズムで決まるからこそ、
>コーディングが速いJavaのほうが、
>アルゴリズムを突き詰めるのに使える時間が多く、
>有利になるんですよ。

主観しか入ってない・・・。資料を示さず自論が支持されていると思ってる・・・。
コーディングが速いってこのスレでやたら見るけど、なんかのJokeなの？

>>437
2つ渡せばいいじゃない。

引数に2つ書くのが面倒なら、クラスにすればいいじゃない。

>>438
JavaとC++の両方を扱う職場で仕事してない人には、資料が必要なのか。

両方を扱っていても、人間コードトランスレータなやりかたしてたら違いが出ないけどさ。

JavaとC++でコーディング速度に差が出るって、どんな小規模な開発の話やねん。
もしくは、組んでる奴のレベルが低いのか？

C++とJAVAは一見　似てるから簡単に頭が切り替えられないんだろ。
JAVAがbegin end を採用してくれてりゃ、簡単に切り替わったんだろうけどな

っつうか、>>430って俺々論しか言わないし。
はっきりいって、>>430が右手でマスかくとか、左手でマスかくとかどーでもいいし。

両方あつかう職場の人間の結論が「Javaの方がコーディングが速い」とかいう
どーでもいい「主観」の話して、「他人」を「資料」で説き伏せる事も出来ないって・・。
どんなコントやねん。

ここのスレのJava専用厨ってJavaがC++より速い「証拠」を一つも出せて
いないだろ。
全部主観ばかり。あのな、自己主張は結構だけど他人を納得させるには
根拠が必要だっていう、議論の基本がなってない。

Javaでプログラムを組む時もどうせ他人のアドバイスなど全く耳に入らず
全部自己流で書いてんだろどうせ。

ここってネタすれだったの？

　 ☆ﾉハヽ　AA入れてって言ったでしょ！
　　ﾙ ’ｰ’ﾘ
　　⊂彡☆))Д´)ﾉ >>445
　　　ﾊﾟｼｰﾝ

ネタスレ以外の何者でもあるまい
しかしC++厨って痛いなｗ

まあ自分の存在意義が、Javaによって脅かされているんだから
目くじら立ててJavaを否定してC++マンセーなのは仕方あるまい

>>448
そうじゃない。Javaなどout of 眼中なので。

>>449
実際、C++のライバルはDだからなぁ。

どうしてこうJava厨は人を常に目下目線で見るのか。
自己愛性人格障害者が多いのではないだろうか？

単に必死な人をからかうのは面白いだけだと思うが

>>452
それだけじゃないと思うよ
性格そのものが根底から歪んでると思う

Javaが最強じゃなくなったら、心が折れるから。
だから、「C++厨をからかってる」ってことにして自分を慰めてる。

皆Java厨を否定しているだけで、実はC++厨なんてどこにもいないのにね。

>>454
その通りだな

>>454
俺(C++厨)はここにいるぞ、フェストゥム！

456=Java厨による自演

C/C++/汗だけで組めないものは無い
JAVAだけで動かないものは山ほどある。

>>443
そうまで言うなら、JavaとC++で、コーディングの速度が変らない、ということを資料でよろしく。

自分には、ここに出せる資料はない。
そういうデータは社外秘だからね。

>>444
連投乙

>>454
Javaが最強? そんな話はJava厨しかしてない。

適材適所で使い分けるべきだろ。
C++とJavaは同系列なんだから、
片方を仕事で使えるレベルなら、
もう片方も少しやれば同レベルになる。

>>459
それは反則だ。言い出した方が先に証拠を示す必要がある。
挙証義務って知ってる？
それをスルーしたらその時点でお前は議論に負けたって事だ。

>>461
そういう防戦しか手が残ってないのか。
それとも尻の穴が小さすぎるのか。

悪魔の証明をしろというわけではないのだから、
資料を出せばいいじゃない。

>>462
はいはいお前の負け。残念でした。
Javaは糞言語だと証明されました。

どっちか先かなんて関係なく、ちゃっちゃと資料を出せば、それで話にケリが付く。

それをしない、
ルールだとか義務を楯にしないといけない、
ということは、
実は、自らもまた、証拠なく反論しているからだろう。

>>463
> はいはいお前の負け。残念でした。

誰も勝っていないのに、勝利宣言しちゃぁマズい。

> Javaは糞言語だと証明されました。

ひどい論理の飛躍ですね。

>>465
そう言われるのが嫌だったらさっさとJavaの方が早くコーディング出来るという
証拠を出せよ。出さない限り言い続けるぞ。

>>466も出せる証拠がないんだな。

>>467
お前が出したら出してやるって言ってるだろ。
お前馬鹿か。

>>460
だから、そういってんだけど。だれも言語の優位性に絶対なんて感じてない。
COBOLですら必要とされる場所ではいい言語だと思ってる。

「Javaの方がコーディングが速い」とかいってるJava厨をみんなでウォチしつつ
チクチクと先の丸い針で突付いて遊ぶのが、ここでのたしなみ。

>>468
相手が証拠が出てきた場合 → 証拠として不採用だと主張する。
そうもいかない証拠が出てきた場合は、それで話にカタがつくので、証拠を出さなくて済む。

相手が証拠を出してこない場合 → 証拠出せと言う。


出せる証拠がなくても大丈夫な状況で>>468のようなことを言ってもなぁ。

>>469
460は俺なんだけど、なぜかJava厨と見なされてるのよ。

>>470
それはお前の疑心暗鬼。安心して証拠を出せ。
もし本気でそう思ってるなら、そういう風になるように自分を追い込んでいった
お前が悪い。

相手を煽るのが目的で、話を前に進める気がない輩は、退場。

JAVAとC++はうまくすみわけしてるのに、あえて同じ土俵に乗せて優劣を競う意味なんてあるの？

って言うかお前ら全員スレ違いだハゲ

野次と煽りは2chの花
お前ら雑魚レスに食いつくんじゃねえぞ！

×COBOLですら必要とされる場所ではいい言語だと思ってる。

基幹ではメンフレ+COBOL以外考えられない。

そのCOBOL基幹業務システムをJavaでリプレイスしてますが何か？

>>474
Java厨とC++厨とただの厨の言い合いをヲチする

まあ、考えられるとか考えられないとかじゃなくって、現状
メインフレームで使う分にはそんなに不満は無いかな。>COBOL

変なメンテナンスしにくいソースなんて、C++でもJavaでも簡単に作れるし。
綺麗に書けばCOBOLもメンテしやすいし。

ただ、基幹もメインフレームじゃなくなってきてるし・・・。
ウチでもCOBOLオンリーの人がJava書いてスゴイことになってるよ・・・orz


でも、このスレタイって「Javaは普通にやったらC++に速度で負けます」って
言ってるようなもんだよな〜。Java厨的にはどうなん？これ？

>>480
そりゃ当たり前だろ。JITコンパイル入れたってネイティブを最初から
吐けない時点でJavaに勝ち目はない。

481がJava厨かC++厨かで流れが変わる

>>480
話を戻してくれてありがとう。

スレタイ通りC++並でいいんだったらもう実現してるんじゃね？
C++より速いとか言っちゃうから荒れるんじゃないかと。
開発スピードをどうこう言ってる奴はスレタイ読めと。

>>383が気になったのでVMのソースをgrepしてみたら
スカラ演算は本当にSSE/SSE2使ってるっぽいね。

でも重たい80bit FPUの代わりに軽い32bitや64bitのSSE/SSE2を用いているというだけで
ベクトル化はされていなかった。残念。

>>484
x87命令はobsoleteなので使わないようにしているのだと思う。

x87命令は演算器自体の速度よりもレジスタがスタックなのも敬遠される理由の1つだと思う。

>「Javaは普通にやったらC++に速度で負けます」って

普通にやらなきゃ良いんじゃない?
例えば、オブジェクトをプールしといて使いまわせばJITのコンパイル時間
無くなるし、アプリの起動時にわざとプリロードさせてJIT側でネイティブに
コンパイルさせるとか(.NETだったら別の方法あるけど)、あるいは
Javaのスレッドは実際にマルチコアに割り当てられるからコードを始めから
マルチスレッド化しとく、とか。

アプリケーション側でやることなのかな。
JavaVM側でやることだと思うよ。

>>486
無理にJavaで速度を稼ごうとするなｗ
素直にJNIを使えよ、そこの馬鹿。

JNI は素直じゃないよ
ポータブルじゃなく、GCable じゃないから

C++ が速いたって、
いまやJavaとの差は JVMの起動時間ぐらいだろ。

その部分を埋めるのは確かに難しいかもしれないが、
その他の諸々の部分のデメリットを考えたら、今は C++ にどれほど
アドバンテージがあるのか疑問。

あとは、実用アプリの数が徐々に揃うのを待つだけだが、
まあ、まだ少し時間がかかるだろうなぁ。

>JIT側でネイティブにコンパイルさせるとか

最初からネィティブにしとけばいいじゃんw

C++側のアドバンテージの話をすると、速度よりもっと違う部分にいくと思われ。

加えて、Javaが「速度的アドバンテージが同等」と語れるのも、「余裕あるメモリ」と
「ある程度以上のCPUパワー」がある環境前提だしね。そういった「恵まれた」環境で
速度差を「誤差」に変えてるわけで。
実際JavaのVMのバイトコード設計の酷さは、ソフト屋が考えた仮想CPUっていっても酷いもんだし。
あれが、必ず一枚かむ環境で、「C++より速い」はありえない。
ネイティブコード吐けば別だけど。「Evalれる」事がネイティブコード化も拒否するし。


ダイレクトなアドレス指定でメモリをさわれたり、オブジェクトの開放タイミングを
自前で制御したり・・・。
C++ではこれらの機能はあたりまえで、その上で速度的アドバンテージは同等か、
クリティカルセクションでは同等以上。コンパイラに精通していれば、出力される
プロセッサのコードを意識したコーディングも可能。Javaは頑張ってもバイトコードに
されてしまう。

結局は適材適所で、高級アセンブリ言語の延長を欲するシーン(OS、デバドラ、組み込み、ゲーム)では
Javaは「速度」的にも機能的にも、足りていないのが現実だと思われ。
（っていうか、そういうシーンではC++ですら否定されがちで、未だCが使われてる事も多いけど）

ただ、アプリケーションの現場では>>490の言ってる事は的を射てると思う。
しかし、Java登場からこれだけ時間がたって、未だ「実用アプリ」の数が少ないのは
C++はもとよりC#やRuby、PHP等、各方面に言語/環境的なライバルが居る現状で、いかがなもんかと。

>>490の意見は楽観的すぎとも思われ。Javaもアプリで頑張って速度を稼ぐ事をやっても
いいと思うんだけど。このスレの（本来の）目的はそこじゃないの？
C++でだって、速度の速いコード書くためには、いろいろプログラム側が努力してんだぜ。
Javaの特性に基づいて、「このシチュエーションはVMのパフォーマンスに影響を与える」とか
そういう話は出来ないもんかね？VMの効率が良くなってアプリの速度が上がったのは、
コーディング側ががんばった結果じゃないんだぜ。

>>492
要点を３行にまとめてくれんか？

>>490
JVMの起動が遅いというよりは、
アプリの実行時に動的にリンクしまくるのに時間がかかってるっぽいぞ。

>>492
実行速度については、

高スキルのプログラマがC++で書いた場合 > 並のプログラマがJavaで書いた場合 > 低スキルのプログラマがC++で書いた場合

結局、言語よりもプログラマのスキルで速度が決まると思う。

> 結局、言語よりもプログラマのスキルで速度が決まると思う。

そんなことは、百も承知で「プログラマの質が同じだったら」どうなのよ？
について語ってると思っていたが。

話をごまかしたいだけなら、どうでもいいけど。

>>493
長文、スマソ。要は、「このスレって、実際にJavaで高速なプログラムを書くノウハウを出し合う
もんじゃなかったの？」って言いたい。「VMが高速だからJavaは既にC++に速度的に並んでる」
のを理由に、C++とJavaで罵り合うんじゃ悲しすぎると。ただ、建設的な意見は出ないみたいだし、俺は消えるわ。

>>494
基本的には同意なんだけど、最近の環境での「アプリケーション」に限って言えば、一定以上の環境なら、
C++とJavaの速度は不等号で並べるほどの速度差じゃないと思う。
プログラムが立ち上がってしまえば、結局プログラマのスキル次第で、ほぼ同等だとは思うんだ。
それくらい、アプリケーションを取り巻く環境は恵まれた物になったわけだし。

ただ、Javaは気を抜くと、スグに便利なクラスライブラリに頼ってオブジェクトを何も考えずに
作りまくって、ガベコレに負荷係りまくるし、メモリ消費も半端じゃなくなる。
ちょっとした規模のアプリを複数の人間で作ると、プログラマの質なんて簡単にバラけるから大変だし。

この辺、「開放を意識しなくて良い」言語の特性も一役買ってるんじゃないかな。
逆に、バルクなツール作るのは手っ取り早くて良いんだけどね。それじゃ、昔のTcl/Tkと同じ扱いで悲しいでしょ。

暇な奴らだ

ごめん、>>496は490じゃなくって、>>492ね。

>>495
プログラマの質が同じ
というのは指標として実戦的ではないと思う。

たとえば、プログラマの質が同じといっても、
並のC++プログラマは入社から平均で7年目
並のJavaプログラマは入社から平均で3年目
ということだったりしたら、比較にならないでしょう?


だいたい、
プログラムの速度はアルゴリズムが支配的で、
言語による速度の違いは微々たるものだしさ。

いまどきのCPUでは、プログラムの速度は、
CPUの演算速度ではなく、キャッシュミス時のメモリアクセスのレイテンシで決まるしさ。
JavaのVMのオーバーヘッドは、そこに隠れちゃうんですよ。

処理速度をあと3割向上させる必要があるからといって、
CPUをクロックが3割速い上位モデルに交換してもダメでしょ。

Java屋はアルゴリズムを用意してもらう側だから、
こんなスレ用意されたって書く事ないんじゃないかな？ｗ

　　　　　 　 　 ＿
　　　 　　　,'´r=＝ﾐ､
　　　　　　卯,iﾘﾉ）)）〉　　　　＜　盛り上がりそうにないかしらぁ〜
　 　　／`-|l〉l;ﾟ ｰﾟﾉl 　　 ∫　　　
　　　 ﾚ´V'|(つ|⌒|⌒|つ([_]
　　　　　 　（｀ヽ/~)ﾉ
　 　 　￣￣￣ し'J￣￣

>>496
要約乙。まぁ、罵りあいのほうが馬鹿でも参加できるから盛り上がしねぇ。
お前さんはこんな隔離病棟スレじゃなくて↓こっちのスレにでも逝きなさい。

JAVAってこんなことも出来ないの？
http://pc11.2ch.net/test/read.cgi/tech/1179580383/

こっちはスレタイはアレだが、中身は建設的。
ただ、やっぱり罵りあいが少ない分、活気もないが。

かしらかしらご存知かしら？

すんごい生臭い話をするとさ。

アルゴリズムとコーディングをカリカリにチューンした、
とても速く動くプログラムを書く技術は必要だけど、
そういうプログラムは、滅多に書いてはいけない。

将来に備えて、
わざと遅く動くプログラムを書いておくのが、
本当のプロの仕事。

そういう備えをしておかないと、
バグ修正や機能追加で遅くなって
客が怒るんですよ。

とくにプロトタイプを誰かに見せる場合、
相手が客だけでなく、直接の上司以外なら、
無駄なループを入れてでも、重くしておくべし。

後でチューニング目標とか設定されたとき困るしなｗ


レスついでに真面目なTipsを書いておこう。

標準API内にも当然APIの高級、低級が存在する。
これはプロファイラを積極的に活用することで辿ることが容易となる。
例えば文字列のバイト列変換は、String.getBytes（charset) でも OutputStreamWriter でも
最後には CharsetEncoder.encode(in,out,endFlag) にたどり着く。（少なくともSunのJREでは）

>>504
話をすり替えるな馬鹿。

お前のそのレスも無駄。スレタイにそったこと書けないなら書くなっての。

まぁ、つまりC++で超ヘタレなアルゴリズムでプログラム書いておいて
Javaでまともなアルゴリズムで作り直してC++並の実行速度が出たぁ！って喜んでなさいってこった。

>>499
> プログラマの質が同じというのは指標として実戦的ではないと思う。

だから >>494 で FA って言いたいの？

別にそれには反対しないから、それで君が納得できるならそう思っておけばいいし、
こんなスレ見る必要もないと思うよ。

> 言語による速度の違いは微々たるものだしさ。

そう思ってるなら、それでいいと思うよ。別に全ての人がコンパイラとかのベンチ
マークで一喜一憂する必要はない。

「いまどきのCPUでは、」以下の文章については、知ったか乙としか言いようがない。

まあ、>>504 と同じで話をすり替えざる得ない状況なんだろうな。

てめえで横道逸れといて、他人様に横道それるなって厨もいいとこだな・・・

っていうかお前ら全員スレ違いなのは変ってないから

自治厨が加わってる分、お前に敵う厨はいないって

>>499みたいな思想は末期的だと思う。
みんながアプリレベルで速度が同等っていってんのは、VMの1命令が数十〜数百レベルの
CPU命令に分解されても気にならないくらいCPUが速いってだけで、キャッシュミスヒットかどうかの
レベルの速度差が問題になる世界なら、確実にVMのオーバーヘッドは問題視されるっての。
アルゴリズムが支配的な速度になる世界ってのは、いわゆるアプリレベルなんだから。キャッシュミスでも
問題にならないような上位の話でしょが。

ﾊｲﾊｲ

>>510
まあまあ、指摘されたぐらいでカリカリすんなよ。

> てめえで横道逸れといて、

で、どのレスを指してるのかな？ 厨房君 (w

>>513
> VMの1命令が数十〜数百レベルのCPU命令に分解されても気にならないくらいCPUが速い

そう言うなら、
単純なプログラムでいいから、
具体的に、C++とJavaで、
どれくらいの速度差があるのか示してよ。

> キャッシュミスヒットかどうかのレベルの速度差

些細な速度差だと思っているようだが、それは断じてちがう。
キャッシュミスしたら、数十〜数百命令分の時間を、無駄に待つことになる。

ﾍｰ
リフレクション使いまくってる時点で（ｒｙ

CPUにとって最も重い処理は、メインメモリからキャッシュへのロードで、
アプリケーション実行に費やしたクロックサイクルの約半分が、それに消費されてるそうな。

>>516
おまえは、μsecオーダーのプログラムを組んでんのか？
msecオーダーのプログラムを組んでんのか？

JVMはそんなにミスヒットを発生させる要員なんんか？

脳みそあんのか？

>>519
4つの疑問すべてが的外れ

新幹線のネット予約システムが止まったり全日空のシステムに
障害起きてるのってこれ全部Javaのせいだろ？だっせ〜ｗ

>>521
前者はしらないが後者は違うよ

コボちゃんです

ANAの国内旅客システムの再構築はJavaとRDBMSで行われた。
で、ちゃんと動かないから古い方に戻したんだよな。

ザマアミロJava

つまり、JavaがANAのシステムを支えているということだな。

支えているなら支えているでバグなんか出すなよカスｗｗｗｗｗｗｗｗ

>>520
答えられネーでやんの。

まあ、脳みそは無いと思うけど。

今回のバグはDBの設計にあるらしいよ

>>528
頓珍漢な質問だからな。

もう一度スレをよく読み直して質問しなおせ。

>>528
彼にとっては 答えられない質問 ≡ 頓珍漢 (と思いたい) 質問 なんだろ。(w

>>531
それはかなりの人に当てはまると思う。

無知なのを恥じる事は無いんだけどね。

>>530
スレを読み直せば、「キャッシュミスがプログラムの速度低下の原因だから、VMのオーバーヘッドは
無視できます」なんて珍妙な回答に到達するのか？

馬鹿ですねえ

馬鹿ですよ

javaだろうがワイヤードロジックだろうが
バグを出すのはSEとプログラマの全責任だが？

答えられるけど頓珍漢な質問だからスルー。

> おまえは、μsecオーダーのプログラムを組んでんのか？

No.

> msecオーダーのプログラムを組んでんのか？

No.

> JVMはそんなにミスヒットを発生させる要員なんんか？

No.

> 脳みそあんのか？

Yes.


で、これが一体何の意味があるのか、と。

キャッシュミスは100nsecのオーダーの世界で頻繁に発生しているので、
1回の応答が何秒もかかるような処理だろうが、
1msecで片付くような処理だろうが、
関係ないのですが。

関係ない

というのは誤解があるかもな。

どちらとも同じように関係してくるのであって、
どちらか片方だけに作用するような関係ではない

VB : 宇多田
C++ : ZARD
JAVA : yozuca*
C# : 小森まなみ

yozuca*
小森まなみ

誰？

yozuca*も小森まなみも知ってるけど、言いたいことは全然分からん

お頭が貧相なんだね

たとえ話は、馬鹿がする。

>>537
だから、関係ないんじゃん。
キャッシュミスが重大な応答速度の阻害要因になるってレベルの話なら、VMのオーバーヘッドは
同様に応答速度の阻害要因になるっての。

VMのオーバーヘッドが無視できるレイヤの話＝キャッシュミスなんてマクロな事象は問題にならない
アルゴリズムが支配するレイヤなんだよ。

あと、最後の質問の回答が間違ってるぞ。

>>544
自分が頓珍漢だってことに気がついてほしい。

まず、
> キャッシュミスが重大な応答速度の阻害要因になるってレベル
という話は、いったいどこから飛び出したのか。

シビアな応答速度の話なんて誰もしてないのに、
いきなり、そういう前提で質問をするから、頓珍漢なのだ。

> VMのオーバーヘッドが無視できるレイヤの話＝キャッシュミスなんてマクロな事象は問題にならない
> アルゴリズムが支配するレイヤなんだよ。

まず第一に、
ミクロな事象というのなら話はわからなくもないが、マクロな事象というのだから、頓珍漢だ。
ただの書き間違いなのか?

第二に、
この話の流れでの、VMのオーバーヘッドというのは、
JITコンパイラが生成するコードが、C++コンパイラの生成するものよりも遅い
ということなわけで、だからこそ、キャッシュミスに隠れてしまうという話になる。

第三に、
メモリアクセスと演算のコスト比が逆転し、差が開き続けているので、
アルゴリズムの優劣を検討する上で、従来のように演算回数だけでは不十分で、
メモリアクセスの回数やパターン、キャッシュとの親和性が、無視できなくなってきている。

大きなワーキングセットのプログラムに至っては、
TLBキャッシュまで意識してやらないといけない。

VBは過去の人なのですか？
C++は故人なのですか？

VB6は過去の人だが、VB.NETはバリバリ現役。

.NETではVBである必要性ないよね。
C#一本でいいじゃないか。

C#はJavaの後発だけあって、いろんな面でJavaより優れているのは事実。
ただまだ新しい言語だし方向性が固まってないのでユーザーも少なく
市場ではひよっ子に過ぎない。

メーンフレームにC#が移植されだしたらJavaを駆逐するかもしれない。

windowsばかり触っていると、C++がCやJAVAのように、普及しているかのような錯覚を抱くが。
一歩UNIXの世界へ踏み出すと、数あるマイナー言語のひとつに過ぎない。

.netに至っては使っている日本人はいないのでは？と思えてきました。

>>550
UNIXでもCはメジャーだろ。C++はマイナーだけど。
WindowsだとMSというファーストパーティのC/C++があるからいいけど、
UNIXだと、SolarisとかHP-UXとかHI-UXとかAIXとか、ファーストパーティによって、
C++の実装度合いがマチマチなんで使いづらい。Cでも#ifdefで切り分けないとつらい。

老人→C
厨→スクリプト

たとえ話は、馬鹿がする。

>>552
550はUnixにおいてCがメジャーでないと言っているようには思えないのだが。

大抵のことはスクリプト系で完結するから
C++使うのってGUIのTKくらい？

全部Visual C++.NETのC++/CLI でやらないと気が済まない俺

>>545
>>499
>いまどきのCPUでは、プログラムの速度は、
>CPUの演算速度ではなく、キャッシュミス時のメモリアクセスのレイテンシで決まるしさ。
>JavaのVMのオーバーヘッドは、そこに隠れちゃうんですよ。

隠れねっての。nsecオーダーの事象とmsecやsecオーダーの事象を同列に扱うな。
突然「アルゴリズムを支配するのはキャッシュ」って・・・。脳みそあんのか？
おまいさんの話は「VMのオーバーヘッドがキャッシュミスヒットのペナルティレベルの速度の蓄積で隠れる」って、
事じゃなかったのか？アプリを巧く作らないと、キャッシュミスヒット乱発して、そのペナルティを考慮すると、
VMなんて誤差になるって思ってんだろ？

こっちは、そうではなく、アプリレベルの応答速度に求められるオーダーと、
VMに求められる速度のオーダーが「桁違い」なんで、一定以上の速度のプロセッサ
になったら、そんなもんは隠れるっていってんの。
「一定以上の速度のプロセッサ」がキャッシュヒットしようがミスヒットしようが、
期待値道理の性能だしてれば、そんなもんは誤差ってのがアプリレイヤ。応答期待値がmsecやsecの世界。
だから、VMのオーバーヘッド(μsecオーダーの処理)が隠れるっていってんの。
アプリが求める応答期待時間に対して、VM分の処理時間が1%以下とかの話になるから「隠れる」っていってんの。
処理全体に対するVMが閉める時間の比率の話でVMが隠れるっていってんの。

キャッシュのミスヒットの蓄積がアプリに影響を与えるレベルの応答速度の話だと、
そもそもVM自身も「キャッシュミスヒット」を起こす可能性があるんだから、同じ比率で
時間的損失を担ことになるっての。VMの有無を余計に浮きぼりさせるっ中年。

自分、どういう前提でアプリの消費時間考えてるん？一回、ナンチャッテ数値で考えてみたら？
各レイヤの時間オーダーだけあわせて。

>>C++使うのってGUIのTKくらい？

その方面もいろいろな派閥がある

　　　　　　　　　　　,,,ィｯｯｼﾐ彡三ミ､,
　　　　　　　　　 ／彡彡三三三ミﾐ彡ミ､
　　　　　　　　／彡彡へ-‐'''ﾞﾞ⌒´ヽ､ミﾐミﾍ
　　　　　　　 {彡彡-''ﾞﾞ　　　　　　U　ミﾐﾍﾍ{
　　　　　　　 |彡;{　　u 　　　　　　　　ミミミﾐ
　　　　　　　 |彡ｉ　ｨｯｧ､　　　ィ≡ﾐ､　 }ミﾐミ
　　　　　　　 r-;;{´ ｨｪｧ､}--{ r‐ｯ-､ }‐‐;;r''´}
　　　　　　　　ヽヽ＿'ﾞ__ﾉ,' ',ヽ__''ﾞ__ﾉ　 :|/::） 　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　 ｀|　　 /(､,　 ,, ）　　　 :::|::,.}　　　＜　そろそろイキそうだ、中に出して良いかい？ 　
　　　　　　　　　ヽ', ヽ弋''‐'''フ-ﾉ　　,::ﾉ　ﾊｧﾊｧ
　　　　　　　　　　ヽ,､　｀‐‐'''´　,.::::::ノ
　　　　　　　　　　 ／ヽ､__ﾆ___ノ''ﾞ .⌒＼
　ｱﾝｱﾝ　　　　 ／　人 ｡ 　　｡ 　丿＼　＼
　　　　　　　　　＼ ＼|　 亠　　 /　／　／　ﾊﾟﾝ
　　／￣￣￣＼　＼⊇ 干＼　⊆　 ／　　　　
　 i'_liﾉ |_|iトil_}__,l　　 （　。　　　 　|　　　／￣￣￣￣￣￣￣￣￣￣￣
　 |i.}┃　┃　ミ;i|《　 ／⌒ｖ⌒＼　）　＜　社長〜中出しして良いから次も主役お願いね♪
　 |lヽ'' ヮ　''' ,_) l／⌒＼ ノ　　 ） |　　　＼＿＿＿＿＿＿＿＿＿＿＿
　/　 　　　　　 |　 | 　　　　　　| 　|　　　　ﾊﾟﾝ
　| 　|.　　Y　　 |　 |＿＿／　　| 　|　　　　　　ﾊﾟﾝ
　| 　|ヽ__人___ノ|　 ト' 　　|　 　 |／＾ヽ
　| 　|　゜　　゜　 |　 |＿／ ヽ＿＿人_ﾉ
⊆, っ　　　　　 とｰっ
〜〜〜〜〜その頃堀江ヲタは…〜〜〜〜〜〜
　　　　　ほっちゃんは天使だおﾊｧﾊｧ　ｼｺｼｺ
　 (*´Д`)　　　　ｼｭｯ　　　　　　　　　　　　ｼｺｼｺ
　Σ⊂彡_,,..i'"':
　　　　　|＼`､:　i'､
　　　　　＼＼`_',..-i
　　　　　　 ＼|_,..-┘

>>550
そうなんだよ。

UNIX出身のライブラリは、setjmp/longjmpを要求するモノがあって、ウザいんだよ。
そういうのはC++から直接使うとヤバいことが起きることもあるので、面倒なんだよ。

中にはFILE*を渡せ、なんていう酷いライブラリもある。
C++以前に、Cでもダメだろ、それは、と。

>>558
> 隠れねっての。nsecオーダーの事象とmsecやsecオーダーの事象を同列に扱うな。

事象1回あたりの遅延時間のオーダーで比較するのはナンセンス。
プログラムが単位時間走る間に、何パーセントの時間を何に使っているか、ということで論じるべき。

> 突然「アルゴリズムを支配するのはキャッシュ」って・・・。脳みそあんのか？

支配するとまでは言ってないが。
ちなみに、メモリ・ウォールという言葉をしっていますか?

> こっちは、そうではなく、アプリレベルの応答速度に求められるオーダーと、
> VMに求められる速度のオーダーが「桁違い」なんで、一定以上の速度のプロセッサ
> になったら、そんなもんは隠れるっていってんの。

そんな条件下で、JavaとC++の速度比較してもなぁ。
速度比較をするなら、処理時間にプロセッサのアイドル時間を計算に入れるのはやめてほしい。

私が言いたいのは、JavaのJITコンパイラが生成する最適化が甘いコードと、
C++コンパイラが生成する最適化が行き届いたコードとの、速度差が十分に小さいということ。
Javaだけでなく、
C++コンパイラのミクロな命令最適化も、使っても使わなくても、大して速度が違わない。
最適化なしで10,000msecかかる処理が、最適化して9,500msecになる程度。
なぜこういうことになったかというと、キャッシュミスしたときのペナルティが支配的だから。

> キャッシュのミスヒットの蓄積がアプリに影響を与えるレベルの応答速度の話だと、
> そもそもVM自身も「キャッシュミスヒット」を起こす可能性があるんだから

VMといってもJITだからね。重いのは最初だけよ。

Javaは当初はJITじゃなかったからなあ。その点C#は初めからJITで
設計されているから整合性が良い。Javaはあちこち後出しじゃんけんで
無理矢理リフォームして不格好になった家みたい。

>>562
良く最適化された計算が中心のコードは確かにそういう傾向がある。

しかし、x86に限定すればJavaを使えるほどのリッチな環境なら
普通SSEも当然入ってるんだよ。
そしたらCにSIMD最適化付きでコンパイルした方が断然速い。

あとは計算が中心になると誰かも言ってたポインタが使えないのが不便かな。
オブジェクトから2つの値を操作するのが煩雑になる。
ここら辺は恐らく人間だけじゃなくてJITにとっても煩雑。

逆にJavaが得意とするオブジェクトの取り扱いが中心のコードは
完全に最適化されるまでかなり時間がかかるはず。
動的な最適化が静的なC++を越える瞬間に興味はあるが
恐らくサーバーのような長時間実行される環境でないと効果がないんじゃないかと。

>>564に禿胴
馬鹿は知らんが、ポインタが使えなくなったのは痛い（ポインタが使いたい
その方が効率の良いプログラムが書けるだろうに
インデックスに頼るのはもううんざり

C#はGCの効く安全なポインタが使えるんじゃなかったっけ？

C#のunsafeを使うとC並みの事ができるんだぜ！

>>559

qtってLispだっけか

>>562
俺はC++なんて、話題に出してねっての。勝手に脳内で敵と戦ってろ。

こっちはたんに「VMのオーバーヘッドがキャッシュミスヒットで隠れる」とかいう、
>>499の壊滅的に間抜けな意見を否定しているだけ。
VMのオーバーヘッドがアプリレベルで隠れるのは、アプリが単位時間に扱えるプロセッサパワーが、
相対的に増えたからだって言ってんの。「アプリレベルでは、VMのオーバヘッドは隠れる」って言ってんの。
ただ、原因が「キャッシュミスヒットが原因なんやー」とかいうドリームを否定しているだけ。

どっからC++の話題が出たんだよ。薬でもキメてんの？会話する気無いなら日記はチラシの裏に書けよ。

あと、いい加減、キャッシュに夢見すぎ。アプリレベルなら、キャッシュより大きい
タイムペナルティなんてごろごろしてるっての。
お前の脳内では、キャッシュがシステムタイムを支配してるんだな。

>>570
なんだと、貴様！　C++厨の俺の前でC++が眼中にないとでも言うのか！
許せん！　そこへ直れ！

http://www.atmarkit.co.jp/fdotnet/special/mono10_02/mono10_02_02.html
> さて、この速度差をどう見るだろうか。JITはチューン次第で速くなる技術である。生まれたばかりのMonoに、
> チューンを積み重ねてきたほかのJITと同等であることを望むのは少々酷かもしれない。とはいえ、限界まで
> 性能を求めなければ、十分に実用になる速度は出ていると思う。まだスタート・ラインに立ったばかりで、
> これから改良が見込めることも含めて考えれば、利用を検討する価値がある速度ではないかと思う。

>>572
Javaじゃないじゃん

>>565
それはVMの作りによると思う。

最適化後のコードを保存して再利用すればいいのだから。
それをやってしまうと、動的な最適化を否定することになるが。

>>566
昔のCPUと違って今のCPUは、
乗算のコストが非常に小さいので、
あまり気にしなくていいと思う。

乗算は1クロックで終わるし、
なんたって、
メモリアクセスが生じないから。

>>570
なぜC++の話が出てくるのか理解できないということは、私の言っていることが理解できていないということ。
私の文章が理解できない代物なのか、あなたの前提知識が足りなさ過ぎるのか、それとも・・・。

とりあえず
1回の応答が1分かかるプログラム (ただしディスクや通信の待ち時間は含まない)
ということで考えてみればいい。

>>575
って言うかその前にスレタイ嫁ハゲ

>>575
お前が考えろボケ。例も出せずに他人を説得したつもりになるなっての。
応答に1分かかるプログラムで、キャッシュミス時のペナルティなんざ糞よりも意味無いわ。
おまえ、分オーダーの応答が期待されるプログラム中、VMが使う時間の割合と、アプリが使うプログラムの割合と、
キャッシュミス時のペナルティを、どんな比率で考えてるんだ？蓄積すれば、何十秒にもなるってか？

だいたい、ディスクや通信の待ち時間の無いプログラムってどんなんだよ。ようするに、キャッシュミス
だけが浮き彫りになるシチュエーションを勝手に夢想してるだけじゃねーか。それでも分オーダーなら
キャッシュミスなんて考慮する必要ないっての。

通常はキャッシュミスなんぞより、頻発するデバイスへの応答待の方がよっぽどペナルティになんだよ。
おまえの想定するアプリケーションは、計算するサブルーチンでしかないのか？比較的計算量の比率が高い
エンコーダーやデコーダーでもディスクにアクセスをふつうにすんのに。
プログラム自体もディスクからロードされネーの？
画面の出力やったら、デバイスの応答待ちになんねーの？
入力待ちはしねーの？
応答期待時間ってわかる？

キャッシュオナニーは見飽きたんだよ。
「なぜC++の話が出てくるのか理解できないということは、私の言っていることが理解できていないということ。」とか
語ってんじゃねーっての。見てて、コッチが恥ずかしいんだよ。

>>577
> 応答に1分かかるプログラムで、キャッシュミス時のペナルティなんざ糞よりも意味無いわ。

もう一度聞く。
メモリ・ウォールという言葉を知っているか?
知らなければ、ちょっとググって勉強したほうがいい。

> おまえ、分オーダーの応答が期待されるプログラム中、VMが使う時間の割合と、アプリが使うプログラムの割合と、
> キャッシュミス時のペナルティを、どんな比率で考えてるんだ？蓄積すれば、何十秒にもなるってか？

VMとアプリの比率はおいといて、
キャッシュミス時のペナルティの比率は、
既に書いているように、50%前後。
1分の処理なら、30秒がキャッシュミス。

1回のキャッシュミスは数百nsecという、
CPUにとっては非常に長い時間なので、
数百命令に一度キャッシュミスしただけで、
CPUのスループットは半分になってしまう。

> ディスクや通信の待ち時間の無いプログラムってどんなんだよ。

そういうのはJavaでもC++でも変らない要素だから。

それに、そういうのはCPUのサイクルの消費が、
全くないわけではないが、極めて少ないし、
その間にCPUは他の処理をすることができるので、
CPUの処理能力を奪うことにはならないため、
今の議論では無視すべきこと。

じゃあキャッシュミス乱発しそうなたたき台。
こんなのじゃベンチにならねぇっていう突っ込みも歓迎。

begin 644 AffineTransform.zip
M4$L#!!0`"``(`%4)OC8````````````````4`!``069F:6YE5')A;G-F;W)M
M+FIA=F%56`P`<*I<1H%07$;U`?4!C55+;YM`$#[#K]A3M!B'@I/V@ETI4M+$
MATB5;+4'*ZH(7NQ%/*S==8U;^;]W9A<P^*$46¥#.S#>S^¥T#GF]*H4@:_8Z¥
M:*>¥06CS$Q'/HQ5#A;W9OF<¥)G$624D>DH07;"ZB0B:ER`FK%"N6DGP34<[(
M7]LF<-4(J2(%#P!$&>&%(M/7A^>G7S^GC_,70B8D¥$?WX7¥`7IZFSR]S`'RY
M]XV]OJ%!_Y(B7KR%5Y1+J1IEDI517YVKJE&^LKP4^RD>?U9N1<R(U`^CU?(>
M5!,57CKX[Y(O21[Q@LZ4X,5J¥48BL9(.T&05;'?*)75,B$//UYD1HO%TDO]A
MP$F7TT&/L-"V;`LH`2.,!I@%8N"8%G@B5'/$0>N'¥!AKAR%Q74YTC(90_@8F
ME-_X59(X$,*O_,#¥P-'!MH#7"Q&`T%JJR5[<#>YJ¥<)W[P8^.L5%`(N@68Q@
M,<)%X/D)6!OB:S]G>:&=HP][)Q]BLH?$'W;9<5J'GF3JH8"¥*;:D2FP9JKA)
M[(3$@H%"QZ'&'M5JS27B9G"^ZX&[EC^XY.¥9:P/85E86*T)4@,Q.R&PO%<N]
M>"L$*]2<Y^R59QF75.]&EV^RD=K4QY3IFHV*58:$^(8@V]JM.0@HP2C'O/5H
MIAKJD-=(K;VXE%0[P2B-:7#15$+AGIGZ3;YJT]OKIL&)Z94-F".Y>*8@J66J
MVQ.F$DWFH!"^¥XIELE4(MH$.4^W:=8&U^MW<->UJ]!'E1P!/D-`1N<5<?<4Y
M!9<AUZI=E%OE;:"G55;0QQ(ZE7FJ-%U.*5UJB0,;<3X%D"H'_5N839-+"VM@
M`B'JL`=L)//23K>Z_?4,4?WN/W;OWG3O'KJWU_G`POY8#:9T$FSU_:"31+?-
MZ`@7OO>YX;]&I"TBZ"*""X@:U^ZL,CNKVIWI;L&-5363S?2A¥.(D/*Q%:2M*
M48123(<_GG!R<T/XN#OP0`"*%)_IN/>Q,#&:N5^Y'=1@CT6I1UM/G.*`L@X$
MJHM]A,9A:"Z-P>QRK.%CX^F,IXTL:&0GZ3Y+M2GF9Q%MUCR69.7`1E;>4D0[
M,Y'TF-*C#?XX:HX?C<,_4$L'"'W88FTD`P``U@<``%!+`0(5`Q0`"``(`%4)
MOC9]V&)M)`,``-8'```4``P``````````$"D@0````!!9F9I;F54<F%N<V9O
I<FTN:F%V8558"`!PJEQ&@5!<1E!+!08``````0`!`$X```!V`P``````
`
end

壊れてるぞ。

これ見てもJAVAがC++よりも劣っていると言えるか？ｗｗｗ
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gpp

PHPとPerlはいい勝負だね

>>581
圧倒的にC++のほうが速いという結果になってるぞ、それ。

>>581
つーかJIT言語とネイティブ言語を比較すんなよ。恥かくだけだぞ。

英語圏外だからよめねーorz

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&lang2=gpp
一目瞭然

>>586
Javaダメダメだね。

そこでどうやったら速くできるか、というのがこのスレの趣旨だろ

>>588
具体的なベンチマークテストなどのデータが一つも出てない
この糞スレでか？

いやそのテストはGCCと書いてあるだろ。
VisualCやVBなんかに比べたらJavaが圧倒的に速い

>>590
>>586みたいな具体的な証拠を出せ

>>591

1.0 C gcc 1.22 1
1.0 C++ g++ 1.22


瞽ですか？

>>592
お前が馬鹿
VisualCとかVBがJavaより遅い証拠を出せと言っている

>>590
ほんとに必死ですね。

>>592
頭が不自由なんですか？

>>591 は、>>590 の
>VisualCやVBなんかに比べたら
の論拠を求めてるようにしか読めないんですが。

>>592みたいなレスを見るとJava厨は頭が悪いんじゃないかと思われても仕方ない

ふーん1+1が2になることに根拠が必要なんだw

>>596
1+1=2とJavaがVisualCより速い事を同格に扱うお前の頭が心配だ

絵の画面がある分遅いに決まってるだろ。
しかもM$製w

絵の画面って何？
コンソールアプリケーションって知らないのか？もしかして

コンソールアプリケーションがGDIで描画された絵に過ぎない事も知らない？もしかして

馬鹿だ・・・そんなのがベンチマークに影響すると思いこんでいるJava厨ワロス
いいから早く証拠を持ってこいよ

>>600
Javaの画面もコンソールアプリケーションだろ
お前本当の馬鹿か？

>>578
だめだ、こいつ。自分が何を指摘されてるか判ってねー。

コボちゃんです

Java厨あったまわりぃーｗ

ちがうな
根本的に

ビル(笑)ゲイツ(笑)(笑)(笑)(笑)(笑)

とりあえずソース貼ってくれ

ここ数日このスレ眺めているけどここって女性週刊誌みたいな場所なんだな

Java厨の言い分を聞いているとJavaはUNIXかLinux、C++はWindowsで
走らせるような感じを受ける。

スピードを単純比較しようとしているのに、プラットフォームが違っちゃだめだろｗｗｗ
どちらか一方に統一しろよ。

これでどうだろう。

begin-base64 644 Transform.bz2
QlpoOTFBWSZTWUZzZ6IAA79/hP6wAIB5f/+Pf/ff6v/33/4AASQIYAZuDt9vWt7jiPIoB0EiEoVM
ENQ9IyZHoTBAABoAAABoMTEeoNQmSH6qeo0xMATJiYTJgAABMEMAEYBkE0mqn+pPU9UzKegBNHqe
oyNMRowgABkaYBACTUVTGmpHpADQAaAAPUAAAAAAAONDQNGmRpo0yAxMEAANAaA0yAwJkCRIgg0T
yAmk2qe0KeFPQYp6aAIxDIZHomgMS8knVc8qaOpjvGJQBYAQDInMj9e1XZLIjg1izacQM+eYoIFL
EoCJVh6ioXCQ0SEEEEVRVRYiIiqxVRVRjASKKMFgKsRBCMBkYoCMQb5H6mtRhdAjJbTklVVUCwFF
Kooau7uhSxiOVvh1QizYmWqmTUuqzVxsMgrmcaNraqsOMZCzagdOaFxqrXjcSeYoSXwZPODNV0As
nuD3glIXKOIuvP2Po+yek5BXptsJigYZ+U3jPaCGVgeKUUBLsA20V1lpx2LfRjOsGloOs7Ukrbm8
GHEEFguknPGlhnAoKAP2sqxw8UYNYKjR/WXkWqbuDpHzGeZG+GbUiS0gtzhLZk2IJ9xGQFA4T4Ls
JgHM9DHIMw/OcBouICCkslAM9Ga/gcZY0AhQJZcpwNZSYaQgv6bcUp3hN6ysud/IMYysLKGNooaI
5OudOJcXp25GLlS+RmAuDqwoIzcF1JDwDRtZfOste/VVDwyJKREpKRphDHAWjxSMoGDLxOUVE9dq
spCDEAR8SwgxyIIEBReimAMXYnS2hB0hDxHR4WIVS5QNLDV5zERiivdkjXnOYiCA4b29ac84pyYN
vGp00k9uL8WyG81NTlex4RbllFBc0S2FhvLXWUSMt6E9RUUY9Gpl6Mas8HghC3Jr+UDLmKYJR2dn
v6xcTWqoq2TUFjV88jQXI2hdZDLCbiA2Ul4JUqB2BVak1agp66+ixYLG1p0IXESBSjxUxZ7KqaiF
Bi8BN4NtpsBcJNcbKaCQKjfxZ2pW18MRpoXebALD2Iz95VoroyoLlfYdkZvQFrDKOXJv4NV9GdDC
61yhoWppHmazOQMF4gvx4hUdR/WEWMXt5jlvHR7jnExFZ0mdKR8GVduEsqp0iMtIsSXvPiIYfulk
+49Dg8NZ5jNZI8aP2LaS3EqRnyJQcSiX75G+qqtaG8ORo42GdNMl2qVRULohv05hmktLslqR0hgS
CCyumkSNYM/nRAf61btZlYFQ8AdaOgfP3Cc5yPOiXSx7PNKasxYzlOgg0HqNK/C5jGcExHZ5DOl0
8WDcCSQX1KMq9fHhAOJXf4F4LNtc5g5Bgrx9XzEOQwTSGKnHWFRoHRtEEChKSlCYD/QYGShLbLhw
Y7KKfl8qESJo0o4lZZMZ3O7ytTeoKkXnANyqFSVKVCxmpYBegN5XFgaE6SpJ6ZXoCMR96dhTaF/z
1mRLtKD3HM+Vugml3DSiCDgFq14T1DMM5yJkZholsCRGCaLhBKqrvYRXKiqOFBwK+EhZpaWxDsK3
w+ihbYe8xYisGXd0skTJZPTrMAwbGls0ixJb6z6WbFqCrmJ26Ny3vGoXZwa8xoMY6TdLEwvhbKIg
jEwvQFAnKnOWr5SFyC0pYuxmsxl8YM9hng7bxH0MmlZQm6PD7YkEyCBqCcpEiXAqJ6AO/x8RhYM3
lqgBlNBntyAGsYGIckNeEsYiYeeIpo1aIabz8GhKKN4RA2QRCP+vbVahk2XzFhCU62cZIsFhYggS
VbFUNeEhK7CgKjxi74pFiSLjIcvizzwc+1vlZwjqvhm5GKpZkXw+eTmTTbYxd/XduAtpCrUGDcw+

wWAy+0WMQXs3rBMkUlciosszbpWb9Mk9ReWk6hBRBadVhGTh3pNt+Rk79olUpqewKLbCGudlK7cS
lBJrlVJbQMNSwcll9Uxx56GbKYCa8iNVgKFRkUOuuglg5tBYbgiiqy+X0uqr4R1D6MXIhLWboG6G
k+KK97UUB9FXcgyoypVisCVutE3IwdJMhjWwGvK0IYVnbFUVFQRa4BgdIfUvotIYwpAO6z5DUFNq
FDiBP+LuSKcKEgjObPRA
====

なんでJNI経由なの?
matrix部分のループ抜き出して比べるようにしないといけないような。
C++/Javaそれぞれのコードで比較すれば?わざわざJNI使わなくても。

TXはL1キャッシュ内で収まるから高速なんじゃなかったっけ
トリップ検索は特殊用途だといわれればそれまでだけど

ついでに、比較するのならこの場合はawt/SwingよりもSWTの方が良いような。

で？キャッシュミスでVMが隠れるの？
はっきり言って、意味が分からんのだが。

こんなもん貼って、キャッシュミスが「わざわざ」多い例を挙げると、
なぜVMをユーザーが意識しなくって良い原因がキャッシュミスのせいになると？

微妙にスレ違いだが、とりあえずこれを見て欲しい。
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=csharp
Monoでさえ、これだけの結果を残している。
Win上だったらC#の圧勝だろう。
Linuxは軽くて安定していることを売りにしている。
速いJavaと軽いC#ならば、C#を選んで然るべきなのかもしれない。

>>617
>微妙にスレ違いだが
流れからして、最早殆どがｽﾚ違い。

てゆうかここ流行りそうなんだけど

>>619
それ随分前 (>>22) に聞いた。で？

>>617

はいはい病院に戻りましょうね。ボクちゃん。

言い方が悪かったみたいでごめんなさい。

>>603
おまえがな。

糞遅いGCC/G++に負けているのだから、
マイクロソフトのVCやインテルのICCに、
勝てるわけがない。

いくつかのベンチマークを見た限りだと、
VCは、かなり速い部類に入るよ。

>>624
kwsk

窓厨だからそうっとしておいてやれ

>>624

メモリ・ウォールという言葉を知っているか?
知らなければ、ちょっとググって勉強したほうがいい。

キャッシュミス時のペナルティの比率は、
既に書いているように、50%前後。
1分の処理なら、30秒がキャッシュミス。

だから、VMは無視していいんだよ。比較スンナ！ボュケ！

>>613
C++が不利になるだけだからこれでさえC++の方が速ければいいんじゃね？

600レス以上もかけて不毛な会話を続けているお前らに笑った

Windowsなんて吹っ飛んじまえ!
UNIX系OS最強www
Windowsのマルチユーザー機能は
・わかりにくい
・複雑
・さらにもろい
Windowsのパーミッション制御は
・わかりにくい
・複雑
・LinuxでCDブートさせれば簡単に突破wwww

つまり
Windowsは糞。みんなLinuxに移ろうぜ!
もはやOSを買う時代は終わった。Linuxなら0円から!
あなたの今お使いのPCで使えます。
Windowsを抹消せよ!!!!!!!!!!!

ええい、何故JNodeを出さんのだ

>630
Linuxのデスクトップは糞。あんなのよく使えるよな。

Windowsにイヤな思い出でもあるんだろ

>630
(ﾉ∀｀)ｱﾁｬｰ

http://www.itmedia.co.jp/enterprise/0403/06/epn01.html

　このACLは、サンのSolarisなど商用UNIX、マイクロソフトのWindows NT以降では標準で利用可能で、
エンタープライズ分野では欠かせない機能の一つとなっている。Linuxにおいては、カーネル2.4系では
標準でACLが実装されていなかったため、Linuxがエンタープライズ分野に向かない理由の一つとして
挙げられることもあった。しかし、カーネル2.6においてパッチがカーネルツリーに取り込まれたことで、
何も意識せずにACLの恩恵を受けられる時代がようやく到来しつつある。

Java厨はJava vs C++の争いに物足りなくなって、窓厨 vs Linux厨の
戦いを始めたか。バカ過ぎてワロス

× Java厨はJava vs C++の争いに物足りなくなって、
○ Java厨はJava vs C++の争いに勝てそうになくなったので、

　　　　　　　　　　 ,. -‐'''''''''''''''""¨¨¨ヽ
　　　　　　 　 　 (.＿＿_,,,,,,,,........ -ｧァﾌ|
　　　 　 　 　 　 |i i　|　　　　 }!　}} /／|
　　　　　　 　 　 |l､　{　　　　j}　/,,ｨ//｜　　　あ…ありのまま　今　起こった事をはなすにょろ！
　　　　　　　　　 i|:　!ヾ､_____ﾉ／ u {:}/｜
　　　　　　　　　//, '/u 　　　 ヽﾊ 　､　ヽ　　　　
　　　　　　　　 〃 {_{＼　　　 ／ﾘ| ｌ │ i|
　　　　　　　　 ﾚ!小ｌ●　　 u ● 从　|、i|　　　な…何を言っているのか　わかないかも！と思うけど
　　　　　　　 　 ヽ|l⊃　､_,､_,　⊂⊃　|ﾉ│　　　わたしも何がおきたのかわからなかったにょろ！
　 　 　 　 /⌒ヽ__|ﾍ　u　ゝ._）　　j /⌒i ! 　　　田辺さんが出張ってきてる とか 実は南さんが１番人気 だとか
　　　　　　＼ /:::::|　l＞,､ __,　イァ/　 /│　　　そんなチャチなもんじゃあ　断じてなかったにょろ！
.　　　　　 　 /:::::/|　|　ヾ:::|三/::{ﾍ､__∧ |　　めがっさ恐ろしいものの片鱗を味わったにょろ！
　　　　　　　｀ヽ< |　|　　ヾ∨:::/ヾ:::彡'　|


　　　　　　　｀ヽ< |　|　　ヾ∨:::/ヾ:::彡'　|

624も627も、そう主張するなら
証拠となるベンチマークの結果を出せ

【激遅】AppleGCC【絶望】
http://pc11.2ch.net/test/read.cgi/tech/1173267844/

AppleJavaはもっと激遅だろうな

　　　　　　　　　 /　　/　 //　　　　　　　　　 ヽ
　　　 　　　　 ／ !/　/　/ ! ! |　ｌ　　 ! ｌ ヽ　 ヽ.!ヽ、
　　　　 　 　/:::::: |彡l　/ /| l　ｌ　ｌ、　 ! ｌ l l 　ヽ! ::::',
　　　　　　cｈ:::::: F l ! ! /‐トl､ ｌ　lヽ,.-ｌ‐トｌ ｌ ｌミ| :::ｎb
　　　　　　||Nヽ:: |l　!ｌlN,:==:Nヽヽヽ ≦kN! ! !ﾆl ジ/||
　　　　　　||| ` ‐f!!ヽヽｲ{:::::ﾘ`　 ヽｲ{:::::ﾘ〉lｲ ﾄ/＝'　||
　　　　　　　　　 N |ヽ　｀¨´ 　 　　　｀¨´ ﾘlｌ ﾘ　　　　　　　　　
　　 　 　 　　 　　.l ﾄ|　　 　　　、,. 　 　 　!_| |　　╋╋　　　　　　
　　　　 　 　 　 　 ! !ヽ　　　　 )-　　　　ノ　!lｌ　　 　┃　　　　　　
　　　　　　　　　　 ヽ 　＞-ｒ‐､　　 ,. イ　　 /.　┏┓　 　╋╋　　　　
　　　　　　　　　　　 　 ,.ｒﾆ!　　!¨´　|ﾆヽ.　　 　　 ┃ 　 　　┃　　　　
　　　　　　　　　　　／.:r'´ｌ　　l　　　ヽ::...＼　　　　　　　┏┓　　
　　　　　　　　 ,.．'´!:::::::!r'‐､,..l、　　 /::::::::/ヽ、　　　　　　 ┃　　
　　　　　 ,.．' ´　　 ｌ:::;.r'　　ﾉ} }_____/::::::::/　　 ｀ヽ、
　　　　 /　　　 　 　!ん､,.､/ { {　　/::::::::/　　 　　　 ヽ、
　　　　/　　| ! 　 　 Ｙ´二ヽ_|~　 /::::::::/　　　　　　 　 l
　　　 /　　 | ヽ 　　 {　--､`! 　 /::::::::/　　　　　　　　 |

BootCampを使えば無問題
ttp://www.youtube.com/v/xUodVT4nA68

　　　　　　 　　 ｒ￣`-‐ '´￣￣＜￣,二ヽ
　　 　 　 　 　 　 ｼ~　／" ｀ヽ ヽ　`'、//
　　　　　　　　　//, '/　　　　 ヽﾊ 　､_Ｖヽ　　ネタスレ以外の何者でもあるまいにょろー
　　　　　　　　 〃 {_{｀ヽ　　　ノ ﾘ| ｌ │ i|
　　　　　　　　 ﾚ!小ｌ●　　　 ● 从　|、i|
　　　　　　　 　 ヽ|l⊃　､_,､_,　⊂⊃　|ﾉ│　
　 　 　 　 /⌒ヽ_ |ﾍ　　 ゝ._）　 　j /⌒i !
　　　　　　＼ /:::::|　l＞,､ __,　イァ/　 /│
.　　　　　 　 /:::::/|　|　ヾ:::|三/::{ﾍ､__∧ |

>>625
っSPEC

SPECにはGCCでの登録は稀少だな。
ということは、遅いってことだ。

Java厨って、
ttp://www.02.246.ne.jp/~torutk/softwarebp/zakki20030201.html
のように、VCより速いとか言ってるものの、VCの最適化を切って比較してるわけで、もうね・・・。

>>645
おまけに「C++の場合はvirtualメソッド」って書いてあるね。
全然公平じゃない比較ワロス

まさに >>508 を地で逝ってるわけか。

別に何でもやるつもりはないし

ところで、Windowsって
・システムのフォルダ構成が無茶苦茶、まず命名規則に統一性がない。
・dllなんてどこのフォルダにあっても同じものが何個あっても動いたりする
・ファイルの命名規則も無茶苦茶、しかも変数名みたいな名前ばかりで何の役割をしているのか直感的に分からない。
Windowsがウイルス被害が多い理由を「シェアNo1だから」という香具師が多い。
ウイルスの名前には、分かりやすい英単語を使っている場合が多い。
ウイルスの方をウイルスらしくなく、システムファイルの方がウイルスらしいのも原因だ。
WindowsよりむしろUNIXの方が、ディレクトリ構成が分かりやすいと思うがどうなんだろな。
システムファイル云々で言うと、○ac OS 9以前の○acOSが最も分かりやすい。(視覚的にユーザがシステムをカスタマイズしやすいということだ。）

言い忘れた
Windowsってインストーラに統一性がなく、どこにどのファイルがコピーされたかとか、レジストリ登録されたかとかがブラックボックスである。
アンインストールもブラックボックスの場合が多い。
○ac OSはその殆どが、アプリケーション本体もしくはフォルダをアプリケーションフォルダにコピーするだけで終わりだ。

>>646
Javaと比較するなら、virtualではないほうが、ズルってもんですよ。

>>649-650
スレ違い。

なぜそうなっているのか、わからないというのは、勉強不足の場合もある。

>>651
いや、そうではない。それに最適化もかかってないし、あの比較は公平ではない。

マカーは本当にアホばかりだな。

そういう意味で言ったんじゃないんだが

俺の書き込んだスレはなぜかその後書き込みが無くなってしばらくして覗くと落ちている。

>>656
その能力で、すべての糞ｽﾚを落として頂けませんでしょうか。

>>657
そういう意味で言ったんじゃないんだが

プログラムそのものの速さはC++のほうが早い
しかし開発期間まで含めるとJavaのほうが早い
これが結論

いいから早く証拠を持ってこいよ

お前らjavaするんじゃねえ！俺に任せとけ！

開発期間→納入するまで
プログラムそのものの速さ→稼動している間ひたすらリソースをロスし続ける

>>662
Javaは重さは、ファイルサイズ・消費メモリ・速度の三冠を
達成しているのがより問題を深刻にしているよな。

納入するまで→楽だよね
稼動している間ひたすらリソースをロスし続ける→知ったこっちゃ無いw

>>664
おまけにより高いマシンを売りつけることができるから
マージンも膨らんでウハウハｗ

そうしてみるとマカーは本当にアホばかりだな。

そしてとどめに「納入後にきちんと動かない」。
どうしようもない。

>>651
Javaでvirtualではない方にして比較すれば？
言語の優劣を比較するってそういうことなんだが。

そういうこと言うならJavaの動的な最適化を禁止、signal受け取れなくなる-serverも禁止にしないとズルってもんですよ。

誰かが実証コードを貼ればいい

構造的に同じになるようにしたときの比較なんじゃないの?
最適化くらいはかけても良いと思うけどね。
しかし10年前の記事に今頃突っ込んでいるというのも滑稽だ。

マルチプロセッサが標準になって長いけど、
C++/Javaともにランタイム面ではスレッド化ってどれくらい進んでるんだろ。

口がすっぱくなるほど言ってるが
言語の優劣を比較するスレではないのだが・・・・・

そうなんだよ。

vertualの有る無しや動的な最適化も含めて言語の優劣だろ

馬鹿ですか？

劣等感満載のC++厨はJavaに勝ちたい気持ちで一杯だから
ﾅﾆが何でもこういう話の展開に持って行きたがるんだろう
そしてこう書くとJava厨はC++厨を論破できないからどうのこうのとレスしてくるのミエミエ

もしくはJava厨は偉そうだとかんなんとか
単細胞なんだよなC++厨は

JavaがC++より実行速度が速くなる必要はない
同程度位になれば業務アプリの世界からはC++はほとんど駆逐できるだろう

そういうことを言うからC++厨がカチンときて無駄なレスが続くんじゃまいか

>>678
俺、C++厨だけど、少し前なら >>677 には同意してたよ。
まぁ、C#がブレイクした今となってはC#がその役を担ったとしても
Javaがそれを果たすことはないだろうが。
そして寧ろC#に駆逐されるのはJavaだけどｗ

>>675-676 は可哀想な人だな、ぐらいにしか思わん。

C++厨＝Javaに負けたくない
Java厨＝Javaに負けたくない

>>662
Javaにすることで開発費が安くなる分が、
Javaにすることでマシンが高くなる分を、
上まわっていればJavaにすべきだし、
下まわっていればJavaにすべきではない。

簡単な話でしょう。

>>668
virtualにしないのは、ベースクラスにキャストしない、ということで、あまりにナンセンス。

>>670
> マルチプロセッサが標準になって長いけど、
> C++/Javaともにランタイム面ではスレッド化ってどれくらい進んでるんだろ。

ランタイム面でスレッド化、というのが意味不明だが・・・

ランタイムライブラリの中身が、呼び出し側のスレッド1つに対して、
複数のスレッドを使うという意味なのであれば、「余計なお世話」だと思う。
ランタイムライブラリくらいだと、粒度が細かくなりすぎて、効率が悪い。

ウンコ共め

>>681
いいこと言うね

だからお前らjavaやるなって
俺が全部やってやるぜ！

そーいや、>>376はなんでC++のがでかかったの？

>>687
ソースが↓でDLできるから自分で確認してみたら？
ttp://www.7-zip.org/sdk.html
C++は詳しくないけどぱっとみて、
1,文字列の操作関係を自作している。
2,Ansi/UnicodeでC++は宣言を分けている。
3,関数のプロトタイプ宣言

という部分が容量食っている原因みたいに思える。
Javaのソースは1,2をStringクラスに投げてる。3に関してはJavaは不要。
stlのstringを使っていない理由は不明。

Javaなんて糞言語はC++に挫折した頭悪い連中がやる言語だよ。
バイトのオバチャンでさえバリバリソースを書くからねえ。

それは長所じゃないのか……？
その基準で行くとアセンブラの方が上になってしまう

アセンブラは最上級言語。
生産性を完全に犠牲にして実行速度・効率をトップに持ってきている。
まあ実行速度の方は今時のC言語の方が速い事が多いが。

いずれにしろJavaは完全に蚊帳の外。

ﾊｲﾊｲ
Javaは糞言語Javaは糞言語

アセンブラのどこが生産性低いんだ？
まさか、0からエディタで打ち込むとか考えてんじゃないだろうな？

そういう話は他でやってくれないか

>Javaと比較するなら、virtualではないほうが、ズルってもんですよ。

「俺シビックRだからお前のエボもツインターボ外して四駆止めないと卑怯だぞ。」
ってのと同じくらい哀れな言い訳。

>>689
上流設計なんてプログラマを挫折した頭悪い連中がやる仕事
管理職なんて技術者としてやっていけない連中がやる仕事

そういうわけで、
C++に挫折しない頭の良い連中は、
C++要員としてピラミッドの底辺に残しておいたほうがいいと判断され、
気がつくと、もうどうにもならない年齢になっている、と。

>>695
virtualと非virtualの比率をいくつぐらいにして・・・

という話をしろよ。

>>695
ドライバーの腕を競うのか
ハードの性能を競うかによって違うだろ

Java＝シビックR
C++＝デボネア

仮に、C++の中でインライン汗書いてSSE3叩きまくっても、
卑怯といわれる筋合いは無いね。汗も呼べる事も含めてC++の実力なのだから。

そうだな
C++ってスゲーな

ﾊｹﾞﾄﾞｰ

ってことはJavaでJNI使ったっていいわけだ
それもJavaの実力なのだから

やっぱJavaが最高だな

そりゃそうだろ

JNIで呼ぶ相手によっては自動的に敗北宣言とみなされますがねw

Javaの中の人って一人しかいないだろこのスレ

でたーｗ
C++厨って面白いなｗ

>>707
だってここはC++厨のおなにーすれだからな──────！！！

>>709
×C++厨のおなにーすれ
○Java厨のおなにーすれ

このスレはC++厨が必死でC++の良さを訴えるスレになりました

×このスレはC++厨が必死でC++の良さを訴えるスレになりました
○このスレはJava厨が必死でJavaの良さを訴えるが全部論破されるスレです

だからjavaは俺に任せとけって！

っていうか必死で訴える必要ないし

どう見てもJava厨必死だな

そうです！！
必死なんです！！

言い方が悪かったみたいでごめんなさい。

ウンコ共め

>>700
C++の標準規格にインラインアセンブラってふくまれてたっけか？
D言語には含まれてたような気もするが。

>>719
予約語asmとして含まれている。但しasm文の内部は処理系定義とされている。

処理系の豊富さも実力のうち

やっぱC++最強だな
Java厨涙目ｗｗｗｗｗｗｗｗ

そうだなC++最強だ
だ　が　つ　か　わ　ね　ぇ　！！

ここのC++厨って今どんなシステム作ってるんだ？

>>723
マカーは本当にアホばかりまで読んだ。

http://www.kmonos.net/alang/wnd/whats.ja.html
ネイティブコンパイルの利点としてよく上がるのが、動作速度が速いことです。
実際Dは "The Computer Language Shootout Benchmarks (CPU Time)" などでも最上位付近にいます。

Dなんかどうでもいいんじゃハゲ

D言語にも負けるJava厨涙目ﾜﾛｽｗｗｗｗｗ

で、
どんなシステム作ってんの？

>>729
ついに性能云々言わなくなったJava厨。敗北宣言ですな

どうみても

C++厨とJava厨のホモすれです

本当にありがとうございました

オレは最初から言ってないけどねｗ
他の人は知らんが

C++なんてどうせデバイスドライバーとかしょぼい業務アプリとかくらいしか使い道あるまい

>>733
あなたはそう思ってるんですね？
C++の方が給料いいんですよ。

仕事は小さくて少ないけど？

あとはMFCとか使ってグチャグチャのWindowsアプリとか？

難しくて人手が足りないから給料が高いんじゃ？
ＰＧがあまりまくってバイトにまでコードを書かせるJavaじゃ
安くなっても仕方ないよな

デバドラはむしろCじゃね

OSがJavaで書かれた話は聞いた事がないな

Javaの場合はプログラマーとしては安いよねー当然
以前からいってるけど、言語の1つであるC++の立場と違って
Javaの言語仕様の部分はプラットフォームの一部だからねー
比較したってしょうがないのにC++厨ってどうしてもJavaに勝ちたいんだよねー

>>738
数年前にデバイスドライバーかいてる奴が、最近はC++だとかいってたよ

>>739
JavaでOS書く理由はなんですか？

給料が安いJava＝安い言語
給料が高いC++＝高い言語

つまり、同じアプリ作っても安く作れるわけだからC++よりJavaの需要の方が多くなるわけで
今、C++の技術者が不足しているから単価が高いといったところで、仕事がなくなってくれば
ホントウに優秀で運のいい奴は生き残れるけど、普通のC++厨は淘汰されてしまうんだよねー

>>742
どう考えてもＰＧが多すぎるJava厨の淘汰の方が先であろう

簡単に覚えられる分JavaのPGは多いよね
しかし、その分規模の大きな開発もあるからなー
案件の量と規模から言えば溢れかえるほどいるわけではないけどね

派遣社員にプログラムを書かせて平気なJava業界は信頼性の面から見ても
心配が残る。

だれかこいつを助けてやってください
http://pc11.2ch.net/test/read.cgi/tech/1164073111/785

>>746
スレ違い

>>734
思うのは自由だよな、と思う。

>>745
ホントにわかってないなC++厨ってｗ
プログラマの技術に期待するような開発ほど危ういんだよ

お山の大将気取って名ｗ

合同会社を設立する際の現物出資にローン未完の自動車等を含める事は出来ますか

板違いって言うかそれってある意味資本じゃなくて負債の持込だよねw

JNIでネィティブ呼べば速いよ
↑Java意味ねーw

結局Javaはクライアントアプリには向いていないのか？

現状ではそうだろうなー

>>753
いや
それも含めてJavaだってことで

C#で主要なAPIを書く事すらVistaでは頓挫したからな
似たようなJavaでUNIXのAPIなんか書かれた日にはUNIXやめるわｗ

馬鹿ですか？
なんでJavaでUNIXのAPIかくんだよ
C++厨ってC++以外のこと全然わかってないんだな

それだけ集中しないと習得できない言語なんだろ？

何だ、この糞スレの伸びようは？
いつまで経っても同じことのどうどうめぐり

今頃気が付いたかｗ
ネタスレだといっとろうが

ここ数日このスレ眺めているけどここって女性週刊誌みたいな場所なんだな

暇な奴

結論はJavaはカス言語だという事

>>758
JavaでOSが書けない事を自白したんですね

だからなに？

Java厨涙目ｗｗｗｗｗ

それだけじゃないと思うよ

それだけじゃないなら何？これだからJava厨は馬鹿だと言われる

C++厨ってガチで厨なんかなｗ
いってる事が子供丸出しｗ

いや、そうではない。

Javaでは一生無理でしょうw

いままでも、なんどとなく挑戦してきたが、すべて失敗に終わった

儲かる言語、ライブラリが正義。

javaの高速化に関するスレがこのスレだけだから困る

C++で高速化を追求していたら心筋梗塞になりました

Javaにそれほどの高速化が求められてるか疑問。
コンシューマのゲーム業界とかがC/C++オンリーなのは理解できるが、Javaの業務アプリの世界でそれ程の実行速度の追求はいらんでしょ。

Javaで速度欲しいときってのはたいがいCPU数強化とかServletをロードバランサで分割って話だけですむからなぁ。
アルゴリズムとプロファイリングで徹底チューニングしてどうするこうするってのが必要なところで使うかって言われたら使わないだろうに。

JavaにしろC++にしろ得意な領分があって、それぞれ棲み分けが行われているのに、
どちらか一方だけを絶賛するような原理主義に落ちるってのは問題じゃないのかね。

>>774
実質隔離スレとしか機能してないけどな

OSを100% pure Javaで作れというのはアレだと思うが、
Javaに特化したOSというのは、あってもいいんじゃない?
C言語向けのOSの上に、JavaVMを乗っけるよりもさ。

JNodeでは物足りませんかそうですか…

>>779
それに関しちゃJNodeってプロダクトがある。
http://www.jnode.org/

JavaVMまでJavaで作る必要はないと思う。

>>777
それはC++厨がわけのわからん対抗意識を持ってこのスレに書き込んでいるからそう見えるんであって
このスレ自体はJavaのパフォーマンスに焦点を当てているだけでJavaマンセーなスレではない

Javaで高速化を追求していたら脳梗塞になりまし

気の毒にな

JavaVMまでJavaで作る必要はないと思う。

ネィティブ言語に対する敗北宣言とみなしてOK？

ﾊｲﾊｲ
OKですよ

Javaはレスポンスよりネットワークのスループットに特化した言語
また、そこでしかいきられない

ネットワークだと、何気に待てちゃう
例えば、ああ回線が不安定なのかなとかで

それが、デスクトップでのレスポンスだと、2秒も3秒も待たされると
何かおかしいとすぐ思われちゃう

>>788
そうそうw
いいたいことなんかわかる
そこに付け込んだ言語なんだよねw

だから、Java プログラマは未熟な奴が多い
いつまでたってもクライアントのお情け（この場合、クライアントが無駄に待つという行為）
に依存してる

>>クライアントのお情

PCの性能もw
PCの性能があがれば、Javaも問題なくなるというやついるけど
それは、C++も同じ条件で、同じように早くなる

よって、いつまでたっても、差が縮まらない

という話は何度もループしてます

じゃあ、結論のようだね

javaはチューニングの方法もわずかしかないからな
たかが知れてるし
プログラマによって、できが大きく変わるということもほとんどない
メリットなのかデメリットなかはわからないがw
C++だと、プログラマによって、そのできが大きく違ってきたりする

プログラマには、面白みのない言語
でも、一番無難な言語
比べられることもないから
比べられたとしても大差ないし

でも最近は、チューニングに躍起になってるらしいよ
今まで、遅い遅いいわれてきたから

>>795
＞面白みのない言語

はぁ？ｗ
頭の悪い単細胞なC++厨には理解できないんだろうねｗ
言語を使いこなすのに躍起になるのが面白いだとか、複雑な言語の機能を使いこなせるから
頭が良いだとか、その程度のことしか言えないチンケな使い捨てプログラマーにはJavaの面白さはわかるまい

図星をつかれたな

コードコンテストなど上位に名を連ねてるやつらで、javaを主に
使う奴なんて皆無なのは事実

そりゃだって、C++みたいに複雑ではないから、そのぶん面白みに欠けるのは当然じゃないの？ｗ
言い換えれば洗練されててエレガントな言語仕様だということなんだけどねｗ

>>799
だからさー・・・・
っていうか、ホントに馬鹿だよねー

納得してくれたようで、なにより

で、未熟なプログラマばかりという結論に至るわけですなw

ﾊｲﾊｲ
C++厨は頭が良くて経験豊富な熟練プログラマばかりでつね

当然だよ、できそこないのプログラマばかり見てきたからねw

よくこんなんで、なーんての見てきたらw
だから、一番無難な言語だといったろう

あんあ低級でもプログラマとして稼げるんだから

では難解なC++言語をマンセーするスレでも立ててマンセーしなさいな
結局、何かと比較してC++が優れている事を確認していないと自信が持てない
哀れなC++厨ってことじゃねーの？

でも、Javaプログラマって、自分でもできそこないって悟ってる奴多いから
いいんじゃないの

C++なんかwin以外ほとんど使われて無いじゃん。

なん関係が？
そう熱くなりなさんなって
阿呆でも稼げるんだから、すごいじゃない

>>786
適材適所

俺も、とってり早く稼ぎたいなら、Java覚えなって
色んな人にいってるw

でも、本当の意味でJavaを使いこなすのはC++を使いこなすより難しいんだよｗ

>>788
文章がメチャクチャ。

クライアントから見て、ネットワークの遅延にJavaの糞重さが隠れても、なぁ。
サーバから見たら、スループットは酷く悪いということになる。

>>812
Javaなんか使いこなしても、大差ないといったろうw

ハイリスク、ノーリターンだよ

ハイリスク、ノータリンかも

Javaなんか、適当にやって適当に稼ぐのが一番

また、そんなのしかいないしね、Java周辺には

>>812
言語でしかないC++と比較するなら、Javaは狭義の意味で使わないと。
つまり、JDK1.0の頃のJavaの文法を解説する本の内容だけでいかないと。

このスレを見ていても思うのだが、

誰かを卑下することで、自分が相対的に高い位置にいることを確認し、安心したいという人

というのは、ほんとうに可哀想だ。






そういう自分も、そういう可哀想な人を卑下しているわけだが・・・まぁいいか。

逆だよ
「本当の意味」といっとろうが
だからC++厨にプログラム書かせるとろくなコード書かないんだよ

>>817
俺が言ったことを言い直してるだけじゃねーかｗ

>>818
まあ、C++はプログラマのできの差が激しいからね
逆にJavaは総じて平凡

だから、本当の意味なんて、へそで茶を沸かすくらいナンセンス

>>818
「本当の意味」なんて書かずに「広義の意味」と書けばいいじゃないか。

でもね、
広義の意味のJavaを使いこなす
ことと比較するなら、
C++を使いこなすのだって言語だけでなく、その周りも含むことになるんだよ。

JavaもC++も、言語だけじゃ何もできない。

本当の意味で、Javaを
使いこなしてる奴なんて見たことないw

見た事ないな
C++もしかりだが

偏差値的にいうと

C++は、偏差値70から40までだね
Javaは、50らへんをうろちょろ

平均は45くらいだろ？C++は

トップコーダーでJavaを主に使うやつなんて皆無だよ

>>821
＞C++を使いこなすのだって言語だけでなく、その周りも含むことになるんだよ。

・・・
あたりまえだろ？

プログラマでは、一番底辺の部類だろ、Javaは

いくらなんでも、これを否定する奴いないってw

ばかでも稼げる素晴らしい言語なのは確か

スレと関係ない話ばかり…
別スレ立てれ

>>826
トップコーダーって？ｗ
っていうかプログラマーマンセーなやつってガキンチョばかりかココはｗ
さもなくば、４０にもなってプログラマーやってる凄腕の貧乏人か？

４０代のC++プログラマーって鬱陶しいよなー流石に

なんだ、話が盛り上がってると思ったら
Java使いがふぁっぴょんしてんのか

おい、ストレス発散もほどほどにな

俺も職場じゃJavaプログラマいじめて、ストレス発散してるけどさ

Javaはいじめられキャラがよく似合うからな

C++邪魔
所詮旧世代言語を拡張し続けてるだけ

>>832-833
４０代貧乏プログラマー乙

　 　 　　　＿＿＿_
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼　　　　　>>832-833
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼ 　＜　明日から
　 |　　　　 （__人__）　　　　|　　　　また若いSEにあごで使われる仕事が
　 ＼　　 　 ｀ ⌒´ 　 　 ／　　　　　始まるよ

いちおうjavaプログラマでも、反発はおぼえるのねw

できそこないでありたくないという証拠かなw

>>837
よう
低反発マット

>>826
一部の例外を持ちだすなよ。

>>827
「その周り」は、JavaとC++でも同じ。
言語によって周りは違わない。

>>830
この業界、
プログラムを自分で書く技術なんて身につけても、
人に使われる側にしかなれないからな。

人を使う側になるためには、
プログラムを他人に書かせる技術を身につけないとな。

>>832
俺の職場にも、そういう人間がいるよ。

口を開けば「JavaはC++に挫折した馬鹿がやる言語」と吹聴して回ってるが、
無駄にC++で頑張ったり、
広く使われているライブラリを使わずに、個人的に作った自前ライブラリを使ってコードを書くので、
周囲がとっても迷惑してる。
人の言うことをちっとも聞かないので、どうにもならん。

Java厨のささやかな抵抗でした

>>841
お疲れ様です

では、本題

なぜ、JavaはC++より遅いのか

低俗なプログラマしかいないからって結論でてるじゃない

>>828

VB、スクリプト系、Webデザイン

>>「その周り」は、JavaとC++でも同じ。
>>言語によって周りは違わない。

JNIで、C/C++で書かれたかれたシステムコード呼んで速いだろとでも言う気ですかw

GCってさ構文がシンメトリーでなくなるじゃん。俺的には論外？みたいな。

で、それと速度とどういう関係が？

>>847
おまえはauto変数にも解放文を求めてるのか・・・

>>1さん

そんなもん、一生でてこない

遅くても問題ないところでしか使われないからね

>>843
> なぜ、JavaはC++より遅いのか

Javaに不利なベンチマークで比較しているから。



と言うと、負け惜しみのようだが、
ベンチマークって意外と難しいのよ。

>>846
いんや。

同じものを作るのに、
Javaを使っても使わなくても、
広範囲にわたる知識と経験が必要だってこと。


>>847
どういうこと?

スコープの終わりで、メモリを解放するコードがないのが、気持ち悪いの?
C++でもデストラクタでメモリを解放するクラスを使ったら、同じことになるよ。

void hoge(void)
{





こんな感じ

なにその現代絵画

C++に合わせるんじゃなくて
Javaが得意な処理をより高速化する方向で考えればいいんじゃないか

どの本だったかな。

不可解なバグに悩むことになるので、
どうしても必要な場合を除き、
freeはしないほうがよい

というようなことが書いてあったのは。
短時間で終了するプロセスをポコポコとforkするunix界では、そういうものらしいな。

fj.lang.c++

つかかんけーないし

Javaの時代は終わった。
既にRuby on Railsの時代。

Javaと比較するなら、C++のクラスのメンバ関数はvirtualにしないと。

なにしろ、C++でJava相当のことをするには、
例えばWindowsのCOMなどのような仕掛けを使うわけで、
ということは、クラスのメンバ関数はvirtualになるのだから。

COMなどの仕掛けを使わずに、つまり、非virtualなメンバ関数を使った場合、
それが例えpublicメンバであろうとも、
オブジェクトへのポインタを受け取った側が、そのオブジェクトのメソッドを呼びたくても、
呼ぶべき関数のアドレスがわからないのですから。

JNIで全てアセンブラで組んだモジュールに丸投げ
C++の手は借りていませんよ(￣ー￣)

まだ糞Java厨はゴタゴタ抜かしてんのか。
もう敗北は喫した事が決定してるのにな。

JNI呼ぶ経路に一切C/C++の介在がない事を証明出来たらな。

JavaがC++より早いなんていうやからがいないだけ安心したw

そういうやからは、おからだ！

>>862
それでも結局ネィチブコードに白旗揚げるわけだろ

>どういう技術を駆使したり、どういうことをすればいいか考える

>>1のこの設問に対して、一向に案が出てこないとは、なんとる惨状

だめぽ

だから、ジャバグラマにそんなできるやついないってのw

>ジャバグラマ

不謹慎にも笑ってしまった

今や富士通、NEC、日立、NTTデータといったところは、技術力よりもサービス重視のため、「要は客からぼったくってなんぼ」の世界。
プログラマは、いくら技術をもっていても活かすことができないのが落ちですね。
1億円の仕事を一次請け企業に9000万円で丸投げ。そんな企業が、当社は技術力が高いだの、資格保有者が多いだのって・・・
どうよ？

>>1は愚問の類ですね^^;

すでに他の言語でプログラムを書ける人間にとって、
Javaは文法を理解すれば、小規模で他所のライブラリなどを使わないプログラムを書くことは可能だ。
しかし、C++は文法を理解しただけでは、それすらも危うい。

たとえば、C++の文法解説の本には、
ttp://slashdot.jp/~bnez/journal/274056
のような話は書かれていない。

親切な本なら、
基本的にはdeleteは外側から行うべきで、
どうしても内側から行う必要がある場合には、
いくつか考慮する点があるが、本書では扱わない。
参考書「ほげほげ」を読んでほしい。
というような注意書をするかもしれないが。

これはどうだろう

Javaでカリカリにチューニングしたとすると（この場合、生産性は無視して）、
C++なみの速度をだすことができるか？
それとも、言語の限界として、やはり無理なのか？

>>873
それがどうした。スレ違い。ここはJavaでC++並みの速度を
いかにして出すかについて書くスレです。

>>874
結局同じじゃねえの

たとえできたとしても、このスレで案がでてくることはないだろうし
誰も実装して証明できないため、空論になってしまう

ま、PCの性能の高速化を待つしかないねw

>>877
そしたら自動的に他の言語も速くなるわけだがｗ

>>878
まあねw
うっさい

つまりゴタゴタ言っている奴等ほど
「結局言語じゃなくて機械語の実行速度だろｗｗｗﾜﾛｽｗｗ」
と言ってるでFA?

みんなウンコってことでFA

Javaがウンコである事は間違いない

>>880を踏まえれば、C++もウンコってことだな

つーかC++がウンコだからJavaが出来たわけで

>>884
でも、できたのはC++よりもウンコな言語ｗ

しかしウンコにならないように作ったはずのJavaも結局はウンコだったわけで

ウンコC++マンセーな奴から見たら
他の言語はみんなウンコに見えるんだろうな

C++を習得するための労力が報われなかったウサ晴らしに
このスレで書き込んでいる哀れなC++厨乙

だいたいうんこ色のcoffee

　 　 　　　＿＿＿_
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼　　　　　
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼ 　＜　明日からまた
　 |　　　　 （__人__）　　　　|　　　　若いSEにあごでこき使われる仕事が
　 ＼　　 　 ｀ ⌒´ 　 　 ／　　　　　始まるよ

　　　40代C++プログラマー

http://www.sra.co.jp/public/doc/GSletter/vol.27/java/java.html

＞ＪＩＴを使えば実行時間はだいぶ速くなるとは言え、C++にはまだまだ及ばないようです。

＞このサンプルは小さな例なので、JITありとなしで起動にかかる時間にほとんど
＞差はありませんが、Swingを使った大規模なアプリケーションなどではJITを使った方が
＞極端に起動時間がかかるようになります。（このサンプルにも数字のマジックが使われて
＞いまして、ループの回数を100回ではなく10回以下にすると、JITなしよりもJITありの方が
＞実行時間がかかるようになります）

JavaのJITはダメダメですねｗｗｗ

つーかそのドキュメント古くねｗ

>>893
そう思うならお前が新しいソースのリンクを貼れよ

>>892
てかJITの特性述べてるだけじゃね？

ジャワコーヒーは好きなんだけどね

そのソースをJava７とかでコンパイルして実行したらどうなの？
C++も一番早いお勧めの処理系使って実行してさ

ネイティブにコンパイル済みの言語と比べる方が頭おかしくね？
tccでコード埋め込んで、JITっぽくしたC++と比較するとかしないと意味なくね？

>>897
そんな愚問、しないで><

しかしJava7とかどんどんバージョンが上がっていくともはやC#と
区別が付かなくなってくるな

俺なんてJavaとC++の区別つかないんだぜ・・・

名前が違う

>>901
それはお前の頭がヘボいだけだから。

おまいらバカですか？ｗ
実用的な状況で比較しないととアカンでしょ
JavaがC++より実行速度が速いとか夢見てる奴は論外だが
結果がでたらそこからJavaコードをチューニングしてけばいいんじゃん

>>904
＞Javaコードをチューニング

具体的にお願いします。

多重継承ができないJavaは糞言語です

JITコンパイラについては、設計の最初から取り入れられているC#の方が
秀逸だなあ。
起動時に特に重いと感じないし。全体的にちょっともっさりしている点は
Javaに似ている。

>>901
そんなもんだよ

>>906
多重継承ｲﾗﾈ
何でもかんでも継承してわけわからんクラス作る奴には困った事だろうけど

>>909
＞何でもかんでも継承してわけわからんクラス作る奴

お前みたいなカスと一緒にすんな

多重継承が必要な場合＝設計がクソ

>>906,910のようなウンコが糞設計できないようにするためにも
多重継承は不要

>>911>>912
さすがJava厨
多重設計がどうしても必要になる場合を知らんようだね
知らないのに糞とか言うのはおかしい

まあJavaには多重継承がないので想像の範囲内でしか
答えられないだろうが

多重設計ってなに？

>>913
アホ丸出し〜ｗ
設計が糞だからそうなるんだYO

ここのC++厨はみなコーダーだからクラス設計なんかしないんだろ？

>>915
馬鹿はお前。Javaばっかり使ってるから頭が堅くなってるようだな

　 　 　　　＿＿＿_
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼　　　　　
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼ 　＜　明日からまた
　 |　　　　 （__人__）　　　　|　　　　若いSEが作ったクラス設計をもとにコーディングする仕事が
　 ＼　　 　 ｀ ⌒´ 　 　 ／　　　　　始まるよ

　　　40代C++プログラマー

多重継承がどうしても必要な場合ってﾅｰに？
それは多重継承じゃなければ解決できない事なの？

デリゲートとかするより多重継承したほうが簡単だからって事だろ？
頭悪いからさーｗ

>>917
逆だろ？ｗ
複雑なC++を覚えるのに一生懸命でクラス設計方法論とかの学習に時間を費やせないから
まともなクラス設計が出来ないんじゃねーかｗ

>>920
C++にデリゲートなんかないんですけど？あるのは関数ポインタだけですが何か？

>>922
はあああああああああああああああああ？ｗｗｗｗｗｗ
ちょ─────────────バカはっけ────────んｗｗｗｗｗ

>>923
C++にデリゲートがあるなら説明してみろやカス。

関数ポインタや仮想関数を使わずにな。

>>922
デザインパターンだっけか？ にあるデリゲートでしょ。他のクラスに処理を委譲する奴。
C#とかにある奴じゃなくて。

っていうかデリゲートの意味わかって使ってんの？
馬鹿じゃねーのｗｗｗｗ
ちょっとはC++の使いかた以外のことも考えないとアカンよｗｗｗｗｗｗ

ついにC++厨が馬脚を現したか
これだからC++厨は使えねーっていってるんだよ

>>925
GOFだとAdapterパターンの一種として紹介されてんだっけか？

>>925-927
委譲という言葉で理解していますが何か？デリゲートはC#の予約語
として区別して覚えてるんだよ。

>>929
多重継承と同じ場所に出てきたら誤解のしようがないと思うが。

そもそも委譲ってデリゲートの訳語だし。

>>929
それはただのおまえのMyルールだろうがｗ

>>930
委譲という意味でデリゲートという言葉を使った事は今まで一度もない。

>>932
英語の技術書とか読まないんか？

>>931
仕方がなかろう。お前らとは住む環境が違いすぎる。

>>934
本人はともかく、まわりにデザパタできる人も居ない環境なのか……

環境の所為にするのか。こいつダメだな

デリゲートというOOP用語を知らないからという理由だけで鬼の首を
取ったように喜んじゃうJava厨って・・・・

これだから低脳は困る。

> デリゲートというOOP用語
OOP用語？

> "OOP用語" の検索結果 約 491 件中 1 - 10 件目 (0.18 秒)

JAVA ファフナー
C# Rahxephon
C++ エヴァ

40代C++厨は、その歳になるまで「言語」にのみ焦点を当てて勉強してきたため
「言語」については詳しいが実用的なプログラム開発は出来ないウンコちゃんで
現場ではウザがられてて誰からも相手にされないから、２ｃｈでウサ晴らししてる
可愛そうな奴だという事が判明して胸が痛くなったよ

> 「言語」については詳しいが
これも怪しいよーな

とりあえずそういうことにしてやろうよ

現実

COBOL＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞その他

>>941-942
言語自体の話題をしてる時にそういう話題にもってくるのは敗北宣言以外のなにものでも
ないんだが、敗北宣言なら敗北宣言でせめてもうちょっと潔さをみせてくれんか？

Java中の頭の中はデザパタしかないんだな
(′･ω･)ｶﾜｲｿｽ

>>946
ところで >>919 が聞いてるけど、interface の多重継承じゃなくて
実装の多重継承が必須になるって具体的にどーゆーケース？

interfaceの多重継承ならJavaでもできるし。

>>947
D&E読め

>>945
それはお前の敗北宣言か？ｗｗｗ

>>948
そんな事いわずに教えてよ。

>>945
だからいったろ？
Javaを本当に使いこなすのは難しいってｗ
言語使用だけ見てるから簡単に見えるんだよ
お馬鹿さぁ〜んｗｗ

>>945
頭の悪いスレ違い40代C++コーダーは逝ってよし

それにしても見事に池沼隔離スレとして機能してんなぁ。

C++ウンコちゃんはC++関連スレに引き取っていただきたいものだ

>>954
いや、C++関連スレも嫌がると思う。

>>947
C++の標準ライブラリでは、
読み取り専用ストリームのクラスbasic_istream<>と
書き込み専用ストリームのクラスbasic_ostream<>から
読み書き両用ストリームのクラスbasic_iostream<>が派生している。

>>956
それinterfaceの多重継承で不可能だとは思えんけど。

ってかそういうが糞設計というんだよハゲ

>>958は956へのレス

まぁ、JavaもInputStreamとOutputStreamがclassになってて
interfaceじゃなかったりするけどさー。

java.nio.channelsとかDataInput/DataOutput使わないといけない。

STLの設計者が958のうん百倍頭が良いのは事実

>>956
ワザワザC++の糞っぷりを披露していただきましてｱﾘｶﾞﾄｳｺﾞｻﾞｲﾏｽ。

はいはい
ドングリの背比べドングリの背比べ

>>961
Javaを設計してる奴らも少なくともおまいよりは1億倍は頭がいいと思うよｗ

多重継承は危険→C++は劣っている
なんつー暴言吐く阿呆もいるのね。
なーもわかっとらんクセしやがって。
包丁職人は殺人の片棒担いどるっちゅーんかい。

>>961
iostream作ったのってSTLの設計者と同じだっけか？
STLってSGIの人じゃなかったっけ？

http://www.s34.co.jp/cpptechdoc/article/cppvsjava1/index.html
ここでも読めや。多重継承が使えないとたちまち困る場面があるっちゅうねん。

>>965
ばーかばーかｗｗ

>>968
Java厨はずいぶん沸点の低い頭してるな。もうファビョってるｗｗ

>>967
全然多重継承必須じゃないと思うけど。多少手間がかかるだけで。
おまけにIDEのサポートがあれば騒ぐほどの手間じゃないし。

>>967
ばーかばーかｗｗｗ

>>969
そりゃおまえだろｗｗ
レス越しに真っ赤中をガメに浮かぶぜｗ
今日は寝れねーなｗ

>>970
これは簡単な例であって、規模が膨れたらそれでも手間かけるのか？
馬鹿じゃん。

>>957
basic_[io]streamがやっていることは書式付入出力の実装。
実際の入出力は、メンバとして持っているバッファクラスのオブジェクトへ任せている。
そのバッファクラスの名はbasic_streambufで、読み書き共用。

>>967の例は、D&Eにも似たような例が載っているけど、
Strategyパターンだと言われればそれまでだと思う。

Strategyだというのは当然Javaのインタフェース実装版のことね

>>973
手作業でやるなら手間だろうけど、IDE使えばボタン一発……

>>973
っていうか>>967はC++厨が安易にクラス設計をしていろんな責務を
1つのクラスに集約してしまう傾向があることを示す、アンチパターンの説明にしか見えんがｗ

というわけで多重継承は単一継承とデザパタで代用できるわけだが
何か他に言い残すことはあるか？

>>978
できんできん。現場で同じせりふ吐いてみろや。
ぬっ殺されるぞ。

>>979
そんな糞現場にはいないからｗ

>>979
凄い現場で働いてるんだなぁ…… がんばれデジｄ（ry

>>979
ここは現場じゃないし、技術的に可能であるならば俺はいいとおもうんだが
ちょっと屋上こいや

>>980
だから最初に住む世界か違うと言ったろう。
あ、給料も段違いだけどな。

>>983
かわいそうに……

>>983
そうだな
40代C++貧乏コーダーちゃん♪

>>984-985
俺一人でお前らの3倍は稼いでると思う。

>>986
うんうん。凄いねー

>>982
技術的に可能という事と、現場で通用してしかも困らないという事とは
だいぶ違うと思うんだが。

>>986
大丈夫
想像するのは勝手だし、きっとドカタは月給換算すれば高給取りだよ

がんばれ・・・

ATLなんか多重継承を活用しているという印象は受けるけど、
それはたまたまC++が多重継承を使えたから、使ったという感じがする。

つまり多重継承ができければ、まあ967みたいな設計になっただろうし、
それで不自然な設計になったとも思えない。

>>989
土方ＰＧはJava。派遣社員で間に合うような土方現場とは違う

>>991
うんうん。凄い現場で働いてる人は言う事がちがうねー

インターフェイスがある時点で多重継承禁止が破綻していた事はバレバレなわけだが

>>993
いや、Javaのは実装の多重継承禁止だし。

馬鹿発言またｷﾀｺﾚ

JavaはC++と同じく多重継承を取り入れようとして、技術的問題点から
取り入れるのを諦めたと聞いた事がある。

その名残がinterface。