9 ms·

And the Java ones don't look anything at all like typical Java, either. But no, the C/C++ ones have not been all manually vectorized to death. The binary-trees

And the Java ones don't look anything at all like typical Java, either. But no, the C/C++ ones have not been all manually vectorized to death. The binary-trees one, for example, is a fairly clean C++ implementation, and runs in less than half the time using less than half the memory of the Java version. It looks like 'only' 4 of the C++ ones use any vectorization intrinsics. > But if you don't, there is no magical 5x speedup of C++ over Java. Nobody said anything about "magic." AOTs are really good. Value types are really good. Return types consistently being on the stack without requiring escape analysis is really good. Java's performance is impressive for how crippled it is by the language, but HotSpot is definitely far from magic. It can't recover from the limitations of the language. You're fully paying for the "high level" & simple nature of Java.

tom_mellior 6y ago
> And the Java ones don't look anything at all like typical Java, either. Which ones do you mean? > But no, the C/C++ ones have not been all manually vectorized to death. True. > The binary-trees one, for example, is a fairly clean C++ implementation, and runs in less than half the time using less than half the memory of the Java version. Unfortunately I can't benchmark this myself because it uses some library I've never heard of. The numbers on the Debian site look pretty outdated, Java binary-trees takes about 1800 ms on my machine. And about 1450 ms after letting it warm up. > AOTs are really good. So are JITs, but we are both really deep in hand-waving territory here. > Return types consistently being on the stack without requiring escape analysis is really good. The fast path of object allocation is bumping a pointer into an allocation buffer and checking it against the buffer's limit. Objects that are short-lived enough that you would want to return them by value in C++ will usually never leave the allocation buffer. So it's not the exact same thing as allocating on the call stack, but it's not far.
- igouy 6y ago
  > … some library I've never heard of… http://apr.apache.org/docs/apr/1.5/group__apr__pools.html http://apr.apache.org/docs/apr/1.5/group__apr__pools.html > The numbers on the Debian site look pretty outdated… slow ?
- kllrnohj 6y ago
  > So it's not the exact same thing as allocating on the call stack, but it's not far. Unfortunately it is far. Creating an address is quick, yes. But that address consistently won't be in L1/L2. Likely won't even be in L3. And if it's a return value containing more than one allocation that's easily more than one cache miss along with dependent reads.

tom_mellior 6y ago

> And the Java ones don't look anything at all like typical Java, either. Which ones do you mean? > But no, the C/C++ ones have not been all manually vectorized to death. True. > The binary-trees one, for example, is a fairly clean C++ implementation, and runs in less than half the time using less than half the memory of the Java version. Unfortunately I can't benchmark this myself because it uses some library I've never heard of. The numbers on the Debian site look pretty outdated, Java binary-trees takes about 1800 ms on my machine. And about 1450 ms after letting it warm up. > AOTs are really good. So are JITs, but we are both really deep in hand-waving territory here. > Return types consistently being on the stack without requiring escape analysis is really good. The fast path of object allocation is bumping a pointer into an allocation buffer and checking it against the buffer's limit. Objects that are short-lived enough that you would want to return them by value in C++ will usually never leave the allocation buffer. So it's not the exact same thing as allocating on the call stack, but it's not far.

igouy 6y ago
> … some library I've never heard of… http://apr.apache.org/docs/apr/1.5/group__apr__pools.html http://apr.apache.org/docs/apr/1.5/group__apr__pools.html > The numbers on the Debian site look pretty outdated… slow ?
kllrnohj 6y ago
> So it's not the exact same thing as allocating on the call stack, but it's not far. Unfortunately it is far. Creating an address is quick, yes. But that address consistently won't be in L1/L2. Likely won't even be in L3. And if it's a return value containing more than one allocation that's easily more than one cache miss along with dependent reads.