2 ms·

"But for the sake of Carmack's engineering background however, it is unsurprising why Java/C#/Kotlin are technically unsuitable for high-performance gaming plat

by jariel 7y ago

"But for the sake of Carmack's engineering background however, it is unsurprising why Java/C#/Kotlin are technically unsuitable for high-performance gaming platforms if one was to create one." This really is just not true. Financial, real-time style High Frequency Trading apps are often written in Java - not C++. Much of the JVM is not a VM, it compiles to machine code - in an optimised manner. For starters. Given how difficult it is to develop safely in C++ I can hardly think of a reason to ever use it on the backend.

SaxonRobber 7y ago
This and more opinions from the oracle certified java guru.
- kitd 7y ago
  Which part are opinions?
- dwohnitmok 7y ago
  From the HN guidelines for commenting (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html): > Be kind. Don't be snarky. > Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data.
jiggawatts 7y ago
Trading apps generally process a small amount of data. Graphs are downright lightweight compared to what a 3D game pumps through. Generally, for a 3D game manual memory management and explicit data layout are critical. For example, it's common to use custom memory allocators with a region for each frame, a region for each loaded level, etc... This is then much cheaper to simply drop on the floor than any kind of object-by-object cleanup, whether that is reference counting, garbage collecting, a traditional heap, or whatever. Even Rust can't yet compete with this! Similarly, many game engines use ECS systems or in-memory columnar data layout to (structure of arrays instead of arrays of structures) to enable SIMD instruction sets such as AVX. Java can be coerced into doing much of the above, but it generally takes a ridiculous effort to approach what comes nearly effortlessly with a language like C++ or Rust. Even C# is a better choice than Java, as it monomorphises more code and recently had a range of extensions[1] added to reduce GC pressure such as stackalloc, Span, Memory, MemoryPool, SequenceReader, ValueTask, etc... I've bought and played several games written in C#, but other than Minecraft I'm not aware of any popular real-time games written in Java in the last 15 years or so. Meanwhile, Minecraft is not at all smooth on my very high end gaming PC in 2019 despite being 8 years old. (I'm sure this can be eliminating by tweaking some settings, but it's indicative of the problem.) I say this as someone who used to professionally develop browser-based Java games back in the early 2000s and had to personally jump through hoops to reduce heap allocations to avoid GC pauses. [1] https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/connect/csharp-all-about-span-exploring-a-new-net-mainstay https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/...
- jariel 7y ago
  Yes thanks for that but I think author was referring to game synch server not actual games. Synching minimal state data can use small data structures etc. But thanks though great comment.
  - jiggawatts 7y ago
    If anything the server-side coding is harder. Many games do the full physics/simulation on the server to minimise cheating, and have to simulate from every player's perspective. Meanwhile the clients have a single perspective and most of the computation effort is offloaded to the GPU. Additionally, most multiplayer games have the same codebase for the server and the client for the obvious reasons. Single player is literally "online play" with an in-memory channel to a local server. All Quake-based games work this way, including the derivative Source-based games and a bunch of other engine variants. Unreal works this way too if I remember correctly. You can't realistically write a client in C++ and a server in Java. You'd be practically doubling your development time!
bsenftner 7y ago
The developer lie most have been hoodwinked to believe: "Given how difficult it is to develop safely in C++..." No. That is high level language propaganda and simply not true.
twic 7y ago
> Financial, real-time style High Frequency Trading apps are often written in Java - not C++. They're written in a very specific style of Java, where you take pains not to allocate, which looks a lot more like C++ than idiomatic Java. Operationally, strange rituals are followed to avoid recompilation or other otherwise normal runtime activity during trading hours. The app will be started on sunday night, and the team spends the week praying it doesn't need restarting during the week. You can do HFT in Java, but it's a dancing bear.

by jariel 7y ago

SaxonRobber 7y ago

This and more opinions from the oracle certified java guru.

kitd 7y ago
Which part are opinions?
dwohnitmok 7y ago
From the HN guidelines for commenting (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html): > Be kind. Don't be snarky. > Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data.

jiggawatts 7y ago

Trading apps generally process a small amount of data. Graphs are downright lightweight compared to what a 3D game pumps through. Generally, for a 3D game manual memory management and explicit data layout are critical. For example, it's common to use custom memory allocators with a region for each frame, a region for each loaded level, etc... This is then much cheaper to simply drop on the floor than any kind of object-by-object cleanup, whether that is reference counting, garbage collecting, a traditional heap, or whatever. Even Rust can't yet compete with this! Similarly, many game engines use ECS systems or in-memory columnar data layout to (structure of arrays instead of arrays of structures) to enable SIMD instruction sets such as AVX. Java can be coerced into doing much of the above, but it generally takes a ridiculous effort to approach what comes nearly effortlessly with a language like C++ or Rust. Even C# is a better choice than Java, as it monomorphises more code and recently had a range of extensions[1] added to reduce GC pressure such as stackalloc, Span, Memory, MemoryPool, SequenceReader, ValueTask, etc... I've bought and played several games written in C#, but other than Minecraft I'm not aware of any popular real-time games written in Java in the last 15 years or so. Meanwhile, Minecraft is not at all smooth on my very high end gaming PC in 2019 despite being 8 years old. (I'm sure this can be eliminating by tweaking some settings, but it's indicative of the problem.) I say this as someone who used to professionally develop browser-based Java games back in the early 2000s and had to personally jump through hoops to reduce heap allocations to avoid GC pauses. [1] https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/connect/csharp-all-about-span-exploring-a-new-net-mainstay https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/...

jariel 7y ago
Yes thanks for that but I think author was referring to game synch server not actual games. Synching minimal state data can use small data structures etc. But thanks though great comment.
- jiggawatts 7y ago
  If anything the server-side coding is harder. Many games do the full physics/simulation on the server to minimise cheating, and have to simulate from every player's perspective. Meanwhile the clients have a single perspective and most of the computation effort is offloaded to the GPU. Additionally, most multiplayer games have the same codebase for the server and the client for the obvious reasons. Single player is literally "online play" with an in-memory channel to a local server. All Quake-based games work this way, including the derivative Source-based games and a bunch of other engine variants. Unreal works this way too if I remember correctly. You can't realistically write a client in C++ and a server in Java. You'd be practically doubling your development time!

bsenftner 7y ago

The developer lie most have been hoodwinked to believe: "Given how difficult it is to develop safely in C++..." No. That is high level language propaganda and simply not true.

twic 7y ago

> Financial, real-time style High Frequency Trading apps are often written in Java - not C++. They're written in a very specific style of Java, where you take pains not to allocate, which looks a lot more like C++ than idiomatic Java. Operationally, strange rituals are followed to avoid recompilation or other otherwise normal runtime activity during trading hours. The app will be started on sunday night, and the team spends the week praying it doesn't need restarting during the week. You can do HFT in Java, but it's a dancing bear.