[concurrency-interest] Any support to determine the number of processors ?
Wed, 23 Jul 2003 10:16:21 -0400
Thanks to Rob Eden for the tip about using the 1.4.1 Runtime.getAvailableProcessors() that I had never noticed.
Once tested on my single CPU XEON 2.4 Ghz I obtain 2 processors, so this returns on NT 2003 the number of LOGICAL processors (not tested with other OS).
For info, multithreading can be disabled in the motherboard setup, at least on my Dell PowerEdge1600SC MB.
Obtaining the number of physical processors would be useful but the number of logical processors is more interesting from my current point of view
I totally agree with Brian, that setting pool sizes... Is a important deployment time decision with many factors to take into consideration but for a quick setup we can try to provide safe default values which can be overriden by the admin at a later time.
Merci ... Thanks
>Architecture and Internet Solutions (AIS)/Solutions Internet et Architecture.
>HRDC/DRHC, 18A, 333 River Road, Vanier, Ontario K1A 0L1
Ph. (613) 946.7749 firstname.lastname@example.org
From: Brian Goetz [mailto:email@example.com]
Sent: 2003-07-22 8:39 PM
To: Dupuy, Olivier [NC]
Subject: Re: [concurrency-interest] Any support to determine the number of processors ?
> When working with a pool of threads, you can decide to optimize
> its size according to the number of processors of your computer and to
> the tasks realized. This way you should be able to optimize the
> processing and you would avoid involving the user in configurating some
> resource file while default values can apply automatically. I was
> searching in the JSR 166 for a method giving access to number of logical
> and physical processors. On some recent Intel processors, like PIV or
> Xeon, the hyperthreading technology let's you execute up to 2 threads
> I don't know about SPARC processors or other models.
This is a more complicated issue than it might immediately
appear. Clearly, number of available processors is one of the important
inputs in determining a sensible thread pool size. On the other hand, the
choice of size of thread pools really is a _deployment_ time decision, not
a development time decision. In most enterprise applications, the
application deployer will have more information available with which to
make a sensible decision (specific hardware information, other applications
running on the same server, administrative policies, etc) than will the
developer. So having the developer "auto-size" these pools may encourage
making these formulas hard-coded within applications, instead of exposing
them and letting the application deployer make those decisions.
Facilities like Xeon HT further complicate the question -- is a Xeon HT one
processor, or two? It depends on the question that you're really trying to
answer, and I'm sure you could pose questions that support either answer as
the "right, obvious, most sensible" answer.
firstname.lastname@example.org Tel: 650-843-1300 Fax: 650-324-8032