|
Christian Graus wrote:
that's a part of the decision to use it.
...if it only would have been MY decision... 
anyways, thanks for your help!
|
|
|
|
|
Christian Graus wrote:
At the core, C# is indeed slower thant C++
I don't want to start a big discussion but that's not true. Surely GDI+ is slower than GDI32 but you can improve the performance by calling the APIs directly. The speed will then be equally to C++ but you pay this off by having to use unmanaged stuff (which is not so nice in C# compared to C++).
|
|
|
|
|
Robert Rohde wrote:
you can improve the performance by calling the APIs directly.
Robert Rohde wrote:
by having to use unmanaged stuff
So, to recap - C# is as fast as C++ if you use it to call C++ APIs, so the work is done by C++ code ? That sounds like the 'VB6 is as good as C++' argument all over again.
Don't let the C++ MVP fool you, I use C# almost exclusively nowadays. But I would maintain that C++ is the faster language, for now. Making C# faster by getting it to call native methods kind of defeats the purpose, why not just use C++ ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
So, to recap - C# is as fast as C++ if you use it to call C++ APIs, so the work is done by C++ code ?
Now that's an real unfair statement. Unless we have some real innovative processors at some point managed code HAS to call unmanaged code - or how do you think a processor should understand it. If it is within the framwork or directly in your app by API calls does not make much difference (besides the matter of personal taste - I prefer MS doing this stuff  ). This is true for every .NET class. The problem with GDI+ (like many other things in .NET) is that it doesn't reveal the power of the whole underlying windows APIs.
|
|
|
|
|
ok, i heard that often before. nearly everybody tells me c# isnt (much) slower. but WHY is it really a lot slower when i check this myself?
as i really wanted to know now, i tried it myself (and feel free to do so, too) and took both (c++ of VS 6.0 and c# of VS.Net 2003) and let them calculate fibonacci numbers up to n=40.
MY results are:
VS6.0 & c++: 2.580 seconds
VS.Net 2003 & c#: 5.019 seconds
(results should be accurate down to less than 1 msec)
so why does c# require almost 2 times the time c++ does?
PLEASE check this yourself, let me know if i'm right and also tell me if i'm not correct...
i'd really like to know the truth and not just rely on some weird microsoft benchmarks.
both tests were build in "Release" configuration, without debug information and with code
optimization a.s.o.
the code was (both times called in first constructor and immediatly after each other, so u can't say it depends on any other circumstances like free RAM or things like that....)
c#:
private long fib(long n)
{
if (n < 2)
return n;
return fib(n-1) + fib(n-2);
}
c++:
long fib(long n) {
if (n < 2)
return n;
return fib(n-1) + fib(n-2);
}
both times the result was 102334155. so what am i doing wrong? why is c# so much slower for me than c++? just because of the excessive recursion and stack usage? should i try an example concerning
"only" function calls or memory access? or check the speed of _dynamic_ array operations?
second thing i don't understand is (and thx for the hint; i really need any solution and thus try this): you're saying c# and calling GDI+ APIs directly is as fast as c++; ok, but the GDI+ code remains the same wheather u call it directly or not. so if it's not GDI+ it has to be c# (what else?)... so isn't this in conflict with your first statement???
this should really be no offense, i only wanna know for sure how things are...
daniel.
|
|
|
|
|
l3st4rd wrote:
so why does c# require almost 2 times the time c++ does?
PLEASE check this yourself, let me know if i'm right and also tell me if i'm not correct...
Any .NET code gets compiled from MSIL the first time it is called. To do a proper benchmark, you need to generate the sequence twice, and time the second pass. Every function is compiled when it is first called.
l3st4rd wrote:
you're saying c# and calling GDI+ APIs directly is as fast as c++;
No, I said GDI. GDI is the way things are handled under the hood. HBITMAPs and BitBlt to HDCs.
l3st4rd wrote:
this should really be no offense, i only wanna know for sure how things are...
Not at all offended, glad to help.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
(well this post was primary addressed to Robert R. cause he did decline that c# is slower than c++ [what i can hardly belive], but anyway...)
Christian Graus wrote:
Any .NET code gets compiled from MSIL the first time it is called. To do a proper benchmark, you need to generate the sequence twice, and time the second pass. Every function is compiled when it is first called.
but anyways, i got some things to say about this:
1st) does any end-user take care to run any piece of program twice before he shouts out "hey, this is crap! it's way too slow!" ?
2nd) the algorithm i checked out was highly recursive. so isn't the appropriate function compiled the first time it is called and afterwards only the generated machine code beeing called? (the real code is really more than short, so the compile time [spread over some thousands function calls] should be really negligible ?)
|
|
|
|
|
l3st4rd wrote:
does any end-user take care to run any piece of program twice before he shouts out "hey, this is crap! it's way too slow!" ?
Most code gets executed many, many times in one use of a program. So, the cost is not that bad. But it IS a cost that needs to be considered. Or you can use NGen to run a precompiled executable and avoid this cost. However, the idea is that the .NET compiler can compile code optimised for your processor, etc.
l3st4rd wrote:
the algorithm i checked out was highly recursive. so isn't the appropriate function compiled the first time it is called and afterwards only the generated machine code beeing called?
Good point - in this case, it may not make much difference to the result. But it would still make some... (clutching at straws). I'm not here to defend C# at all costs, C++ is better at somethings, for sure. I'm a C++ MVP, for goodness sakes. I just want to make sure you are making a fair comparison.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
hey, i got _NOTHING_ against c#. it's really nice for developing some tools / smaller apps. the developement time is (compared to VC 6.0) MUCH faster. i use c#.NET alot, but i think there're some situations where c# is just the wrong choice. but with the project i'm doing at the moment (it's my master thesis) i had _NO_ choice which language to use, so i try to make the best of it. and i feel sloppy delivering a kinda working program which every user would complain about. i used c++ (and mfc) for years so i'm also tending to c++ (never ever tried c++.Net...) but now i gotta write my prog using c# and i give a f*** which language is better, i just wanna write a good program; thats all!
(IMO c++ is better, but this doesnt care here, i don't wanna start a discussion about this, every language has its warranty....)
|
|
|
|
|
l3st4rd wrote:
i think there're some situations where c# is just the wrong choice.
Agreed - it's not a magic bullet.
l3st4rd wrote:
never ever tried c++.Net...)
LOL - did anyone ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
l3st4rd wrote:
so why does c# require almost 2 times the time c++ does?
Like Christian already stated there are some things you have to consider when testing .NET apps especially converning startup time. If I find some free minutes later this day I'll make a test myself.
l3st4rd wrote:
but the GDI+ code remains the same wheather u call it directly or not. so if it's not GDI+ it has to be c# (what else?)
Like Christian stated: GDI and GDI+ are totally dieferent (except for the GDI in the name  ).
|
|
|
|
|
think you got me wrong; i meant that if not GDI+ is causing the code to be slower (you said it's nearly as fast as c++ [and GDI] when directly calling the APIs) doesn't this also mean that c# (or better the framework) is causing the code to be slower?
on the other hand you said c# is'nt much slower than c++, so this is kinda confusing...what you think is now actually responsible for the graphics beeing drawn much slower ?
(when i spoke about "c#" i did of course always mean c# AND the framework, as c# without framework is useless...)
|
|
|
|
|
i tried DrawImageUnscaled; it sounds very reasonable to me that this method is faster than DrawImage, but in fact i can't measure a real difference... DrawImageUnscaled takes ~ 46-56 msec and DrawImage ~ 46-51 msec (for almost the whole screen).
is it possible that both methods result in DrawImageUnscaled beeing called if the source and dest size is exactly the same?
(i'm asking cause the actual behavior is really unacceptable for my customer and me and i really need to find a better solution)
|
|
|
|
|
Microsoft recommend using the Unscaled method. Why is 50 msec unacceptable ? How often does it need to do this ? What's the actual task, and the speed you're after ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
well i wanted to be able to draw a whole screen on every MouseMove (probably you already know, but this works quite fine under VS6.0 & c++)
i first compared the execution time of BitBlt and DrawImage<unscaled> (and thus have been after a speed of < 10 msec) but i just realized that GDI code resides in kernel mode and a different thread and so i'm not so sure about how much i can give about that results... (but as i'm guessing the video driver is using direct IO and thus assuming the execution times of the these methods are quite relevant), i'm looking for execution times below 10msec...
but i'm looking for nothing more than moving objects of any size smoothly with c#...
daniel.
|
|
|
|
|
Have you considered doing your drawing using managed DirectX ? I don't see any other way that things are going to go faster for you, to be honest, and it really sounds like this project needed to be in c++.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
i don't have a clue about managed DirectX (just played arround a bit with unmanaged DirectX) but sounds like a nice idea (except that it also sounds like quite a lot of work...)
but i'll consider this proposal...DirectX does result in unmanaged, pure and fast c code, right?
|
|
|
|
|
Managed DX basically gives you easy access to DirectX, which is all unmanaged code, AFAIK. Certainly, it's for writing games and can handle moving your bitmap about. I'd download the SDK and see if the samples give you samples of the stuff you want ( a windowed app would be your first priority IMO ).
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
yeah, right: a windowed app IS my first priority....
u know wheather there's also such a 'wrapper' for OpenGl (cause i'm more familiar with OpenGl than DX, but ok, stupid question, i could also have a look myself....)
i also considered doing all the graphics stuff in c++ and importing this to the c# app (but as u can guess, this will be quite a lot of work, too...)
well...at least this discusion told me not to do any further research about fastening up the c# code, thats quite a big afford, too...
so thanks for your help, as a start! 
|
|
|
|
|
The nehe site would have it if it can be done, but I doubt it could be done as cleanly as DX is.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
...and yes! i'd love to do this project in c(++)...
|
|
|
|
|
|
Anyone who uses 'words' like 'noob' is a certified moron in my opinion.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
you're not better, and you don't need more than my 1
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
so am i missing anything or is GDI+ ... REALLY soooo slow?
GDI+ is not hardware accelerated  so you would get roughly the same performance regardless of whether you were using C# or C++
is there ANY other way than porting the whole code to use imported GDI32 APIs ?
Not if you want it as fast as possible
"I think I speak on behalf of everyone here when I say huh?" - Buffy
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
