Re: Tasking performance between Ada83 and Ada95

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Bob Duff said

<<Probably the problem is that GNAT uses the tasking (threads) of the
underlying OS, and what you're measuring is the poor performance of
those underlying systems.  Often, the issue is that you're doing system
calls to lock things and so forth -- and system calls take a l-o-o-o-n-g
time.  I don't think it's all that hard to make it fast -- change the
RTS to do all its own task dispatching and whatnot, and never never do a
system call in time-critical operations.  But then you lose something:
you have to jump through hoops to do asynchronous I/O, for example.
Also, the O/S doesn't know about your tasks, so it won't know how to
schedule your tasks in relation to tasks (threads) in other unrelated
programs.  If a page fault happens, and you're not using OS threads,
your whole program will wait for disk I/O.  A real-time program might
not care about these things, however.>>


That's my guess too. I very much doubt that the Alsys World compiler on HPUX
used system level threads, and I also guess that the
version of GNAT on HPUX is probably using DCE threads.
So the comparison is completely meaningless.

What we are doing with several of the new distributions of GNAT is to provide
a mechanism for selecting system level threads or our own thread package.
The system level threads give full system concurrency and allow true
multi-processing on an MP, but tend to be a lot slower, and also often
less accurate with respect to Annex D requirements. Our own threads package
(typically FSU threads), does not give full system concurrency, but is often
much more efficient, and also more accurate with respect to Annex D
requirements. This gives the best of both worlds, leaving the choice
up to the user.

Robert Dewar
Ada Core Technologies