.NETはどの程度遅い？
150 ：デフォルトの名無しさん：03/07/30 01:54
>>107
わたくしの勘違いか？
誰かソース取ってきて試した人いる？
実験２のガウスで逆行列求めるプログラムを同じ回数 1000000回で
vcとc#で実行
vc --> 0.585sec
c# --> 3.424sec
ページの結果とぜんぜん違う。
わたくしの勘違いか？
誰かソース取ってきて試した人いる？
実験２のガウスで逆行列求めるプログラムを同じ回数 1000000回で
vcとc#で実行
vc --> 0.585sec
c# --> 3.424sec
ページの結果とぜんぜん違う。
151 ：デフォルトの名無しさん：03/07/30 02:34
>>150
実験１のほうしか試してないんでわからんが、
たぶんソースの保存状態が一部、一貫してないんだと思う。
ManagedC++,C++,C#で比較したけど
大部分の速度差の原因はmathライブラリの差だった。
s = pow(x,2) - exp(x);//C
s = Math::Pow(x,2) - Math::Exp(x);
n = floor(log((b - a) / limit) / log(2.0));//C
n= Math::Floor(Math::Log((b - a) /limit) /Math::Log(2.0));
実験１のほうしか試してないんでわからんが、
たぶんソースの保存状態が一部、一貫してないんだと思う。
ManagedC++,C++,C#で比較したけど
大部分の速度差の原因はmathライブラリの差だった。
s = pow(x,2) - exp(x);//C
s = Math::Pow(x,2) - Math::Exp(x);
n = floor(log((b - a) / limit) / log(2.0));//C
n= Math::Floor(Math::Log((b - a) /limit) /Math::Log(2.0));
152 ：デフォルトの名無しさん：03/07/30 15:33
.NETの限界が垣間見えますた
153 ：デフォルトの名無しさん：03/07/30 15:39
実験結果を見ると、C#アプリってちゃんと起動した後は、C++に
近いスピードなんだが･･･
その前に起動が遅すぎる。
ランタイムがメモリ食いすぎなんじゃないか？
近いスピードなんだが･･･
その前に起動が遅すぎる。
ランタイムがメモリ食いすぎなんじゃないか？
154 ：デフォルトの名無しさん：03/07/30 16:10
ネイティブコードとの速度比較なんて、やる気ねいてぃぶよ。
ｗ(＾д＾)ｗ ｷﾞｬﾊ
ｗ(＾д＾)ｗ ｷﾞｬﾊ
155 ：デフォルトの名無しさん：03/07/30 16:47
VCPPML に、MSVC用のレイアウトマネージャー落ちてるよ
156 ：デフォルトの名無しさん：03/07/30 18:30
157 ：デフォルトの名無しさん：03/07/30 18:40
息子だったら勘当しているところだ
158 ：デフォルトの名無しさん：03/07/30 18:50
もう一発キター！
159 ：デフォルトの名無しさん：03/07/31 08:32
J2EE and .NET Performance case study
http://www.middleware-company.com/casestudy/tmc-performance-study-jul-2003.pdf
http://www.middleware-company.com/casestudy/tmc-performance-study-jul-2003.pdf
160 ：デフォルトの名無しさん：03/07/31 08:41
WebServiceでは相変わらず.NETの圧勝だな。
161 ：デフォルトの名無しさん：03/08/01 12:40
OSごとだとどの程度の差があるんだろう。
やはり2000が一番早いのかな
やはり2000が一番早いのかな
（＾＾）
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
164 ：デフォルトの名無しさん：03/08/24 15:36
コンパイラに相殺機能があるなんてしらんかった
165 ：デフォルトの名無しさん：03/08/24 18:20
一発目が遅いのは、ネィティブにコンパイルするからでしょ
166 ：デフォルトの名無しさん：03/08/25 13:15
>>165
一発目も遅いし、二発目以降もずっと遅い。
一発目も遅いし、二発目以降もずっと遅い。
167 ：デフォルトの名無しさん：03/08/25 13:24
CLRの初回起動以外は違うアプリでも速いのは結構すごい。
168 ：デフォルトの名無しさん：03/08/25 14:13
速いといっても、実際は結構遅い。
169 ：デフォルトの名無しさん：03/08/25 15:06
ネイティブにコンパイルされるというより、
ランタイムライブラリがキャッシュされている方が効いているような気がする
ランタイムライブラリがキャッシュされている方が効いているような気がする
170 ：デフォルトの名無しさん：03/08/25 16:20
ランタイムライブラリがキャッシュされるのは、別に.NETに限らない。
単なるDLLでもそういう結果となる。
だから、
>CLRの初回起動以外は違うアプリでも速いのは結構すごい。
はキティ。
単なるDLLでもそういう結果となる。
だから、
>CLRの初回起動以外は違うアプリでも速いのは結構すごい。
はキティ。
171 ：デフォルトの名無しさん：03/08/25 16:49
172 ：デフォルトの名無しさん：03/08/25 16:57
>>170
Javaだと複数VM立ち上げたりするから。
Javaだと複数VM立ち上げたりするから。
173 ：デフォルトの名無しさん：03/08/25 23:11
JAVAはVAKAだね
174 ：デフォルトの名無しさん：03/08/27 06:44
VBランタイムより遅いのか。
どこまでローテックなんでしょうかMICROSOFTDOTNETFRAMEWORKは
どこまでローテックなんでしょうかMICROSOFTDOTNETFRAMEWORKは
175 ：デフォルトの名無しさん：03/08/27 11:48
ローテックではありません。
新しいWintel製品の販促ツールでつ。
新しいWintel製品の販促ツールでつ。
176 ：デフォルトの名無しさん：03/10/14 21:39
結局、やっぱ３次元ソフトとかには向かないよね
MFCのサポートいつまでやる気かな＞MS
MFCのサポートいつまでやる気かな＞MS
177 ：デフォルトの名無しさん：03/11/21 23:45
.NETの方がメモリを余分に食うのだがな。
メモリ食いすぎじゃボケ
メモリ食いすぎじゃボケ
178 ：デフォルトの名無しさん：03/12/07 08:14
179 ：デフォルトの名無しさん：03/12/07 12:18
現状そこまでして使いたいソフトが.NETに存在しないのだ。
180 ：デフォルトの名無しさん：03/12/08 01:51
マネージコードとネイティブコードの問題が取りざたされていたが、
将来性とインストール時の安全性で．Ｎｅｔなんじゃないのか？
将来性とインストール時の安全性で．Ｎｅｔなんじゃないのか？
181 ：デフォルトの名無しさん：03/12/10 13:15
>179
おまえが作れ
というか、MS-Officeが.NETへ移行したら
みんな、移行せざるを得んだろうな
おまえが作れ
というか、MS-Officeが.NETへ移行したら
みんな、移行せざるを得んだろうな
182 ：デフォルトの名無しさん：03/12/10 13:50
マネージドだと境界チェックが入る分遅くなるらしいね。
183 ：デフォルトの名無しさん：03/12/10 14:00
っていうか、ウィンドウズネイティブでx86依存なのに.netで遅くする必要あんの？
mfcで良いじゃん。
JavaはUNIXとかalphaとか携帯とか色々移植するから遅いのも解るんだけど、
.netでウィンドウズネイティブなんだから遅い必要なんか無いだろ。バリバリ
ネイティブコードで書いて速度上げろ( ﾟДﾟ)ｺﾞﾗｧ!とか思う。
mfcで良いじゃん。
JavaはUNIXとかalphaとか携帯とか色々移植するから遅いのも解るんだけど、
.netでウィンドウズネイティブなんだから遅い必要なんか無いだろ。バリバリ
ネイティブコードで書いて速度上げろ( ﾟДﾟ)ｺﾞﾗｧ!とか思う。
184 ：デフォルトの名無しさん：03/12/10 14:03
185 ：デフォルトの名無しさん：03/12/10 14:16
>>184
そのうちって何時よ？
そのうちって何時よ？
186 ：デフォルトの名無しさん：03/12/10 14:27
>>182
境界チェックって配列の境界チェックの事か？
境界チェックって配列の境界チェックの事か？
187 ：デフォルトの名無しさん：03/12/11 12:40
>>183
x86は長くない。いずれItaniumとx86-64に分裂する。
x86は長くない。いずれItaniumとx86-64に分裂する。
188 ：デフォルトの名無しさん：03/12/11 14:55
AMDとINTEL両方に備えないとな
CEなんかすでにマルチプラットフォームだし
NT自体もAlphaやMIPS、PPCでも動くし
CEなんかすでにマルチプラットフォームだし
NT自体もAlphaやMIPS、PPCでも動くし
189 ：デフォルトの名無しさん：03/12/11 15:00
> NT自体もAlphaやMIPS、PPCでも動くし
NT時代にMSIL（みたいなの）が存在しなかったのが衰退の原因だったからねー
JavaはAppletだけでとてもWin32を置き換えられるものじゃなかったし
NT時代にMSIL（みたいなの）が存在しなかったのが衰退の原因だったからねー
JavaはAppletだけでとてもWin32を置き換えられるものじゃなかったし
190 ：デフォルトの名無しさん：03/12/11 22:43
.NETも重いしIISと心中したし、と思ってたら、
今度はWinFXでsql鯖なんかも組みこんでさらに重くなる。
今度はWinFXでsql鯖なんかも組みこんでさらに重くなる。
191 ：デフォルトの名無しさん：03/12/11 22:47
>>190
いや、.NETはOSに組み込まれるから死滅することはありえない。
WinFX: An All-Managed API
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm
これ読むとWinFXがWin32を使用していないということが良く分かる。
いや、.NETはOSに組み込まれるから死滅することはありえない。
WinFX: An All-Managed API
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm
これ読むとWinFXがWin32を使用していないということが良く分かる。
192 ：デフォルトの名無しさん：03/12/11 23:01
.NETがOSに組み込まれてM$ワールドが死滅か。
193 ：デフォルトの名無しさん：03/12/11 23:02
194 ：デフォルトの名無しさん：03/12/11 23:12
.netが普及すると64bitCPUに移行しやすくなる気がする。
195 ：デフォルトの名無しさん：03/12/12 09:58
気がするだけ。
Win16からWin32に逝こうは問題が無いどころか環境がゆるくなった。
Linuxだって64bitだし、Win64出るの遅杉。
Win16からWin32に逝こうは問題が無いどころか環境がゆるくなった。
Linuxだって64bitだし、Win64出るの遅杉。
196 ：デフォルトの名無しさん：03/12/12 17:28
intとポインタが同じサイズの限り、
俺のプログラムはどこでも動く様に作られている。
まあ16bitじゃ無理だが。
俺のプログラムはどこでも動く様に作られている。
まあ16bitじゃ無理だが。
197 ：デフォルトの名無しさん：03/12/13 03:38
> intとポインタが同じサイズの限り、
198 ：デフォルトの名無しさん：04/03/22 23:17
D言語よりも遅い
俺は unsigned char と bool しか使わない。