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

Nathan Reynolds nathan.reynolds at oracle.com
Wed Feb 13 09:41:54 EST 2013


If we ever get around to adding ProcessorLocal and its implied processor 
id and core-distance computing method, then we should probably consider 
adding APIs which describe the system upon which the JVM is running.  
This should include the number of hardware threads and which physical 
cores they belong to, the number of physical cores and which processor 
socket they belong to and the number of processor sockets.  This model 
comes from a Intel MP system point of view. There are probably other 
machine configurations which need to be accounted for in the API.  After 
this is specified, then affinity masks make sense.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/13/2013 6:47 AM, Vitaly Davidovich wrote:
>
> If you're using an affinity mask, sure.  The advantage of having this 
> in jdk is cross platform support and not having people write the same 
> code across their apps.
>
> Sent from my phone
>
> On Feb 13, 2013 8:39 AM, "Stanimir Simeonoff" <stanimir at riflexo.com 
> <mailto:stanimir at riflexo.com>> wrote:
>
>
>
>     On Wed, Feb 13, 2013 at 3:32 PM, Vitaly Davidovich
>     <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>
>         /proc/cpuinfo parsing is the way to go but would be nice to
>         have a "machine spec/capability" API baked into the JDK.
>
>     But you still to get info on which CPU the process is limited to,
>     i.e. affinity. Which is the harder task. OTOH, /proc/cpuinfo is
>     quite trivial to parse.
>
>     Stanimir
>
>         Sent from my phone
>
>         On Feb 13, 2013 5:49 AM, "Stanimir Simeonoff"
>         <stanimir at riflexo.com <mailto:stanimir at riflexo.com>> wrote:
>
>
>                 Is there a way to know how many physical processors
>                 are available on the JVM?
>
>             On linux you can use taskset -p <pid>
>             (pid you can retrieve form /proc/self )
>             and you can use /proc/cpuinfo to determine which
>             processors have siblings.
>
>             Quite inconvenient overall. So kernels might have
>             /proc/self/affinity which would make life easier .
>             And of course there is JNI and syscall.
>
>             Stanimir
>
>
>                 Cheers,
>                 ?
>
>
>
>                     Nathan Reynolds
>                     <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>
>                     | Architect | 602.333.9091 <tel:602.333.9091>
>                     Oracle PSR Engineering <http://psr.us.oracle.com/>
>                     | Server Technology
>                     On 2/12/2013 2:18 PM, ?iktor ?lang wrote:
>>
>>
>>
>>                     On Tue, Feb 12, 2013 at 8:28 PM, Kirk Pepperdine
>>                     <kirk at kodewerk.com <mailto: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  <mailto:Concurrency-interest at cs.oswego.edu>
>>                     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>                     _______________________________________________
>                     Concurrency-interest mailing list
>                     Concurrency-interest at cs.oswego.edu
>                     <mailto:Concurrency-interest at cs.oswego.edu>
>                     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
>                 -- 
>                 *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
>                 <mailto:Concurrency-interest at cs.oswego.edu>
>                 http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>             _______________________________________________
>             Concurrency-interest mailing list
>             Concurrency-interest at cs.oswego.edu
>             <mailto:Concurrency-interest at cs.oswego.edu>
>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> _______________________________________________
> 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/20130213/f6bf2fbb/attachment-0001.html>


More information about the Concurrency-interest mailing list