[concurrency-interest] To Hyper-Thread or not

√iktor Ҡlang viktor.klang at gmail.com
Sun Dec 25 11:55:47 EST 2011

Definitely makes a lot of different for Akka's performance.


On Fri, Dec 23, 2011 at 11:20 PM, David Holmes <davidcholmes at aapt.net.au>wrote:

> **
> The hotspot JVM does no pinning/binding of any kind. The OS provides the
> illusion of an entity called a "processor", which appear to be equivalent
> to the JVM but in practice a thread is not a core is not a socket. The OS
> does all the scheduling and will generally use locality heuristics and
> prefer to run threads on the same entity they last ran on. But it varies.
> David
> -----Original Message-----
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of *Rahul Saksena
> *Sent:* Saturday, 24 December 2011 5:57 AM
> *To:* concurrency-interest at cs.oswego.edu
> *Subject:* [concurrency-interest] To Hyper-Thread or not
> Assuming we have 8 physical cores (intel xeon SMP) and the java process
> has more than 12 threads running  through out its life cycle (no shared
> variables),
> Would you enable hyperthreading and have 16 logical cores?
> Does enabling hyperthreading result in far less number of context switches
> in this case?
> Does the jvm recognize that these threads have no shared data/contention
> and pin/bind it to different cores?
> Thanks,
> Rahul.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111225/89b5e21c/attachment.html>

More information about the Concurrency-interest mailing list