3 ms·
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 utiliz
by yelnatz 12y ago
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.
- rikkus 12y agoThat'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.
- gear54rus 12y agoI'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?
- deleted 12y ago[deleted]
- illumen 12y agoYeah, 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 http://nvlabs.github.io/moderngpu/mergesort.html
- wfunction 12y ago> Can you clarify what you mean by that? I'm saying their merge sort was likely not actually in-place.