An inquiry into nondogmatic software development. An experiment showing double performance of the code running on JVM comparing to equivalent native C code.
"It seems that the code executing on VM can be actually much faster than the native one thanks to technologies like HotSpot"
Execute VM inside a VM, then repeat arbitrary many times => unlimited speedup! Check mate atheists!
It's either that or you're just writing very inefficient native code... I wonder which one is more likely....
Just like in your case you're calling malloc()/free() just to allocate 24 bytes of data. Internally those general purpose allocators are very complex library functions from the particular libc implementations. They maintain data structures to track allocations of various sizes and when they need to allocate more memory than the fixed pools they already have they call mmap()/sbrk() (Linux) or VirtualAlloc (Windows) to ask the OS to map more physical memory in their virtual address space (which is not trivial in terms of cost as well). With all that said none of the libc implementations that I've seen implements those function in such a way so that they are fast for very small and frequent allocations (not only because such pattern is very uncommon among good C programs but also because you could've done much better job manually by building your own allocator knowing the exact small-size limits and allocation frequency). On the other hand due to the nature of Java such small allocations are more common (sometimes can be unavoidable) so I suspect the JVM guys have designed allocation strategy that does decent job on very small sizes. Internally they probably allocate memory at decently sized chunks and then give small pieces of them to your nodes (your nodes also probably end up much closer in memory to each other improving cache locality a lot).
Writing a good custom allocator in C could speed up your program by an order of magnitude. Even the most basic pool allocator implementation will probably easily destroy your Java code...
I can't believe people are still coping with this "Java is n times faster than native" meme that's been going for years now. Stop it, get some help.
morisil
commented
3 years ago
"It seems that the code executing on VM can be actually much faster than the native one thanks to technologies like HotSpot"
Execute VM inside a VM, then repeat arbitrary many times => unlimited speedup! Check mate atheists!
It's either that or you're just writing very inefficient native code... I wonder which one is more likely....
Just like in your case you're calling
malloc()/free()just to allocate 24 bytes of data. Internally those general purpose allocators are very complex library functions from the particular libc implementations. They maintain data structures to track allocations of various sizes and when they need to allocate more memory than the fixed pools they already have they callmmap()/sbrk()(Linux) orVirtualAlloc(Windows) to ask the OS to map more physical memory in their virtual address space (which is not trivial in terms of cost as well). With all that said none of the libc implementations that I've seen implements those function in such a way so that they are fast for very small and frequent allocations (not only because such pattern is very uncommon among good C programs but also because you could've done much better job manually by building your own allocator knowing the exact small-size limits and allocation frequency). On the other hand due to the nature of Java such small allocations are more common (sometimes can be unavoidable) so I suspect the JVM guys have designed allocation strategy that does decent job on very small sizes. Internally they probably allocate memory at decently sized chunks and then give small pieces of them to your nodes (your nodes also probably end up much closer in memory to each other improving cache locality a lot). Writing a good custom allocator in C could speed up your program by an order of magnitude. Even the most basic pool allocator implementation will probably easily destroy your Java code...I can't believe people are still coping with this "Java is n times faster than native" meme that's been going for years now. Stop it, get some help.