2 ms·
A few reasons: Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it wo
by gwbas1c 8d ago
A few reasons:
Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it would be slower.) I've personally done some high performance multithreaded programming in C# / .Net, but it only "works" because C# / .Net assumes the TSO memory model. (Described in TFA.)
In contrast, games need to squeak every cycle of performance out of their chips, and optimizations can be very CPU specific. When games target bytecode, they either won't be able to take full advantage of the hardware, or otherwise will need a lot of platform-specific fallbacks (that negate the point of bytecode anyway.)
(This is why I prefer console gaming or "simple" games that don't tax the hardware.)
- MiroslavPokorny 7d agoI appreciate there will parts of a game that have hand rolled assembly, but even those have problems when x86 move forward. In the near future SIMD instructions will double their widths and todays fast code using them will be old. C# solves this problem by providing rich libs, so Microsoft continues to evolve faster functions, without programmers having to the all do the same work again and again.