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

Vitaly Davidovich vitalyd at gmail.com
Wed Feb 13 08:32:25 EST 2013


/proc/cpuinfo parsing is the way to go but would be nice to have a "machine
spec/capability" API baked into the JDK.

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/de8623ac/attachment.html>


More information about the Concurrency-interest mailing list