You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Attila Szegedi <sz...@freemail.hu> on 2001/10/15 14:04:40 UTC
Re: [Really Off Topic] Re: threading : 'context switching' : optimalconfiguration
Now that this thread is tagged as Really Off Topic, I guess I can let myself totally loose:
Here's an experimental throughput test attached. It creates a large (20 levels deep, full) binary tree containing ints, then starts threads that traverse the tree in random order and sum the values in nodes. This is pretty much a stripped-to-the-essence example of an app that accesses large graph of objects on heap.
Now, compare the results of running a single instance of
java ThroughputTest -t 2
and two instances of
java ThroughputTest -t 1
java ThroughputTest -t 1
simultaneously on your OS and VM of choice (on an SMP box, of course -- this is meaningless on a single-processor machine!). You can also fiddle with the -d (depth of the tree) and -r (frequency of throughput reports on System.out) options.
My tests on NT and Solaris showed that two processes with single thread are always a better choice:
- on NT 4.0, running a single-process-with-two-threads yields only 80% of the throughput compared to two-processes-with-a-single-thread.
- on Solaris 8, in a single-process-with-two-threads, one of the threads is essentially stalled, only the other seems to get CPU cycles. Running two single-threaded processes works nicely. This thread stall looks worrying to me.
- I have no SMP Linux box, so can not test on it. If anyone can provide me with output of running this test on Linux, I'd be grateful (Bojan?).
Attila.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <ve...@jakarta.apache.org>
Sent: 2001. október 15. 11:25
Subject: [Really Off Topic] Re: threading : 'context switching' : optimalconfiguration
We might as well rename this list :)
On 10/14/01 11:37 PM, "Nick Bauman" <ni...@cortexity.com> wrote:
>> On windows, it's certainly true that thread processor affinity is not
>> related to other threads in a given process. You can get threads of
>> the same process to each run on different processor. In fact, Windows
>> does it's best to do that for you. As I recall, the windows model is
>> fairly straightforward and simple, which might be one of the reasons
>> that NUMA is so hard for them.
>
> I've never heard of a process that runs multiple threads being allowed to
> migrate from one processor to another in any OS. If this is indeed the case
> then I learned something new today.
Quick thought 'experiment' to convince you :
Given a process with 2 calculation-intensive threads of execution, and those
two threads were constrained to the same processor, how would you achieve
*any* performance improvement on a multi-processor machine over a single
processor machine? If a thread couldn't be executed on another processor,
then your threads would serialize their execution on the same processor...
>
> In my hands-on experience, when a multi-threaded application is written for
> Solaris, and that Solaris machine has, say, 4 processors, the app actually
> starts 4 processes (you can see each them with `ps` and `mpstat`), each
> bound to one processor, to maximize scalability. I can say I have
> personally seen this with Sun IPlanet server on Solaris a year ago.
:)
Are you sure the application didn¹t do something more sophisticated than
just make 4 threads?
If you still have access to that box, we can write a quick test program to
prove that out...
>>
>> While I don't know for sure, I would bet the same it true for solaris.
>>
>> In fact, the linux model of thread <-> process is considered a problem
>> by some due to the weight.
>
> Startup weight, yes. If you're using a Thread Manager and better yet, non-
> blocking IO threads (standard API in jdk 1.4), this weight is negated.
>
>> Attila's conjecture I believe is correct. And that's not because it's
>> my conjecture too (but it helps :) He expressed it very neatly.
>>
>> geir
>
> Okay if you say so. How can I prove it? With Java on Solaris, Native
> Threads, I see one Java process, all my threads run in there.
No, I don't think you should take my word for it. We should prove it
somehow. I haven't worked on Solaris lately to tell you how to do this. I
would bet that current processor affinity is hard to figure out in Java.
The model that would do it is to write a program that can start 1-N threads
that accesses a shared resource that takes some time. For example, protect
a Thread.sleep() in a synchronized method or block - say put one in a
singleton - and then have the threads call that, and then do a unit of work.
Say count upwards, printing out where you are modulo 10,000 or something.
On a dual processor box, with the process starting two threads, I would
expect you to mimic Attila's observed behavior as the threads would have to
wait for each other accessing the synchronized block. If you started
multiple programs each with 1 thread, you have no such problems. Each
thread has to wait for the sleep to expire, but only for themselves, and not
wait on the others...
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
Re: [Really Off Topic] Re: threading : 'context switching' : optimalconfiguration
Posted by Bojan Smojver <bo...@binarix.com>.
Quoting Attila Szegedi <sz...@freemail.hu>:
> Now that this thread is tagged as Really Off Topic, I guess I can let
> myself totally loose:
>
> Here's an experimental throughput test attached. It creates a large (20
> levels deep, full) binary tree containing ints, then starts threads that
> traverse the tree in random order and sum the values in nodes. This is
> pretty much a stripped-to-the-essence example of an app that accesses
> large graph of objects on heap.
>
> Now, compare the results of running a single instance of
>
> java ThroughputTest -t 2
>
> and two instances of
>
> java ThroughputTest -t 1
> java ThroughputTest -t 1
>
> simultaneously on your OS and VM of choice (on an SMP box, of course --
> this is meaningless on a single-processor machine!). You can also fiddle
> with the -d (depth of the tree) and -r (frequency of throughput reports
> on System.out) options.
>
> My tests on NT and Solaris showed that two processes with single thread
> are always a better choice:
>
> - on NT 4.0, running a single-process-with-two-threads yields only 80%
> of the throughput compared to two-processes-with-a-single-thread.
Actually, that's not all that bad. Given that there is heap contention and all.
The point is, there IS performance improvement when compared to a single thread
scenario. So, threading API does work with SMP!
> - on Solaris 8, in a single-process-with-two-threads, one of the threads
> is essentially stalled, only the other seems to get CPU cycles. Running
> two single-threaded processes works nicely. This thread stall looks
> worrying to me.
Have you tried that with the new one-to-one model? I think Solaris 8 runs
many-to-many be default (from those documents), so maybe your test falls into
the category of some of those 'bad performace scenario' cases.
> - I have no SMP Linux box, so can not test on it. If anyone can provide
> me with output of running this test on Linux, I'd be grateful
> (Bojan?).
No problem. If you donate a nice SMP box I promise to do all the tests you need.
I'm not greedy, a dual Athlon MP should do ;-)
Seriously, don't have any SMP Linux machines.
Bojan
Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Posted by Bojan Smojver <bo...@binarix.com>.
David Rees wrote:
>
> On Wed, Oct 17, 2001 at 11:35:55AM +1000, Bojan Smojver wrote:
> >
> > Since this is an interesting subject, I've checked IBM's latest list of
> > fixes
> > (http://www-106.ibm.com/developerworks/java/jdk/linux130/fixes130.html)
> > and the first on on the list is:
> >
> > |cx130-20000706|13323 | |N/A |Occasional hang on SMP
> >
> > Who knows, maybe they fixed it.
>
> I've been using IBM's JDK for a long time now (over a year now) on
> multi-processor Linux systems without any problems. The last time it
> crashed on me with long running processes is probably around Feb or March
> with an older revision of the JDK than above.
Thanks. This is good news.
Bojan
PS. The more I learn about IBM as a company these days, the more I
respect what they did: JDK, JFS, Linux S/390, Jikes, Xalan, Xerces,
SOAP...
Re: [Really Off Topic] Re: threading : 'context switching' : optimalconfiguration
Posted by David Rees <dr...@runt.ebetinc.com>.
On Wed, Oct 17, 2001 at 11:35:55AM +1000, Bojan Smojver wrote:
>
> Since this is an interesting subject, I've checked IBM's latest list of
> fixes
> (http://www-106.ibm.com/developerworks/java/jdk/linux130/fixes130.html)
> and the first on on the list is:
>
> |cx130-20000706|13323 | |N/A |Occasional hang on SMP
>
> Who knows, maybe they fixed it.
I've been using IBM's JDK for a long time now (over a year now) on
multi-processor Linux systems without any problems. The last time it
crashed on me with long running processes is probably around Feb or March
with an older revision of the JDK than above.
-Dave
Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Posted by Bojan Smojver <bo...@binarix.com>.
Bojan Smojver wrote:
>
> Dennis Doubleday wrote:
> >
> > At 07:34 AM 10/16/01, you wrote:
> >
> > >Would you have IBM's 1.3.0 handy. I know it flies compared to Sun's
> > >HotSpot on a single CPU box, but since I don't have any SMP's...
> >
> > Both Sun and IBM 1.3.0 JVMs for Linux used to crash when running multiple
> > threads on SMP. The bug was blamed on Linux glibc. I don't know if it ever
> > got fixed; apparently not, according to this from the Bug Parade.
> >
> > http://developer.java.sun.com/developer/bugParade/bugs/4343002.html
>
> It seems from the page that someone reported this on Solaris as well.
Since this is an interesting subject, I've checked IBM's latest list of
fixes
(http://www-106.ibm.com/developerworks/java/jdk/linux130/fixes130.html)
and the first on on the list is:
|cx130-20000706|13323 | |N/A |Occasional hang on SMP
Who knows, maybe they fixed it.
Bojan
Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Posted by Bojan Smojver <bo...@binarix.com>.
Dennis Doubleday wrote:
>
> At 07:34 AM 10/16/01, you wrote:
>
> >Would you have IBM's 1.3.0 handy. I know it flies compared to Sun's
> >HotSpot on a single CPU box, but since I don't have any SMP's...
>
> Both Sun and IBM 1.3.0 JVMs for Linux used to crash when running multiple
> threads on SMP. The bug was blamed on Linux glibc. I don't know if it ever
> got fixed; apparently not, according to this from the Bug Parade.
>
> http://developer.java.sun.com/developer/bugParade/bugs/4343002.html
It seems from the page that someone reported this on Solaris as well.
Anyway, I don't have any SMP's so far, but on single CPU machines, my
experience was better with Sun's JDK 1.3.0_04 and especially with IBM's
JDK 1.3.0, build cx130-2001062, which was not only much faster, but also
rock stable. 1.3.1 and 1.3.1_01 were crashing on my systems even after
the 'ulimit -s' and 'LD_ASSUME_KERNEL' workarounds (ie. I think the
cause was of a different nature, but Sun people didn't believe me).
However, my environment isn't really stock standard - I run a Rawhide
updated RedHat 7.0, glibc stands at 2.2.4-18. This has been absolutely
flawless (so far) with IBM's latest 1.3.0 JDK (which does use
LD_ASSUME_KERNEL workaround).
<semi-rant>
There are so many pieces of software on Linux that successfully use
glibc that I think JDK developers are trying to shift the blame to glibc
rather then fix their own bugs. This is not to say that glibc is perfect
- it's just that JDK people are probably more familiar with other
libraries.
</semi-rant>
Bojan
Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Posted by Dennis Doubleday <dd...@mail.yourfit.com>.
At 07:34 AM 10/16/01, you wrote:
>Would you have IBM's 1.3.0 handy. I know it flies compared to Sun's
>HotSpot on a single CPU box, but since I don't have any SMP's...
Both Sun and IBM 1.3.0 JVMs for Linux used to crash when running multiple
threads on SMP. The bug was blamed on Linux glibc. I don't know if it ever
got fixed; apparently not, according to this from the Bug Parade.
http://developer.java.sun.com/developer/bugParade/bugs/4343002.html
-------------------------------------------------------------
Dennis Doubleday email: dday@yourfit.com
yourfit.com, Inc. web: http://www.yourfit.com/
Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Posted by Bojan Smojver <bo...@binarix.com>.
David Kinnvall wrote:
>
> Ok. Bojan, Attila, others:
>
> Corresponding results with IBM's 1.3.0 on the same
> machine (Dell PowerEdge with dual P3 1GHz and 1GB
> memory):
>
> # java -version
> java version "1.3.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
> Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT
> enabled: jitc))
>
> One process with two threads:
>
> # java ThroughputTest -t 2
> java.vm.name = Classic VM
> java.vm.version = 1.3.0
> java.runtime.version = 1.3.0
> Thread-0: 3.2743943 pass/sec
> Thread-1: 3.2594523 pass/sec
> Thread-0: 3.27654 pass/sec
> Thread-1: 3.27654 pass/sec
> Thread-0: 3.2851512 pass/sec
> Thread-1: 3.2594523 pass/sec
> Thread-0: 3.2722514 pass/sec
> Thread-1: 3.2722514 pass/sec
> Thread-0: 3.2819166 pass/sec
> Thread-1: 3.2754667 pass/sec
>
> Two processes with one thread each:
>
> shell window number one
>
> # java ThroughputTest -t 1
> java.vm.name = Classic VM
> java.vm.version = 1.3.0
> java.runtime.version = 1.3.0
> Thread-0: 3.2819166 pass/sec
> Thread-0: 3.27654 pass/sec
> Thread-0: 3.2786887 pass/sec
> Thread-0: 3.2808397 pass/sec
> Thread-0: 3.2711809 pass/sec
>
> and number two
>
> # java ThroughputTest -t 1
> java.vm.name = Classic VM
> java.vm.version = 1.3.0
> java.runtime.version = 1.3.0
> Thread-0: 3.282994 pass/sec
> Thread-0: 3.27654 pass/sec
> Thread-0: 3.2722514 pass/sec
> Thread-0: 3.2840722 pass/sec
> Thread-0: 3.2754667 pass/sec
>
> Conclusions? Well, at least these:
> - VM:s with native threads under Linux scale well on SMP.
> - IBM' 1.3.0 VM is faster than Sun's 1.3.1, by approx 28%.
> - ...?
First off, big thanks for the effort!!!
As for the results, they speak for themselves.
I think Linux is giving 'commercial' OS-es something to think about. And
it is obvious that IBM didn't invest only PR effort but also the coding
effort into it. According to the Volano report
(http://www.volano.com/report/index.html), IBM's JDK for Linux beats its
equivalent for Windows in performance, although has problems with
network scaling.
Bojan
Re: [Really Off Topic] Re: threading : 'context switching' : optimalconfiguration
Posted by David Kinnvall <da...@alertir.com>.
Ok. Bojan, Attila, others:
Corresponding results with IBM's 1.3.0 on the same
machine (Dell PowerEdge with dual P3 1GHz and 1GB
memory):
# java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT
enabled: jitc))
One process with two threads:
# java ThroughputTest -t 2
java.vm.name = Classic VM
java.vm.version = 1.3.0
java.runtime.version = 1.3.0
Thread-0: 3.2743943 pass/sec
Thread-1: 3.2594523 pass/sec
Thread-0: 3.27654 pass/sec
Thread-1: 3.27654 pass/sec
Thread-0: 3.2851512 pass/sec
Thread-1: 3.2594523 pass/sec
Thread-0: 3.2722514 pass/sec
Thread-1: 3.2722514 pass/sec
Thread-0: 3.2819166 pass/sec
Thread-1: 3.2754667 pass/sec
Two processes with one thread each:
shell window number one
# java ThroughputTest -t 1
java.vm.name = Classic VM
java.vm.version = 1.3.0
java.runtime.version = 1.3.0
Thread-0: 3.2819166 pass/sec
Thread-0: 3.27654 pass/sec
Thread-0: 3.2786887 pass/sec
Thread-0: 3.2808397 pass/sec
Thread-0: 3.2711809 pass/sec
and number two
# java ThroughputTest -t 1
java.vm.name = Classic VM
java.vm.version = 1.3.0
java.runtime.version = 1.3.0
Thread-0: 3.282994 pass/sec
Thread-0: 3.27654 pass/sec
Thread-0: 3.2722514 pass/sec
Thread-0: 3.2840722 pass/sec
Thread-0: 3.2754667 pass/sec
Conclusions? Well, at least these:
- VM:s with native threads under Linux scale well on SMP.
- IBM' 1.3.0 VM is faster than Sun's 1.3.1, by approx 28%.
- ...?
Regards,
David
----- Original Message -----
From: "Bojan Smojver" <bo...@binarix.com>
To: <ve...@jakarta.apache.org>
Sent: Tuesday, October 16, 2001 1:34 PM
Subject: Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
> David Kinnvall wrote:
> >
> > Attila,
> >
> > Linux SMP results for a dual-CPU Dell PowerEdge 2550
> > with 1GB RAM and two 1GHz P3 CPU:s running RedHat 7.1
> > on the 2.4.3-12smp kernel as follows:
[snip]
> > This is with the Sun JDK using native threads.
> > Looks pretty decent to me, I must say. Attila?
>
> He, he, not bad for a $0 OS!!! Go Linux!!!
>
> Would you have IBM's 1.3.0 handy. I know it flies compared to Sun's
> HotSpot on a single CPU box, but since I don't have any SMP's...
>
> Bojan
Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Posted by Bojan Smojver <bo...@binarix.com>.
David Kinnvall wrote:
>
> Attila,
>
> Linux SMP results for a dual-CPU Dell PowerEdge 2550
> with 1GB RAM and two 1GHz P3 CPU:s running RedHat 7.1
> on the 2.4.3-12smp kernel as follows:
>
> Case 1, single process, dual threads:
> <begin>
> # java ThroughputTest -t 2
> java.vm.name = Java HotSpot(TM) Client VM
> java.vm.version = 1.3.1-b24
> java.runtime.version = 1.3.1-b24
> Thread-1: 2.4283633 pass/sec
> Thread-0: 2.4108005 pass/sec
> Thread-1: 2.4366472 pass/sec
> Thread-0: 2.4366472 pass/sec
> Thread-1: 2.4473813 pass/sec
> Thread-0: 2.4248302 pass/sec
> Thread-1: 2.4473813 pass/sec
> Thread-0: 2.4455855 pass/sec
> Thread-1: 2.4360535 pass/sec
> Thread-0: 2.4366472 pass/sec
> Thread-1: 2.4213073 pass/sec
> Thread-0: 2.442599 pass/sec
> </end>
>
> Case 2, dual processes in separate shell sessions, single thread:
> <begin>
> # java ThroughputTest -t 1
> java.vm.name = Java HotSpot(TM) Client VM
> java.vm.version = 1.3.1-b24
> java.runtime.version = 1.3.1-b24
> Thread-0: 2.4408102 pass/sec
> Thread-0: 2.4390244 pass/sec
> Thread-0: 2.4437928 pass/sec
> Thread-0: 2.4503798 pass/sec
> Thread-0: 2.4473813 pass/sec
>
> running concurrently with this in a separate shell
>
> # java ThroughputTest -t 1
> java.vm.name = Java HotSpot(TM) Client VM
> java.vm.version = 1.3.1-b24
> java.runtime.version = 1.3.1-b24
> Thread-0: 2.4277737 pass/sec
> Thread-0: 2.437835 pass/sec
> Thread-0: 2.4348674 pass/sec
> Thread-0: 2.437835 pass/sec
> Thread-0: 2.4319067 pass/sec
> </end>
>
> This is with the Sun JDK using native threads.
> Looks pretty decent to me, I must say. Attila?
He, he, not bad for a $0 OS!!! Go Linux!!!
Would you have IBM's 1.3.0 handy. I know it flies compared to Sun's
HotSpot on a single CPU box, but since I don't have any SMP's...
Bojan
Re: [Really Off Topic] Re: threading : 'context switching' : optimalconfiguration
Posted by David Kinnvall <da...@alertir.com>.
Attila,
Linux SMP results for a dual-CPU Dell PowerEdge 2550
with 1GB RAM and two 1GHz P3 CPU:s running RedHat 7.1
on the 2.4.3-12smp kernel as follows:
Case 1, single process, dual threads:
<begin>
# java ThroughputTest -t 2
java.vm.name = Java HotSpot(TM) Client VM
java.vm.version = 1.3.1-b24
java.runtime.version = 1.3.1-b24
Thread-1: 2.4283633 pass/sec
Thread-0: 2.4108005 pass/sec
Thread-1: 2.4366472 pass/sec
Thread-0: 2.4366472 pass/sec
Thread-1: 2.4473813 pass/sec
Thread-0: 2.4248302 pass/sec
Thread-1: 2.4473813 pass/sec
Thread-0: 2.4455855 pass/sec
Thread-1: 2.4360535 pass/sec
Thread-0: 2.4366472 pass/sec
Thread-1: 2.4213073 pass/sec
Thread-0: 2.442599 pass/sec
</end>
Case 2, dual processes in separate shell sessions, single thread:
<begin>
# java ThroughputTest -t 1
java.vm.name = Java HotSpot(TM) Client VM
java.vm.version = 1.3.1-b24
java.runtime.version = 1.3.1-b24
Thread-0: 2.4408102 pass/sec
Thread-0: 2.4390244 pass/sec
Thread-0: 2.4437928 pass/sec
Thread-0: 2.4503798 pass/sec
Thread-0: 2.4473813 pass/sec
running concurrently with this in a separate shell
# java ThroughputTest -t 1
java.vm.name = Java HotSpot(TM) Client VM
java.vm.version = 1.3.1-b24
java.runtime.version = 1.3.1-b24
Thread-0: 2.4277737 pass/sec
Thread-0: 2.437835 pass/sec
Thread-0: 2.4348674 pass/sec
Thread-0: 2.437835 pass/sec
Thread-0: 2.4319067 pass/sec
</end>
This is with the Sun JDK using native threads.
Looks pretty decent to me, I must say. Attila?
Regards,
David
----- Original Message -----
From: "Attila Szegedi" <sz...@freemail.hu>
To: <ve...@jakarta.apache.org>
Sent: Monday, October 15, 2001 2:04 PM
Subject: Re: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
Now that this thread is tagged as Really Off Topic, I guess I can let
myself totally loose:
Here's an experimental throughput test attached. It creates a large (20
levels deep, full) binary tree containing ints, then starts threads that
traverse the tree in random order and sum the values in nodes. This is
pretty much a stripped-to-the-essence example of an app that accesses
large graph of objects on heap.
Now, compare the results of running a single instance of
java ThroughputTest -t 2
and two instances of
java ThroughputTest -t 1
java ThroughputTest -t 1
simultaneously on your OS and VM of choice (on an SMP box, of course --
this is meaningless on a single-processor machine!). You can also fiddle
with the -d (depth of the tree) and -r (frequency of throughput reports
on System.out) options.
My tests on NT and Solaris showed that two processes with single thread
are always a better choice:
- on NT 4.0, running a single-process-with-two-threads yields only 80%
of the throughput compared to two-processes-with-a-single-thread.
- on Solaris 8, in a single-process-with-two-threads, one of the threads
is essentially stalled, only the other seems to get CPU cycles. Running
two single-threaded processes works nicely. This thread stall looks
worrying to me.
- I have no SMP Linux box, so can not test on it. If anyone can provide
me with output of running this test on Linux, I'd be grateful (Bojan?).
Attila.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <ve...@jakarta.apache.org>
Sent: 2001. október 15. 11:25
Subject: [Really Off Topic] Re: threading : 'context switching' :
optimalconfiguration
We might as well rename this list :)
On 10/14/01 11:37 PM, "Nick Bauman" <ni...@cortexity.com> wrote:
>> On windows, it's certainly true that thread processor affinity is not
>> related to other threads in a given process. You can get threads of
>> the same process to each run on different processor. In fact,
Windows
>> does it's best to do that for you. As I recall, the windows model is
>> fairly straightforward and simple, which might be one of the reasons
>> that NUMA is so hard for them.
>
> I've never heard of a process that runs multiple threads being allowed
to
> migrate from one processor to another in any OS. If this is indeed the
case
> then I learned something new today.
Quick thought 'experiment' to convince you :
Given a process with 2 calculation-intensive threads of execution, and
those
two threads were constrained to the same processor, how would you
achieve
*any* performance improvement on a multi-processor machine over a single
processor machine? If a thread couldn't be executed on another
processor,
then your threads would serialize their execution on the same
processor...
>
> In my hands-on experience, when a multi-threaded application is
written for
> Solaris, and that Solaris machine has, say, 4 processors, the app
actually
> starts 4 processes (you can see each them with `ps` and `mpstat`),
each
> bound to one processor, to maximize scalability. I can say I have
> personally seen this with Sun IPlanet server on Solaris a year ago.
:)
Are you sure the application didn¹t do something more sophisticated than
just make 4 threads?
If you still have access to that box, we can write a quick test program
to
prove that out...
>>
>> While I don't know for sure, I would bet the same it true for
solaris.
>>
>> In fact, the linux model of thread <-> process is considered a
problem
>> by some due to the weight.
>
> Startup weight, yes. If you're using a Thread Manager and better yet,
non-
> blocking IO threads (standard API in jdk 1.4), this weight is negated.
>
>> Attila's conjecture I believe is correct. And that's not because
it's
>> my conjecture too (but it helps :) He expressed it very neatly.
>>
>> geir
>
> Okay if you say so. How can I prove it? With Java on Solaris, Native
> Threads, I see one Java process, all my threads run in there.
No, I don't think you should take my word for it. We should prove it
somehow. I haven't worked on Solaris lately to tell you how to do this.
I
would bet that current processor affinity is hard to figure out in Java.
The model that would do it is to write a program that can start 1-N
threads
that accesses a shared resource that takes some time. For example,
protect
a Thread.sleep() in a synchronized method or block - say put one in a
singleton - and then have the threads call that, and then do a unit of
work.
Say count upwards, printing out where you are modulo 10,000 or
something.
On a dual processor box, with the process starting two threads, I would
expect you to mimic Attila's observed behavior as the threads would have
to
wait for each other accessing the synchronized block. If you started
multiple programs each with 1 thread, you have no such problems. Each
thread has to wait for the sleep to expire, but only for themselves, and
not
wait on the others...
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing
the
freeness of speech." - Benjamin Franklin