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

Stanimir Simeonoff stanimir at riflexo.com
Wed Feb 13 08:39:22 EST 2013


On Wed, Feb 13, 2013 at 3:32 PM, Vitaly Davidovich <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>
> 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
>>>> 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>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 listConcurrency-interest at cs.oswego.eduhttp://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
>>>>
>>>>
>>>
>>>
>>> --
>>> *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
>>>
>>>
>>
>> _______________________________________________
>> 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/ae02e407/attachment-0001.html>


More information about the Concurrency-interest mailing list