[concurrency-interest] Benchmark to demonstrate improvement in thread management over the years.

Kirk Pepperdine kirk at kodewerk.com
Tue Aug 13 02:49:12 EDT 2013

On 2013-08-13, at 8:38 AM, James Roper <james.roper at typesafe.com> wrote:

> On Tue, Aug 13, 2013 at 2:59 PM, Unmesh Joshi <unmeshjoshi at gmail.com> wrote:
> Hi James,
> At what number of threads JVM or OS performance starts degrading? Or number of threads start becoming the main bottleneck in the system? 
> Really, you just need to do your own load testing specific to your own application, hardware and OS requirements.  The current Linux scheduler runs in O(log N),

Really? I thought it was using an O(N) heap sort. Anyways, IME, the bigger problem is that getting the thread scheduler scheduled so that you can get threads scheduled... (there might be a Dr. Seuss thing going on here).

> so technically, that means performance starts degrading at 2 threads, since every thread added increases the amount of time the scheduler takes.  But of course, that degradation is negligible compared to the amount of time your app spends waiting for IO.  So it all depends on your app, what it's doing, and what its requirements are.
> It's not just scheduling that gets impacted, another obvious one that I already I pointed out was memory consumption, so once the thread stacks have consumed all available RAM, then they won't just be the bottleneck, your application will slow to a crawl or even crash.

Slow is something due to something else. No more stack space leads to OOME Stack space exhausted. Is this what you mean?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130813/780e584e/attachment.html>

More information about the Concurrency-interest mailing list