NET 2.0 Vs. C++ Engines

[Riftworm]

This taken from a Bioware thread unrelated to thread topic got me concerned.

 

Posted 11/13/06 23:22 (GMT) by racofer

.NET (more specifically, .NET 2.0) is a programming language made by Microsoft(this fact alone should sum it all). Almost every computer software today is written in C or one of it's many variations (c++, visual c++, etc...). Games that you enjoy are written on this language. .NET in the other hand is a relatively new language and like Java it requires much more system resources to run than C. Just try anything written in C and in .NET and you can see the difference, its like night and day in terms of performance.

 

This was taken from wikipedia:

"Applications running in a managed environment such as the Microsoft framework's CLR or Java's JVM tend to require more system resources than functionally similar applications that access machine resources more directly. However, due to the Just-in-time optimization in the VM, some applications run even faster than their native counterparts that have been optimized beforehand. This has been shown e.g. in IronPython and Phalanger projects and also even in raw computational power requiring FFT transform. Usually applications that require maximum performance or precise timing of operations would be written in C, unmanaged C++, or other languages that emphasize performance."

 

More info here http://en.wikipedia.org/wiki/.NET_Framework

 

To sum it all, it's a bad language for Games. It will never be as fast as any other game we have seen until this day. That's why there's sooooo much memory usage. Just check out the Catalyst Control Center from ATI. It's entirely done in .NET language. This resulted in much higher system resources usage than the old Control Panel.

It's also believed by many ATI users that the integration of .NET on the Radeon drivers cause a drop in sale. Also every benchmark shows a degradation in performance on ATI cards using this .NET application compared to the old Control Panel.

 

That's the reason we said NWN2 is beyond repair in terms of performance. .NET is bad and unless NWN2 is re-written from scratch, we will have to live with this.

[Morgoth]

Well I guess it helps the programmers to reduce the complexity to implement features, since many things are already standardized with .NET. This of course also means less efficiency. But efficiency costs expertise and time, something programmers not always have.

[angshuman]

(This thread probably belongs to the Tech Forum.)

 

This is a very deep and interesting issue. C and C++ are languages of the 60's, when machines used to have 32KB memory, 1MB Winchester drives were state-of-the-art, and integrated circuits used to operate in KHz. Look how far we have come today. Unfortunately, in terms of programming models, we have not progressed at all, continuing to use the antiquated procedural systems created in the 60's according to the needs of those times.

 

Unforunately, hardware (ISA) abstractions, OS abstractions and Language abstractions together form a very tight vicious cycle that is very diddicult to get out of. Therefore, although the underlying hardware (at the microarchitectural level) has progressed at a breakneck pace, the abstractions exposed by the hardware to the layers above have remained more or less the same for over 40 years. It is not clear any more if the so-called "inefficiencies" of many of today's higher level languages (Java, Python, ML) are genuine inefficiencies or merely artifacts of sticking to an antiquated paradigm.

 

The good news is that the multi-core fad (or rather, the stall in single-thread performance scaling) has hit us all like a freight train, and is forcing architects and programmers alike to try and re-think the entire approach we have been using for solving problems. It's not just a performance issue any more. Multi-threaded programs are a PITA to debug and write correctly and efficiently. The number of ways in which a programmer can shoot himself in the foot using an "efficient" language like C has grown to unmanageable levels. This is why safe higher level languages are being looked at with a renewed interest in the community.

 

I'm not sure if .NET, CORBA etc. are necessarily the solution. I don't know much about them, but AFAIK they are more like patchworks to existing C/C++-based infrastructures to enable large modular projects to be managed easily. I'd be a lot more interested if someone attempted to write a game engine in Perl or Python.

[alanschu]

<nitpick>I wouldn't necessarily say C++ was a language of the 60's</nitpick> "

[karka]

In the past, only way to write efficient programs was writing them directly in assembly langugages. But after complexitiy of writing programs with assembly exceeded the capabilities of programers, they started to use higher level languages.

 

So, the question is complexitiy. If using c# makes it possible for programmer to code what he/she wants, then c# is not a bad option.

[taks]

actually, i'm back to hand-coding in assembly. at least, i have to use __asm__ directives to get the performance necessary for embedded applications. it's not so much the language inefficiencies only. the big problem now is that we have a mix of vector engines on top of superscalar architectures. in other words, floating-point units are vector based (single instruction multiple data, or SIMD), but there is often more than one fpu on the core (superscalar). the problem lies with an inability for dated compiler optimizations to deal with such silicon freaks of nature. ask anyone that programs an altivec (PowerPC G4 and later) or the new intel/x86 pipes for performance. even with hand tuning it is a bear. compilers just can't deal with it. and if a language is more abstract, i.e. .NET, it simply aggravates the issue.

 

taks

Edited November 14, 2006 by taks

[Gorth]

I wouldn't necessarily say C++ was a language of the 60's :blink:"

.NET is not a languagenitpick>

[Diamond]

This taken from a Bioware thread unrelated to thread topic got me concerned.

 

Posted 11/13/06 23:22 (GMT) by racofer

[...]

That's the reason we said NWN2 is beyond repair in terms of performance. .NET is bad and unless NWN2 is re-written from scratch, we will have to live with this.

<{POST_SNAPBACK}>

You can relax, as this is uninformed. NWN2 is not based on .NET, it is a native Win32 application. .NET is required for the toolset (GUI specifically).

[Darque]

Moved to a more appropriate forum.

[Vaclav]

In the past, only way to write efficient programs was writing them directly in assembly langugages. But after complexitiy of writing programs with assembly exceeded the capabilities of programers,  they started to use higher level languages.

 

So, the question is complexitiy.  If using c# makes it possible for programmer to code what he/she wants, then c# is not a bad option.

<{POST_SNAPBACK}>

 

.net is api and not the programs languages :ph34r:

[Diamond]

In the past, only way to write efficient programs was writing them directly in assembly langugages. But after complexitiy of writing programs with assembly exceeded the capabilities of programers,  they started to use higher level languages.

 

So, the question is complexitiy.  If using c# makes it possible for programmer to code what he/she wants, then c# is not a bad option.

<{POST_SNAPBACK}>

 

.net is api and not the programs languages :ph34r:

<{POST_SNAPBACK}>

It is a platform and a technology, not just the API.

[@\NightandtheShape/@]

This thread is void and BS, it is clearly written by someone who knows frak all.

 

Now that said, the best way to get speed is always ASM, but too much ASM can very quickly become unmanageable, that's not to say it can't be managed, but it's hard to work on the bare metal and it's the realm of the elite.

 

Modern games actually contain very little ASM, except for perhaps shaders and some algorithms, C++ and ASM actually work very nicely togeather and while I have never actually had to personally do it, it is always an option for optermization.

 

Now onto C/C++... are they fast, yeah, infact what you'll find games tend to be, is some kinda bastard hybrid of C and C++ all wrapped up into one program. This tends to get the best speed as when you code in C++ most of the time you're just working with C anyways, it's kinda hard for me to articulate, but lets say.. C++ is C but with a little more ontop, this means overheads... So C++ can be slower, when you take into account OOP coding opposed to the bastard hybrid coding style.

 

That said, C++ is certainly not managed, you have to write your own memory management crap, now you can elect to use managed directX but this is mainly for use with C# and Visual Basic .NET.

 

As for .NET it's just a little coder toolkit at the end of the day, it makes the coders life easier (I still tend to write my own purpose write containers, and such for certain tasks).

 

End of.

[@\NightandtheShape/@]

In the past, only way to write efficient programs was writing them directly in assembly langugages. But after complexitiy of writing programs with assembly exceeded the capabilities of programers,  they started to use higher level languages.

 

So, the question is complexitiy.  If using c# makes it possible for programmer to code what he/she wants, then c# is not a bad option.

<{POST_SNAPBACK}>

 

C# is certainly a favourite of mine after C/C++/ASM Hybrids... Just wish I could find a reason to write more bare metal stuff... MMMMM Bare metal.

[Diamond]

C++ is C but with a little more ontop, this means overheads... So C++ can be slower, when you take into account OOP coding opposed to the bastard hybrid coding style.

<{POST_SNAPBACK}>

I'd argue that. With proper use of C++ classes, STL and custom allocators you can achieve same performance as in C. STL may seem bloated, but most of it is compiled inline, e.g. std::vector boils down to simple pointer arithmetic. Coupled with the fact that compilers improved over the years, I'd say C++ overhead is something not worth worrying about.

 

EDIT:

As for .NET it's just a little coder toolkit at the end of the day, it makes the coders life easier (I still tend to write my own purpose write containers, and such for certain tasks).

<{POST_SNAPBACK}>

I'd argue this point too. .NET became widely used as an alternative to Java in IT.

Though I'm not implying that games must be written in it.

 

However MS is sinking a lot of money in pushing the platform in all directions, even game development (managed Direct X) and operating systems (experimental MS operating system, Singularity). My university, for example, offers a scholarship from MS for a PhD research in bioinformatics with C# and SQL Server 2005.

Edited November 14, 2006 by Diamond

[karka]

In the past, only way to write efficient programs was writing them directly in assembly langugages. But after complexitiy of writing programs with assembly exceeded the capabilities of programers,  they started to use higher level languages.

 

So, the question is complexitiy.  If using c# makes it possible for programmer to code what he/she wants, then c# is not a bad option.

<{POST_SNAPBACK}>

 

.net is api and not the programs languages :ph34r:

<{POST_SNAPBACK}>

 

Yes, but discussion was about managed languages.

[@\NightandtheShape/@]

In the past, only way to write efficient programs was writing them directly in assembly langugages. But after complexitiy of writing programs with assembly exceeded the capabilities of programers,  they started to use higher level languages.

 

So, the question is complexitiy.  If using c# makes it possible for programmer to code what he/she wants, then c# is not a bad option.

<{POST_SNAPBACK}>

 

.net is api and not the programs languages :ph34r:

<{POST_SNAPBACK}>

 

Yes, but discussion was about managed languages.

<{POST_SNAPBACK}>

 

around 30% slower, that is all there is to say about managed languages.

[@\NightandtheShape/@]

C++ is C but with a little more ontop, this means overheads... So C++ can be slower, when you take into account OOP coding opposed to the bastard hybrid coding style.

<{POST_SNAPBACK}>

I'd argue that. With proper use of C++ classes, STL and custom allocators you can achieve same performance as in C. STL may seem bloated, but most of it is compiled inline, e.g. std::vector boils down to simple pointer arithmetic. Coupled with the fact that compilers improved over the years, I'd say C++ overhead is something not worth worrying about.

 

EDIT:

As for .NET it's just a little coder toolkit at the end of the day, it makes the coders life easier (I still tend to write my own purpose write containers, and such for certain tasks).

<{POST_SNAPBACK}>

I'd argue this point too. .NET became widely used as an alternative to Java in IT.

Though I'm not implying that games must be written in it.

 

However MS is sinking a lot of money in pushing the platform in all directions, even game development (managed Direct X) and operating systems (experimental MS operating system, Singularity). My university, for example, offers a scholarship from MS for a PhD research in bioinformatics with C# and SQL Server 2005.

<{POST_SNAPBACK}>

 

I was actually in regards to C++ not think of the STL, it doesn't come better than STL, my thought was in regards to general code structure, inheritance is always one that springs to mind.

 

The fastest games are written in both C and C++ and about as readible as a turd.

[Diamond]

How can you use C++ and not use STL?

Anyway, readability of the code is purely author's fault. Except for the cases where you have to use legacy codebase.

[@\NightandtheShape/@]

How can you use C++ and not use STL?

Anyway, readability of the code is purely author's fault. Except for the cases where you have to use legacy codebase.

<{POST_SNAPBACK}>

 

:crazy: When you want speed, there can be too much going off, this is not fault of the author, but sometimes, you have too little room, you reuse variables which you never intended to use for tasks, it can become such a mess, but if it works it works, and if it's fast, then it's fast. Optimized code is always hard to read, naturally readibility is always at the top of the list when you originally write anything, but the gloves come off when it gets to optermization central.

 

Sometimes though, more readible code can be nice and fast, i recently helped cut a programs memory useage by 15MB, just by helping some restructure the way things were contained.

 

I do use STL.

Edited November 14, 2006 by @\NightandtheShape/@

[Diamond]

:crazy: When you want speed, there can be too much going off, this is not fault of the author, but sometimes, you have too little room, you reuse variables which you never intended to use for tasks, it can become such a mess, but if it works it works, and if it's fast, then it's fast. Optimized code is always hard to read, naturally readibility is always at the top of the list when you originally write anything, but the gloves come off when it gets to optermization central.

 

Sometimes though, more readible code can be nice and fast, i recently helped cut a programs memory useage by 15MB, just by helping some restructure the way things were contained.

<{POST_SNAPBACK}>

I was picking at your claim that mixed C/C++ code is ridiculously unreadable by nature (and by "mixed" I mean mixing C/C++ paradigms).

 

Anyway, in my experience, messy code usually means that it has fallen victim to premature optimization. It should be readable even in optimized form unless you have a good reason for it not being readable (interfacing and/or porting auto-generated code or code from different platform/paradigm/etc). Even frameworks optimized for low-memory environment (embedded) can be well structured (look at Symbian C++).

[metadigital]

When you want speed, there can be too much going off, this is not fault of the author, but sometimes, you have too little room, you reuse variables which you never intended to use for tasks, it can become such a mess, but if it works it works, and if it's fast, then it's fast. Optimized code is always hard to read, naturally readibility is always at the top of the list when you originally write anything, but the gloves come off when it gets to optermization central.

<{POST_SNAPBACK}>

That is a brilliant rationalization for poor programming practice. ;p

[Gorth]

When you want speed, there can be too much going off, this is not fault of the author, but sometimes, you have too little room, you reuse variables which you never intended to use for tasks, it can become such a mess, but if it works it works, and if it's fast, then it's fast. Optimized code is always hard to read, naturally readibility is always at the top of the list when you originally write anything, but the gloves come off when it gets to optermization central.

That is a brilliant rationalization for poor programming practice. ;p

>_

 

A less talented coder can write nice structured code that gets a job done in it's own pace. A sloppy coder can write unreadable, but fast code with a low execution complexity O(some funny expr.) or how ever that notation was back at the universithy when doing formal algorithm comparisons. A good coder writes well structured, efficient code. Choice of paradigm is not only a question of coding speed/code execution but a questiion of analysis/design paradigm, maintenance cost, accessability, system integration and a heck of a lot more.

[@\NightandtheShape/@]

When you want speed, there can be too much going off, this is not fault of the author, but sometimes, you have too little room, you reuse variables which you never intended to use for tasks, it can become such a mess, but if it works it works, and if it's fast, then it's fast. Optimized code is always hard to read, naturally readibility is always at the top of the list when you originally write anything, but the gloves come off when it gets to optermization central.

<{POST_SNAPBACK}>

That is a brilliant rationalization for poor programming practice. ;p

<{POST_SNAPBACK}>

 

I'm assuming sarcasam.

 

Sometimes you have to hack, sometimes it has to be as fast as possible, it doesn't matter how it looks, if it's readible, so long as it runs fast, this is the LAST stage of development in games, not the first, you set out and write a lovely well structured program, the best case scenario is that it runs fast enough in it's readable state, but if you need more speed, you get it, you need to consume less memory, you get it, that doesn't mean you forget about comments, or anything of the sort, it just means you can end up writing something evil, and against all good programming practices, because those good programming practices don't exist because they're fast, and efficiant they exist because they make communication easier, atleast from my humble experience base.

Edited November 14, 2006 by @\NightandtheShape/@

[metadigital]

Hee hee. Yes, documentation is the first casualty of programming. (Or was that truth and war? I always get them mixed up ...)