Hacker News Reader

Comment by yelnatz | Hacker News Reader

Can you clarify what you mean by that?

Article said they got 2.2x improvement using their parallel method compared to STL. Trade off was having 100% CPU utilization vs 12.5% with STL.

View on HN

That's not really a trade-off, if you're using the term with a negative connotation. Going from using 100% of one core to 100% of eight (well, 4, but hyperthreading) would normally be considered an advantage.

I'm probably wrong, but wouldn't it be a decrease in overall productivity? 2.2x increase in speed (higher the better) but ~7x increase in load (lower the better) for the same workload.

Or let x be time we need to complete the task:

12.5 * x first (load over time) is less than second 100 * x / 2.2 for the same x.

Or is this an inaccurate comparison?

Yeah, it depends. How much memory bandwidth do you use with each? Are the results useful incrementally? What else do you have to do on the machine? If this is the only task, and you don't care about power use, then using all resources for a quicker time is better. If you care about power use, or have other things running on the machine, then great. Being in place will of course matter with memory bandwidth and available RAM.

GPUs are way more parallel, and faster than this too. "clocks about 100x faster than calling std::stable_sort on an i7 Sandy Bridge" http://nvlabs.github.io/moderngpu/mergesort.html

> Can you clarify what you mean by that?

I'm saying their merge sort was likely not actually in-place.

Reply on news.ycombinator.com