[concurrency-interest] Some interesting (confusing?) benchmark results
vitalyd at gmail.com
Tue Feb 12 16:24:21 EST 2013
For pure CPU bound work, I typically add 1 or maybe 2 more threads than #
of hardware threads; this is to account for hardware threads possibly
hitting a hard page fault and getting suspended. I don't see how having
any more than that threads benefits perf.
Sent from my phone
On Feb 12, 2013 4:21 PM, "√iktor Ҡlang" <viktor.klang at gmail.com> wrote:
> On Tue, Feb 12, 2013 at 8:28 PM, Kirk Pepperdine <kirk at kodewerk.com>wrote:
>> > Do you agree that thread pool sizing depends on type of work? (IO bound
>> vs CPU bound, bursty vs steady etc etc)
>> > Do you agree that a JVM Thread is not a unit of parallelism?
>> > Do you agree that having more JVM Threads than hardware threads is bad
>> for CPU-bound workloads?
>> No, even with CPU bound workloads I have found that the hardware/OS is
>> much better at managing many workloads across many threads than I am. So a
>> few more threads is ok, many more threads is bad fast.
> That's an interesting observation. Have any more data on that? (really
> As I said earlier, for CPU-bound workloads we've seen the best performance
> when only loading 60-70% of the cores (other threads exist on the machine
> of course).
> *Viktor Klang*
> *Director of Engineering*
> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
> Twitter: @viktorklang
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest