Every Byte Matters • Hacker News Board

Re: Every Byte Matters

#151

Post by pron » Fri, Jun 05, 2026, 10:06 AM UTC

mabster wrote: post #149

imtringued wrote: post #129

Earlier quoted context omitted.

>I wouldn't say HPC and video game engines are "traditional performance critical work". Not because they're not performance critical, but because the range of performance critical programs is far larger - think bank card transaction processing; think mobile phone routing, and there are many more examples (also, AAA video game engines are indeed very traditional in their design and tech choices, but their performance-…

Low level CPU-related optimisation is absolutely still a thing. The GPU is always filled to the brim trying to get as much quality out of a graphics frame so a lot gets offloaded to the CPU. When I was doing this I was doing a lot of low-level CPU optimisation. GPU optimisation was usually more about transform process topology but there was plenty of low-level work to do there too. Games are both high throughput AND…

C++ is no doubt king in games (for reasons that aren't necessarily primarily performance [1]), but not only are there plenty of high-throughput low-latency applications in C++, I believe there are more than in C++.

BTW, "low latency" is relative, and in most games the relevant latency is the frame, which is usually between 5-15 ms. I worked at a place that did large low-latency software, some soft realtime and some safety-critical hard realtime, where the cutoff between Java and low-level was whether the required latency was under 10us (tha's microseconds!). That's an order of magnitude below what's in games. We did use specialised versions of Java (and specialised kernels), but these days, on normal OSes and plain Java, the cutoff is usually around 1-3ms (although at that point you often need special kernels anyway).

Something that C++ people often don't know is that there's nothing in Java that makes it any harder to compile and run with optimisations at least as good as those offered by C++, but the opposite isn't the case: there are fundamental problems that make it hard to perform some optimisations in C++. Of course, the tradeoff is predictability. Some aggressive optimisations require speculation, which means a fallback to deoptimised (even interpreted) code and then recompilation. I pure compilation and memory management terms, Java has the advantage, but it aims to make the average-case faster than C++ at the expense of the worst case.

[1]: E.g. AAA games are extremely conservative when it comes to technology choices; more conservative than even the military. AAA games often need to target limited consoles where there are few alternatives to C++ available.

Re: Every Byte Matters

#152

Post by [deleted] » Fri, Jun 05, 2026, 3:43 PM UTC

rao-v wrote: post #150

jayd16 wrote: post #142

Earlier quoted context omitted.

Well the whole point is that memory (cache in this case) is not cheap at all. We have very little and the point is to do as little loading of what you don't care about as possible to keep the cache full of only exactly what is needed for the task. How do you imagine it's possible to write to every SoA and every AoS and have that as cheap as only the first step?

Many operations are map reduce where writes are low volume compared to reads

[deleted]

Re: Every Byte Matters

#153

Post by mabster » Sat, Jun 06, 2026, 8:31 AM UTC

pron wrote: post #151

mabster wrote: post #149

Earlier quoted context omitted.

Low level CPU-related optimisation is absolutely still a thing. The GPU is always filled to the brim trying to get as much quality out of a graphics frame so a lot gets offloaded to the CPU. When I was doing this I was doing a lot of low-level CPU optimisation. GPU optimisation was usually more about transform process topology but there was plenty of low-level work to do there too. Games are both high throughput AND…

C++ is no doubt king in games (for reasons that aren't necessarily primarily performance [1]), but not only are there plenty of high-throughput low-latency applications in C++, I believe there are more than in C++. BTW, "low latency" is relative, and in most games the relevant latency is the frame, which is usually between 5-15 ms. I worked at a place that did large low-latency software, some soft realtime and some s…

I'm a Java developer now, amongst other languages. The advantage of Java is that it takes A LOT less time to develop something, so there is the whole bang for buck for sure. I have had a few problems where I would love shared direct memory access and some atomics (because it would be a lot easier). But for the most part developing in Java is a lot quicker.

I don't think game developers are more conservative than any other developers. We do have large C++ codebases and so it's hard to change.

All modern engines have a few scripting languages tacked on too.

Something like Lua usually is the sweet spot: most of the people developing scripts are not developers. We even had a Java interpreter for scripting once, but it lost favor for this reason.

There were exceptions, but I found that developers generally preferred C# over Java anyway. Our assets pipelines are generally in C# already.

Any speculative optimisation we were doing by hand. There is the whole deferring allocations / moving allocations, both of which we were already doing (e.g. copying every frame).

A lot of our C++ code is intrinsics (including memory primitives like _mm_stream_ps and barriers) and you HAVE to have good control over how memory is laid out (e.g. knowing that data is split between cache lines so that you you don't get contention). Lots of spin locks too. I just don't see how you can do this kind of low level work in Java.

Re: Every Byte Matters

#154

Post by pron » Sat, Jun 06, 2026, 11:12 AM UTC

mabster wrote: post #153

pron wrote: post #151

Earlier quoted context omitted.

C++ is no doubt king in games (for reasons that aren't necessarily primarily performance [1]), but not only are there plenty of high-throughput low-latency applications in C++, I believe there are more than in C++. BTW, "low latency" is relative, and in most games the relevant latency is the frame, which is usually between 5-15 ms. I worked at a place that did large low-latency software, some soft realtime and some s…

I'm a Java developer now, amongst other languages. The advantage of Java is that it takes A LOT less time to develop something, so there is the whole bang for buck for sure. I have had a few problems where I would love shared direct memory access and some atomics (because it would be a lot easier). But for the most part developing in Java is a lot quicker. I don't think game developers are more conservative than any…

> A lot of our C++ code is intrinsics (including memory primitives like _mm_stream_ps and barriers)

Java has such intrinsicts, too: https://docs.oracle.com/en/java/javase/25/docs/api/java.base.... They may not look like intrinsics that compile to a single machine instruction, but the are (I don't think we offer stream access, simply because there hasn't been demand for it; if there is, we can add it. I actually added a streaming array copy to the JVM because I thought I could use it for something, but the results weren't what I expected, so I took it out)

BTW, here's a list of our intrinsics:

https://github.com/openjdk/jdk/blob/master/src/hotspot/share...

As you might notice, they include SIMD intrinsics offered through https://docs.oracle.com/en/java/javase/25/docs/api/jdk.incub...

> and you HAVE to have good control over how memory is laid out (e.g. knowing that data is split between cache lines so that you don't get contention)

We have the `@Contended` annotation precisely for that: https://github.com/openjdk/jdk/blob/master/src/java.base/sha... You have to use a flag to tell the JVM to respect this annotation, but the people who write high performance code know this: https://www.baeldung.com/java-false-sharing-contended

> Lots of spin locks too.

We have an intrinsic for spin locks: Thread.onSpinWait() https://docs.oracle.com/en/java/javase/25/docs/api/java.base...()

> I just don't see how you can do this kind of low level work in Java.

There's no reason you should if you're not writing high performance code in Java, but the people who write such code in Java know how to do these things in Java.

To be clear, Java certainly doesn't offer as much precise control as a low-level language, but it does offer everything you need for high performance (except array-of-struct, but that will arrive soon). The reason for that is that there's high demand for these constructs because so much of the worlds performance-sensitive software is written in Java. Traditionally, not games (which often have to run on platforms for which we don't offer Java) but manufacturing automation, defence, and trading.

> There is the whole deferring allocations / moving allocations, both of which we were already doing (e.g. copying every frame).

Yes, you can certainly do some memory management optimisations in C++, although with some effort (it's especially hard to use some standard library stuff, but when I write high performance code in C++ I don't use std at all). The low-level language that makes it easier is Zig.

> Any speculative optimisation we were doing by hand.

It's hard to do speculative optimisation by hand, unless you're generating code on the fly. The way speculative optimisations work is that we observe that something has been true so far (e.g. think about a specific branch that's always taken or a dynamic dispatch that only hits a certain target at a certain callsite) but the compiler can't prove that it's necessarily true. So we emit machine code that assumes it's true with special traps that would trigger some fault signal if the assumption is invalidated. If the trap is hit, we capture the signal, deoptimise the subroutine and then recompile it differently (without the assumption).

In C++ what I do is do some of the same optimisation results by hand (typically using templates), but of course, they're not speculative and I need to be careful. There's also code size and I-cache implications, but while we try to keep an eye on the I-cache, Java doesn't always get this balance right, either.

Re: Every Byte Matters

#155

Post by vouwfietsman » Sat, Jun 06, 2026, 2:59 PM UTC

tsimionescu wrote: post #108

vouwfietsman wrote: post #95

Earlier quoted context omitted.

I'm not sure why anybody would at the same time be implementing SoA AND resizing 20 arrays for a single delete, those things seem to be on either ends of the "I care about performance" spectrum.

The point is that a simple SoA implementation requires this - each field in the monster struct is an item in 20 different arrays. So, removing one monster means removing that item from those 20 arrays. Now, as others have suggested, you can have a more complex implementation, where instead of removing the monster's fields from those arrays, you just mark them as "dead" or whatever and then skip them when consuming th…

> So, removing one monster means removing that item from those 20 arrays.

Removing from an array is not the same as resizing, which is what I commented on. Resizing is a very deliberate, bad, choice.

If you need to support deletes, you can do this without resizing an array. Either by tracking object lifetimes and inserting tombstones, or by swapping to fill in deleted objects. Both of them retain good performance characteristics. Both of them are easy.

This is not "simple vs complex" this is "I misunderstand vs understand SoA"

Re: Every Byte Matters

#156

Post by johnthescott » Sun, Jun 07, 2026, 2:28 AM UTC

if truly "every byte matters" then why java?

Re: Every Byte Matters

#157

Post by mabster » Sun, Jun 07, 2026, 9:29 AM UTC

pron wrote: post #154

mabster wrote: post #153

Earlier quoted context omitted.

I'm a Java developer now, amongst other languages. The advantage of Java is that it takes A LOT less time to develop something, so there is the whole bang for buck for sure. I have had a few problems where I would love shared direct memory access and some atomics (because it would be a lot easier). But for the most part developing in Java is a lot quicker. I don't think game developers are more conservative than any…

> A lot of our C++ code is intrinsics (including memory primitives like _mm_stream_ps and barriers) Java has such intrinsicts, too: https://docs.oracle.com/en/java/javase/25/docs/api/java.base... . They may not look like intrinsics that compile to a single machine instruction, but the are (I don't think we offer stream access, simply because there hasn't been demand for it; if there is, we can add it. I actually adde…

Ok fair enough. I don't write performance stuff in Java so I haven't even needed to look at this stuff to be honest. Most of the intrinsics I would want are there, except for any memory related stuff. I'm still not sure how structs are laid out in memory but I guess there's something for that too. My favourite thing in C++ is just loading a big binary blob and being able to point directly into it.

The only thing that was different was that we had a number of platform-specific intrinsics to really shake fast code out. E.g. shuffles on x86 on older SSE editions were terrible and we would have custom x86 code for shuffles or let memory out differently.

The only thing we use from C++ stdlib is unique_ptr. For everything else we had our own much more tailored, much faster, stuff. We had something like 10 different array containers for example.

Yeah what you described with templates is what we are doing re speculative optimisation. We have tuned versions for different workloads. We would inspect before we decide which one to run (only if that wasn't slower then just having one implementation, which was often the case because of instruction cache).

Something to be aware of is that on consoles mmapping a page to be executable was forbidden. So no JIT. And you aim for your slowest target so PC just follows that.

Re: Every Byte Matters

#158

Post by pron » Sun, Jun 07, 2026, 10:53 AM UTC

mabster wrote: post #157

pron wrote: post #154

Earlier quoted context omitted.

> A lot of our C++ code is intrinsics (including memory primitives like _mm_stream_ps and barriers) Java has such intrinsicts, too: https://docs.oracle.com/en/java/javase/25/docs/api/java.base... . They may not look like intrinsics that compile to a single machine instruction, but the are (I don't think we offer stream access, simply because there hasn't been demand for it; if there is, we can add it. I actually adde…

Ok fair enough. I don't write performance stuff in Java so I haven't even needed to look at this stuff to be honest. Most of the intrinsics I would want are there, except for any memory related stuff. I'm still not sure how structs are laid out in memory but I guess there's something for that too. My favourite thing in C++ is just loading a big binary blob and being able to point directly into it. The only thing that…

> My favourite thing in C++ is just loading a big binary blob and being able to point directly into it.

That's what the Foreign Function & Memory API (FFM) is for: https://docs.oracle.com/en/java/javase/25/docs/api/java.base... (before FFM, this was done through something called Unsafe, which is now in the process of being removed).

> Something to be aware of is that on consoles mmapping a page to be executable was forbidden. So no JIT. And you aim for your slowest target so PC just follows that.

Certainly. Games have very good reasons to prefer C++ over Java. But these reasons have much more to do with platform support and other hardware constraints than sheer performance.

Re: Every Byte Matters

#159

Post by tealpod » Thu, Jun 11, 2026, 10:44 AM UTC

pron wrote: post #71

tealpod wrote: post #64

Earlier quoted context omitted.

We compiled one of our Java app to native binary using GraalVM (for encyption and secret managment needs). Side effect is the Java native binary performance is excellent, app startup time also significantly less compared to JVM version. I am not sure how it compares with C++, Rust and Zig, but we made a benchmark with a similar Go binary, Java native version performance (load tests) is similar to Go binary. Only RAM…

The RAM difference is primarily because both Native Image (what you call Graal VM) and Go use much simpler and less efficient memory management techniques. HotSpot uses much more RAM by design as there are inefficiencies caused by using too little of it. Memory management - and especially very sophisticated approaches that are only used by the best resourced teams - is an especially misunderstood aspect. I gave a tal…

Nice, I like to see your talk video, audio. Thanks.