News for hackers. Stuff that matters.

A comment on Performance in Big Data Land: Every CPU cycle matters. Parent comment

Re:Performance in Big Data Land: Every CPU cycle matters by nostrademons on Wednesday October 28, 2015 @08:09PM (#10468360)
There's still a pretty big speed penalty for Java because the object model encourages a lot of pointer-chasing, which will blow your data locality. In C++, it's common for contained structs to be flat in memory, so accessing a data member in them is just an offset from a base address. In Java, all Object types are really pointers, which you need to dereference to get the contained object. HotSpot can't really optimize this beyond putting really frequently used objects in registers.

A lot of big-data work involves pulling out struct fields from a deeply nested composite record, and then performing some manipulation on them.

[ Parent | on HN ]
Re:Performance in Big Data Land: Every CPU cycle matters by vvanders on Wednesday October 28, 2015 @08:34PM (#10468460)
Listen to the parent here, I've seen 10x performance in production Java code just using flatbuffers(and paying the marshaling costs from ByteBuffer).

50x is not unreasonable for C/C++ code that was OO and uses a data oriented approach instead.

[ Parent | on HN ]
Re:Performance in Big Data Land: Every CPU cycle matters by vitalyd on Wednesday October 28, 2015 @10:11PM (#10468792)
Memory indirection is the biggest issue indeed. However, I'd also add that java has a terrible performance model, as a language. Unless you stick to primitives only, the abstraction costs start to add up (beyond pointer chasing). It shoves the entire optimization burden onto the JVM which by the time it runs has lost a bunch of semantic and type information in some cases. There are also codegen deficiencies in current hotspot C2 compiler (i.e. generated code subpar compared to roughly equivalent gcc).
[ Parent | on HN ]
Re:Performance in Big Data Land: Every CPU cycle matters by abc_lisper on Thursday October 29, 2015 @01:01AM (#10469377)
> In C++, it's common for contained structs to be flat in memory, so accessing a data member in them is just an offset from a base address

JVM inlines virtual method calls as one of its optimizations. See: http://www.oracle.com/technetwork/java/whitepaper-135217.htm...

[ Parent | on HN ]
Re:Performance in Big Data Land: Every CPU cycle matters by dsharlet on Thursday October 29, 2015 @01:59AM (#10469517)
How is that related to the parent's point?
[ Parent | on HN ]