Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #22311
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: nThreads |
| Date | 2013-02-14 22:19 +0100 |
| Message-ID | <ao52n7Fm6npU1@mid.individual.net> (permalink) |
| References | <e8f7a805-da38-4882-8037-2c964982abd1@googlegroups.com> <kfh9p5$ciq$1@dont-email.me> <1mv2pq2irp6wa$.1lqfljcyio53l$.dlg@40tude.net> |
On 14.02.2013 01:46, Joerg Meier wrote: > On Wed, 13 Feb 2013 16:06:37 -0800, markspace wrote: > >> However, 100 to 300 threads is trivial for most modern system. Since >> most tasks will be IO-bound, it make sense to have lots of threads so >> some can be running while others wait for data to be returned. (Sorry >> to contradict Mr. Meier but I'm pretty sure he's off base.) Given a > > Obviously, you can pretty much have Integer.MAX_VALUE threads if all of > them are waiting without negatively impacting your waiting performance - > that's not really a sensible way to look at that question ;) Obviously. > I said, and stand by, that context switching is not free and is the cost of > having too many threads. Nobody questioned that. > Threads that sleep or otherwise wait, such as for > IO, don't typically cause much context switching. Yes, but in a pool with a fixed upper limit of threads they consume a slot while sitting there doing nothing (and causing no CPU cost). In this case a core will be idle if you limit pool size to number of cores. If the application is doing IO (or anything else which might cause intermediate blocking) you are unnecessarily restricting throughput of the application if you take number of cores (or threads as they are called in some architectures) as limit. What the best limit is obviously depends on the nature of the application. > We once ran (by accident) something that triggered 100,000 threads (+ GC > and whatever) on a normal Linux server with a quad core CPU and it still > worked (although much slower than with the intended 100). As far as I know, > neither Linux nor the hardware was anything unusual. There you go. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
nThreads bob smith <bob@coolfone.comze.com> - 2013-02-13 15:25 -0800
Re: nThreads Joerg Meier <joergmmeier@arcor.de> - 2013-02-14 00:46 +0100
Re: nThreads Roedy Green <see_website@mindprod.com.invalid> - 2013-02-14 03:43 -0800
Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:56 -0500
Re: nThreads markspace <markspace@nospam.nospam> - 2013-02-13 16:06 -0800
Re: nThreads Joerg Meier <joergmmeier@arcor.de> - 2013-02-14 01:46 +0100
Re: nThreads Lew <lewbloch@gmail.com> - 2013-02-13 17:27 -0800
Re: nThreads Robert Klemme <shortcutter@googlemail.com> - 2013-02-14 22:19 +0100
Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:59 -0500
Re: nThreads Roedy Green <see_website@mindprod.com.invalid> - 2013-02-13 18:37 -0800
Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 09:01 -0500
Re: nThreads Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-14 07:07 -0400
Re: nThreads Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-14 09:55 -0800
Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:55 -0500
csiph-web