C++ vs. C#

3c6597370b476903ed475f70b4b3ce31
0
john 102 Jan 25, 2003 at 00:05

I was surprised to find out that in DirectX, some tutorials were very much faster in C# than C++. What does this imply? I personally prefer C# because it really cuts down development time, but what’s making me think twice is performance. If C# is as fast as C++ then why not move to C# ?

106 Replies

Please log in or register to post a reply.

2940f695c41efc6cd617f2dbf7d2c065
0
woz1010 101 Jan 25, 2003 at 16:18

Interesting.

If I am not mistaken, C# requires the .NET framework to be available both for development, and to the end user (The game players), and would require them to have this .NET framework installed.

I think it comes with XP, though not absolutely sure, and is available for install on Windows 2000.

So if C# proves to be faster in most cases over C++ with DirectX, then anyone, everyone wanting that game, or any other application, must upgrade. Ah it all makes sense now :blink:

But it could also be just the way the examples where written, at different times, by different programmers.
Where these examples in C# the same as in C++, so you could run similar samples from both languages and see the speed differences?

590e8bdac8129bd87b188df15e62d0e5
0
CyraX 101 Jan 26, 2003 at 06:03

If I am right,
CLI is the thing that works as a layer between your OS kernel and the exe. Thus it interprets EVERYTHING that is compiled. This means that when you run ANY EXE, it is interpreted, much like JAVA bytecode on JVM. Now if you see, C# was being developed ALONG with the CLI. Obviously they know some tricks in the language that CLI has worked out.
May be they will make C# even faster in the coming days…

3c6597370b476903ed475f70b4b3ce31
0
john 102 Jan 26, 2003 at 06:18

But how come Java is considered very slow for games? Don’t the new features of C# make a bottleneck (e.g. Garbage Collection is one big example).

944699b365de3645578c5806f661f2f9
0
godEcho 101 Jan 26, 2003 at 07:19

cyrax- the ‘cli’ in windows was dos. Thats been completely done away with in the NT kernel. Now when you run cmd or command, it runs directly on the kernel, like any other program. Also, programs no longer run through the cli to the kernel.

about java:
Say what you will about java, but if you need a program to run with any sort of efficiency, java sucks. Java doesn’t let you use _any_ direct memory addressing modes. While this prevents things like segmentation faults (heh, sort of anyway), it also puts function calling overhead through the roof. I guess you could just minimize function calls…. oh wait, you can’t. Everythings an object, so you have to go through 18 layers of abstraction to print something to the screen. Yeah, thats a shame. At least its completely cross platform right? Well, that’d be true if it didnt take them \~6 months to release mac and *nix versions. A full development cycle later, people have either adopted the new version for Sun’s new “features” or rejected it because they can no longer service a good % of their clients.

About c#:
I refuse to believe it’d produce exe’s any faster than any other ms compiler. If you know anything about the way a exe is put together by a compiler (lookup tables, resolution tables) you’d know there isn’t anything microsoft could do to make c# executables any faster. If anything, they’d be slower. c# allows you to incorporate multiple types of languages. This results in a scoping/referencing nightmare (on the part of the compiler).

Whether or not c# speeds up development has a strong relation to what you’re doing. C# isn’t going to fix my bugs, and its sure as hell isn’t going to magically make my physics engine work. The speed of development has much more to do with the experience of the programmer, knoweldge of the language, and understanding of causal relationship between code, and the errors it can produce.

C, was originally about being able to compile the same code on any platform you wanted without too much effort. C++ was an attempt to bring C up to date, and for all of its inconsistencies, it more or less did that. C# is a ploy to heard developers into a microsoft only “solution” to “fix” the problems people have managing a development team.

*ahem*

would you believe that I didn’t mean for that to sound so bitter ?

\^_-

D491261d0cdbea6f1f04129ba87f4d09
0
void 101 Jan 26, 2003 at 09:01

Ok, I have heard of these DirectX demos in C++ and C#, I have also heard that the C# appear to run faster because the C++ ones are written REALLY REALLY REALLY badly. If you want to test the true difference in speed between C++ and C#, write your own NON graphics apps in both languages, try to make them almost the same, and you will see that the C++ ones spank the crap out of C#.

944699b365de3645578c5806f661f2f9
0
godEcho 101 Jan 26, 2003 at 17:03

Word.

2940f695c41efc6cd617f2dbf7d2c065
0
woz1010 101 Jan 26, 2003 at 17:40

godEcho’s description is right on the money.

F07a4a5f6dfbdfbd22acbacaccf4a3fa
0
Paladin 101 Jan 29, 2003 at 20:16

If you run the demos, the c# apps have a faster frame rate than the c++ demos.

also posted before was the fact that it uses .net framework… remember, using .net c++ code and c# code gets compiled to the CLR first… so, it isn’t a good test to just run the demos on a machine that uses the .net compiler. test the frame rate of c# vs. the frame rate of c++ where the c++ app is compiled using the VS 6 or Borland compiler. You should see a difference.

0684f9d33f52fa189aad7ac9e8c87510
0
baldurk 101 Jan 30, 2003 at 19:28

just to add to godEcho’s <s>rant</s>post, I’d say that java isn’t applicable for games, but is quite appropriate in other areas

94804f488280d10e3019349cdc1f037f
0
Chompchoad 101 Jan 30, 2003 at 19:35

@godEcho

cyrax- the ‘cli’ in windows was dos. Thats been completely done away with in the NT kernel. Now when you run cmd or command, it runs directly on the kernel, like any other program. Also, programs no longer run through the cli to the kernel.

godEcho,

Before you correct someone, you should probably check to be sure you understood their post in it’s context. I believe that Cyrax was referring to CLI ( as in common language infrastructure), rather CLI (as in command line interface).

CLI is an enormous part of the portability features enabled in the .NET environment, seen in various press release like this one.

Not a flame, just attempting to clarify an earlier assertion. :)

944699b365de3645578c5806f661f2f9
0
godEcho 101 Jan 30, 2003 at 22:00

I was in no way putting cyrax down, and didnt mean for my previous post (or future ones) to sound so flame-esque. If i have offended cyrax, or anyone else, I appologize. I misunderstood what he meant by CLI, and he didn’t clarify. Regardless, I am still of the opinion that his assertion is wrong.

As for Common Language infrastructure, I am not overly familiar with the topic. As for it being part of any sized feature, I have serious doubts that microsoft is legitimately interested in portability. Although the article even goes as far as to say,

“The main reason [for the submission] had to do with overcoming the customer perception that Microsoft is somehow entirely built on proprietary standards”

I think this is an attempt to soft-soap people. Microsoft is, in fact, and empire. Whether it is evil or not, is personal opinion. They cornered several markets with their “proprietary standards.” So obvious is this fact, that it caught the DoJ’s attention, so you’ll have to pardon me when I take their claim with a grain of salt.

As far as effeciency goes, I’m not sure how adding another abstraction layer for code would help. Its most likely my mistaken understanding again, but I’m not sure how CLI could be for both low-level effeciency and portability.

“It isn’t [for] commercial products. It isn’t something you would normally use to develop applications on. It’s more of an educational and research-oriented thing,”

“It” being “Rotor” which is their codename for Shared Source Common Language Infrastructure (CLI) implementation.

Perhaps someone can clue me in?

38270665d8bd4e183530834b040a959e
0
dgilla 101 Jan 31, 2003 at 03:33

Keep in mind that the MSIL (Microsoft intermediate language) is jit’ed when executed. While one has the option of disabling the jit compiler, it is active by default. This results in an MSIL to machine code transformation, speeding up C# code performance to nearly that of compiled C++. For trivial programs the difference in performance is negligible, however, as the program grows and deals with more complex data structures, garbage collection is usually required, the performance hit of this can be considerable.

Though I have not seen these C#/directX demos, the first question that comes to my mind is “dose this demo compare the performance of C# to native C++, or that of manged C++”. As pionted out earlier, C++ can be complied into MSIL (this is referd to as “Managed C++”, this would certainly affect the performance of the C++ application.

A Note on Java (and why its so slow). Java also uses a jit compiler, and the speed of trivial Java code is also close to that of C++. However, Java also employs garbage collection (which of course slows things down. One of the greatest performance drains in Java is not the virtual machine, however. It is the interface to the operating system, Java’s IO/memory addressing is quite slow, as well as its interface with system services from the native OS. This is probably due to the evolving nature of the Java platform. Many of its libraries appear to be added as an afterthought, and are not as efficient as they could have bean. This is evidenced by the shear number of APIs this platform entails, many attempting to correct the flaws of there predecessors. .Net, on the other hand, has had the opportunity of learning from some of Java’s mistakes, as there seams to be a bit less overhead in making system calls, and the API’s are cleaner.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 11, 2004 at 18:27

Hi guys,

I was wondering the difference of speed between C# and C++ for a long time ago.
Now I have THE answer. I made a program in C++ and after in C# and believe me, I take few months to write both. The benchmark is only mathematics calculation (intersection ray/plane, edge /sphere, vertex / sphere) and data structure traversal (edges/vertex/triangles). The result makes me with no voice:
55 seconds for C# against 8 seconds in C++ !!!
(This result exclude the model loading and octree partitioning)

I wasn’t surprised so much because of the VM behind dotnet.
But really I expected less difference because of the hudge positive comments on “C#” regarding the performances.

Has anyone made also a test to compare ?

kind regards,
Epsilon

7543b5c50738e23b200e69fe697ea85a
0
NomadRock 101 Oct 11, 2004 at 19:02

That is hardly THE answer, everyone knows that a single benchmark tells you almost nothing, because there are almost no situations where one is slower or faster that the other in *every* way.

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 11, 2004 at 19:55

.NET 1.0 and 1.1 have unoptimized floating point support.

Although I have not benchmarked it personally, I am told that the .NET 2.0 beta is highly optimized for floating point and even takes advantage of CPU specific instructions.

This means that calculations should become on-par or even faster than those in a regular machine code compiled language like C++

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 12, 2004 at 02:45

@woz1010

If I am not mistaken, C# requires the .NET framework to be available both for development, and to the end user (The game players), and would require them to have this .NET framework installed.

I think it comes with XP, though not absolutely sure, and is available for install on Windows 2000.

So if C# proves to be faster in most cases over C++ with DirectX, then anyone, everyone wanting that game, or any other application, must upgrade. Ah it all makes sense now

The .NET Framework does not come with XP and is is available for other NT operating systems like 2000.
@.NET v1.1 Redis Page

Supported Operating Systems: Windows 2000, Windows 98, Windows ME, Windows NT, Windows XP

It is supported on even Windows 98. Even if this wasn’t the case, the only way that this optimization could happen is for them to cripple the C++ demo…. which will simply turn off developers to the idea of using DirectX over OpenGL (which is quickly gaining in popularity).
@epsilon

I was wondering the difference of speed between C# and C++ for a long time ago.
Now I have THE answer. I made a program in C++ and after in C# and believe me, I take few months to write both. The benchmark is only mathematics calculation (intersection ray/plane, edge /sphere, vertex / sphere) and data structure traversal (edges/vertex/triangles). The result makes me with no voice:
55 seconds for C# against 8 seconds in C++ !!!
(This result exclude the model loading and octree partitioning) I wasn’t surprised so much because of the VM behind dotnet.
But really I expected less difference because of the hudge positive comments on “C#” regarding the performances.

Considering that you are running an 8 second test, it makes sense. If you were to start timing as you begin the C++ compilation and then end when the program exits then you would get an idea of how the two times relate. With C# you are factoring in the compilation time (one of the reasons that C# has the fastest compiler that i have ever seen, seconds for compilation that would take days with C++). The .NET Framework uses JIT or Just-in-time compilation. This means that it compiles the “bytecode” or MSIL into binary and optimizes it for the current CPU before executing it. If you want to get a decent comparison, run the app for more time then a couple seconds (for instance a game wouldn’t run for just a couple seconds). Also the second time that you run the app is much quicker JIT’ing then the first. .NET languages do not have a “VM” they have the .NET runtime which JIT’s the parts of the assembly that are being used. It is also very handy for optimization and the runtime allows many useful features like .NET Security, marshalling, reflection, dynamic source compilation, dynamic serialization using reflection, cross-platform deployment etc. These are things that you cant find in a native language and are well worth a couple seconds overall that you might loose each time you a run an app. The framework is also the most extensive, flexible and well-documented that i have ever seen (which is suppressing since it is written by Microsoft but is nevertheless true). The .NET framework is also entirely open-source unlike Java.

Also consider the fact that you are comparing simple mathematical calculations. You are comparing the #1 most difficult thing to implement as efficiently as it could be found in a native language. Also did you optimize the apps for both languages or not, because that will make a big difference? Now if you want to take everything into consideration instead of using a high-specialized test which caters to C++. Consider an entire application such as Axiom and OGRE. The Axiom C# port of the famous OGRE engine actually outperformed its C++ counterpart. It is also much smaller and more maintainable, written much more quickly, is much easier to read and understand, much more extensible, and the same build can be deployed an nearly any OS without and the code-base requires not IF-DEF’s and maintenance of different builds. I would consider the entire package and not just a simple test which as NomadRock had put it is very limited in its scope. If you wait for .NET 2.0, you will see what has been tested to be an outstanding 5x speed boost in this already incredibly fast engine. Java even supports JIT’ing now. I don’t see why people blindly consider C# to be too slow a language to accomplish anything. This is the same thing that was C was considered to be in relation to Assembly back in the day. C# and the .NET framework make an excellent choice for game development for the aforementioned strengths especially due to maintainability, cross-platform deployment, and rapid application development even if it was to be much slower. But it may take a while because of the stigma associated with managed languages.

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 12, 2004 at 14:02

.NET 2.0 drops support for 98

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Oct 12, 2004 at 16:11

what is win98? sorry, but.. why shouln’t they drop support for a 6 year old os based on .. how old is dos? :)

D45a946590ea97f316bb848b54f6a36b
0
Codemonger 101 Oct 12, 2004 at 18:32

Interesting topic … Think of this for a second:

I’ve seen test where C# output code is identical to VB.Net ouput code, the input is different but the ouput is the same. So if you think VB.NET is slower than C++, then why should you think C# is somehow faster than C++. I find the whole debate interesting, and kind of funny at the same time. I don’t think you will find a lot of support of people arguing the speed of VB.NET vs. C++ :D , even though VB.NET is using the almost identical code and the exact same libraries C# is using :tongue:

The newest DX examples in C# are faster than C++, which is exactly when I ditched my undying support for DX and moved on to OpenGL using C/C++. Seems like DX will primarily focus on C# in the future, until XNA comes out.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 12, 2004 at 19:03

Also consider the fact that you are comparing simple mathematical calculations.  You are comparing the #1 most difficult thing to implement as efficiently as it could be found in a native language.  Also did you optimize the apps for both languages or not, because that will make a big difference? 

Yes of course I optimized my code for both languages.
It is an entire application and not only a “special test specialized only to beat C#”.
I used lots of time to write this application and I have seen at the end the speed result is in favour of C++.

I didn’t say “don’t use C# because it’s slow”
I said in the case of “mathematical calculations” and “data structure traversal”,
C++ is 5.5 times faster than C#.

For database application or xml parsing and transforming C# is competitive and simpler to use, as Java.

… would consider the entire package and not just a simple test which as NomadRock had put it is very limited in its scope

believe me, it’s a real app.

If you wait for .NET 2.0, you will see what has been tested to be an outstanding 5x speed boost in this already incredibly fast engine.  Java even supports JIT’ing now.

I am waiting to test .net 2.0 but I am realist, they will not improve their VM by 5.5 times. Please be realistic too. Concerning Java, they also use Just In Time compilation since a long time ago.

C# and the .NET framework make an excellent choice for game development for the aforementioned strengths especially due to maintainability, cross-platform deployment, and rapid application development even if it was to be much slower.

You should take care about my results when you say things like this.
For games development we need always almost real time algorithms like path finder or mathematical test collision … etc
This is exactly what I compared in my application, but you don’t want to see the results.

I heard lots of comments like you in internet, saying that .net will be faster than an C code even on mathematical calculation because it can use some processor instruction …. I am waiting .net 2.0 but at this moment this is really not true, and I really don’t see how it could be true.

Kind regards,
Epsilon

D45a946590ea97f316bb848b54f6a36b
0
Codemonger 101 Oct 12, 2004 at 19:22

I heard lots of comments like you in internet, saying that .net will be faster than an C code even on mathematical calculation because it can use some processor instruction …. I am waiting .net 2.0 but at this moment this is really not true, and I really don’t see how it could be true.

You are right this is a myth that C# is faster than C++, and only a myth. If .Net utilizes SIMD instructions then a comparison program in C/C++ should also be written with the same instructions.

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 12, 2004 at 23:03

@Codemonger

If .Net utilizes SIMD instructions then a comparison program in C/C++ should also be written with the same instructions. [snapback]12732[/snapback]

Well the idea is that a C++ program written and compiled now is different from a C# program written now and compiled on an advanced processor at some time in the future. The C# program has an obvious advantage, but the C++ program cna be recompiled to the same effect.

Realisticly, one should expect JIT and plain native code to have very similar performance if JIT time is excluded. GC and other fancy features really do not suck as much performance as most expect and GC is actually the reason that some .NET DX samples run FASTER than the C++ versions.

The sample programs allocate a lot of memory using the new keyword and as any good C/C++ programer knows, new has a lot of overhead. It needs to search for a chunk of available memory large enough and make considerations to avoid fragmentation.

GCed environments use frame based allocation (which can certainly be implemented in C++) which is very similar to the capacity vs. length concepts with arrays. I believe the Unreal Engine uses this and it is described in detail in Game Programming Gems. In effect, it is much faster to allocate memory in a GCed environment and generational GC (another topic on its own) makes memory freeing not that much of an issue.

Allocating as much as these samples do is considered bad practice in C++, with good performance reasons. In .NET it isn’t as much of an issue, so the samples produce some missleading results.

I have discussed this topic to death. I am tempted to write an article…

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 12, 2004 at 23:29

@Codemonger

Interesting topic … Think of this for a second:

I’ve seen test where C# output code is identical to VB.Net ouput code, the input is different but the ouput is the same. So if you think VB.NET is slower than C++, then why should you think C# is somehow faster than C++. I find the whole debate interesting, and kind of funny at the same time. I don’t think you will find a lot of support of people arguing the speed of VB.NET vs. C++ :D , even though VB.NET is using the almost identical code and the exact same libraries C# is using :tongue:

The newest DX examples in C# are faster than C++, which is exactly when I ditched my undying support for DX and moved on to OpenGL using C/C++. Seems like DX will primarily focus on C# in the future, until XNA comes out.

[snapback]12727[/snapback]

I agreee, VB.NET and C# (as are all of the other .NET languages) are all compiled into the same MSIL. There may be slight nuances in the specific compilers, but they are effectivly just as fast.

XNA will not replace DirectX. WGF or the Windows Graphics Foundation built into Longhorn will. Sadly there will be no Direct for “older” OS’s.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 12, 2004 at 23:47

@epsilon

I didn’t say “don’t use C# because it’s slow”
I said in the case of “mathematical calculations” and “data structure traversal”,
C++ is 5.5 times faster than C#. For database application or xml parsing and transforming C# is competitive and simpler to use, as Java.

You should take care about my results when you say things like this.
For games development we need always almost real time algorithms like path finder or mathematical test collision … etc
This is exactly what I compared in my application, but you don’t want to see the results.

This is the point i am getting at. I dont see C# surpassing C++ in terms of sheer optimized speed, but you gain many powerful features that allow simple solutions to complex problems. My point is that this app specificly takes advantage of mathematical calculations which I had admited are much faster in C++, a these algorithems are likely to stay in native code, but that doesnt stop the rest of the application from being written in C#. I have seen some impressive work developed this way. We are you telling me that i am disinterested in results when that is obviousl not the case. There are two sides the the argument and you gain a lot when using C#, and also lose some in speed. I have seen on average a very low loss of speed when using C# and if you decide to implement many of these algorithems in a utility library (such as is done using the Tao wrappers with libraries like ODE) then you gain a lot of this loss back.

If you wait for .NET 2.0, you will see what has been tested to be an outstanding 5x speed boost in this already incredibly fast engine. Java even supports JIT’ing now.

I am waiting to test .net 2.0 but I am realist, they will not improve their VM by 5.5 times. Please be realistic too. Concerning Java, they also use Just In Time compilation since a long time ago.

I didnt say that they would improve their “VM” (which actually not what it is, it is a runtime framework… big difference)i by 5x. I said that I have seen in one engine that had actually been tested with .NET 2.0, a 5x FPS increase. This is due to the fact that much of what it does can benifit from judicous use of generics. This is another programming tactic that it now supported, not just an optimization of the framework. I am very much a realist who is using actual results from the Axiom engine trials.

I heard lots of comments like you in internet, saying that .net will be faster than an C code even on mathematical calculation because it can use some processor instruction …. I am waiting .net 2.0 but at this moment this is really not true, and I really don’t see how it could be true.

Really, what in the world are you talking about? I hardly claimed that C# would be faster then C. Actually i stated quite the opposite and said that simple algorithems nearly always are faster in even C++ (pointing out how your tests did not reflect the peformance of the .NET framework on average) and ceeding that lower level languages like C++ and C tend to run faster but are not neccisarily choosen to develop with.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 13, 2004 at 02:09

In effect, it is much faster to allocate memory in a GCed environment and generational GC (another topic on its own) makes memory freeing not that much of an issue.

“Not much of an issue” - well, well :)

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 13, 2004 at 12:47

You would be amazed at how fast GC (and hence memory freeing) really is.

Try running the Allocation Profiller on one of those Managed D3D samples. Take a look at the time line view in particular. It shows you how many GCs occur and when.

The results will show what seems like a rediculously high number of GCs happening early, then it leveling out but still remaining higher than expected. The truth is that a GC of the newest generation of objects is relatively inexpensive and (if I remember correctly) is performed in a parallel thread which leaves the CPU free to continue issuing commands to the GPU.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 13, 2004 at 14:29

You would be amazed at how fast GC (and hence memory freeing) really is.

Unfortunately I’m kind of aware of the topic, so I’m not as amazed as I could have been when tackling that stuff for the first time ;)

The truth is that a GC of the newest generation of objects is relatively inexpensive

Aye.

and (if I remember correctly) is performed in a parallel thread which leaves the CPU free to continue issuing commands to the GPU.

The latter is not really the case. See this quote from MSDN [1]:

So, when the garbage collector wants to start a collection, all threads executing managed code must be suspended. The runtime has a few different mechanisms that it uses to safely suspend threads so that a collection may be done. The reason there are multiple mechanisms is to keep threads running as long as possible and to reduce overhead as much as possible. […]

(It would be kind of hard to perform parallel collection with a Mark/Compact GC)

So a separate thread for GC doesn’t really improve performance, as the other threads are suspended during collection. [2]

Note that I’m not against GC at all (or something like that). I try to be aware of potential issues, though ;)

Cheers,
Michael

[1] http://msdn.microsoft.com/msdnmag/issues/1…I2/default.aspx
[2] What MS is doing, though, is to use a separate thread .NET for calling finalizers (which can be done in parallel).

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 13, 2004 at 17:11

This is the point i am getting at. I dont see C# surpassing C++ in terms of sheer optimized speed, but you gain many powerful features that allow simple solutions to complex problems. My point is that this app specificly takes advantage of mathematical calculations which I had admited are much faster in C++, a these algorithems are likely to stay in native code, but that doesnt stop the rest of the application from being written in C#. I have seen some impressive work developed this way. We are you telling me that i am disinterested in results when that is obviousl not the case. There are two sides the the argument and you gain a lot when using C#, and also lose some in speed. I have seen on average a very low loss of speed when using C# and if you decide to implement many of these algorithems in a utility library (such as is done using the Tao wrappers with libraries like ODE) then you gain a lot of this loss back.

Did you speak about to use C# game programming by using native dll ?

I have already make (not seen) these kind of development ie using core functions in a dll in C and others part into a higher language. What I can say is that I lost a lot of time to make interaction between them. The gain you have in C# you will lose it by making wrappers and making interaction. At the end you will have almost the same structure in both language. Have a look on Managed DirectX, they have a C# wrapper for almost C++ object !!!

We can also make a wrapper in C++ to make things more readable and more high level, but I fear this is another long story.

Kind regards,
Epsilon

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 13, 2004 at 19:03

@Michael

Thanks for that note about the GC threading! I was sure there was another thread in there for something, but I wasn’t sure of the details hence the “(if I remember correctly)”. Now I won’t have to go look it up :-)

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Oct 13, 2004 at 23:23

as ya all know my hobby is software raytracing (realtime as good as possible). and while i can’t show much, i’m at least happy to be able to have some simple (very simple :D) shading math running in .NET 2.0, written in c#, with an exe calling a dll, and the code runs at 240fps on the p4 2.8ghz. what it does is detecting a sphere, shade it, and do exposure on the fullscreen.

and the pixeldrawing is done with winforms.. not mdx..

i’m quite impressed by myself (and it’s fun to see the jit, and gc interact with fps.. :D).

and yes, it’s impressive to see how several rules in c++ vanish in c#. like the allocations of lotsa small objects, and such things.

there are a lot of things quite slow in c++ the way they are designed. of course c++ is powerful enough to do anything. but realistically, most simply use new to create a new object, use inheritance, stl, and the stuff. and in such a generic scenario, c# can beat out the performance in quite some of c++’ bottlenecks.

more about this online in tons of discussions, and papers (i don’t have a link list.. i just use google).

oh, and, the fact that a JIT update is the only thing i have to do and all my apps have the latest service packs, and optimisations in, is another nice thing.

just look at the mess with the security hole in the jpeg loading code of microsoft. as it was statically linked, it just happened to get spread in tons of applications, and everyone needs now to get patched individually. HORRAY!

and one day, i take my app to an athlon64 with dual core and SSE3 in, and all the fuzz. and it runs some seconds, does some tuning, and gets highest performing results there. while my good old sse1 optimized singlethreaded dump old c++ code still struggles..

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 14, 2004 at 00:06

I agree that interop between C# and native C or C++ can be very costly, but if you have very little communication between the two as is the case with ODE and you have very lengthy calculations in the native library then you may make it up. Personally i would choose to have every implemented in a managed language for sake of portability simplicity and as davepermen had pointed out, optimization. Still if you are concerned about sheer speed, it is an option. I know that games are very speed-critical applications, but if you loose say 5% fps in certain situations but gain much more (portability, maintainability, simplicity, etc), then it may very well be worth it and may allow you to speed more time developing useful features and optimizes your code or just get the product out sooner. Now is the age of RAD or Rapid Application Development. You need to be able to build off of or extend your prior work and get products out quickly otherwise they will become obsolete and the speed boost may be rendered useless. C# is by no means a guarantee of these things, but it truly helps.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 14, 2004 at 17:02

@davepermen

and one day, i take my app to an athlon64 with dual core and SSE3 in, and all the fuzz. and it runs some seconds, does some tuning, and gets highest performing results there. while my good old sse1 optimized singlethreaded dump old c++ code still struggles..

Maybe you are right for your C# code, but you are using a lot of native dll to gain speed and they will not be optimized unless you recompile them. Concerning the winform pixel drawing, they are just call native dll too. These kind of benchmark are not fair to compare two languages. You like raytracing … me too. My application ( kind of renderer ) shows how fast is C++ compares to C# but of course my C# code doesn’t use any native dll.

kind regards,
Epsilon

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 14, 2004 at 17:13

@xeonx

I know that games are very speed-critical applications, but if you loose say 5% fps in certain situations but gain much more (portability, maintainability, simplicity, etc)

You are speaking about 5% but this is really not that I have seen, I spoke about 5.5 times slower. Also I would agree with you if we are losing only 5%
@xeonx

Now is the age of RAD or Rapid Application Development. You need to be able to build off of or extend your prior work and get products out quickly otherwise they will become obsolete and the speed boost may be rendered useless. C# is by no means a guarantee of these things, but it truly helps.

If you have a company and if your games are very slow compares to other games,
I don’t believe you will sell a lot of copies of your game and I assume you will not be very happy of this situation. As we can see in the games magazine, any slow games are simply eliminated. I think you are much more speaking about database based developpment where the functionality is much more important than the execution speed.

Kind regards,
Epsilon

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 14, 2004 at 20:57

@epsilon

@xeonx

I know that games are very speed-critical applications, but if you loose say 5% fps in certain situations but gain much more (portability, maintainability, simplicity, etc)

You are speaking about 5% but this is really not that I have seen, I spoke about 5.5 times slower. Also I would agree with you if we are losing only 5%
@xeonx

Now is the age of RAD or Rapid Application Development. You need to be able to build off of or extend your prior work and get products out quickly otherwise they will become obsolete and the speed boost may be rendered useless. C# is by no means a guarantee of these things, but it truly helps.

If you have a company and if your games are very slow compares to other games,
I don’t believe you will sell a lot of copies of your game and I assume you will not be very happy of this situation. As we can see in the games magazine, any slow games are simply eliminated. I think you are much more speaking about database based developpment where the functionality is much more important than the execution speed.

Kind regards,
Epsilon

[snapback]12859[/snapback]

Well games only need to run at 30FPS, the rest just goes into AI and special effects, so FPS really isnt an issue, especially if the game is highly configurable (which any good game would be) and supports real-time FPS optimizing for maintaining a particular range. I am currently working on a game in C# as well as the RealmForge GDK and FPS hasnt been an issue. From what i have seen in comparisons between OGRE and Axiom (a C# port of OGRE), Axiom is actually faster. Both of these are very well writen 3d rendering engines and Axiom is more flexible, much more concise and maintainable, and was developed very quickly. So actually i have seen a speed increase. What exactly are you doing that is 5x slower. Is it an entire rendering engine which has entire demos running a 1/5 the number of FPS, or is it just perf-analysis of a couple method calls. What C# rendering engine are you looking at that a speed hit is noticable (ie consistently under 30 FPS). A speed hit on one thing like ray tracing does not in any way make for a slow game, you will always find algorithems that are faster and slower depending on what you are comparing.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 14, 2004 at 22:20

Well games only need to run at 30FPS, the rest just goes into AI and special effects, so FPS really isnt an issue

Wrong conclusion; imagine your game already runs at 30FPS (because it’s using this cutting edge technology).

supports real-time FPS optimizing for maintaining a particular range.

Reduced FPS and reduced detail are both pretty bad.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 15, 2004 at 15:03

@Michael

Well games only need to run at 30FPS, the rest just goes into AI and special effects, so FPS really isnt an issue

Wrong conclusion; imagine your game already runs at 30FPS (because it’s using this cutting edge technology).

supports real-time FPS optimizing for maintaining a particular range.

Reduced FPS and reduced detail are both pretty bad.

[snapback]12862[/snapback]

I fail to see what is wrong with keeping the FPS down to only what is visible. As i had said, you redirect the rest of the processing to other features such as AI and Visual Effects. I would be an insane waste of processing time to render more frames then the eye can detect (30+ fps). The max is about 29.73fps. I was pointing out that it is not very hard to make a game that doesnt run slow, and you dont have even have to reduce level detail to keep it there. “Reduced FPS and reduced detail are both pretty bad”, what an observation!! But it is irrelevent as i am suggesting neither. Have you ever seen Morrowind FPS optimizer, it is extremely useful and allows you to control where the proccessing is being done, expand the max view distance, set AI ranges for different areas, etc. And FPS should rarely be below 30fps so slow is not a problem.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 15, 2004 at 15:19

I was pointing out that it is not very hard to make a game that doesnt run slow, and you dont have even have to reduce level detail to keep it there.

But what makes you thinking this was the case?

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 15, 2004 at 18:18

@xeonx

What exactly are you doing that is 5x slower.  Is it an entire rendering engine which has entire demos running a 1/5 the number of FPS, or is it just perf-analysis of a couple method calls. What C# rendering engine are you looking at that a speed hit is noticable (ie consistently under 30 FPS).

It is a tool to calculate some trajectories on a 3d triangle mesh.
It needs to store vertices and triangles on a octree to speed-up the intersection tests. That’s why I said it’s a kind of raytracer.
@xeonx

A speed hit on one thing like ray tracing does not in any way make for a slow game, you will always find algorithems that are faster and slower depending on what you are comparing.

I don’t find any algorithm better than I am using, if it is not the best algorithm, it is one of the best. My goal was not to try to improve the algorithm (already enough fast and good) but to compare two languages.

kind regards,
Epsilon

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 16, 2004 at 14:38

@Michael

I was pointing out that it is not very hard to make a game that doesnt run slow, and you dont have even have to reduce level detail to keep it there.

But what makes you thinking this was the case?

[snapback]12879[/snapback]

From the demo games that i have written using the RealmForge GDK which i developed. Everything is in C# and FPS is in no way a problem.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 16, 2004 at 14:47

@epsilon

@xeonx

What exactly are you doing that is 5x slower. Is it an entire rendering engine which has entire demos running a 1/5 the number of FPS, or is it just perf-analysis of a couple method calls. What C# rendering engine are you looking at that a speed hit is noticable (ie consistently under 30 FPS).

It is a tool to calculate some trajectories on a 3d triangle mesh.
It needs to store vertices and triangles on a octree to speed-up the intersection tests. That’s why I said it’s a kind of raytracer.
@xeonx

A speed hit on one thing like ray tracing does not in any way make for a slow game, you will always find algorithems that are faster and slower depending on what you are comparing.

I don’t find any algorithm better than I am using, if it is not the best algorithm, it is one of the best. My goal was not to try to improve the algorithm (already enough fast and good) but to compare two languages.

kind regards,
Epsilon

[snapback]12889[/snapback]

You wrote a ray-tracing alogrithem, by the very nature of it, it would be better suited to C++. But a 3D engine (and even more so with a game) is not entirely 3D ray tracing. This *is* one particular case. I am looking at 3D rendering engines as a whole and considering all of the benifits. There are cases (such as the DirectX demos) in which C# runs faster (though you can decide to go write your own GC…), but when comparing Ogre and Axiom, Axiom runs faster and provides many other perks becuase of its use of C# and the .NET framework. You will be hard pressed to find a managed language that runs faster then C or C++ in many algorithems, but when you consider the way in which all of the features are implemented and the systems work together - the big picture - it doesnt always match the speed of one particular type of algorithem. Its pretty impressive that you wrote your own ray tracing comparison though. Does it render anything or just make the calculations?

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 16, 2004 at 16:49

@xeonx

Its pretty impressive that you wrote your own ray tracing comparison though.  Does it render anything or just make the calculations?

It is a kind of renderer because I only calculate some trajectories on triangle mesh. It mades lots of intersections and find tangent point between plane/sphere, edge/sphere. So It doesn’t render for the moment. I was looking for TAO to render the mesh and the results but I will stay in the current state because of the lack of performance (5.5 times slower, it is really too much). I don’t exclude to reuse this C# code in case I (or others) would want to use it from .net plateform or using from scripting environnment.
I will continue now with C++ code and will use Opengl and Qt to make the UI part and render the results. Some years ago, I started to make my own renderer (z buffering) but I stopped the developpment and used Opengl instead.
I am searching the best way to store the mesh for making algorithms on it (fastest ray intersection, collision, face count reduction …) and to have the fastest opengl rendering with vertx buffer for example. It will take some time I think :-)
I will develop on linux (gentoo) but Qt will allow to run this app on windows / mac / unix. Qt is the best window toolkit I ever seen.
I will think about to make this tool in dll and maybe in the futur make bindings for C# :-))))
@xeonx

There are cases (such as the DirectX demos) in which C# runs faster (though you can decide to go write your own GC…), but when comparing Ogre and Axiom, Axiom runs faster and provides many other perks becuase of its use of C# and the .NET framework

Please could you explain to me the kind of benchmark you made to compare these 2 engines ? Is Axiom relied on Ogre ? does it use Ogre by native dll ? The 3d model is stored on dll side or completely in C# ? Have you some collision algorithms ? in which side dll or C# ?
I am very curious :-O

kind regards,
Epsilon

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 16, 2004 at 17:58

@epsilon

Please could you explain to me the kind of benchmark you made to compare these 2 engines ? Is Axiom relied on Ogre ? does it use Ogre by native dll ? The 3d model is stored on dll side or completely in C# ? Have you some collision algorithms ? in which side dll or C# ?
I am very curious :-O [snapback]12910[/snapback]

Axiom is written entirely in C#, it is a full features rendering engine in which the same build can be thrown on any computer of any platform run just the same (no more if-defs and maintaining builds for different systems). The average FPS in the demos is faster then OGRE in some and slower then others (just like most comparisons) so it is not that it is consistently slower then a C++ engine.

It is full-featured, covering everything from materials (very high-level shader definitions) and the like. It is a C# port of OGRE so it does not use it. It nearly covers all of the OGRE functionality but with a much smaller code-base which has many new and great features thanks to the use of the .NET framework. The efficiency is progressing nicely and soon it will be much faster. The RealmForge GDK is a full features game engine, framework, and editor which uses Axiom as the rendering engine. It adds support for 3D Audio, scripting, data driven scene and world creation, many different types of entities and controllers, and provides a very high-level API for game development.

It actually provides an API which is independent of Axiom (so you could plugin in another renderer) and allows you to define every aspect of the game in the *in-game* editor. Much of these features are made possible becuase of the features of the .NET framework. C# really allows for many things to be done which are not possible in OGRE with C++ and with on average the same speed (and this will only get much better with .NET 2.0 and the planned optimizations). Both Axiom and RealmForge GDk are incredible products, especially when considering how “young” the projects are. I have seen far too many threads in which developers state that the .NET framework is to slow to be of any use in game development when this just isnt the case. When you get to the high-level framework which is required for the development of any game of significant complexity it gains back the efficiency that may have been lost with particular algorithems. The variance in FPS between the Axiom and OGRE demos just goes to show the efficiency doesnt depend on the language so much as the implementation, while the .NET framework provides many useful features and allows a very simple and quickly development implementation which will also allow more time for optimizations.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 17, 2004 at 07:18

In which commercial games has Axiom been used?

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 17, 2004 at 15:51

@Michael

In which commercial games has Axiom been used? [snapback]12929[/snapback]

Considering that it hasnt even made its alpha release yet, none. The RealmForge GDK which I am building on top of it does have several credible dev-teams waiting on it though becuase it provides the needed features that complete Axiom in terms on full-features game engine. You cant expect a comercial game after a couple months of development, especially since it requires at least a year or two for the game itself to be developed. But the level of progress after such a small time atests to it. Considering how it compares to other engines which were used for comercial games it is inevitable that it will be once completed.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 17, 2004 at 21:03

@xeonx

@Michael

In which commercial games has Axiom been used? [snapback]12929[/snapback]

Considering that it hasnt even made its alpha release yet, none. The RealmForge GDK which I am building on top of it does have several credible dev-teams waiting on it though becuase it provides the needed features that complete Axiom in terms on full-features game engine. You cant expect a comercial game after a couple months of development, especially since it requires at least a year or two for the game itself to be developed. But the level of progress after such a small time atests to it. Considering how it compares to other engines which were used for comercial games it is inevitable that it will be once completed.

[snapback]12936[/snapback]

I see, thanks.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 17, 2004 at 22:29

Actually, scatch that. A company based in Indiana just decided to use RealmForge to develop a comercial MMORPG and are providing hosting for the code-base and server-based demo games.

Bba99cde4c49924aea2beb20cf3f8ea2
0
Ravyne 101 Oct 18, 2004 at 02:11

Firstly, I would like to point out that Microsoft does not control the future of .net any more than it does C++. While MS was involved in the development of the CLI/CLR and the sole developer(I believe) of C#, all of these technologies have been submitted to a standards body (I forget which.) This standards body is what will decide the future of .net (in the platform sense, not MS’s tagging ‘.net’ onto the end of all their products :rolleyes: )

Anyhow, I think C# is a viable platform for many types of games, certainly any non-realtime game can be done in c#, and I would say that any independant-quality real-time game (fps or what-have-you) can be done using c# as well. Someone setting out to be on the bleeding edge should stick with C/C++ but thats not most people, so I think one should ask themselves if C# is adequate for their goals, and if it provides other benefits (such as shortened development time) that another language would not.

I think that alot of independant developers need to realize that they aren’t competing directly with the pros (not that they shouldn’t push themselves.) Even if your engine has the technical abilities of Doom3, indies don’t often have the art-staff to support it. Indies don’t have to push the bleeding edge, so we are more free to take advantage of technologies which provide benefits outside of shear performance.

All that said, I like C++ and thats what I use, but I’m keeping an eye on .net.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 18, 2004 at 04:23

Very well put. Also if you check out the OGRE vs Axiom comparision thread at the Axiom forums, you will see that implementation matters more then the language selected as which engine outperforms the other depends on the specific demo and the results remain very similiar.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 18, 2004 at 12:31

@Ravyne

Firstly, I would like to point out that Microsoft does not control the future of .net any more than it does C++. While MS was involved in the development of the CLI/CLR and the sole developer(I believe) of C#, all of these technologies have been submitted to a standards body (I forget which.) This standards body is what will decide the future of .net (in the platform sense, not MS’s tagging ‘.net’ onto the end of all their products :rolleyes: )

I think this is a slightly idealistic view, the standards cover only C# and CLI (which only defines the core standard libaries).

Cheers,
Michael

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 18, 2004 at 17:42

@xeonx

Very well put.  Also if you check out the OGRE vs Axiom comparision thread at the Axiom forums, you will see that implementation matters more then the language selected as which engine outperforms the other depends on the specific demo and the results remain very similiar.

Have you some data structure algorithms in Axiom ?
I think it relies mostly on the graphic card. I checked again and again my C# code but I didn’t make any fault. It means you will be speed equivalent as C++ if you relie on your video card, but I think you will lose a lot of performance when you will have to make some algorithm on your triangle mesh. I agree with you, C# as Java allows more flexibility over C++, but we should always take care about the performance. I am curious to see the first developpements using Axiom in C#…. very curious.
Please could you just explain what are exactly the functionalities C# allows to do and C++ cannot ?

kind regards,
Epsilon

Baaecfb3a09127d5bc5045f89025e49e
0
UnknownStranger 101 Oct 18, 2004 at 19:10

@epsilon

I agree with you, C# as Java allows more flexibility over C++, but we should always take care about the performance. [snapback]12976[/snapback]

Sorry, you lost me there.

How do C# and Java “allow more flexibility” than C++?

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 19, 2004 at 04:32

@UnknownStranger

@epsilon

I agree with you, C# as Java allows more flexibility over C++, but we should always take care about the performance. [snapback]12976[/snapback]

Sorry, you lost me there.

How do C# and Java “allow more flexibility” than C++?

[snapback]12981[/snapback]

C# certainly doesnt impose any needless restrictions as one might think other then important one such as single-class inheritance, and declaring the use of pointers or unmanaged code. It does provide flexiblity in not just the excelent framework, but also in features of a manged language. Metaclass programming with attributes and reflection, dynamic serialization using this, dynamic inspection of types in assemblies for loading plugins, dynamic C# source file compilation using a class in the framework (not an external compiler) in a fraction of the second for an entire assembly. By far the best GUI framework, controls like the propertygrid which allow complex applications to remain very simple, .NET security which allows you to place restrictions on running code to accessing certian types of methods, assemblies, etc - even taking indirect access into consideration. An excelent RPC system (.NET remoting) and pretty much every important system like this all implemented in the core framework (eg. a whole slew of different highly-customizable encryption techniques), the design (like the ability to use a StreamReader to decompress or decrypt on the fly while reading the stream as needed), by far the best documentation I have ever seen (easily a bottle neck for many good frameworks and really helps for rapid development and troubleshooting). Also with C# nearly everything is very intuitive and simple and mature/tested or standardized. This is why C# (the same language as that of development) would even be the scripting language for the game. The ability to interface seemlessly with now hundreds of languages ranging from COBOL, to Python, to Perl, to VB, to Ada. The ability to depoly the same application or framework on any computer or OS without a single if-def statement and without maintianing a seperate build… The list really goes on. C# brings a lot to the table and these features would even be worhth a somewhat sizable speeed hit (considering that generally complex feautres do bring a speed hit to a game anways) but that is not even the case!!!

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 19, 2004 at 04:35

@Michael

@Ravyne

Firstly, I would like to point out that Microsoft does not control the future of .net any more than it does C++. While MS was involved in the development of the CLI/CLR and the sole developer(I believe) of C#, all of these technologies have been submitted to a standards body (I forget which.) This standards body is what will decide the future of .net (in the platform sense, not MS’s tagging ‘.net’ onto the end of all their products :rolleyes: )

I think this is a slightly idealistic view, the standards cover only C# and CLI (which only defines the core standard libaries).

Cheers,
Michael

[snapback]12963[/snapback]

It doesnt matter what is registred as a standard, open-source projects like Mono and Portable.NET are implementing their own frameworks and adding significant functionality to them over the standard .NET framework. Dev-teams may eventually restrict themselves exclusivly to these runtimes due to this (though not until they play catch up with WinForms). My only gripe is that cross-platform GUI development is more difficult then cross-platform 3D graphics. Portable.net got the right idea to develop everything from the ground up entirely in C#, while Mono is using a huge 3rd party dependency and an awkward API for C#: GTK#. QT# may be something to look into though and I am working with wx.NET which is very good, but also not so mature (though the wxWidgets core is).

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 19, 2004 at 20:21

C# certainly doesnt … The list really goes on. C# brings a lot to the table and these features would even be worhth a somewhat sizable speeed hit (considering that generally complex feautres do bring a speed hit to a game anways) but that is not even the case!!!

I think you and UnknownStranger have a different understanding of the term “flexible”.
@xeonx

Firstly, I would like to point out that Microsoft does not control the future of .net any more than it does C++. While MS was involved in the development of the CLI/CLR and the sole developer(I believe) of C#, all of these technologies have been submitted to a standards body (I forget which.)

@xeonx

It doesnt matter what is registred as a standard

Hrm.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 20, 2004 at 17:46

I tried my application with Mono yesterday to see the difference of speed with microsoft.
So I summarize:
C++ : 8 seconds
C# Microsoft : 55 seconds
C# Mono : 160 seconds

Now definitively I am shocked about these results.

I think personally it may be good to spend a bit more time to manage pointer / new / delete and to have the speed gain than to have this difference. With C++ we will run at maximum speed and I think we are more compatible on all plateform. Qt will allow to manage more easily some kind of difference we could have.

Of course, I think this is easier to program with Java / C# because it is simpler to not care about the memory management and don’t see heavy pointer * in the code and to have only one file for a class and to have a faster compilation and … I can find many many arguments but the fact is C++ is a lot faster. All depends what we want to do with.

I agree with Stroustrup: I don’t see why we would need a proprietary language. I fear that in the futur, industry will not want to heard something else that C# .NET. Also I fear that these tools will not be free in the futur. For the moment it is free and .NET is trying to convert the C++ community by bringing lots of functionnalities : who wants to be alone with pointers ???
For how long it will stay free ?

I am thinking that when C++ will be dead, Linux / Unix will have no chance to compete with Windows.
I think it will be soon impossible to run a native application on windows. Why ?
because interaction with windows should call a .net function which is managed and so your application will be managed, and a managed C++ application lose all of its power. We will gain no speed improvement and we will be annoying with the language difficulties. What will be the reason to use C++ on windows now ??? and now you can eliminate every potential application on Linux / unix because Windows means 90% of the market.

I am sure you will say : we have mono and portable.net and if they don’t success other people will bring a solution. But are you sure about it ? I am more and more less confident with these tools. Never they will really compete with Microsoft of course. Never they will have the last functionalities you will be impatient to have … Never an industry will want to have a .NET diiferent of Microsoft, and even the service provider will not certificate their program with other tools than microsoft.

For the games, using C++ will give you the possibility to develop for PC, linux, all gaming consoles
included Playstation, gamecube at full speed. And C# ?

I am sure someone will find good argument again and again but for me there is no way.
Now I am not confident about .NET, for speed and for the futur other than windows.
I am asking simply why people don’t move and didn’t move on Java ???
I think if someone is searching for a simpler language and very portable, why waiting for .NET ????
Java is even faster than .NET !!!
Also I am just wondering why Axiom is not made in Java ?

Just for information, each time I was thinking to make a program in .NET at work, each time I though about unix and each time my program had to run on a UNIX (sun / IBM) computer.
You will ask me why I didn’t use C++ ? because customer don’t like to heard C++ because it means too expensive to maintain, too difficult to find programmers …. but they don’t want to use Java on desktop, only with J2EE / jsp. For desktop they are using VB. And I am sure they will want soon to use only .NET…. or maybe Java never know if they will think about portability.

For all of these reasons, I have (re)installed a linux partition with gentoo, and I will developp with KDevelopp and Qt. Of course I would prefer visual studio but I am flexible I will make effort use a “simpler” IDEA. Only important is the result.

kind regards,
Epsilon

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 21, 2004 at 23:55

You test is still very limited in scope, the speed of one particular algorithem has nothing to do with the overall performance of a game engine, let alone the game running on it. It has everything to do with implementation though. Also when considering how advanced Axiom is and how it is even faster then OGRE – the C++ of which it is a port – in some cases, attests to this. These speed of raw algorithms like ray tracing is far less critical then systems like AI, scripting, and scene management (which are all implementation-centric).

Below is a list of the results from comparing Axiom in C# to OGRE and C++. And in the places where there is a difference, it is just a couple percent less or even greater (not a factor of 5). This trial is far more relevant considering that it is comparing what you will actually see in FPS in a finished product, not a particular task found in the engine like ray tracing. And this is even further skewed in how OGRE has put time into optimizations while Axiom really hasn’t yet. Once Axiom does and the .NET framework 2.0 comes out, it would not be unlikely to see Axiom beating OGRE in more of the trials.

My Computer

  • Direct 9.0c October
  • .Net Framework: 1.1.4322.573
  • 1600MGz Pentium M w/ 512 RAM
  • ATI Mobility Radion 9000 32MB
  • 1400x1050 @ 32bpp Fullscreen
  • Operating System: Microsoft Windows NT 5.1.2600.0

Axiom Results (Release Build from CVS 10-16-04) vs Ogre Results (0.14.0 Prebuilt Release)

  • CameraTrack
    Average: 99.93502, Best: 110.5578, Worst: 70.78764, Frames: 95, Time(ms): 10008
    vs
    Average: 89.547371 Best: 101.391647 Worst: 72.564606
  • CelShading
    Average: 172.4322, Best: 172.4825, Worst: 172.1393, Frames: 167, Time(ms): 10001
    vs
    Average: 172.977478 Best: 173.306778 Worst: 172.310760
  • CubeMapping
    Average: 130.0475, Best: 130.3483, Worst: 126.3682, Frames: 123, Time(ms): 10001
    vs
    Average: 124.790047 Best: 125.748497 Worst: 119.641075
  • Dot3Bump (NOTE: Uses a different model)
    Average: 81.20572, Best: 81.83633, Worst: 80.11869, Frames: 78, Time(ms): 10011
    vs
    Average: 118.834244 Best: 121.272362 Worst: 114.087296
  • Fresnel
    Average: 28.34465, Best: 28.94212, Worst: 27.31707, Frames: 23, Time(ms): 10015
    vs
    Average: 24.264023 Best: 26.239067 Worst: 23.692005
  • ParticleFX
    Average: 33.28254, Best: 67.6617, Worst: 32.00776, Frames: 34, Time(ms): 10026
    vs
    Average: 36.369019 Best: 93.688362 Worst: 33.300686
  • SkeletalAnimation
    Average: 135.8369, Best: 136.0477, Worst: 135.0546, Frames: 132, Time(ms): 10003
    vs
    Average: 153.118439 Best: 154.228851 Worst: 152.390442
  • Smoke
    Average: 57.66978, Best: 101.8793, Worst: 57.08661, Frames: 53, Time(ms): 10006
    vs
    Average: 82.717522 Best: 121.878128 Worst: 78.063240
  • Water
    Average: 101.3532, Best: 116.0714, Worst: 98.21429, Frames: 95, Time(ms): 10002
    vs
    Average: 108.639755 Best: 112.983154 Worst: 89.463219

As you can see Axiom is often very close in FPS, and in the more complicated demos like Fresnel actually beats the OGRE FPS. The large variance in performances just goes to show that implementation matters more then the language which you choose to develop in, so why not choose the best tool for the job: one which will produce a robust and dynamic product in minimal time.

By the way, Java is hardly faster then C#. Especially when considering like versions or that Java does not JIT by default. What test results have you seen for this?

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 22, 2004 at 00:02

I want to know where you are getting the idea that Java runs faster then C#. Check out these reports, the code is available for download, the results are detailed, and the soure credible. There are a series of tests covering different aspects and C# performs consistently better (about 20-30% so). I have worked with Java developers and they often cede on the fact, so why would you argue it?

http://www.cs.cornell.edu/vogels/weblog/2002/11/25.html

http://www.cs.cornell.edu/vogels/weblog/2002/11/24.html

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 22, 2004 at 17:55

So how exactly are OGRE and Axiom related? I supposed they use the same algorithms, but then you mentioned that OGRE was optimized but Axiom wasn’t optimized yet, so it seems they aren’t. But on which base are you doing your benchmarks, then?

(Sorry if I missed something essential from your post, I don’t have time to go through it completely atm)

  • Michael
6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 22, 2004 at 20:31

I will port my application in Java to make a benchmark.
I use Java at work and I know very well the speed of Java.
Also I have already done a renderer in Java : z-buffering, triangle filling
I think the language itself is faster than .NET
but all graphical things or some specifical areas seems to be a bit faster in C#
but you must know that all the Java libraries are written in Java, instead of C# which relies a lot on native library.
We will see in few weeks with the benchmark of my application.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 22, 2004 at 20:35

Again I repeat, Axiom seens to rely a lot on the video card,
I mean there is no sense to analyse benchmark like Ogre vs Axiom to compare the speed of two languages.

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 23, 2004 at 00:25

I hate to see this thread continue, but those benchmark results are somewhat interesting.

I hate even more to add further fuel to the fire myself, but I must mention that many modern games utilize a scripting language which can be 10 to 20 times slower than native code. UnrealScript, in particular, I know can be even slower than that! Or at least that used to be true. I would find evidence of Warren Spector (I think thats how it’s spelled) saying so, but Flipcode’s new forums does not yet have a search feature. Since C# is comprable in speed to C++ and is already so mature and well supported (expecially compared to a proprietary scripting language, and somewhat true in comparison to Python, Lua, etc) the lack of the \~20 time slow down make it an excellent choice for a scripting language and to a degree is enough by itself to justify using it for a complete engine.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 23, 2004 at 01:06

@epsilon

I will port my application in Java to make a benchmark.
I use Java at work and I know very well the speed of Java.
Also I have already done a renderer in Java : z-buffering, triangle filling
I think the language itself is faster than .NET
but all graphical things or some specifical areas seems to be a bit faster in C#
but you must know that all the Java libraries are written in Java, instead of C# which relies a lot on native library.
We will see in few weeks with the benchmark of my application. [snapback]13183[/snapback]

Much of the .NET framework is written in C#, but yes there is some interop (especially in the way of WinForms, but then Java again does the same with Swing). MSIL is actually fare more full-featured and optimized then the java byte-code which takes a somewhat less effective approach to many things. Of course this makes sense since MS simple took the idea of Java and improved on them. There have been some extensions in the Java bytecode with 1.5, but it still supports many legacy operations (I havent studied it too deeply, so correct me if im wrong). Also by default Java does *not* JIT its classes. It only does this if a JITer plugin is present and - depending on the environment - this option is selected manually. JIT’ing allows C# to run like actual native code (which is one of the reasons its *often* similiar to C++ in speed). There are of course cases with very mathimatical algorithems in which - for one reason or another - the code does not run as fast as C#. I know that the GC is not the problem since it rarely runs and allows C# to be faster in certain instances (ie vs. ‘new’ memory allocation in C++ as found in the DirectX demos). I would be interested in finding out what the problem is. Was you demo compiled as using checked operations? Also it could be the use of unmanaged code and pointers that speeds of certain things (such as array access). Also I know that the ArrayList - a very common data structure indeed - is a fairly inefficient class even when compared to the Java implementation.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 23, 2004 at 01:16

@epsilon

Again I repeat, Axiom seens to rely a lot on the video card,
I mean there is no sense to analyse benchmark like Ogre vs Axiom to compare the speed of two languages. [snapback]13184[/snapback]

Thats exactly my point. That C# is an excelent choice in 3D game development. Most good 3D engines will rely heavily on the graphics card as it peforms operations much faster. So you arent going to see the huge speed hits that other developers have posted that they would away from C# because of. There is a lot to the engine though, it does quite a bit in C# and this is implemented efficiently and therefore runs fast (as again implementation is more important the then choice of language for the sake of speed). That is why i would suggest making your choice on a language to develop in based upon your preference and the features that are affoarded to you by the language in question. One of the very attractive aspects of using C# is that the .NET framework supports very quick and painless dynamic compilation. Due to that and the simple and inuitive nature of the C# language, it makes a perfect solution for scripting and allows scripts to be compiled for speed and to exist in the same language for the sake of no interop or wrapping of the API in a different language (as it sometimes done with other scripting languages that are used… and even the unattractive custom scripting languages which are interpreted). I really dont care to much if C++ may run a particular mathimatical algorithem a bit faster then it would run in C#, if that isnt going to have any impact on the acutal speed of the end-product. Axiom has many algorithems ranging from scene management and culling, to render queing and physics and as can be seen in the tests, these do not slow down the engine. If there will be no impact on the end-speed of a product, i dont see how the efficiency with particular algorithems has any relevance what-so-ever to whether C# should be used for development.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 23, 2004 at 01:27

@SnprBoB86

I hate to see this thread continue, but those benchmark results are somewhat interesting.

I hate even more to add further fuel to the fire myself, but I must mention that many modern games utilize a scripting language which can be 10 to 20 times slower than native code. UnrealScript, in particular, I know can be even slower than that! Or at least that used to be true. I would find evidence of Warren Spector (I think thats how it’s spelled) saying so, but Flipcode’s new forums does not yet have a search feature. Since C# is comprable in speed to C++ and is already so mature and well supported (expecially compared to a proprietary scripting language, and somewhat true in comparison to Python, Lua, etc) the lack of the \~20 time slow down make it an excellent choice for a scripting language and to a degree is enough by itself to justify using it for a complete engine.

[snapback]13196[/snapback]

Wow i didnt see your post at first. Yes C# is an excelent choice for scripting. I have been using it with RealmForge since the get-go and it as worked wounderfully. Its is simple, very fast, and our scripting solution is really incredible and efficient. Every aspect of the framework is easily scriptable (from the renderer to the each particular entity in the world) and a wide range of scriptable game events are provided for this and many many more are coming soon. With our solution, you can actually attach the scripts that you wrote wether in a plugin asembly or just loose C# files which can be edited on the fly during game-time!!! Also you can provide parameters for these scripts using the In-Game editor so as to prevent those simple scripts which just call a particular script or function with a set of parameters and turn them into dynamicly editable and easily viewable parameter set. This use of C# as the scripting language combined with an entirely data-driven and dynamic nature of the RealmForge GDK (all made possible by the unique features of the *managed* .NET framework) will actually allow game developers to develop an entire game and even extend the engine without ever having to leave the In-Game editor, let alone compile and assembly. They could actually do all this *while* testing the game itself. This has been very appealing to many developers and is why it has be selected by a company to develop a comercial game! There are many great features found in C# and the .NET framework which not only lend to the rapid development of games and other applications, but also to the power which these applications wield and the simplicity at which this is accomplished. One simple example is Reflection and the PropertyGrid control which can allow a complex system to have all of is sub-systems, entities, and configurations edited in one simple and elegant way with no additional code. I have implemented a comparable control using wx.NET to allow all entities, systems, config classes, and event the classe from plugins!!! to be easily edited in-game.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 23, 2004 at 01:33

@Michael

So how exactly are OGRE and Axiom related? I supposed they use the same algorithms, but then you mentioned that OGRE was optimized but Axiom wasn’t optimized yet, so it seems they aren’t. But on which base are you doing your benchmarks, then?

(Sorry if I missed something essential from your post, I don’t have time to go through it completely atm)

  • Michael

[snapback]13175[/snapback]

they are kind of long posts :blush: Axiom is based off of OGRE, but it is a ground-up rewrite which has been able to take advantage of many of the features of the .NET framework to make things much simplier and avoid complex and cumbersome solutions to many things. It is not simply a “change what statements dont compile” kind of port. It has not been in development for as much time as OGRE though and the dev-team is not nearly as large, so much of the time has gone into implementing the features and not yet to many optimizations. Axiom 1) has spent far less time in development of it, 2) has a much smaller dev-team, 3)does not yet used generics or “templates” such as I am sure OGRE does, and 4)has not spent much time on optimization. All of these facts simply go to show that Axiom will be *that much* faster when these things are done, since it is already fast enough without them.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 26, 2004 at 00:09

@xeonx

they are kind of long posts :blush: Axiom is based off of OGRE, but it is a ground-up rewrite which has been able to take advantage of many of the features of the .NET framework to make things much simplier and avoid complex and cumbersome solutions to many things. It is not simply a “change what statements dont compile” kind of port. It has not been in development for as much time as OGRE though and the dev-team is not nearly as large, so much of the time has gone into implementing the features and not yet to many optimizations. Axiom 1) has spent far less time in development of it, 2) has a much smaller dev-team, 3)does not yet used generics or “templates” such as I am sure OGRE does, and 4)has not spent much time on optimization. All of these facts simply go to show that Axiom will be *that much* faster when these things are done, since it is already fast enough without them. [snapback]13200[/snapback]

Thanks for your reply.

So basically it’s not useful for comparing between C++ and C# performance, but rather for comparing development speed, and not even that, because you are building on the OGRE design and development effort. Still an interesting project :)

  • Michael
F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 26, 2004 at 11:21

@Michael

So basically it’s not useful for comparing between C++ and C# performance, but rather for comparing development speed, and not even that, because you are building on the OGRE design and development effort. Still an interesting project :)

  • Michael

[snapback]13298[/snapback]

It is useful to compare peformance, especially the over all performance of the game engine. But my point is that if many mathimatical or cpu-intensive algorithems are not going to be *used* in the game engine and written in C# (but instead rely on the GPU) then why use that to represent the speed of the language. C# is not nearly that slow when looking at large apps as a whole, the speed of a one algorithem becomes nearly irrelevent while the design and implementation of the engine is far more critical. If you loose a couple millisecond on one algorithem every 200 frames renderered, but you have the ability to cut out or optimize a bunch of steps (or even one) in the scene culling, scripting, game logic, etc. then you will more then make up for it. And C# makes optimizations fairly easy and development fairly quick as its a RAD language (this is more my opinion though, but the fact is that what you are skilled with and effective with for a particular task is more important in the long run then small snapshots on efficiency). I dont see the heavy use on the GPU (which is down by all good game engines and frameworks) is a cause to dismiss its speed, its a good design choice. Its hardly like C# is not running, you have 1000’s of lines of C# code executing every frame easily and i dont see a speed hit.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Oct 26, 2004 at 16:44

@xeonx

@Michael

So basically it’s not useful for comparing between C++ and C# performance, but rather for comparing development speed, and not even that, because you are building on the OGRE design and development effort. Still an interesting project :)

  • Michael

[snapback]13298[/snapback]

It is useful to compare peformance, especially the over all performance of the game engine. But my point is that if many mathimatical or cpu-intensive algorithems are not going to be *used* in the game engine and written in C# (but instead rely on the GPU) then why use that to represent the speed of the language. C# is not nearly that slow when looking at large apps as a whole, the speed of a one algorithem becomes nearly irrelevent while the design and implementation of the engine is far more critical. If you loose a couple millisecond on one algorithem every 200 frames renderered, but you have the ability to cut out or optimize a bunch of steps (or even one) in the scene culling, scripting, game logic, etc. then you will more then make up for it. And C# makes optimizations fairly easy and development fairly quick as its a RAD language (this is more my opinion though, but the fact is that what you are skilled with and effective with for a particular task is more important in the long run then small snapshots on efficiency). I dont see the heavy use on the GPU (which is down by all good game engines and frameworks) is a cause to dismiss its speed, its a good design choice. Its hardly like C# is not running, you have 1000’s of lines of C# code executing every frame easily and i dont see a speed hit.

[snapback]13311[/snapback]

I fully agree with Michael.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 27, 2004 at 00:17

@epsilon,Oct 26 2004, 12:37 PM

@xeonx,Oct 26 2004, 02:14 PM

@Michael,Oct 25 2004, 08:02 PM

So basically it’s not useful for comparing between C++ and C# performance, but rather for comparing development speed, and not even that, because you are building on the OGRE design and development effort. Still an interesting project :)

  • Michael

[snapback]13298[/snapback]

I fully agree with Michael.

[snapback]13314[/snapback]

The idea is not even neccisarily that the engine was developed quickly, but that the use of the .NET framework allows for the development of many differnet poweful features which would flat out not be available with C++. These allow for simplicity and time-saving in terms of the development of the end-game (as opposed to engine) These features range from the scripting solution, plugins, the In-Game Editor,and seemless cross-platform deployment with out a single if-def or maintaince of seperate builds (but you would have to delve into RF documentation to get at why). What can be shown is the difference in the size of the OGRE and Axiom code-bases. Axiom is a much more concise solution. I am not comparing the time it took to develop Axiom, but how small/concise the solution or implementation is when taking using the same techniques. This really is a better indicator of development time.

I am not interested in simple comparison of C++ vs C# for performance, but C++ vs C# for performance in the contect of game engines in which case i have already pointed out they will be comparable.

For many other (not rendering) projects performance differences would not even be noticable. Of course if you were developing a high-perf MathLib or Server solution, C# may not be your best bet, but when it comes to game development - as shown in Axiom vs OGRE - the use of C# does not noticably impact performance. So it is useful for comparison of performance in the two in terms of game development (which is of course the issue at hand).

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 27, 2004 at 20:45

I am not interested in simple comparison of C++ vs C# for performance, but C++ vs C# for performance in the contect of game engines in which case i have already pointed out they will be comparable.

Note that our argument didn’t exclude performance in the context of game engines.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 27, 2004 at 22:59

@Michael

I am not interested in simple comparison of C++ vs C# for performance, but C++ vs C# for performance in the contect of game engines in which case i have already pointed out they will be comparable.

Note that our argument didn’t exclude performance in the context of game engines.

[snapback]13376[/snapback]

And note that i had provided test results that showed comparable perforamance between a C++ engine and its C# port. There are something things dene by the GPU, but there is still much time spent on other things in the game engine yet comparaible performance. Even if you were to say that Axiom’s “slowness” is just not noticed becuase of the load given to the GPU (which is the tendancy of good game engines) then that would be the case and a game or game engine written in C# would stil lbe of comparable speed. I dont see what the problem is.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Dec 05, 2004 at 13:04

I tested my program with .net v2.0 beta 1
and I found this is slower than v1.1.
It takes 72 seconds instead of 55 seconds.

Something funny I tried to use only float instead of double,
and it takes 35 seconds for v1.1 and 33 seconds for v2.0 beta 1

Concerning the port to Java, I would like to do, but it is a lot of work,
and I am a bit lazy… I will try.

Kind regards,
Epsilon

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Jan 04, 2005 at 20:27

Finally, I have done the port to Java and I am bit surprised by the result.
It takes 135 sec. It is the first evaluation, I have to look the code to check if all is correct. I was expecting a better performance than C# but maybe I was wrong.
With C# I used “struct” statement for base class like “Vector”.
It can explain the result, but I have to check ….

kind regards,
Epsilon

E72f771c34f4e58f34a2eac1844b214e
0
Trident 101 Jan 05, 2005 at 09:30

You may also try to run JVM in “server mode” (-server option) For some apps it speeds things up considerably.

744d06ebf78d82e8667f1f7ad8392daf
0
SYS49152 101 Jan 05, 2005 at 11:50

hey nice topic so i need to drop my 2 cents here… :)

i dont think c# will replace c++ in game development. but for RAD c# is really a good choice.

ofcourse a mix of c# and c++ is a good choice for 3d game development.

also writing editing tools is very nice with c#.

for a newbie c# is a very nice option now to start with 3d / game development.

if someone starts with c# and find out that c# is way to slow in some options he still can switch back to c++. since he dont need to learn every aspect of the programming language.

( ofcourse going trough the pointer hell in c++. hehe )

but c# is a new language so it will grow in the next years.

i have switched for my self from c++ to c# and iam really happy with it.

  • Andy
2b97deded6213469bcd87b65cce5d014
0
Mihail121 102 Jan 05, 2005 at 15:52

Boy that C++/C# discussion is getting really huge and i don’t see any point in it!

Both languages have their pro/cons and it’s a matter of personal choice what one will use for development purposes, ain’t it?

I suggest, we end this madness - NOW!

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Jan 06, 2005 at 14:19

@Mihail121

Both languages have their pro/cons and it’s a matter of personal choice what one will use for development purposes, ain’t it?

Yes, it’s the personal choice between sanity and madness <wink>

SCNR,
Michael

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Jan 11, 2005 at 21:53

I tried to compare the languages for speed only … raw speed
I saw lots of people saying C#/java is faster than C++,
and I try to prove / to find the … my answer ….

C++ is the winner …. sorry ! …. Xeon ? :)

Java is maybe the nicer port compared to C# ….
but it is my own opinion…
and C# is promised to a great commercial success :(
(except we are speaking only Java in the bank & pharma industry …)

So as I said before … I will continue in C++ now,
even if I will see *p everywhere … just kidding …
but a lot of &p instead of …. :))

Seriously I found very interesting to args my point of view as to read the position and experience of other people, I found it very rich :)

So I hope this post will continue if other people have some useful experience to share :)

Kind regards,
Epsilon

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Jan 30, 2005 at 19:56

I found a bug in the java version and the time is now 22 sec.
I am very surprised, it seems very competitive compared to C++ (8 sec)

I was surprised about the previous result because Java seems faster than C# in the normal usage, but I didn’t expect more than twice.

I will check again the C# version because the time seems to be too much compared to Java. I am very confident about the code but never now.

kind regards,
Epsilon

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Jan 31, 2005 at 18:39

Hi guys,

I have now the final benchmark for all version,
I was so surprised about the java result that I checked for different values against the C++ version. The status is I made less point calculation in the java version.
so maybe I was a bit too happy and I regret a bit to have written the result so fast.

Also I have ported the java version to C# (by the microsoft assistant), the java port was very similar to the C++ version. The result code is clean, there is no particular remark to say on this point.

The values to calculate the benchmark are slightly different than previously, that’s why the C++ value is a bit higher.

java: 57 sec
C#: 33 sec
C++: 14sec

I am now very surprised about C# and disapointed about java.
Note that C++ has a little disadvantage because it informed about the progression.

any feedback ?

kind regards,
Epsilon

D51f51907edd6bafbd2c364dc2589141
0
tomcant 101 Jan 31, 2005 at 20:59

Any chance C# might pick up speed, performance wise, in the future? I mean, in future versions… ?

give me a straight answer.

F17c4076675e90da78d3df56e1f98e0a
0
Ridge 101 Feb 07, 2005 at 19:16

Episilon have you published your code for these variations of your synthetic benchmark?

These kinds of benchmarks are highly dubious. If they’re written 1-to-1 then you’re potentially missing per-language optimizations or hitting weak points in the language that would be better suited to a different approach, however, if you deviate then people will complain that it’s not 1-to-1. I can think of a number of operations, which from a c++ standpoint are valid that when implemented in c# have an unintended perf impact.

065f0635a4c94d685583c20132a4559d
0
Ed_Mack 101 Feb 07, 2005 at 19:43

Face it; C++ rocks, C# sucks as does Java. There. Glad that’s sorted.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Feb 07, 2005 at 23:22

i’m alwys glad to see that we can leave objective comments outside in this place :)

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Feb 08, 2005 at 04:20

@tomcant

Any chance C# might pick up speed, performance wise, in the future? I mean, in future versions… ?

give me a straight answer.

[snapback]15628[/snapback]

Absolutely!

The 1.* versions of the C# compiler are, as Microsoft has admitted, poorly optimized for floating point calculations. While I have not performed a benchmark, I am told that the 2.0 beta (which works quite well for me) is significantly faster in that department. The JIT is supposed to be improved also.

Additionally, it’s entirely possible that a AMD64 optimized .NET runtime could become available for WinXP64.

5afbc27ac74935606e4fcda9b2774289
0
tgraupmann 101 Feb 08, 2005 at 18:31

@Codemonger

Interesting topic … Think of this for a second:

I’ve seen test where C# output code is identical to VB.Net ouput code, the input is different but the ouput is the same. So if you think VB.NET is slower than C++, then why should you think C# is somehow faster than C++. I find the whole debate interesting, and kind of funny at the same time. I don’t think you will find a lot of support of people arguing the speed of VB.NET vs. C++ :D , even though VB.NET is using the almost identical code and the exact same libraries C# is using :tongue:

The newest DX examples in C# are faster than C++, which is exactly when I ditched my undying support for DX and moved on to OpenGL using C/C++. Seems like DX will primarily focus on C# in the future, until XNA comes out.

[snapback]12727[/snapback]

Based on what I’ve seen. Using C# cuts down on your development time. I haven’t seen any performance issues when using C#. Plus I too am seeing an FPS increase. From 40 FPS to 60 FPS. I’m doing OpenGL though…

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Feb 09, 2005 at 09:39

I too am seeing an FPS increase. From 40 FPS to 60 FPS.

compared to what under what circumstances ?

D51f51907edd6bafbd2c364dc2589141
0
tomcant 101 Feb 14, 2005 at 16:24

Does anyone think that maybe one day C# will be as fast as C++… ? That would rock.

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Feb 14, 2005 at 16:43

This has been discussed to death, but I will say:

Currently, C# is very fast. In the future, the performance hit of managed code will remain the same, but its relative effect will get smaller. If there is a 5% performance hit now, then overall performance of a system doubles, the new performance hit is only 2.5%. This will never reach zero, but it will eventually get close enough that it will be immesurable.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Feb 15, 2005 at 07:55

@SnprBoB86

Currently, C# is very fast. In the future, the performance hit of managed code will remain the same, but its relative effect will get smaller. If there is a 5% performance hit now, then overall performance of a system doubles, the new performance hit is only 2.5%. This will never reach zero, but it will eventually get close enough that it will be immesurable. [snapback]16039[/snapback]

I was very surprised of my results. However I expected a lot Java before C#.
I wondering this is because C# is done very closed to windows that we have this difference of speed. Maybe Java is more plateform compatible, I mean less maintenance for multiple targets.

For instance the difference of speed is enough to prefer C++ in case of lots of calculations, and not enough to prefer C# or Java for database oriented application. Anyway I will prefer in any case Java to C#, because of the portability.

I am making an opengl interface to my tool (a milling tool) in C++ / Qt
which is in my opinion the best tool to achieve the portability. Qt will be even available in GPL on windows for the version 4.

kind regards,
Epsilon

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Feb 15, 2005 at 08:04

Anyway I will prefer in any case Java to C#, because of the portability.

what about mono ?

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Feb 15, 2005 at 08:26

@anubis

Anyway I will prefer in any case Java to C#, because of the portability.

what about mono ?

[snapback]16045[/snapback]

Hummm, … I don’t believe in Mono :-(
Every customer will prefer to use a well integrated environnement as Microsoft .NET
Mono is even very unconfortable with the UI interface, and I don’t believe in GTK#.
Mono will stay unknow customer side.
I am seeing that Java is used server side (jsp/jsf) and C# for desktop application with Microsoft .NET 1.1.

To be honest, I don’t see any advantage to use .NET client side instead of Java if the portability is one of your goal.

If I made my application kernel in every language, it was to be sure of C++,
because it needs more development time, and more difficult to read (*&->).
At the end, as I has written previously, the speed factor is enough to prefer C++ in my case.

Kind regards,
Epsilon

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Feb 21, 2005 at 12:33

Hi guys,

What is your opinion on Mono & Java ?

  • Epsilon
F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Feb 21, 2005 at 13:33

Mono is even very unconfortable with the UI interface, and I don’t believe in GTK#.

you don’t believe in GTK or GTK# ? because liking GTK or not would be a matter of opinion. in that sense i can say that i don’t believe in Swing.

Mono will stay unknow customer side.

maybe so for windows… but does it really matter ?
admitably mono has the disadvantage of standing against a big front of opposition, which may or may not be its demise. i don’t see that the last work has been spoken here so i wouldn’t jump to conclusions about wether it will get a foot in the door on linux. the only real arguement against mono is that it will have to keep up with microsoft to remain interoperable. i don’t see a real problem with that since .net will have to remain backwards compatible anyway so mono applications will most likely still run on windows even if it won’t work the other way round. even if microsoft should change directions completely i believe that the technology has a strong value on it’s own.

What is your opinion on Mono & Java ?

platform independance aside, imo .net has the way better class library. also once it becomes the windows standard with longhorn i assume that many third party components will appear that are wirtten for .net. then mono/.net give you a broader choice of languages to chose from while you are otherwise limited to java.

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Feb 21, 2005 at 14:55

@anubis

Mono is even very unconfortable with the UI interface, and I don’t believe in GTK#.

you don’t believe in GTK or GTK# ? because liking GTK or not would be a matter of opinion. in that sense i can say that i don’t believe in Swing.

The big difference with swing is that GTK# is a binding of GTK.
Swing is the only java GUI, implemented for Java with Java.
I think this is a big difference.
but I should admit that I prefer the Qt user interface programming.
@anubis

Mono will stay unknow customer side.

maybe so for windows… but does it really matter ?
admitably mono has the disadvantage of standing against a big front of opposition, which may or may not be its demise. i don’t see that the last work has been spoken here so i wouldn’t jump to conclusions about wether it will get a foot in the door on linux. the only real arguement against mono is that it will have to keep up with microsoft to remain interoperable. i don’t see a real problem with that since .net will have to remain backwards compatible anyway so mono applications will most likely still run on windows even if it won’t work the other way round. even if microsoft should change directions completely i believe that the technology has a strong value on it’s own.

I never said Mono is a technology failure. They are making a great job,reimplementing a technology is already a big challenge and a great success.
But to be in opposition with Microsoft means danger. They can’t follow Microsoft enough to be really competitive for IT services company for example, and so far to the customer - end user.
That’s why I said it means no sense to go with Mono to gain portability, Java has the same technology and is already done and is working very well.
@anubis

What is your opinion on Mono & Java ?

platform independance aside, imo .net has the way better class library. also once it becomes the windows standard with longhorn i assume that many third party components will appear that are wirtten for .net. then mono/.net give you a broader choice of languages to chose from while you are otherwise limited to java.

[snapback]16127[/snapback]

I don’t agree, Java has a more consistent class library. This point is difficult to arg because of the personal choice & opinion. A lot of tools and library are available for Java, and a lot of tools available for C# are also available for Java and vice-versa.

The only thing that is missing a lot in Java is Signal/Slot like in Qt.
Delegates in C# are less convenient and I wouldn’t like that Java will have the same.

  • Epsilon
F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Feb 21, 2005 at 15:16

but I should admit that I prefer the Qt user interface programming.

use Qt# then :)

That’s why I said it means no sense to go with Mono to gain portability, Java has the same technology and is already done and is working very well.

you are probably right here. judging from interviews with the mono lead programmer being interoperable with .net is only one of the aims for mono though. the main reason seams to be to simply port the technology because they thought it was great. obviously that statement could have been a political one by novell to shut up the people complaining about microsoft driving the bus.

I don’t agree, Java has a more consistent class library. This point is difficult to arg because of the personal choice & opinion

true… the same goes for the language preference of language. that leaves the language independency as an arguement for me. for example i like eifel and that interoperates with .net, as well as many other languages that have a .net version now. that can bring a whole new range of concepts to your hands (like the addition of functional concepts to c#, as in nemerle).

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Feb 22, 2005 at 07:52

@anubis

I don’t agree, Java has a more consistent class library. This point is difficult to arg because of the personal choice & opinion

true… the same goes for the language preference of language. that leaves the language independency as an arguement for me. for example i like eifel and that interoperates with .net, as well as many other languages that have a .net version now. that can bring a whole new range of concepts to your hands (like the addition of functional concepts to c#, as in nemerle).

[snapback]16137[/snapback]

Personally, the fact we can use multiple language for .net is really not an advantage for me. For example C++.NET is really another language with another keywords and philosophy. Also the result is very slow, the winform are only in header file (same as C#) and it is not well adapted with the language (.cpp)

I don’t know very well Eifel but I know perfectly ADA and the language is powerful. I don’t really want to see the new syntax for .NET because it will break all the good ADA concepts. And .NET is limited (or almost) limited to windows.
It is annoying for ADA or C++ which are multi-plateform.

I am just making Qt and I am looking for Qt4 and it is awesome the number of innovations. I just regret a lot to have not adopted this product before :-(
Why only one company know how to make a very good multi-plateform product in C++ ? It is pur C++ even if they are using a preprocessor (moc). It is really a great tool.

Concerning Qt# :rolleyes: I will not use it because it is not supported by trolltech and mono will go for GTK#. :tongue:

kind regards,
- Epsilon

6a2cd5aefb6d7eb66835ce64e9bd6925
0
epsilon 101 Jan 04, 2006 at 15:23

Hi guys,

I am now using openmp with linux, qt and intel compiler.
Wowww it is great.
We also gain 25% of speed increase only by recompiling the source code by the intel compiler over GCC. furthermore Openmp is really great and wonderful for using the dual processor dual core as most as possible. The parallel programmation is really a great domain.

Just one more argument to justify my choice over C++ :D

Cheers,
Epsilon

18ccdda5dd73ae685dc697ae519cd808
0
ProgramWizard 101 Jan 06, 2006 at 12:15

Haven’t read the whole thread, but wanted to reply anyway:

I perfer C++. I’ve read some C# tutorials, and it seems like you have to write more code to get something done in C#. Actually, I perfer C over both of them, but that’s a disscussion for a different day.

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Jan 06, 2006 at 13:02

@ProgramWizard

Haven’t read the whole thread, but wanted to reply anyway: I perfer C++. I’ve read some C# tutorials, and it seems like you have to write more code to get something done in C#. Actually, I perfer C over both of them, but that’s a disscussion for a different day.

really?!!?? what tutorials did you read?! because i can tell from expirience, normally, it’s exactly the other way round. since c# i’ve never got as much stuff working with an as low amount of code. and in vc#2005ee, i got intelisence wich works 100% perfect in c#, wich allows me to write about any word in 1 to 3 keypresses. wich makes me hell fast in writing that less code.

i actually think i can’t even move back to c++ and think that much while coding about the language and how to properly do something in c++.. c# is much more easy, allows me to think much more about the actual problem i’m coding with, than the language.

Cd577ee1cb56aa2ad5645b7daa0a2830
0
eddie 101 Jan 06, 2006 at 13:05

I’m with you daveperman. I’d be interested to see example code of what exactly in C# is more code than C++. Particularly since C# hides so much of the stuff that C++ demands from you.

6f0a333c785da81d479a0f58c2ccb203
0
monjardin 102 Jan 06, 2006 at 14:00

Also, C# probably requires you to do things that you should be doing in C++ anyway, like using namespaces and properly encapsulating properties.

406ad7b52f4ed7443e3971e6b2adf430
0
kariem2k 101 Jan 06, 2006 at 15:34

Hi
I use C++ for hardworks like game programming and c# for bussinues applications which uses GUI and databases.
thanks

6aa952514ff4e5439df1e9e6d337b864
0
roel 101 Jan 06, 2006 at 15:42

I recently moved to C#, and I love it :D The documentation of Managed DirectX (MDX) is the only drawback I encountered.

292735c946e23b74087633232f49c58d
0
Pon 101 Feb 14, 2006 at 08:34

Aye. I just moved to C#, still learning it, in fact, writing a semi-DirectX accelerated ray tracer :D

Although it will run slow as hell, because of the sheer amount of pure maths operations, it will still be pwnage :ninja:

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Feb 18, 2006 at 17:20

@davepermen

what is win98? sorry, but.. why shouln’t they drop support for a 6 year old os based on .. how old is dos? :)

Ever tried to sell a game in Asia? Win98 is still a big thing there (due to copyright reasons… in most asian states win98 is free now).