[Openmcl-devel] 0.13.x vs. 0.14.x

[Gary Byers]

On Sun, 4 Jan 2004, Sven Van Caekenberghe wrote:

> On 04 Jan 2004, at 21:28, Raffael Cavallaro wrote:
>
> > On Jan 4, 2004, at 3:06 PM, Sven Van Caekenberghe wrote:
> >
> >> We have no dual processor hardware in our office to do testing, only
> >> the production machines in colocation. Has anybody used OpenMCL
> >> 0.14.x with its native multi threading on a dual processor mac ? Is
> >> there a remote possibility that a native multi threading openmcl
> >> executing a multi threading application monopolizes the machine ?
> >
> > If you send me some simple test code that you feel exercises the
> > native multi threading appropriately, I would be happy to test it for
> > you on a dual processor machine.
>
> Have a look at http://homepage.mac.com/svc/DW-Bench
> The idea is to use paserve to serve either a static or a dynamic page
> and then exercise the server using the apache benchmarking tool ab. You
> do not really need KPAX to set this test up. Pushing up the -n and -c
> parameters might tell you something about scaleability or how well the
> dual processor machine utilizes its resources.
>

If you can do so, it might be interesting to test both the cases where
ab and the lisp are running on the same host vs the case where they're
not (and of course additional network traffic may complicate matters
in the latter case.)

I tried this last spring (when I could stand the noise of having a
dual processor XServ on my desk ...) and was surprised to see 0.13
doing better than an early version of 0.14.  Some of this was locking
overhead that's since been reduced, but some of it has to do with OS
scheduling issues.

If 0.13 and ab are running on the same dual-processor machine (and not
much else is), it tends to be the case that 0.13 hogs one CPU and ab
hogs the other; 0.13 can busy-wait until a connection request arrives,
switch to another thread, process the request, and reenter its scheduler
without competing for CPU resources.  (In the single-processor case,
this time-limited busy-waiting tends to limit throughput.)

When connection request arrive in 0.14's case, a thread will wake up
and want to use a CPU.  Especially in cases where requests are
processed concurrently, there's a greater chance that ab will get
preempted (whenever more threads are ready to run than there are CPUs
to run them on.)  Obviously, ab can send fewer connection requests per
second if it's getting preempted regularly than when it's able to
more-or-less hog a CPU, and the rate at which connection requests
can be completed is limited by the rate at which they can be sent.

You probably don't want to optimize for the case where a webserver's
throughput depends on it not preempting another high-availability
process on the same host. 0.13 is less likely to preempt ab than 0.14
is; it's also unable to utilize a second processor to handle requests
concurrently.

(This all may seem obvious, but it took me a while to figure out what
was going on.)