4 ms·

>Most games and most intensive applications are C++ based. That's what I'm trying to say. .NET is finally in the place where it's good enough for games (except

>Most games and most intensive applications are C++ based. That's what I'm trying to say. .NET is finally in the place where it's good enough for games (except AAA titles), unlike JVM it supports value types and has true generics that can generate proper collections for them (big deal for games where a lot of the data is in small tuples of floats) and lot's of "unsafe" stuff where you get direct memory access. Mono guys even developed AOT compiler with LLVM optimizer and allowed you to drop things such as runtime bounds checking - you'd probably get to 10% of C++ code, the only remaining problem being non-deterministic GC pauses (can be worked around). Also I don't know why "intensive" applications can't be written on .NET with maybe a few drops to native C when needed. If it's scientific/cluster computing/number crunching then - I'm speculating - but I doesn't sound like you want to be running Windows anyway and Microsoft doesn't ship their C++ tools for other platforms so that doesn't sound reasonable. But we're arguing different points here. I'm not asking - why is Microsoft supporting C++. What I'm saying is - they seem to be pushing a new fad with this "going native" stuff - and I don't see any rationale behind it. Why actively push for C++ over .NET, .NET doesn't seem to be getting nearly as much attention recently (I could be wrong tough) and let's face it C++ isn't exactly something that needs marketing to get noticed and picked up and it doesn't even seem to be MS strong point in the market.

batista 15y ago
That's what I'm trying to say. .NET is finally in the place where it's good enough for games No, it's not. Only for higher level game logic. Even Word made with .NET would fill sluggish. Each layer of convenience has a penalty. It does gets better with Moore's law, but native also gets better along with it, so the gap remains. Plus, we always do more stuff with our software, so CPU demands are getting higher too. It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point.
- moonchrome 15y ago
  >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.
stonemetal 15y ago
Especially in the light of Windows 8 and ARM support. Have they announced anything like Apple's Fat binaries? Surely emulating ARM on x86 isn't the whole plan. If it is the marketing of "going native" is a bit amusing. I am just glad the static analysis tools are coming to the low end VS.
vonmoltke 15y ago
If it's scientific/cluster computing/number crunching then - I'm speculating - but I doesn't sound like you want to be running Windows anyway and Microsoft doesn't ship their C++ tools for other platforms so that doesn't sound reasonable. It is reasonable when you consider that Microsoft has been trying to break Windows into the HPC segment over the past two years or so. The perceived lack of a suitable toolchain and focus on the development of enterprise languages and technologies helped keep Microsoft out of that arena. This re-emphasis on C++ is a necessary, though not sufficient, step if they want to continue pushing for that market.

batista 15y ago

That's what I'm trying to say. .NET is finally in the place where it's good enough for games No, it's not. Only for higher level game logic. Even Word made with .NET would fill sluggish. Each layer of convenience has a penalty. It does gets better with Moore's law, but native also gets better along with it, so the gap remains. Plus, we always do more stuff with our software, so CPU demands are getting higher too. It's not like software (especially games) is static, so that the managed/native gap will get insignificantly imperceptible at some point.

moonchrome 15y ago
>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.

stonemetal 15y ago

Especially in the light of Windows 8 and ARM support. Have they announced anything like Apple's Fat binaries? Surely emulating ARM on x86 isn't the whole plan. If it is the marketing of "going native" is a bit amusing. I am just glad the static analysis tools are coming to the low end VS.

vonmoltke 15y ago

If it's scientific/cluster computing/number crunching then - I'm speculating - but I doesn't sound like you want to be running Windows anyway and Microsoft doesn't ship their C++ tools for other platforms so that doesn't sound reasonable. It is reasonable when you consider that Microsoft has been trying to break Windows into the HPC segment over the past two years or so. The perceived lack of a suitable toolchain and focus on the development of enterprise languages and technologies helped keep Microsoft out of that arena. This re-emphasis on C++ is a necessary, though not sufficient, step if they want to continue pushing for that market.