06/08/29 10:56:44
>>710
アメリカにいけば著名人ですらそうだぞ。
I thinkI thinkI thinkI thinkI thinkI thinkI think
ア イ シ ン ク ッ ！
だ。
論文でもそうだ。さもないと他人の意見をパクった韓国人や中国人
と同等に扱われる。
724:デフォルトの名無しさん
06/08/29 11:00:47
>>723
猿真似は日本人のお家芸。
725:デフォルトの名無しさん
06/08/29 11:02:47
>>711
Flashは4まではJavaのほうが圧倒的に早かった。
今はしらない。
Javaと違い、Flashでできることは限られている。
あれは時系列で開発してゆくからな。
Javaとは畑も開発スタイルも違う。
Flashは簡単なアニメーションなら高速で処理できる。
だが、三角関数や対数関数、指数関数などを徹底的に
駆使した幾何学模様の描画はどうだろう。
是非とも検証してみてくれ。
ActionScriptを使ってちゃんと三角関数などを使って計算してな。
726:デフォルトの名無しさん
06/08/29 11:05:35
>>714
そのEJBのバージョン、
それからプログラムのソースコードや
マシンのスペック、測定データをここに公開する気はないのかね。
まさか古いバージョンのJavaで作られたPetStoreを
例に挙げるわけではあるまい。
もう古くて参考にはならんぞ。
EJBを使ってるところは本当に少ないがな。
多くはEJBの変わりにPOJOを使ってるところばかりだし。
Seasar2とかSping Frameworkとかな。もしくはStruts + Tomcatオンリーとか。
StrtusやJSFすら使わないところも未だにあるが。
727:デフォルトの名無しさん
06/08/29 11:07:27
> Javaの方がパフォーマンスがいいなんて妄想もいいところ。
> JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
> その上で実行すればJavaより遅くなるわけが無い。
こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
オッサンに多いんだな。
728:デフォルトの名無しさん
06/08/29 11:08:09
>>722
ナノ秒なら
Java5からも実装されたぞ。
System.nanoTime()
729:デフォルトの名無しさん
06/08/29 11:25:25
>>727
そういう小僧は盗んだコードで走る馬鹿だろう？
なんでもおっさん扱いしないでくれよ
730:デフォルトの名無しさん
06/08/29 11:38:05
みんな自分の信ずる言語・環境を支持すればいいだろ
どうしてJavaスレには他の奴らが荒らしにくるんだ？
他の言語・環境がどんなに素晴らしいのかしらんがスレ違いだ
巣に帰れ！
731:デフォルトの名無しさん
06/08/29 12:23:15
次世代を語るところだから、どうしても他の言語と比べた改善点とか要望が出るんじゃない？
732:デフォルトの名無しさん
06/08/29 13:08:47
>>728
言葉が足りなかったかな
すでに実装されている話なんだし次世代の話題じゃないだろうということ
>>716は細かい制御したいのに5.0のコンカレントAPIすらさわってないんだろうなーとかおもっちまう
733:デフォルトの名無しさん
06/08/29 13:53:56
>>731
お前はネイディブコンパイラとのパフォーマンス比較を改善点や要望とでも言うのか？
だたの攻撃だろ？違うのか？
734:デフォルトの名無しさん
06/08/29 14:04:44
>>730
昔懐かしい「C#って死滅しちゃうの？」シリーズスレで
大暴れしていた例のM$厨では？
735:716
06/08/29 14:10:20
>>732
nanoTimeだけじゃアニメーションできなくない？
nanoTimeはsleepの分解能チェックや誤差の補正に使うものかと
結局sleep使わなきゃだめなんじゃないか？
それかObject.waitか。
J2SE6ではDoubleBuffer関係で何らかの改良があると聞いたかが。
そうそうConcurrentは使ってないな。まだ。そんなに必要性も感じてないが。
736:デフォルトの名無しさん
06/08/29 15:08:29
>>727
> > JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
> > その上で実行すればJavaより遅くなるわけが無い。
> こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
> 騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
？
進化とか古いとか関係ないだろう。CでJavaコンパイラを実装してclassコードを実行するという話をしているのだから
「Javaの方が速い」とならないことは自明なのだが。
恐らく「Javaは実行中にコードの最適化するから速い」とか言いたいんだろうが、
その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
ただ、CでわざわざJVMを再実装するのはコストがかかるから現実的ではないというだけ。
別にそこを認めてもJavaの優位性は変わらないと思うんだけどね。
いつものことだが、JavaしかできないやつはJavaを否定されると自分自身も否定されたような被害妄想を抱くよな。
どっかの宗教団体みたいで嫌だ。いろんな言語触れよ。次世代Javaの議論にも役立つぞ。
737:デフォルトの名無しさん
06/08/29 15:32:33
とんでもない勘違いをしている奴がいるぞｗ
738:デフォルトの名無しさん
06/08/29 15:40:53
痛い子が居るなぁ。
739:デフォルトの名無しさん
06/08/29 15:43:39
>>736 → 737,738
740:デフォルトの名無しさん
06/08/29 15:48:26
>その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
この意味が分からない。絶対と言い切れる根拠はなんなんだろ？
741:デフォルトの名無しさん
06/08/29 15:51:25
Javaで作ってスーパーコンピュータで動かせば速い。
742:デフォルトの名無しさん
06/08/29 15:54:16
>>740
馬鹿には つ き あ う な
743:デフォルトの名無しさん
06/08/29 15:57:28
>>740
> その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
> この意味が分からない。絶対と言い切れる根拠はなんなんだろ？
極論を言えば、
int main(){JavaVM *jvm;JNI_CreateJavaVM(&jvm);jvm->DestroyJavaVM();}
と書けば少なくとも速度は同じになるというだけのこと。
そんなにややこしいことは言ってない。
「JVMがCで書かれている」というのをもうちょっと考えろよ。
744:デフォルトの名無しさん
06/08/29 15:59:54
>>741
JVMの役割を知っていれば、わざわざスーパーコンピューターでJavaを使おうなんて考えないよ。
745:デフォルトの名無しさん
06/08/29 16:01:56
>743の続き
で、JVMのソースコード中から、実行に不要な部分を削除していけば、
JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
実際にはそんなところに開発コストをかけるのは無駄だから現実的ではないと言ってるだけ。
頭が悪いのか、それとも宗教にはまってるからなのか。。。
746:デフォルトの名無しさん
06/08/29 16:05:00
>>735
nanotimeはポーリング用
定期実行にはTimer方面つかえといっておろう
747:デフォルトの名無しさん
06/08/29 16:06:08
> JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
JVMはCのライブラリィではないよ（笑）
748:デフォルトの名無しさん
06/08/29 16:46:20
>>742
あい、了解したw
749:716
06/08/29 17:51:39
>>746
アニメーションとかの20msecとかそういう間隔の話をしているつもりだったんだけど、
Timer? ありえなくないか？
750:デフォルトの名無しさん
06/08/29 17:54:46
751:デフォルトの名無しさん
06/08/29 17:55:17
747はとても親切だ。
暴れてるやつは声を出して読むように。
752:デフォルトの名無しさん
06/08/29 18:00:01
>>749
どういう動きかわかってないんじゃない？
基本から勉強したほうがいいよ
753:716
06/08/29 18:07:25
>>752
教えてくれ。
Timerも結局waitを使っているとドキュメントされているが、
waitは正確性を欠く、それをnanoTimeとかで確認してスケジュールを補正するのが教科書とおりなのだが、
Timerを使ってしまうと補正ができなくないのではないか？
次世代になってもwaitとかの精度はそんなに変わらないんだろうな
754:デフォルトの名無しさん
06/08/29 18:15:40
そこまでわかってるなら問題あるまい
垂直同期にこだわらなければ60fpsにする必要もあるまい
垂直同期にしたら自動的にリフレッシュレートであわせられる
Win32ネイティブでやってるのと状況はかわらんよ
755:デフォルトの名無しさん
06/08/29 19:20:49
Windowsのマルチメディアタイマーは1msで寝れたと思うが
756:デフォルトの名無しさん
06/08/29 19:50:44
malloc/freeはどうした？＞最速厨
JVMは都合のいいタイミングまでガベコレを遅延できる。
これをやると、特にSMPで差が開く。
757:デフォルトの名無しさん
06/08/29 20:03:09
蒸し返すな
758:デフォルトの名無しさん
06/08/29 20:09:11
>>756
性能を重視するならmalloc/freeをそのまま使ったりなんてせず、
普通は独自アロケータを定義するでしょ。
759:デフォルトの名無しさん
06/08/29 20:54:34
>>720は、ぐぐってみたところ、
Javaの方が実行速度が速い例がたくさん見つかったので、
>>736>>743でごまかそうと必死w
760:デフォルトの名無しさん
06/08/29 22:55:04
Javaがなんでもかんでも速いというつもりは全然無いんだが、Ｃで組んだっ
て結局実装の仕方次第だろ。malloc/freeを何度も繰り返すような素のＣの
組み方したら、JVMの「そもそもメモリ解放自体めったにしないで確保してる
メモリを使い回す」ような実装より遅くてあたりまえ。
例えばObjective-CはＣのサブセットで、コンパイルすれば完全なバイナリに
なるわけだが、メソッド呼び出し速度とメモリ取得・解放速度でJavaのほうが上回る。
これはオブジェクト周りの実装の仕方の差だろ。
そこを意識して力技なパフォーマンスチューニングを組み込んでＣでゼロから
作れば、速くなるのも当たり前。
JavaがＣより速いとかいう話は、「Ｃで普通に組んだものより、Javaで普通に
組んだものの方が速いことがある。なぜなら、JVM自体にすでにパフォーマン
ス・チューニングがされているから」という意味だってことがわからないのだろうか。
普通に組んだ時のパフォーマンスの差には意味があると思うけどねえ。
761:デフォルトの名無しさん
06/08/29 22:55:23
>>736
C言語原理主義者の言い訳ごくろう。
また「Javaしかできない奴」とステレオタイプ貼り付けとは。
Javaで飯食ってきたかったらJavaしかできないなんてありえんからね。
762:デフォルトの名無しさん
06/08/29 22:57:39
>>758
その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
とってるよ、あれ。フリーリスト管理独自実装とか、ショボイことしてい
る間は越えられんでしょ。
763:デフォルトの名無しさん
06/08/29 23:03:03
コンパイラやＶＭの性能次第で、幾らでも早い言語・遅い言語になるわけだが。
言語の特性とコンパイラ最適化技術辺りは最低限踏まえて議論しような。
764:デフォルトの名無しさん
06/08/29 23:10:49
マイクロベンチしにくい言語だなぁと思うことはよくある。
例えばN秒間の実行回数が4400～5200とか異常な数値を出すこともしばしば。
ヒープサイズは-Xms -Xmxともに同じサイズにしても起こすから原因がつかめない
765:デフォルトの名無しさん
06/08/29 23:12:15
結局、学生とかによくある卓上理論ってやつじゃないのか？
766:デフォルトの名無しさん
06/08/29 23:22:36
机上だと思う。
767:758
06/08/29 23:46:35
> その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
越えられるよ。
つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
満足できないから独自実装するわけで。
> ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
> とってるよ
それは独自アロケータでも同じ。
そもそも、あるサブシステムでは特定のサイズのメモリを大量にアロケートするとか、
そういうプログラム固有の事情も考慮した上で最適なアロケータを設計するんだよ。
一般道から高速道までいろいろな状況でもそれなりに速く燃費の良いエンジンを作るのと、
サーキット上での速さの極限を目指したエンジン作りとを比較するようなもの。
そもそも設計方針から全く違う。
768:デフォルトの名無しさん
06/08/29 23:52:47
いずれにしても現実にあるjavaのOOなプログラムは速度の最適化は難しいんじゃないか？
javaだからっていうか、OOだから。
例えば、java3dとか、hibernateとか、
769:デフォルトの名無しさん
06/08/30 00:04:22
じゃあ、比較すんなよ。
770:デフォルトの名無しさん
06/08/30 00:06:31
>>767はなんかすごそうな職人さんのようですね。
必要に迫られて独自にそういうすごいのを作ったのでしょうが、
凡人・汎用ではjava vmぐらいでいいです。ruby gc thread とか遅くても
ちゃんと答えを出してくれればいいです。
771:デフォルトの名無しさん
06/08/30 00:07:08
>> その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
>越えられるよ。
>つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
>満足できないから独自実装するわけで。
このように、独自実装厨はチューニングが重ねられた汎用アルゴリズムに
劣る糞コードを生成するわけだ。乙
772:デフォルトの名無しさん
06/08/30 00:08:40
Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
Javaならある意味JVMが勝手にチューニングしてくれるし。
773:デフォルトの名無しさん
06/08/30 00:09:33
生産性を意識すりゃなんだって「それなり」の速度だっての。
うざいから他所でやってくれ、マ板でやることじゃないだろ。
774:デフォルトの名無しさん
06/08/30 00:23:50
>>768-774 みんなから一斉にツッコミのあらし。なんか知らないけど、笑いが止まらねー
775:デフォルトの名無しさん
06/08/30 00:30:06
次世代Javaに速度は強くもとめないということで。
おもいらそれよりSE 6のどこが素敵なのかまとめてくれんか？
776:デフォルトの名無しさん
06/08/30 00:38:07
ヒープ共有とタスクトレイはツール促進に繋がると思う。
777:デフォルトの名無しさん
06/08/30 00:48:00
Java 5.0 で既に十分高速なので議論しても仕方が無い。
それより、Java 6.0 Java 7.0 に予定されている言語拡張・ライブラリについて語ろうぜ。
778:デフォルトの名無しさん
06/08/30 01:08:56
>>11の
＞プロパティのサポート
＞メソッドリファレンスのレポート
＞クロージャのサポート
＞言語レベルでのXMLのサポート
＞JVM上で動作する動的言語のサポート
＞スクリプト言語サポートの拡張
＞モジュール化のサポート
＞Swingアプリケーション開発のためのツールの充実
のうち、今回出てきたのは「メソッドリファレンス（たぶんローカル・ファンクションのこと
だろう）」と「クロージャのサポート」なわけだが、
「プロパティのサポート」はまだ具体例が出てきてないね。
最後のSwingアプリケーション開発のためのツールって
のは、たしかSwingをベースにしたアプリケーション・フレー
ムワークを作るとかだったっけ。
779:デフォルトの名無しさん
06/08/30 01:17:25
最後のはただのNetBeansプラットフォームだったりしてな
780:デフォルトの名無しさん
06/08/30 01:27:48
# クラスパスのワイルドカード指定
これなｗ これが一番重要な更新だったりしてｗ
781:デフォルトの名無しさん
06/08/30 01:48:38
URLﾘﾝｸ(weblogs.java.net)
URLﾘﾝｸ(weblogs.java.net)
782:デフォルトの名無しさん
06/08/30 02:59:33
つ ｽﾚﾘﾝｸ(tech板)
783:デフォルトの名無しさん
06/08/30 03:04:55
Swing Application Frameworkって具体的にはどんなの？
784:デフォルトの名無しさん
06/08/30 03:25:08
>>758,>>767 その経験は選ばし者のみ体験できることぞよ。そこから習得した業をこれからも存分に発揮するが良い。わははははは
785:デフォルトの名無しさん
06/08/30 04:34:32
まずJavaをCたらしめているcloseメソッドをなんとかしろよ
まず名前をdeleteに変えてバカに気づかせろ
786:デフォルトの名無しさん
06/08/30 06:11:40
>>781
ktkr
いったいここまでたどり着くのに何年かけてんだ？
こんなのNEXTSTEPをSolarisにポートした連中なら最初に気が付いてるだろ
787:デフォルトの名無しさん
06/08/30 08:30:02
いやー、これなかなかいい設計だぞ？
今の基準でみると糞みたいなNEXTSTEPのフレームワークと違ってw
788:デフォルトの名無しさん
06/08/30 09:15:32
>>756
> malloc/freeはどうした？＞最速厨
> JVMは都合のいいタイミングまでガベコレを遅延できる。
分からん奴だな。そのガベコレをCで実装すればいい。
>>759
> >>720は、ぐぐってみたところ、
> Javaの方が実行速度が速い例がたくさん見つかったので、
Javaの方が速いっていうのは、C側ベンチでJavaと同じ事をしていないだけのこと。
Javaの挙動全てをCで実装すればJavaと同じ速度になるのは当たり前だと言ってるだけだ。
>>772
> Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
.classファイルを読み込んでJVM上で実行（もちろんJIT付き）するようなCプログラムを書けば、
Javaの方が速くなるなんてことは無いと言ってるだけなのに何で分からんかな。
789:デフォルトの名無しさん
06/08/30 09:18:19
必死だな。
790:デフォルトの名無しさん
06/08/30 09:22:30
こんなに頭悪い奴だとは思わなかった。
791:デフォルトの名無しさん
06/08/30 09:24:23
>>788
いいたいことはなんとなく分かったが、それを言うことで
あんたが何をしたいのかがさっぱり分からん。
792:デフォルトの名無しさん
06/08/30 09:28:24
自分の無知の隠蔽
793:デフォルトの名無しさん
06/08/30 09:34:40
痛い子が粘着してるな
明日までの辛抱かの
794:デフォルトの名無しさん
06/08/30 10:08:05
>>775
しかし、バージョンアップするたびに高速化してるみたいなんだけど。
次期バージョンJava6もPreJITによってかなり高速化が期待できるんでない？
二回目以降のアクセスからはCのネイティブと同じ扱いになってかなり高速化する、みたいな。
795:デフォルトの名無しさん
06/08/30 10:10:16
>>792
面白すぎる。
マ板で必死にJava叩きしてるおっさんどもを思い出すw
796:デフォルトの名無しさん
06/08/30 11:11:25
>>791
> >>788
> いいたいことはなんとなく分かったが、それを言うことで
このスレで頭がいいのはあんただけのようだな。
> あんたが何をしたいのかがさっぱり分からん。
>>720を理解できない奴が多かったから説明しただけ。
あんたみたいに理解力のある奴ばかりだったらいいんだがな。
>>736に書いた通り、Javaをけなそうとしているわけではないし、Cが素晴らしいなんて言うつもりも全く無い。
797:デフォルトの名無しさん
06/08/30 11:16:38
JVMはCで実装しなきゃいけない決まりでもあるの？
Javaチップ上でベンチ比較する場合についてはどう考えてるの？
この場合Cの処理系をまず用意しないとダメだけど…
798:デフォルトの名無しさん
06/08/30 11:45:08
>>796
どっかの宗教団体みたいなのはお前のほう。
お前の主張がいったい何になるのか説明できんだろ。
お前の意見が何もプラスにもならないならどっかの宗教団体と変わらない。
799:デフォルトの名無しさん
06/08/30 12:46:01
わかったから、アセンブラで書くと最強！
Cはその次！
で良いだろ
実の無い議論しても無駄だろ
800:デフォルトの名無しさん
06/08/30 13:19:58
こいつら一体何なんだ・・・
801:デフォルトの名無しさん
06/08/30 13:34:54
> JVMはCで実装しなきゃいけない決まりでもあるの？
> Javaチップ上でベンチ比較する場合についてはどう考えてるの？
はいはい、机上の仮説はどうでもいいから、
まずはC,C++で実装された現行のJVMにも性能面でひけを取らない
Javaチップを開発してからまた来てね。
802:デフォルトの名無しさん
06/08/30 13:36:25
>>800
Cで１からjvmもどきを書くと現行のJITより高性能をたたき出せる天才プログラマ様らしいよ
803:デフォルトの名無しさん
06/08/30 13:37:01
もうお前等来なくていいよ!
804:デフォルトの名無しさん
06/08/30 13:41:37
>>720 が悪い。
805:デフォルトの名無しさん
06/08/30 13:51:17
> > Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> > Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
> そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
まあ、CPUのサポートする命令セットに合わせて実行時に自己書換する、なんて
テクニックは大昔からあるよね。
今だって、多くの動画コーデックはSSE等の拡張命令の有無を実行時に調べて
動的に実行コードを生成したりしてるし。
そういう古くからあるテクニックの一部がJVM実装にも取り込まれるように
なってきた、ってだけの話。
806:デフォルトの名無しさん
06/08/30 14:06:40
俺よー、JVMの仕組みよく知らないんだけどJavaって実行時に
何度も実行される箇所はコンパイルしてネイティブコード生成するんだよな？
だから
コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)
なんかJavaはCを越えられないと言ってる奴はどうも
ネイティブコード生成後もJVMで解釈して実行してると思ってそうなんだが…？
CでもIntelMacのユニバーサルバイナリみたいに全CPUに最適されたコードを含んだ
バイナリを持てばJavaを上回るのは明らかだけど、そんな事してる奴いないよね。
807:デフォルトの名無しさん
06/08/30 14:23:54
> コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
>
> この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)
だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>805のような動的実行コード生成をC, C++でもやればいいだけの話。
で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
808:デフォルトの名無しさん
06/08/30 14:32:31
>>807
>> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
必ず同じ事ができるとは限らない。
809:デフォルトの名無しさん
06/08/30 14:34:51
「JavaがCより速い場合がある」ってのは、同じようなアルゴリズムでコードを書いた場合ってことだろ。
そりゃ、最適化したコードで比べればどんな場合でもCの方が速くなるだろうよ。
でも、その最適化したコードをCで書くのは、コストや能力を考えると現実的に不可能だ。
810:デフォルトの名無しさん
06/08/30 14:37:58
> >> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
>
> 必ず同じ事ができるとは限らない。
その理由は?
Cで書かれたJVMにできて、Cで直接書かれたプログラムにできないことって何?
それともJavaチップのことでも言ってるの?(笑
811:デフォルトの名無しさん
06/08/30 14:51:14
>>806
コンパイル時間 << ε
ならば、誤差の範囲内として無視できる。
すると、JavaとCとでは速度はさほど変わらなくなる。
また、
Java実行速度 - C実行速度 << ε
なら、ますます無視できる。
ここでεとは非常に小さな値を表し、 <<は<よりもうんと大きな差があることを意味する。
つまりうんと小さくなるという意味。
812:デフォルトの名無しさん
06/08/30 14:55:54
で、Ｃでできるからなんだよ？
813:デフォルトの名無しさん
06/08/30 14:57:04
>>810
実例を出すと、ベクトル型スパコン。
Cで書かれたプログラムより、FORTRANプログラムの方が速いとされる。
コンパイラはどちらもCで作られている。
これは、ソースレベルでは同じアルゴリズムであっても、FORTRANで記述
されたプログラムの方が、Cよりも最適なベクトル化できるからである。
コンパイラを同じCで作っても、どこまで最適化できるかは、各言語仕様も
関係してくる。
814:デフォルトの名無しさん
06/08/30 15:48:19
あれ、いつの間にここはFORTRANスレになったのかな?
815:デフォルトの名無しさん
06/08/30 15:49:14
>>813
だから、｛Cで書かれたFORTRANコンパイラ＋.Fのソースファイル｝を合わせて、
一つのCで書かれたソフトウェアと見なすって話が延々と続いているわけだ。
論理的には正しいが、実効的な意味はない。
ってのが>>736の最後のパラグラフの意味だと思われ。
816:602
06/08/30 16:04:51
>>778
メソッドリファレンスって俺待望の >>602 で書いたようなことじゃないのかね？
だとしたら、あと5年はjavaを使おうかと思うな
でもSE7からなのか。。。
817:デフォルトの名無しさん
06/08/30 17:09:12
>>788
> >>756
> > malloc/freeはどうした？＞最速厨
> > JVMは都合のいいタイミングまでガベコレを遅延できる。
> 分からん奴だな。そのガベコレをCで実装すればいい。
不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
メモリ関数の使用を禁止すれば、ソースを書き直さなければならず、
もはやCのプログラムではなくなる。だから、JavaやC#のような新しい
言語ができたことを理解しろ。
818:デフォルトの名無しさん
06/08/30 17:15:04
>>817
へー、Boehm GCを使ったCプログラムはCのプログラムではないんだ。
819:デフォルトの名無しさん
06/08/30 17:25:20
>>818
ベタベタなコードにコンサバなGCで体裁繕ったらパフォーマンスでないぞ
いい加減みっともないまね続けるなよな
820:デフォルトの名無しさん
06/08/30 17:31:01
>>817
> 不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
JVMはどうやってガベコレを実装してるの？
821:デフォルトの名無しさん
06/08/30 17:33:30
>>807
つまり、普通の人はそんなの作らない＆作れないから、
凡人が高速なプログラムを作ろうとしたらJavaで書いて実装した方がいいって事だよね。
理論的にCオンリーの方が早くなるっていうのは別に、誰も否定しないと思うけど
現実的にJavaの方が早くなる【場合がある】っていうのを認められないのは厨房だと思うな。
822:デフォルトの名無しさん
06/08/30 17:34:27
>>820
メモリ関数使ってるに決まってるだろ。馬鹿じゃねぇの？
823:デフォルトの名無しさん
06/08/30 17:38:48
Javaの人は、Cはほどほどに教養程度なんじゃない？
詳しかったらJavaの環境に居ないで、Cの環境（Win32やUnix）に行ってるでしょ。
せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
次世代Java環境が気になるJava使いの人はついて来れないと思う。
824:デフォルトの名無しさん
06/08/30 17:42:27
>>823つまり冷やかしもほどほど程度にしとけってことかな？
825:デフォルトの名無しさん
06/08/30 17:47:11
言語仕様も関係するが、それよりも実行形式の抽象度の違いによるんだよ。
826:デフォルトの名無しさん
06/08/30 17:50:09
>>823
当然、おまいはGCの実装経験がある or 実装できるのだな。
各種GCアルゴリズムについて語らないか？
827:デフォルトの名無しさん
06/08/30 17:54:35
>>822は叩かれてる人？泣きそうになってるみたいだけど
828:デフォルトの名無しさん
06/08/30 18:09:04
>>807
>だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>>805のような動的実行コード生成をC, C++でもやればいいだけの話。
>で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
>OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
if(SSE２命令が利用可能か？) {
// SSE２命令を利用したインラインアセンブラによるコード
}
else {
// SSE２命令を利用しないインラインアセンブラによるコード
}
これのどの辺りが動的実行コード生成になるのか説明してくれんか？
無知は怖いね。
829:デフォルトの名無しさん
06/08/30 18:52:56
高速化高速化いうてるけど
1.4.2のが5.0より速いらしいぞ
SUNのベンチ鵜呑みにするなや
830:デフォルトの名無しさん
06/08/30 18:56:32
>>828
ほらよ。
URLﾘﾝｸ(mkosaki.blog46.fc2.com)
831:デフォルトの名無しさん
06/08/30 19:08:15
> せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
> 次世代Java環境が気になるJava使いの人はついて来れないと思う。
だろうね。
というか、そういう話をこのスレでやるのがそもそも間違い。
パフォーマンス厨は↓へ行ってくれ。
ｽﾚﾘﾝｸ(prog板)
832:デフォルトの名無しさん
06/08/30 19:41:39
>>823
いまどきそうやってCはJavaよりも凄く、
「Cを知っていればJavaを知らなくても偉いんだ！」
と勘違いしてCしか知らず、Javaのことろくに勉強しないのも、恥ずかしいことなのだが。
833:デフォルトの名無しさん
06/08/30 19:49:41
いまどきそうやってJavaはCよりも凄く、
「Javaを知っていればCを知らなくても偉いんだ！」
と勘違いしてJavaしか知らず、Cのことろくに勉強しないのも、恥ずかしいことなのだが。
834:デフォルトの名無しさん
06/08/30 20:04:14
いまどきそうやって技術は一般常識よりも凄く、
「技術を知っていれば一般常識を知らなくても偉いんだ！」
と勘違いして技術しか知らず、一般常識のことろくに勉強しないのも、恥ずかしいことなのだが。
835:デフォルトの名無しさん
06/08/30 20:08:04
>>833
お前よ、餓鬼みたいに>>832のコピペしてるのどっかで見たことがあるぞ。
C#死滅スレのVBとC#を崇拝する、継承嫌いの餓鬼だろw
836:デフォルトの名無しさん
06/08/30 20:08:49
>>834
まてまて技術は一般常識の範疇に入るぞ
837:デフォルトの名無しさん
06/08/30 20:12:42
いつまでたっても馬鹿が釣られまくっとるな
ガキが相手するから正常化せんのだが能無しには分からんか
838:デフォルトの名無しさん
06/08/30 20:29:39
>>828
ﾌﾟ
無知は怖いね。
839:デフォルトの名無しさん
06/08/30 20:54:06
嵐が過ぎた後は誰もいなくなっている悪寒。
お前らCがJavaより早くJavaはCより早いのは分かったから
メソッドリファレンスが何なのか情報提供してくれ。
840:デフォルトの名無しさん
06/08/30 21:01:00
>>837
奴はＶＢとC#に詳しいアホだよ。
昔、語尾に「嘲笑激藁」「ﾌﾟﾌﾟ」「ｹﾞﾗ」「ﾜﾗ」「大爆笑」
をつけてた奴、ハンドルが「255」とかつけてた奴に
非常にそっくり。
結局あそこまでC#を持ち上げても、全然はやらなかったな。
どうせ奴は鬱憤晴らしにスレを荒らしてるだけだろう。
841:デフォルトの名無しさん
06/08/30 21:03:33
>>807
つーか、動的生成云々うるさいけど、それってモジュール切り替えでええんじゃないん？
実行時生成なんてしなくても、コンパイルしたモジュールも含めればいいだけの話。
C使いでもめったに使わない技術を得意げに語るのは哀れですらある。
Java厨だってバイトコードの自力生成なんて滅多にしない。
842:デフォルトの名無しさん
06/08/30 21:04:55
レスすんなカス
どこまで脳みそゆるいんだ
843:デフォルトの名無しさん
06/08/30 21:07:33
>>787
いやー盛り上がってるとこ悪いが、20年経ってその台詞恥ずかしくないかw
844:デフォルトの名無しさん
06/08/30 21:13:58
ところでJavaCardって何に使うの？
Java OneとSUNのシンクライアントでつかうくらいしか聞いたこと無い。
Edyのがすごいよ、コンビニ清算最速ってすごくね？
845:デフォルトの名無しさん
06/08/30 21:15:41
ココの住人には>>823は図星なのか？
みんなずいぶん喰らったみたいけど大丈夫か？
846:デフォルトの名無しさん
06/08/30 21:16:00
>>813
C言語にポインタがあるために、ベクトル化による十分な最適化ができないが、
FORTRAN言語にはそのポインタがないので、十分にベクトル化できると聞いた
ことがある。
Java言語が出たとき、JavaもポインタがないのでFORTRAN並に最適化できる
のではないかという極端な記事が、Cマガジンに載っていたような覚えがある。
今となってはJavaの仕様では、FORTRAN並に最適化は無理なのは自明だが・・。
847:デフォルトの名無しさん
06/08/30 21:17:28
>>841
バイトコードの自力生成ってできたの？しらなｋった。
ところで、どうやってやるの
848:デフォルトの名無しさん
06/08/30 21:19:42
図星ってのもあるが正直どうでもいい
特定環境に最適化されたGCなんて興味ないなって感じ
849:デフォルトの名無しさん
06/08/30 21:20:32
>>830
オイオイ、必死に何か探してきたと思ったらコレだ。
自己書き換えと動的実行コード生成は似て非なるものなんだが。
850:デフォルトの名無しさん
06/08/30 21:32:51
>>847
適当なバイト列を作ってClassLoader#defineClass()を呼ぶだけだ。
そのバイト列はJavaVM仕様に合わせて作ればいい。
BCELやasmなどのバイトコード作成用ライブラリもある。
Java5からはClassLoader側で細工しなくてもバイトコード変換ができるように
java.lang.instrumentパッケージ以下のクラスが追加された。
851:デフォルトの名無しさん
06/08/30 21:54:51
>>850 しらなかった、あんがと。Jakarta BCELを読んでみる。
852:デフォルトの名無しさん
06/08/30 21:59:14
>>851
正直言って、BCELは設計が古いというか微妙に使いにくいので、
新規ならASMかJavassist使った方が良いかと
他言語 -> Javaバイトコードのコンパイラ作るなら、Javassistはちょっと使いにくいが
853:デフォルトの名無しさん
06/08/30 22:09:50
今BCEL読んでる最中だけど、これってすげーな。
この技術と言うか概念というか、次のリリースでスクリプト言語を
java vmに取り込むとか言うのより、さらに高次元の話じゃん。
854:デフォルトの名無しさん
06/08/30 22:32:11
大体概要は分かったけど、すごかった。こういうツールが整備されて
徐々に万人向けに使いやすくなっていくと、これからも OSに依存しな
い Java の環境がより強固なものになっていく予感がする。
昔Sunが目指していたNetworkがどうのというやつなのかな。
> 他言語 -> Javaバイトコードのコンパイラ作るなら
>>852さんはこういう系の人なのでしょうか？
そうとは知らずに、言葉遣いが足らず失礼しました。
855:デフォルトの名無しさん
06/08/30 22:50:38
>>854
852だけど、一応そういう系の人です。Java VM上で動作する
とあるスクリプト言語開発してます。超マイナーな言語ですが
一応どんな言語かというと、Javaに似たセマンティクスに
スクリプト言語っぽいシンタックスシュガーをふりかけました
みたいな言語です
> 言葉遣いが足らず失礼しました
？別に特に>>854さんが失礼な言動をしたとは思わなかったけど
856:デフォルトの名無しさん
06/08/30 22:54:35
あ、ひょっとしたら誤解してるかもしれないんで一応いっておくと
>>850さんと>>852(= >>855)は別人なんで
857:デフォルトの名無しさん
06/08/30 23:31:46
いや～、やっぱりここにはいろんな人が来てるね～
＼＿＿＿＿＿ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
∨ |
| まいど、まいど！繁盛、繁盛！！
＼＿ ＿＿＿＿＿＿＿＿＿＿＿
＿＿ ∨
／ ／| ∧＿∧
|￣￣|／| （・∀・ ） (
|￣￣| |￣￣￣|＼＿（＿ ）＿ （・∀・： ）Java は さいきょう じゃ
|￣￣| |＿＿＿| ∧＿∧ ￣￣￣ ／／／／|
|￣￣| |＿＿＿|（ ）＿＿＿_|￣￣￣|／|
|￣￣ （ ○ ） ￣￣￣| |
| ｜ ｜ | | |
| （＿（＿） |／
858:デフォルトの名無しさん
06/08/30 23:44:50
ここで思ったんだが、JVM用のC言語を書くってのはどう？
859:デフォルトの名無しさん
06/08/30 23:47:50
>>858
JVMしか作成できない言語を作るの？
どんなメリットがあるの？
860:デフォルトの名無しさん
06/08/30 23:53:53
ちょっとだけスレを読んでみたけど、
ガベコレ実装しそうな職人とか、
サーバー用ツールと次世代Javaの関係が気になる人とか、
クライアント用(携帯アプリ)の開発者とか、
コンパイラ作る人とか、
CマンセーなのにJavaが気になる人とか、
JVM上で動作するスクリプト開発者とか、
いっぱい居て楽しそうだね～♪
861:デフォルトの名無しさん
06/08/30 23:55:09
>>859
ごめん言葉足らずだったね
JVM上で動くバイナリを吐くC言語だ
862:デフォルトの名無しさん
06/08/31 00:10:41
>>861
> JVM上で動くバイナリを吐くC言語だ
Cのソースからクラスファイルを作るということ？
863:デフォルトの名無しさん
06/08/31 00:20:12
>>855
ちょいと質問なんだが、JRubyやJPyton、GroovyやJavaScriptじゃだめだったの？
独自スクリプト言語を新規開発するに至る動機はナンデスカ？
864:デフォルトの名無しさん
06/08/31 00:54:34
「独自スクリプト言語を新規開発する」どころか、
「独自スクリプト言語を新規開発するためのフレームワーク」が出て来ているのに、
そんな質問するに至る動機はナンデスカ？
せめてどんな特徴があるんですか？くらいにしてくれよ
865:デフォルトの名無しさん
06/08/31 00:56:48
>>862
そんな感じ
それなら単純にJava言語とC言語の比較が出来るだろ
866:デフォルトの名無しさん
06/08/31 01:01:57
>>861
そんな無意味なものを誰が使うんでしょうか。
性能上の要求が高くて、高級アセンブラを使うリスクを拾わなきゃいかん場合に、
仕方なくCを使うのであって、要求が低くてJavaなり何なり使って手抜きできるな
ら、手抜き言語使うんじゃないの。
867:デフォルトの名無しさん
06/08/31 01:02:58
> それなら単純にJava言語とC言語の比較が出来るだろ
言語仕様そのものを比較するわけじゃないから、意味なくない？
868:デフォルトの名無しさん
06/08/31 01:07:26
>>863 私の野生の勘ですが、javascript かjrubyの開発関係の人ですよ、きっと。もしくは学者先生。だからそそうのないように・・
869:sage
06/08/31 01:18:44
>>868
なんで2chで書きこみのリアル人生に気を使う必要があるんだと小一時間(ry
大体、そんなｴﾗｲ人がこんなところでクダまくかいな。
870:デフォルトの名無しさん
06/08/31 01:20:32
>>855
JVM系のスクリプト言語は多くが動的型で、パフォーマンスがJavaに比べて劣るから、
静的型でJavaと同等のパフォーマンスを保ちつつ、手軽に書ける言語が欲しかった
というところ
実際、簡単なベンチマークとってみたら、Javaとほとんど同等の速度が出てた
まあ、セマンティクスがJavaに極めて近いから、速度出るのは当たり前なんだが
とはいえ、予定していた言語仕様はそれなりに実装できたものの、ライブラリをまだ
全然作ってないので、Javaのライブラリを使うしかないという情けない状態になってるが
871:デフォルトの名無しさん
06/08/31 01:27:29
>>870
よくわかりませんが、それって、例えばGroovyみたいな言語
→JVMバイトコードのコンパイラ作ったってことですか？
872:デフォルトの名無しさん
06/08/31 01:27:45
>>858,>>861-862,>>865-867
現時点での実用性で考えると、いらない、意味無いというのは当たり前だと思う。
現状の、Java VMが各OS上のの単なる１サービスや１アプリケーションと考えると
無意味だけど、これとは逆に各OSはJava VM上の１アプリ・１コンテンツと考えると、
状況は変わってくるんじゃないかな？
よく言うところの、ネットワークをでかいプラットホーム見立てて各OSはJavaの環境
で統一って言うやつ。
ちなみに私は>>858じゃないよ。
873:デフォルトの名無しさん
06/08/31 01:28:06
>>869
855だけど
> 大体、そんなｴﾗｲ人がこんなところでクダまくかいな。
まあ、そりゃそうだわなw
リアルではただの大学院生です
ただ、エライ人でも興味ある分野のスレ見てる人は結構居るみたいですが
874:デフォルトの名無しさん
06/08/31 01:29:30
>>871
そういうことです
しかし、自分が言えたセリフじゃないが書き込みのペースが早いなw
875:デフォルトの名無しさん
06/08/31 01:31:55
>>867
だって、JavaとCの比較ならおかしくないだろ
JITとAOTのどっちが早いってだけの話なのか？
876:デフォルトの名無しさん
06/08/31 01:36:29
なんか知ってるかもと思ったので質問。
Java6のHotSpotコンパイラでエスケープ解析が入るのが売りの一つらしい
けど、スタックにオブジェクトが積めるようになるとそんなに性能上がるの？
世代別GCならヒープへのオブジェクトの確保解放はたいしたコストじ
ゃないし、どうせ短寿命なら初回MinorGCでedenからさようなら～なので、
なんかイメージつかないんだけど、ナニがどう軽くなるんでしょう？
877:デフォルトの名無しさん
06/08/31 01:43:02
ところで、JVMで動作するC言語の処理系だけど、既にあるよ
JVMで動作するっていうか、C言語 -> Java言語のプログラムへの
トランスレータだけど。C2Jでぐぐってみるといいと思う
878:デフォルトの名無しさん
06/08/31 01:45:47
>>875
静的コンパイルとHotSpotでどっちが早いというのがテーマなのかねえ…
「HotSpotコンパイル」の中身がどんな最適かなのかわからないことには、
なんともかんとも。
879:デフォルトの名無しさん
06/08/31 01:49:48
もしスクリプト言語作るなら、
個人的には数式処理・代数処理程度で、
それをevelする程度で十分なんですけど。
複素数や行列の独自表記ができたり、(a+b)^2と書けたり
多項式展開や因数分解できたりとかです。
Java VMで動くバイトコードコンパイラ、スクリプトコンパイ
ラ？を作る意義・動機と言うのは、そういう特定用途に特化し
た言語を作るのでもありということだと思うんですけど・・
880:デフォルトの名無しさん
06/08/31 03:49:03
C言語厨である>>841はなぜJava似のC++も使いこなせ
なかったんでしょう
881:デフォルトの名無しさん
06/08/31 03:50:11
>>844
Javaカードは、
住民基本台帳カード、
大日本印刷が作ったカード、
海外の国民健康保険カードに使われているよ
882:デフォルトの名無しさん
06/08/31 04:24:32
>>876
そりゃヒープに取らないで済めば、その分処理が軽くなるでしょう。
ヒープはGC含めてなんだかんだで競合が多いので、
C10Kな時なんかには効いてくる。object poolもしないで済む。
883:デフォルトの名無しさん
06/08/31 05:56:41
>>877
そのトランスレータ使える？ たった一行のCのプログラムもとんでもない量のJavaになるし、
ポインタ演算している所なんか、酷すぎる。
884:デフォルトの名無しさん
06/08/31 07:12:58
>>787
ちょw
まだアプリ間連携もまともにできないJavaなのにw
どうみてもやっと「アプリケーション構成を考えるようになりました」ってレベルだろ？
URLﾘﾝｸ(docs.sun.com)
のデリゲートとか
URLﾘﾝｸ(docs.sun.com)
のサービスにいつ追いつくのやらw
20年前のフレームワークに負けてるってはずかしくね？
885:デフォルトの名無しさん
06/08/31 09:15:02
>>828
> >>807
> >だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
> >>805のような動的実行コード生成をC, C++でもやればいいだけの話。
> >で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
> >OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
> if(SSE２命令が利用可能か？) {
> // SSE２命令を利用したインラインアセンブラによるコード
> }
> else {
> // SSE２命令を利用しないインラインアセンブラによるコード
> }
> これのどの辺りが動的実行コード生成になるのか説明してくれんか？
> 無知は怖いね。
無知晒し上げ
886:デフォルトの名無しさん
06/08/31 09:31:54
最近、各種OSは、
securityがらみでdata領域を実行出来なくする方向だけど、
JIT/HotSpotはそれじゃ困るやね。
887:デフォルトの名無しさん
06/08/31 10:01:01
>>883
.いや、たぶん実用にはならないだろうなあとは試してみて俺も思ったけど
まだそういう処理系は無いという前提で話が進んでいるように見えたので、
一応そういうものはあるということが言いたかっただけ
888:デフォルトの名無しさん
06/08/31 11:34:40
>>884
なんかcocoaとかで見る名前だね。
あたりまえか。
何でこれがSunにおいてあんだ？
889:デフォルトの名無しさん
06/08/31 11:44:02
>>885
ﾄﾞﾄﾈﾄ厨笑えるw
890:デフォルトの名無しさん
06/08/31 11:59:42
>>888
OPENSTEP
891:デフォルトの名無しさん
06/08/31 12:44:51
>>886
デフォルトが実行不可になるってだけで、
別途実行可能な領域を確保する方法は用意されている。
たとえばUNIX系ではmmap()にPROT_EXECフラグを付けて領域を確保すればいい。
というか、IA32アーキテクチャではNXビットがサポートされるようになったごく最近まで
PROT_EXECフラグの有無にかかわらず常に実行可能になっていたってだけで、
他のアーキテクチャでプログラムしていた連中にとっては今更って話だろうね。
892:デフォルトの名無しさん
06/08/31 15:09:33
Java6.0っていつリリースされるの？
893:デフォルトの名無しさん
06/08/31 19:36:00
>>888
これSunがSolarisにポートした幻のOPENSTEPのやつだな
俺リアルで使ってたけど、、
894:デフォルトの名無しさん
06/08/31 19:56:15
>>1の「分離」とかSockets Direct Protocol
はMustangで実現してなくないか？
dolphinで?
895:デフォルトの名無しさん
06/08/31 19:58:30
>>892
そのうち
896:デフォルトの名無しさん
06/08/31 20:45:38
That house?
897:デフォルトの名無しさん
06/08/31 21:11:58
次のjavaではインライン・アセンブラが出来るようなる
らしい・・・
898:デフォルトの名無しさん
06/08/31 21:49:05
>>892
Java6.0はリリースされない
リリースされるのはJava6
899:デフォルトの名無しさん
06/08/31 22:14:09
>>897
ネタだろうけど、あえて反応してみる。こんな感じか？
public class HelloWorld {
public static void main(String[] args){
asm("getstatic java/lang/System.out:Ljava/io/PrintStream;");
asm("ldc \"Hello, World\"");
asm("invokevirtual java/io/PrintStream.println:(Ljava/lang/String;)V");
}
}
しかし、もし仮に本当にJavaにインラインアセンブラが搭載されたとしても、goto
使えるくらいしか利点が無さそう…
バイトコードレベルでは、大した最適化もできんし、JITコンパイラの最適化を阻害する危険もあるしな
900:デフォルトの名無しさん
06/08/31 22:45:40
>>899
>>897はネタの匂いがするけど
それだったらJava標準でなくてもすでに誰かが
作ってそうだ。
Java 6ではそれと似たような方式でスクリプト言語をサポートしていたし。
結局、Jakarata OROと同じように文字列のエスケープは避けられないというわけで。
外部ファイルに置いた場合だけエスケープしなくて済むってほうが言語としてまともだね。
901:デフォルトの名無しさん
06/08/31 23:43:59
コンパイラサポートすんだから普通にやるんじゃないか。
902:デフォルトの名無しさん
06/09/01 00:06:39
>>892
2006年10月以降？
URLﾘﾝｸ(journal.mycom.co.jp)
903:デフォルトの名無しさん
06/09/01 06:18:20
>>902
ありがとう！
904:デフォルトの名無しさん
06/09/01 09:52:57
この秋といってたけど、１１月以降が濃厚だな。
905:デフォルトの名無しさん
06/09/01 11:13:19
Java6の魅力はＧＵＩまわりの強化くらいかね。
アノテーションが増えたって言うけど、どんなもんが増えた？
新たにGenerics対応したクラスも出る？
906:デフォルトの名無しさん
06/09/01 14:30:24
> JVMはどうやってガベコレを実装してるの？
JVMにはJava言語用に作られたGCがあるだけで、C言語には使えないよ。
907:デフォルトの名無しさん
06/09/01 14:41:41
>>906あんまり正確じゃないなその表現は。
908:デフォルトの名無しさん
06/09/01 15:37:41
いつになったら.NET並の速度になるん？
909:デフォルトの名無しさん
06/09/01 16:00:38
javaと.netは目指しているものが違うから同じように比べてもねぇ
910:デフォルトの名無しさん
06/09/01 18:50:50
>>908
CLR の仮想関数呼び出しは遅すぎで使い物にならないわけだが。
Pure Java と Pure C# なライブラリを比較すると
明らかに JVM >>>>>>>>>>>> CLR であることがわかる。
911:デフォルトの名無しさん
06/09/01 19:32:29
>>908
ドトネト並みっていってるが、
ドトネトだってJavaより遅いのは遅いぞ。
どっちもVM上で動いているんだから。
どっちも遅いんだし。
比べるならC/C++とのほうが重みがある。
ドトネトだとVMの性質がJavaと異なるし
得意分野、得意分野が微妙にことなる。
912:デフォルトの名無しさん
06/09/01 19:39:22
Java6 mustang = null;
Java5 tiger = new Java5();
tiger.swing++;
tiger+=derby;
tiger+=webServer;
Java6 mustang = (Java6) tiger;
こんな感じかな？
913:912
06/09/01 19:40:07
最初の一行いらないね。失礼。
914:デフォルトの名無しさん
06/09/01 20:48:22
NETが日本で最も普及しているプログラム言語
ｽﾚﾘﾝｸ(tech板)
915:デフォルトの名無しさん
06/09/01 21:17:57
>>912
Java5型はオブジェクトの型なのか文字列型なのか数値なのか
どっちみちString型の猿まねはできないし++や+=を使えるのは
Stringオブジェクトか数値型だけなのでエラーになるわな。
916:デフォルトの名無しさん
06/09/01 21:18:20
>>914
つまらんし、根拠がない
917:デフォルトの名無しさん
06/09/01 21:28:45
>>915
オペレータオーバロードｷﾀ━━━(ﾟ∀ﾟ)━━━!!!!
918:デフォルトの名無しさん
06/09/01 21:51:25
>>911
わからないでもないが、同じバーチャル・マシンという環境で比べた方が公平だと思うぞ
Cはネイティブ・マシンだろ
またガベコレがどうしたこうしたとかなのか？
919:デフォルトの名無しさん
06/09/01 21:52:39
ネイティブ・マシン……
920:デフォルトの名無しさん
06/09/01 22:02:58
そういや、Stringには++使えないんだった。
つーかJavaに演算子オーバーロードなんて期待すべきでないし
勧めるべきじゃない。
C++の二の舞になったC#と同じ道を歩む。
あれは大失敗だった。
921:デフォルトの名無しさん
06/09/01 22:05:07
>>918
同じVMといってもな、VMは各種ベンダによって速度が異なるし。
IBMが作ったのとSunが作ったのとではJVMの速度やライブラリによる速度も変わってくる。
その辺りも厳密に考えないと逝けない。
そう考えると、面倒だし議論するだけ無駄だと思うんだが。
そういう比較は、こだわると、FFとドラクエとを比較するくらい実にくだらない議論になると思うよ。
922:デフォルトの名無しさん
06/09/01 22:20:11
>>921わかってるじゃん。
923:デフォルトの名無しさん
06/09/02 00:26:08
>>905
1.2～1.4のようにデスクトップアプリが大幅にパワーアップするようなのはあんまりなさそうだ
5.0以降デスクトップに力入れてますといってるけど、小粒なのが多くて
むしろ力入れてないのではと思いたくなる
924:デフォルトの名無しさん
06/09/02 02:48:50
public class Java6 extends Java5{
Swing swing = getSwing().add(new AntiAlias());
DB db = new Derby();
public Java6() throws NotReleasedException{
try{
openSource();
}catch(Exception e){
log.error("やっぱり無理だった");
}
throw new NotReleasedException("もうちょっとまって");
}
}
925:デフォルトの名無しさん
06/09/02 03:40:53
しかし.NETのCLRが「速い」というのは初めて聞く意見なんだが、
なんか速くなったのか？ ずっと「遅い遅い」と言われ続けてたと
思うんだが。
926:デフォルトの名無しさん
06/09/02 10:27:07
>>920
演算子のオーバーロードは便利だよ。演算子オーバーロードじゃなくても、
クラスごとに演算子の動作を定義できるのは便利。
C＋＋のはいけてないけど、pythonのように、演算子ごとに対応するメソッドを
用意する方法ならわかりやすいし、実装も簡単（コンパイラに手を入れるだけで済む）。
Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
927:デフォルトの名無しさん
06/09/02 10:38:16
>>926
> Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
激同
で、いらないっていいながらJavaに実装されるといきなりﾏﾝｾｰし始めるからもっと嫌い。
Javaは好きだがJavaをまともに使えるのはほんの一握り。大抵は基礎の無い阿呆ばっかだ。厨の割合が高過ぎる。
928:デフォルトの名無しさん
06/09/02 10:40:06
少なくともBigなんちゃらや日付時間関係は演算子使いたいよな
文字列だけ砂糖付きはずるいぞ
929:デフォルトの名無しさん
06/09/02 11:06:01
> 厨の割合が高過ぎる。
そういう業界だろｗ
930:デフォルトの名無しさん
06/09/02 11:30:59
>>928
BigDecimalが対応されたらクライアント用でも業務系での地位は確定するな
931:デフォルトの名無しさん
06/09/02 12:11:19
>>926
>>927
そんなもの別にJavaユーザに限った話じゃないでしょ。なんですぐにそういう話になるかなあ
C++ユーザだってよく、Javaに対して、GCなんてイラネとか言っているのは耳にする
ある程度普及した言語には、厨や信者が一定割合でつくというだけの話だと思う
932:デフォルトの名無しさん
06/09/02 12:17:23
>>926
演算子っつーと、[] も演算子だよな。
数値計算しないから + や - のオーバーライドはできなくても個人的には困らんけど
MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
933:デフォルトの名無しさん
06/09/02 12:30:06
listのほうは難しい気がするがmapのほうは現行の構文とかさならないからできそうな気がするんだけどね
とおもったけどキーがIntegerとかでintわたしてオートボクシングとかされると配列とみわけがつかんか
934:デフォルトの名無しさん
06/09/02 13:41:26
>>926-927
大丈夫か？MSや.Netマンセーなのか？
例えば、そんなのオレは面倒とかを除けば、
やってる事は同じなんだけど、そういうの気がつかないのかな。
プロパティとかインデグザとか。
delegate, eventはいいね。なんともMSらしい。
935:デフォルトの名無しさん
06/09/02 13:45:56
コンパイラをいじれば、
いつでもできるんじゃないの。
ただ実質同じことだし、
そういう要求をかなえてまで、
面倒くさいぞー系の蛆が溢れると、
Javaの品質が下がるからまだ今もやらないってこと。
936:デフォルトの名無しさん
06/09/02 17:43:09
>>926
Genericsは、「あんなものイラネ」と言われたことないよ。
937:デフォルトの名無しさん
06/09/02 17:46:46
>>936
Genericsイラネ
938:デフォルトの名無しさん
06/09/02 17:50:21
>>937
C厨
939:デフォルトの名無しさん
06/09/02 17:58:10
>>933
なんでlistだと難しいのかくわしく。
940:デフォルトの名無しさん
06/09/02 17:58:15
JavaもtoStringは演算子オーバーロードできるしな
例えばインタフェースベースの演算子オーバーロードなら
interface Calculateableみたいなのを用意して
Numberと同じメソッド定義しておけば、目的を見失うことも無いだろう。
941:デフォルトの名無しさん
06/09/02 18:04:28
>>939
配列と区別がつかないからだろ
942:デフォルトの名無しさん
06/09/02 18:33:17
個人的には言語仕様の拡張はしなくてもいいから
VMの性能とデスクトップ周りの強化をしてほしいな・・・
943:デフォルトの名無しさん
06/09/02 18:36:08
>>942
それは着々と進んでるだろ。
944:デフォルトの名無しさん
06/09/02 20:03:27
>>941
区別はつくよ。むしろなんで区別がつかないと思うのか聞きたいところだ
945:デフォルトの名無しさん
06/09/02 20:26:27
128bit Java
946:デフォルトの名無しさん
06/09/02 20:45:46
>>926
おまえは何も解ってない。
ストラウストラップが警告した事項を
947:デフォルトの名無しさん
06/09/02 20:45:57
>>944
もちろんコード全体を見りゃ区別はつくさ
objs[i]と書いてあるときにobjsは配列かListか
すぐには判断できない場面があるわけだ
両者が共通の性質やAPIを持つなら区別できなくても問題ないけどな
実際には配列は固定長だし、APIもlengthでサイズを知るなど異なるわけ
配列を廃止するならともかく両立させるのは混乱の元
948:デフォルトの名無しさん
06/09/02 20:47:03
>>926-927は同一人物による書き込みだよな
949:デフォルトの名無しさん
06/09/02 20:48:17
>>932
[]は単項演算子みたいなもんだからいいんだよ
+や-となると２項演算子なので
演算子の優先順位を意識するのが大変になるんだよ。
それに他人が作った奴の演算子が混ざったらどうなると
思ってるのか。
950:デフォルトの名無しさん
06/09/02 20:49:15
>>932
> MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
その程度のことのためだけにそんな演算子を付加するのか。
C#のget/setと変わらないくだらん機能だな
951:デフォルトの名無しさん
06/09/02 20:52:14
>>940のやり方なら間違った演算子定義は出来ないからいい。
問題があるとすれば右辺値の一番左の値がプリミティブじゃなかったときくらい。
952:デフォルトの名無しさん
06/09/02 21:28:30
>>942
俺的には、Java3Dの強化をなんとかして欲しいな。
953:デフォルトの名無しさん
06/09/02 21:29:01
>>947に激しく同意できる。
C++の二の舞になったら終わりだ
954:デフォルトの名無しさん
06/09/02 21:30:17
統合アーカイバプロジェクト並みの圧縮ファイル対応とか
デスクトップ周りでやらなきゃいけないことは、まだまだ沢山あると思う
デスクトップ周り専門のApacheみたいなグループが登場しないと無理だが
955:デフォルトの名無しさん
06/09/02 21:33:18
BigDecimalで演算子を使えるようにしてくれって要望は、
BigDecimalクラスをラッパークラスとするプリミティブなbigdecimal型を
用意するっていうC#のdecimal型でどうにかするって手もあるが、
あれは、128bits限定だからな。
BigDecimalのコンストラクタにMathContext.DECIMAL128を設定した
精度しか得られないしな。
956:デフォルトの名無しさん
06/09/02 21:34:11
>>954
圧縮ファイルで一体何をしたいんだ？
つか、Jakarta Commonsにそれっぽいのないか？
もしくはSourceForgeにありそうだが
957:デフォルトの名無しさん
06/09/02 21:39:17
何がしたいって聞くようなことか？
958:デフォルトの名無しさん
06/09/02 21:41:01
Commons Compressだったかがβすら出ずに存在したような気がする
959:デフォルトの名無しさん
06/09/02 22:24:20
>C#のget/setと変わらないくだらん機能だな
Java7の拡張の候補にプロパティが入っているのだけどな。
960:デフォルトの名無しさん
06/09/03 00:04:24
入ってたとしても、C#と全く同じってことはなかろうと予測
961:デフォルトの名無しさん
06/09/03 00:27:08
>>959それどこの記事でわかるの？
962:デフォルトの名無しさん
06/09/03 00:32:42
>>959がデマだったりすることはよくある。
あの文体は、いつものJavaスレを荒らしてるドトネト厨だから。
3年も4年も前からJavaスレや死滅スレで大暴れしてる変態。
963:デフォルトの名無しさん
06/09/03 00:35:56
やっぱりドトネト棒ってハズレだったんだね。
コーヒーの方が大人だね。
964:デフォルトの名無しさん
06/09/03 00:42:45
>>961-963
まずこのスレを「プロパティ」で検索してみたらどうなんだ？
965:デフォルトの名無しさん
06/09/03 00:45:38
URLﾘﾝｸ(journal.mycom.co.jp)
にしっかりと「プロパティのサポート」が発表されたと書いてあるんだが。。。
プロパティサポートといっても、それがget/set生成みたいなもの
なのか、式言語みたいに「obj.property」というようにアクセスできる
ようにする、という意味なのか、groovyの「@Property」みたいに
@Property size
とか宣言できるようにするのか、といった具体的な話はまったくない
わけだけど。
966:デフォルトの名無しさん
06/09/03 00:48:13
>>962
>>963
こういうやつらっていつになったらJavaの世界から消えてくれるんだろ
967:デフォルトの名無しさん
06/09/03 01:05:16
>>963
ドトネト棒って語呂と名前がｳｹﾙw
968:デフォルトの名無しさん
06/09/03 01:08:17
>>965
その、アノテーションっぽい気がした。
@Propertyならいいねえ。
get/setはねえちょっと。
getter.setterに相当するメソッドに
@Propertyアノテーションをつけるのが妥当って感じだね。
969:デフォルトの名無しさん
06/09/03 03:11:05
>>967それも棒の先には「おまえらは、ハズレ」って書いてあるんだろうだしｗｗｗ
970:デフォルトの名無しさん
06/09/03 10:27:31
>>946
「ストラウストラップが警告した事項」って具体的に何？
>>947
おいおい、Javaは静的な型があるんだから、別にコード全体を見るまでもなく、変数の宣言部分をみれば配列かListかはすぐに判断できるし、別に混乱なんかしないだろ。
この程度で混乱なんかしないでくれよ。
>>949
[]は単項演算子じゃなくて、+や-と同じ２項演算子だよ。
それに演算子の動作を自分で定義できることと、演算子の優先順位は関係ないよ。
PythonもRubyも演算子の動作を自分で変えられるけど、優先順位は変えられない。だから別に混乱しない。
>>950
でもELでは[]でアクセスできるようになってるよね。「その程度」のことであれば、
ELでも[]でなくてgetter/setter使えばいいはずだし、もっといえばEL自体必要ない。
Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。
971:デフォルトの名無しさん
06/09/03 10:39:13
>>970
言っている事自体はだいたいまともだが
> Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。
とJavaユーザを一緒くたにして煽るのはやめてくれ。ELの[]が便利と言っている層とJavaには[]は
イラネと言っている層がどれくらい重なっているのか調べたわけでもないだろう？
972:デフォルトの名無しさん
06/09/03 10:43:14
そもそもJSP上でaddなんてしないんだから[]で何の問題も無いだろ
粘着にレスすんなよ
973:デフォルトの名無しさん
06/09/03 11:30:35
>>970
いっとくが、JavaとELとは全く別の言語だ。
Javaユーザが[]はイラネといってるのはJavaの文法にいらねといってるだけで
ELの文法に[]がいらねといっとるわけではなかろう。
そんなこともわからないでJavaエンタープライズアーキテクトを侮辱するとは
身の程知らずもいいところだ。
974:デフォルトの名無しさん
06/09/03 11:50:25
JavaとELとが別言語なんてのはだれだってわかってる。
だからなんでわざわざELなんて用意されたかを考えろや。
Javaそのままだと書きにくいからELが用意されたんじゃないの。
Javaの書きにくさのひとつとして list.get(1) や map.get("key") があり、
これが list[1] や map["key"] とかけたらいいなといってるだけ。
ほんとうにlist.get(1)やmap.get("key")が書きやすい/読みやすいなら
ELでもそれをつかえばいいだけ（ELにはメソッド呼び出しないけど）。
「JavaとELとが別言語」なんて話がずれるだけじゃん。
975:デフォルトの名無しさん
06/09/03 12:13:34
>>971
> とJavaユーザを一緒くたにして煽るのはやめてくれ。
一緒くたにしている馬鹿には馬の耳に念仏では?
976:デフォルトの名無しさん
06/09/03 13:45:49
ｽﾚﾘﾝｸ(tech板)
次スレ
977:デフォルトの名無しさん
06/09/03 14:06:08
>>970
ストラウとラップは演算子のオーバーロードを
誤った使い方をするとろくなことがないぞってことを言ってるんだよ。
誤った使い方をしなければいいといっても
誤った使い方をする奴は腐るほどいるし。
それで複数の会社組織が独自に演算子を定義して
デスマって酷いことになるわけだ。
978:デフォルトの名無しさん
06/09/03 14:07:23
>>974
じゃあさ、お前にはなんでJakarta Velocityみたいなのが
用意されたのかわかるの？
プリプロセッサではなくVelocityが用意された理由を。
979:デフォルトの名無しさん
06/09/03 15:24:48
[]のオーバーロードは欲しいな。
980:デフォルトの名無しさん
06/09/03 15:35:42
ListだったらどうせIterator経由でアクセスしない？
List.getなんて滅多に使わなくないか？
981:デフォルトの名無しさん
06/09/03 17:07:07
んだな
982:デフォルトの名無しさん
06/09/03 17:47:33
しかもIteratorにはfor(:)の砂糖が既に入ってるしな
983:デフォルトの名無しさん
06/09/03 19:27:06
うむ、そうだ
984:デフォルトの名無しさん
06/09/03 20:02:49
次世代は無糖でｗ
985:デフォルトの名無しさん
06/09/03 20:23:27
new ArrayList=("あああ","いいい","ううう");
みたいに出来んかな。
public ArrayList(String... varArgs);
こんな感じのコンストラクタで。
986:デフォルトの名無しさん
06/09/03 21:05:54
>>985
それもだけど、
ArrayList#addAll(Collection<? extends E> c);も、
c.toArray();で配列に直してから使ってる。
ArrayList#addAll(E[] c);がないのはもったいない。
987:デフォルトの名無しさん
06/09/03 21:46:14
>985
Arrays.asListでいいんでないの？
988:デフォルトの名無しさん
06/09/03 21:55:40
あーたしかにコレクションをパっとつくりたいと思ったことはあるな。
とくにテストコードで。
今だと
List strList = Arrays.asList( new String[]{"test1", "test2"});
とかやっててくどいとは思う。
一方で、Javaの、文法はシンプルに、機能はクラスライブラリで、という
スタンスは嫌いじゃない。文法拡張するときは「そんな砂糖いらね」という
抵抗があったほうがちょうどいいと思うぞ。やたら拡張するよりはね。
989:デフォルトの名無しさん
06/09/03 23:11:48
>>987
確かに5.0のArrays.asListは
public static <T> List<T> asList(T... a)
だからまあ悪くないんだが、返ってくるのが変更不能リストなのがイマイチ
変更可能リストを返すメソッドが欲しいな。コードはこんな感じで
public class ListUtil {
public static <T> List<T> list(T... a){
List<T> newList = new ArrayList<T>();
for(T t : a) newList.add(t);
return newList;
}
}
使うときはstatic import使えば、
list("A", "B", "C", "D")
のようにするだけで変更可能なリストが作れるので便利
990:デフォルトの名無しさん
06/09/03 23:21:03
>>985
まるでPerlやPHPまんまだな
991:デフォルトの名無しさん
06/09/03 23:24:05
>>989
それもPHPまんまやないか
992:デフォルトの名無しさん
06/09/03 23:32:02
>>991
意味不明。PHPで、array(...)などとして配列が作れることを言っているつもり？
そんなもん別にPHP(やPerl)独特のものでもなんでも無い。
なんで厨はすぐに自分の知っている(好きな)言語の機能のパクリかのように言いたがるかなあ
993:デフォルトの名無しさん
06/09/04 00:30:14
なになに、どっちにしろ型の概念が曖昧な
スクリプト言語に共通する書き方だよな
994:デフォルトの名無しさん
06/09/04 00:52:40
>>980
for( : )使うことが多いけど速度の差も結構あるし
何番目かを意識したりループの中で挿入とか削除とかもある
for( : ) 使うのが80％くらいかな
995:デフォルトの名無しさん
06/09/04 01:05:58
O'Camlなみに型推論しる！
996:デフォルトの名無しさん
06/09/04 03:09:08
あのー・・・
997:デフォルトの名無しさん
06/09/04 07:23:57
>>989
Arrays.asListってlistの様に振る舞うけど、
結局は配列のままのwrapper返すんじゃないの?
998:デフォルトの名無しさん
06/09/04 07:32:05
>>997
確かそう。
これをArrayListに追加するときは、>>986のようにまた配列にもどして使うのでもったいない。
999:デフォルトの名無しさん
06/09/04 08:09:13
>>989
new LinkedList(asList(a, b, c, d))
でいいやん。
1000:デフォルトの名無しさん
06/09/04 08:17:59
asXxxはビュー(実態は変わらず見方を変えたもの)を返す、ってことだな。
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。