If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Anyone calling GDI+ "highly optimized" is either insane or misinformed.

It doesn't matter what you think of gdi+, it's still doing the heavy lifting in Paint.net. So if you think Paint.net is performant, than gdi+ can't be all that bad. Granted, I've only used gdi+ with native code, and thus I don't have to suffer the overhead generated when making calls from managed to unmanaged, but that has nothing to do with gdi+.

Originally Posted by BlackStar

The examples given here refute the claim that you cannot create performant managed applications. You seem to be interested in something else entirely, namely language microbenchmarks.

No, I'm interested in comparisons between the performance of the code the actual languages create. Currently the closest thing to a fair comparison would be the Language Shootout benchmarks, since a) the programs are 100% done in the language they represent b) the programs solve the exact same problem.

And no, I've never claimed that you can't create 'performant' managed applications. Since what qualifies as 'performant' differs greatly depending on application. What I am claiming is that native code will be more 'performant' than managed code, and thus if performance is of key importance to your application, native code is the choice.

What I am claiming is that native code will be more 'performant' than managed code, and thus if performance is of key importance to your application, native code is the choice.

Let's assume that C++ is on average 50% faster than C#. A typical game might spend 50% of its time in OpenGL drivers, 25% in physics, 5% in OpenAL, 5% in networking, 10% in scripting (AI, game code) and 5% in other CPU tasks (frame setup, input handling, timing etc).

Using C++ would grant me a 2.5% speed advantage in CPU tasks and maybe another 2.5% due to interop overhead. The rest of the tasks are not affected by the choice of language.

5% better framerate in C++? Big effing deal. You can get that 5% back by spending a couple of days tweaking your OpenGL shaders in the C# version. A couple of days? Yes, that's the aggregate compilation times for the C++ version.

As I said, applications are not created in a void. Language performance is meaningless on its own in everything but purely math code. Every other task will have to rely on OS components, middleware libraries and tons of other modules with their own performance characteristics. Does it matter that Python is 50% slower than C, when all the program is doing is copying files on disk, manipulating XML, executing SQL queries or waiting the OS to finish redrawing the window?