4 ms·

>Each layer of convenience has a penalty. That's only true if you can beat the layer implementation, and frankly I don't know any programmers (including myself

>Each layer of convenience has a penalty. That's only true if you can beat the layer implementation, and frankly I don't know any programmers (including myself) that would beat a optimizing compiler in code generation. >It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point. Here you go : http://deltaengine.net/ http://deltaengine.net/ - used in this game : http://soulcraftgame.com/ http://soulcraftgame.com/ a pure managed game engine, cross platform (works on iOS, Android, WP, Windows - XBox/Linux/OSX planned next, possibly ported to other consoles). Also look up indie game titles, XNA, Mono games, etc. It's not AAA stuff, but I never claimed otherwise. Simple tools are far more valuable than performance in many scenarios.

batista 15y ago
That's only true if you can beat the layer, and frankly I don't know any programmers (including myself) that would beat a optimizing compiler in code generation. We're not talking writing assembly vs having the compiler do it, here. We're talking using a high level language with features such as garbage collection, bounds checking etc, versus not. Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler". For an extreme example, a C++ program can easily beat a JRuby program -- despite the JRuby program being run on an optimizing JIT compiler. The only cost is more programmer work, but not in the scale of difficulty of writing assembly versus C++. And in fields such as Games and Multimedia, you don't sacrifice performance for programmer convenience.
- moonchrome 15y ago
  >Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler". No - those layers were invented because those things were such common errors - ie. - most people got them wrong. So nope, most people aren't able to beat those in everyday code, and debugging is expensive. Performance is not the only metric, even in games, and you have to "beat" the other metrics as well - such as bug count/correctness and productivity. Maybe when you have AAA titles and can budget a few millions on dev team alone the equation looks different, and that's why I singled them out. But for small teams (mobile) and indies/amateurs .NET is good enough (and is being used). And games regularly sacrifice performance for productivity, look up early unreal script (interpreted), and how it was often the bottle neck but was still used in development.

batista 15y ago

That's only true if you can beat the layer, and frankly I don't know any programmers (including myself) that would beat a optimizing compiler in code generation. We're not talking writing assembly vs having the compiler do it, here. We're talking using a high level language with features such as garbage collection, bounds checking etc, versus not. Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler". For an extreme example, a C++ program can easily beat a JRuby program -- despite the JRuby program being run on an optimizing JIT compiler. The only cost is more programmer work, but not in the scale of difficulty of writing assembly versus C++. And in fields such as Games and Multimedia, you don't sacrifice performance for programmer convenience.

moonchrome 15y ago
>Those kinds of layers are both expensive AND beatable, regardless of the "optimizing compiler". No - those layers were invented because those things were such common errors - ie. - most people got them wrong. So nope, most people aren't able to beat those in everyday code, and debugging is expensive. Performance is not the only metric, even in games, and you have to "beat" the other metrics as well - such as bug count/correctness and productivity. Maybe when you have AAA titles and can budget a few millions on dev team alone the equation looks different, and that's why I singled them out. But for small teams (mobile) and indies/amateurs .NET is good enough (and is being used). And games regularly sacrifice performance for productivity, look up early unreal script (interpreted), and how it was often the bottle neck but was still used in development.