But the bigger ones are not yet (so, no results yet).
One of the important questions to answer first is how the mapping should be done. A naive version using new/delete/smartpointers is going to have performance issues. Other options would be to use arena allocators and completely remove memory management overhead from the equation. Depending on what comparison/C++ usage scenario is desired, both options would be useful.
Interesting that Crystal did worse than Java even on many non-GC-stress-test benchmarks. I wasn't expecting that.
Some theories as to sources of the slowness:
- The Boehm GC is so much worse that it accounts for bad performance even on benchmarks that don't stress it.
- Crystal's polymorphic calls don't use inline caches and JIT speculation so they aren't as fast as Java's.
- LLVM isn't as good at bounds check elimination as Java because C++ doesn't need it.
- The Crystal code used reference types where it normally would use value types, and Java really has a better code generator for this sort of object-oriented code.
From: http://www.oracle.com/technetwork/java/whitepaper-135217.htm...
"The Server VM contains an advanced adaptive compiler that supports many of the same types of optimizations performed by optimizing C++ compilers, as well as some optimizations that cannot be done by traditional compilers, such as aggressive inlining across virtual method invocations. This is a competitive and performance advantage over static compilers. Adaptive optimization technology is very flexible in its approach, and typically outperforms even advanced static analysis and compilation techniques."
So HotSpot may detect "hot spot code" in runtime and aggressively inline it - this is what LLVM can not do, becuase it doesn't run in runtime...
4 comments
[ 2.8 ms ] story [ 16.3 ms ] threadBut the bigger ones are not yet (so, no results yet).
One of the important questions to answer first is how the mapping should be done. A naive version using new/delete/smartpointers is going to have performance issues. Other options would be to use arena allocators and completely remove memory management overhead from the equation. Depending on what comparison/C++ usage scenario is desired, both options would be useful.
Some theories as to sources of the slowness:
- The Boehm GC is so much worse that it accounts for bad performance even on benchmarks that don't stress it.
- Crystal's polymorphic calls don't use inline caches and JIT speculation so they aren't as fast as Java's.
- LLVM isn't as good at bounds check elimination as Java because C++ doesn't need it.
- The Crystal code used reference types where it normally would use value types, and Java really has a better code generator for this sort of object-oriented code.
So HotSpot may detect "hot spot code" in runtime and aggressively inline it - this is what LLVM can not do, becuase it doesn't run in runtime...