Hacker News new | ask | show | jobs
by mabster 4 days ago
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.

1 comments

> 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.