[concurrency-interest] Some interesting (confusing?) benchmark results

Vitaly Davidovich 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)
>> Yes
>> > Do you agree that a JVM Thread is not a unit of parallelism?
>> Yes
>> > 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
> interested)
> 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).
>
> Cheers,
>
>>
>
>>
>> Regards,
>> Kirk
>
>
>
>
> --
> *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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130212/829c6428/attachment.html>


More information about the Concurrency-interest mailing list