くだすれＣ＃(Part3)

C#って限界ありすぎ

>>925
Remoting 使へよ

>>952
煽りかもしれんが、どこらへん？
俺結構なんでもできるなー、と感心しているんだけど。
面倒なのはAPIとかCOMとか使う時に自分で定義を書かないといけないことぐらい。

遅いのはアレだけど。限界てアレか。起動速度か？

>>954
毎日書いてる人だよ。

>>951
unsafeの説明で、
「unsafe コードは、配列の境界チェックを省いてパフォーマンスを向上させます。」の
一文がありますね。
そうか・・これで速度向上するかも！と思って、ためしに関数をunsafeにしてみたんですが、
結果は残念ながら、まったく変化なしでした。。。

unsafeとfixedステートメントを使って、配列に内容をセットするのに
ポインタを使うコードに書き直してみましたが、3.8秒かかっていた処理が
3.2秒になる程度でした。
なんか抜本的な間違いをしているのでしょうか？　(x_x)

ーーーーー差し替え部分ーーーーー

st=System.DateTime.Now;
for(int i=0;i<intMAX;i++)
{
fixed(PT* pp=&p[0])
{
for(int j=0;j<5000;j++)
{
pp[j].x=j;
pp[j].y=j;
}
}
}
ed=System.DateTime.Now;

ApplicationのアイコンとMainFormのアイコンの指定が別々でウザイね。
無駄にサイズが増える。

>>936
うーん、ｃ＃とｖｂが同じといわれると、ちょっと残念な気がする、、。
だったら、最初からvbで楽にプログラムすればいいきがするし、、、。

>>959
そうだよね。
しかも、もっとショックな結果が・・・・　(´･ω･`)

VB6のネイティブコンパイルのほうがC#.NETよりも速い

んだよね・・・。('A`)・・・
いくらなんでも、んなことあるか！！と思ったんだけど、
少なくともこのケースに限っては間違いない。

ほぼ同じ処理を走らせるのに、
C#.NET（unsafe）が 3.29秒、VB.NETが4.2秒、VC6が1.25秒、
VB6が2.48秒でした。

C♯の限界がまた一つ垣間見えますた。

>>961
お前の限界

>>960
> いくらなんでも、んなことあるか！！と思ったんだけど、
その根拠はVBは遅いっていう先入観だろ？
論理的に考えればネイティブコードの方が速いのは当然だと思うが。

>>963
んー　ちょっと違うかな。
VBが遅いというイメージも確かにあったけど、それ以上に
C#.NETは仮にもC言語の系列なんだから、そう遅くはないはず・・・という
イメージがあったから。
でも、今でも自分の手法のどこかに間違いがあることを
期待してるんだけど・・　(´･ω･`)ｼｮﾎﾞｰﾝ　新しい案件で.NET使いたいよーーー

>>964
C言語の系列って文法の話だろ。
例えばC言語にもインタプリタはある。
当然それはC言語の系列というかC言語そのものだが
C言語のコンパイラよりも遅い。
実行までの仕組みを考えれば自ずと答えが出るはずだが。

うーん、結局．net系は
今から１０年後とかのマシンが超早くなった時代を考えて作られた言語なのかな？
vbよりも遅いってのは俺としてもマジショック！！
俺は最近ｃ＃買ったんだが、vb買えばよかったのかな？とも思ってしまう、、、。
ｃ＃は意外に速い、、、と言う話もあったはずなんだがなー、、、。
その話はどこへ行ったんだろう、、、。

>>965
でも、ｃ＃だって一応コンパイラーでしょう？

>>967
.NETやJavaとC言語(VC6やBCB等のネイティブコードを吐く奴)の
コンパイルされてから実行されるまでに行われるプロセスの違いに
ついて勉強することをオススメする。

>>966
そんなにショック受けるなよ。JavaだってVBより遅いんだし。

>>965
んーー
そういう理屈で言えば、VB6のネイティブコンパイルはほぼ
VC6のReleaseと等価でないとおかしくない？
でも実際は、配列の範囲チェックとかはずしても、倍程度時間がかかる。
結果を見る前に理屈だけで推測するのってけっこう難しい気がするよ。
実際、VB6がまだ正式版が出る前には、VCと同等のスピードが
出ますって触れ込みだった時期もあったんだけどね・・・。
（残念ながらソースは手元にないです）

>>970
コンパイル結果(実行内容)が等価でないのだから
その分の差が出て当然だろ。
コンピュータは気分で動いているのじゃないのだから
遅いのにはちゃんとした理由がある。

>>957

そのコードほんとに intMax 回実行されてますか？
ベクトル化スーパーコンピュータでも数秒で終わる処理とは
思えないけど。

>>971
＞コンパイル結果(実行内容)が等価でないのだから
＞その分の差が出て当然だろ。

もちろんそう。俺が言いたいのはそういうことじゃなくて、
その「遅いちゃんとした理由」を、試す前に理屈だけで
得られるのかどうかってことだよ。
たとえばVB6が発表段階の時に、VC6の半分の速度しか
出ないってことが理屈だけで予想できたとは思えないんだけど・・・。
まあ、できたと言われりゃそれまでだけどｗ
んー　それよりも本題は、これが本当にC#.NETの実力なのか
どうかってことです。たまたまC#.NETにとって最悪なケースで
テストしてしまったのかもしれないし、コーディング次第でもっと
変わりそうな気もする。
もうちょっといろいろ試してみます。

>>972
はい、実行されていると思いますよ。
ループから抜けたあとの i の値を見たら、ちゃんと intMax と
同じ値になってますし。

>>973
最悪なケース化といわれれば最悪なケース。
そもそもJavaや.NETは単純なループをまわすためになんぞ設計されちゃいない。

>944のコード試したら12秒かかった^^;

素直に.NETの限界ですって言えよ。

>>976
ちなみにマシン性能は？
うちは P4 1.8 + Mem512 + XP Pro です。

なお、配列の範囲チェックに時間食ってるのかと思って、ためしに
配列じゃなく一個だけの変数に値を入れるように変更してみたけど、
おおむね速度比率的に変化なしでした　(x_x)

Javaでベンチするとどんなもの？

>>977
素直にお前の限界って認めろよ。

>>973
俺が言いたいのは理屈で考えればネイティブのVBの方が
C#よりも速いと言うことは十分予想できるのに
そんなに驚くなって言うことだよ。

C#の方が速い(VBの方が遅い)ってのは理屈に反した
思い込みでしかないだろ。

>>981
驚く驚かないは個人の自由だと思いますがｗ
試しもしないで思い込みで決め付けてたなら問題ありですけど。
もうその話はやめませんか？
自分にとっては「事実として遅かった」「どうにかして速くできないか」という
ことが重要であって、自分の予想が合ってただのはずれてただの
ということはどうでもいいんですが・・・。

ちなみにハンドル間違ってました。935の人ｽﾏｿ。934でした。

>978
P3-600　512MB　XP Pro

ついでに >957 に差し替えると .8.8秒くらい

>>982
おれはC#がVC6の三分の一もの速度が出たことに驚きましたが。

実際にモノが出てから、俺にはこの結果は分かってた
なんてのは誰にでも言えるわなｗ
２年ぐらい前の.NET系のメーリングリスト読むと、ある程度
知識がある人たちの間でも意見が分かれていたことが分かるよ。

>>985
まっ世の中には先入観で断定してしまう奴がいるってことだな。
半分くらいはわざと悪いデマを流しているような気もするが。

ネイティブに勝てないことくらい思いつけよ

粘着(+д+)ｳｻﾞｰ

次スレ名は前々スレにあったように

ふらっとC♯

希望。

ならお前が立てれよ

得意げに結果が分かってたというﾔｼは恥知らず

>>990
立てたいけど立てられないのでお願いしておる次第です。

立てたよ。

ふらっとC♯（Part4）
http://pc2.2ch.net/test/read.cgi/tech/1059028988/l50

埋め埋め。

梅　梅

(ﾟдﾟ)ｳﾏｰ　(ﾟдﾟ)ｳﾏｰ

1000!!

998

999
↓1000おめ。

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。