|
I wouldnt say that, since, as stated, OpenGL is a fairly thin layer over hardware.
Virtually all 'rendering' is done by the language manipulating the API. Here, C# is putting points in space, animating them, and all the rest of the hard work typically done by a 3D engine.
The hardware is texturing and rendering it, and, like all 3D programs, OpenGL (or DirectX) is just the API through which this is communicated to the hardware, and very little work is ever done by OpenGL itself (with most modern cards anyways).
Now, if you are using software OpenGL, it would be a different story. Then you can say C/Assembly is doing most of the work.
// Rock
|
|
|
|
|
Thanks for enlightening me
I never thought about that stuff this deep.
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
I have to agree with Fazlul when he disagrees with your statement that:
it seems like it is a decent language after all and possibly an effective replacement for the C++ even in demanding field of real-time graphics
Why? Because small engines (like this one) spend most of their time doing rendering (in hardware) - as opposed to interpeting C#. Rest assured that as the engine gets bigger and implements better algorithms (like visibility culling which is more complex than a BSP tree, terrain algorithms, AI, script parsing, etc), the engine will fall further and further behind the benchmarks of a C or C++ engine because the engine will actually begin to spend a significant amount of time inside the C# code (which will be inherently slower than C/C++).
Here's an example:
Let's say that your application spends 0.01 seconds of it's time interpreting 10000 lines of C#. Then, it spends 0.03 seconds actually inside OpenGL (C/asm code) and doing rendering. This makes the entire scene rending take 0.04 seconds, or 25 frames per second.
Now, 10000 lines of code for an engine isn't much. As the engine gets bigger and starts doing more complex things, it might grow to 100,000 lines. This pushes the time spent in C# to 0.1 seconds, for a total of 0.14 seconds, or 7 frames per second.
The problem is that you don't see the speed problems of a C# engine when it is small.
|
|
|
|
|
Brit wrote:
Here's an example:
Let's say that your application spends 0.01 seconds of it's time interpreting 10000 lines of C#. Then, it spends 0.03 seconds actually inside OpenGL (C/asm code) and doing rendering. This makes the entire scene rending take 0.04 seconds, or 25 frames per second.
Now, 10000 lines of code for an engine isn't much. As the engine gets bigger and starts doing more complex things, it might grow to 100,000 lines. This pushes the time spent in C# to 0.1 seconds, for a total of 0.14 seconds, or 7 frames per second.
Fortunately, performance degradation is not quite as linear as that. Just because 10K lines take 0.01sec, it doesnt mean that 100K takes 10 times as long. In most cases, 99% of the performance hit occurs in 1% of the code. Its quite feasible to use a language like C#, or Java to develop a game engine. You'd certainly develop it faster. Then find the code that is bottleneck and optimise it, perhaps by writing that in unmanaged C++.
|
|
|
|
|
I was not really assuming it was linear. Rather, I was making the point that the more processing which must be done in the engine's code (which is C#), the more you'll see performance degrade - because the C++ version of the same function would be much faster (5x faster from what I've seen). I wanted to illustrate the fact that a small C# engine doesn't prove anything about whether a big C# engine is fast enough to be competitive with a C++ engine. Even worse, you won't really see the preformance problems until the engine is pretty well developed.
The 99%/1% figure that you use is not terribly realistic. In 3D software I've written, we had to limit each component a budget -- because each part (animation, physics, occlusion, etc) wanted a big chunk of rendering time. Each time we'd add a new component, we'd say, "Why did that hit our framerate so much?"
If the engine remains small and doesn't need a whole lot of functionality, fine. Afterall, most processors are fast enough that an inefficient engine can still get a good framerate. But, if it is to be a full-featured finely-tuned engine, and you wanted as many polygons as possible in the scene, I wouldn't go anywhere near C#. (At least not until MS creates it's C#-to-native-code compiler.)
|
|
|
|
|
You guys keep writing things like "interpreting" and "until MS
creates its C#-to-native-code compiler". Am I missing something
or is that just bogus? To my understanding, C# (or any other
.NET language for that matter) code *is* compiled to IL code
at compile-time and JIT-compiled at (first) run-time to
native processor code. So the first time you run a C#
executable there is a delay before the program runs caused
by the JITting but from then on it's all just as fast as
running native code produced in the unmanaged world.
I think that, if your code is careful in avoiding garbage
collection as much as possible in "the inner loops",
C# code should execute just as fast as C++, if not
faster (more specific hence better processor
optimizations).
Just my 2 cents, I would love to be proven wrong
though. (really!)
eltwo
|
|
|
|
|
You are correct. In many ways it is as fast or faster especially with string type manipulations. There can be a JIT performance hit if the assembly hasn't been compiled yet but even this can be circumvented with NGEN.exe (native image generator).
There can also be opportunites (when you're really sure) when you can use unsafe pointers to speed up tiny loops; and all this without the exorbitant c++ syntax.
One thing to avoid is the CLR/unmanaged boundary which, because of marshalling, is very expensive performance wise. With that said, even DX9 is fully CLR/managed accessible.
|
|
|
|
|
Thank you for making that point. Here is some evidence to support that C# can be faster than C++:
Two open-source Linux implementations of Microsoft's .NET are called Portable.NET and Mono. Each have a C# compiler. Portable.NET's C# compiler is written in C. Mono's is written in C# itself. Mono's is significantly faster.
Whether that's optimizations by the compiler or simply because it's a more elegant language, the point is that it is easier to create a fast program in C# than in C.
My source: http://www.go-mono.com/faq.html#pnpproject
|
|
|
|
|
I must strongly disagree with your point of view.
First I'm not shure that you understend the actual mechanism of C#/.NET. The code isn't interpreted, it's compiled at runtime and then executed just like C++. It is like 2 times slower than the same C++ code at worst, and usually much less.
I've seen few comercial 3D graphic projects and worked on one, and I rarely saw a method or algorithm that couldn't be more optimized, just wasn't because: the developers didn't know how, or spent time on optimizing unimportant parts (without carefull measurement of bottlenecks) and, mostly, it was too expensive to spend developer's time on it when other milestones should be reached on time. If the C# development is faster than C++ then more time is left for optimizations, leaving the team with better performing code on the end.
Also it is common thing that as the project grows in size it actually benefits of higher level language and faster development environment since the code organization plays more and more important part.
If it was otherwise, like you said, then no one would even think of moving to C++ from C or ASM.
And if you have some critical code sections like some BSP, search, AI or just want to reuse old C++ code you can do it by creating managed C++ bridge between it and C#!
|
|
|
|
|
All I have to say is:
Holy crap! Out of all the messages I've posted (over 1700) this is the only thread that keeps poping up randomly from nowhere. (You might've noticed that I posted a year and a half ago.) But every 4 months or so - another message!
------------------------------------------
The ousted but stubbornly non-dead leader reportedly released an audiotape this weekend, ending by calling on Iraqis to, quote, "resist the occupation in any way you can, from writing on walls, to boycotting, to demonstrating and taking up arms." adding, "you know, pretty much anything I used to kill you for." - The Daily Show
|
|
|
|
|
Indeed! I didn't look at the dates
|
|
|
|
|
Today tons of 3D software made in C++ rely on OpenGL and DirectX.
Ok, .NET and JVM are made in C++, so Java programs are in fact C++ programs...
MSVBRUN.DLL too... So VB programs are C++ programs.
VB programs are even compiled by the C2.EXE from Visual C++.
So, what's the point here ?
I think the autor is correct, he proved his point: C# is fast enough for, e.g., 3D games.
Crivo
Automated Credit Assessment
|
|
|
|
|
I got your point Daniel, but you over-did that "VB and Java are all C++" thing
If that logic is okay, then finally everything is machine code. So we could even say that a VB written program is actually a machine code thing!
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
I guess I'm still not convinced that C# is fast enough for 3D Games (at least not ones that are supposed to be competitive in the market). Why? Because small engines (like this one) spend most of their time doing rendering (in hardware) - as opposed to interpeting C#. Rest assured that as the engine gets bigger and implements better algorithms (like visibility culling which is more complex than a BSP tree, terrain algorithms, AI, script parsing, etc), the engine will fall further and further behind the benchmarks of a C or C++ engine because the engine will actually begin to spend a significant amount of time inside the C# code (which will be inherently slower than C/C++).
|
|
|
|
|
the C# code (which will be inherently slower than C/C++).
Care to back this up with some actual statistics?
Fully-compiled managed code can be just as fast as unmanaged. The only exception is when the garbage collector needs to make a pass, which shouldn't be that often. Compared to the problems that can be caused by a stray memory leak hiding somewhere, this penalty is IMHO worth it.
Furthermore, many parts of a game aren't nearly as processor-intensive as the inner graphics loops. The actual gameplay mechanics of most current games could run just fine on a much slower system, and this code is fine no matter how it's implemented. Using efficient algorithms is far more important than writing those algoithms in unmanaged code.
|
|
|
|
|