Performance in Big Data Land: Every CPU cycle matters • Hacker News Board

Re: Performance in Big Data Land: Every CPU cycle matters

#11

Post by bbrazil » Wed, Oct 28, 2015, 11:40 PM UTC

sargun wrote: post #3

I might suggest a new definition for "Big Data" - Data, whose size is greater than fits in one machine's memory.

The definition I like is that it's when the size of the data becomes a significant challenge to solving your problem.

For example 1TB of data won't fit in memory, but if all you need to do is a sequential read in under a day then it's not a problem.

Re: Performance in Big Data Land: Every CPU cycle matters

#12

Post by dalke » Wed, Oct 28, 2015, 11:44 PM UTC

sargun wrote: post #3

I might suggest a new definition for "Big Data" - Data, whose size is greater than fits in one machine's memory.

100 billion records, 6TB max RAM for http://www8.hp.com/uk/en/products/proliant-servers/product-d... => 54 bytes per record.

BTW, some previous HN discussions along these lines:

"Don't use Hadoop - your data isn't that big " - https://www.chrisstucchio.com/blog/2013/hadoop_hatred.html and https://news.ycombinator.com/item?id=6398650

"Your data fits in RAM " - http://yourdatafitsinram.com/ - https://news.ycombinator.com/item?id=9581862

Re: Performance in Big Data Land: Every CPU cycle matters

#13

Post by leetNightshade » Wed, Oct 28, 2015, 11:50 PM UTC

andmarios wrote: post #9

Then why big data land is dominated by JVM-based frameworks?

You assume that JVM is slow, yes? That's not always the case. Interestingly, there's cases where JVM applications run just as fast as if not faster than native code. This blows my mind, as a C++ programmer myself.

http://codexpi.com/java-vs-cpp-performance-comparison-jit-co...

http://stackoverflow.com/questions/5641356/why-is-it-that-by...

http://beautynbits.blogspot.com/2013/01/performance-java-vs-...

Re: Performance in Big Data Land: Every CPU cycle matters

#14

Post by abc_lisper » Wed, Oct 28, 2015, 11:59 PM UTC

leetNightshade wrote: post #13

andmarios wrote: post #9

Then why big data land is dominated by JVM-based frameworks?

You assume that JVM is slow, yes? That's not always the case. Interestingly, there's cases where JVM applications run just as fast as if not faster than native code. This blows my mind, as a C++ programmer myself. http://codexpi.com/java-vs-cpp-performance-comparison-jit-co... http://stackoverflow.com/questions/5641356/why-is-it-that-by... http://beautynbits.blogspot.com/2013/01/performance-java-vs-...

Once compiled to native code, which it will be for big data because the same classes are reused over and over, I would assume it would be in same ball-park as C/C++ code.

Re: Performance in Big Data Land: Every CPU cycle matters

#15

Post by zmmmmm » Thu, Oct 29, 2015, 12:02 AM UTC

So this person says every CPU cycle matters and then immediately takes the single CPU cycle and multiplies it by billions, the scale of their data.

So no, it's not "every" CPU cycle, it's the ones that scale with the highest dimension of your data that matter. Which is the same old story we have always had, save your energy for optimising the parts that matter, because the ones that matter probably matter orders of magnitudes more than the ones that don't.

Re: Performance in Big Data Land: Every CPU cycle matters

#16

Post by nostrademons » Thu, Oct 29, 2015, 12:09 AM UTC

abc_lisper wrote: post #14

leetNightshade wrote: post #13

Earlier quoted context omitted.

You assume that JVM is slow, yes? That's not always the case. Interestingly, there's cases where JVM applications run just as fast as if not faster than native code. This blows my mind, as a C++ programmer myself. http://codexpi.com/java-vs-cpp-performance-comparison-jit-co... http://stackoverflow.com/questions/5641356/why-is-it-that-by... http://beautynbits.blogspot.com/2013/01/performance-java-vs-...

Once compiled to native code, which it will be for big data because the same classes are reused over and over, I would assume it would be in same ball-park as C/C++ code.

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.

Re: Performance in Big Data Land: Every CPU cycle matters

#17

Post by syed99 » Thu, Oct 29, 2015, 12:14 AM UTC

"Different data types will force Vertica to use a different number of CPU cycles to process a data point" At the end of the day that performance bump comes down to the data point itself, sometimes the decrease in that CPU cycle wouldn't be as significant as expected.

Would love to see if the performance bump is highly significant on a much larger and complex data set.

Re: Performance in Big Data Land: Every CPU cycle matters

#18

Post by [deleted] » Thu, Oct 29, 2015, 12:14 AM UTC

[deleted]

Re: Performance in Big Data Land: Every CPU cycle matters

#19

Post by corysama » Thu, Oct 29, 2015, 12:16 AM UTC

andmarios wrote: post #9

Then why big data land is dominated by JVM-based frameworks?

Because a couple decades ago Java convinced Enterprise Land that they can't hire millions of C++ jockeys and expect them to work effectively in huge projects that plan to evolve into the next decades' (aka: the present's) legacy mudball. Instead, they decided it would be easier to hire millions of Java jockeys and have them build enormous kiln-fired mudballs using the same architectural strategy as the Egyptian pyramids. They convinced academia to raise an entire generation of Java jockeys, hired them all right out of school, and set them immediately to piling up enormous mud bricks forever.

So, now they have a few million Java jockeys churning away and a few million person-decades of work put into their mud piles. When starting any new project, there isn't much question about how to build it: More Mud!

Re: Performance in Big Data Land: Every CPU cycle matters

#20

Post by jrbancel » Thu, Oct 29, 2015, 12:20 AM UTC

Is 100 Billion (order of a few TB) Big Data?

In my experience, CPU is rarely the big issue when dealing with a lot of data (I am talking about tens of PB per day). IO is the main problem and designing systems that move the least amount of data is the real challenge.