Re: multicore-multithreading benchmarks

[Jeffrey Creem <jeff@thecreems.com>]

Chip Orange wrote:

> 
> Thank you for the reply, and for the Windows API call information.
> 
> It sounds like you're telling me, because you gave me the Windows API, that 
> there's no "standard" way in Ada to handle any of this?  Does this seem like 
> a lack in Ada to you as it does to me, or am I missing some bigger picture?
> 

You are not missing anything. There is nothing in native Ada that will 
give you the information that you are looking for (At least not in Ada 
83/95 - Since I have not really looked at much of the new tasking 
features of 2005 I can't say for certain that there is nothing there).

> With multicore/cpus being readily available, wouldn't you think any 
> programmer should be rewriting his applications to take advantage of this, 
> and so, would need this type of information to do so?  Or should we, as a 
> general rule, just break all programming tasks into threads, assuming that 
> the OS will handle load balancing better than we could?
> 

I think it sort of depends on what you are doing. When we talk about 
future multicore machines  you often hear people say that nothing will 
take advantage of more than 2 cores given the way todays software is 
written. That might be true in many cases. Certainly the work I do (for 
pay) will scale pretty well beyond 2 cores but it will hit a limit not 
long after. While the programs typically have a lot of tasks(when 
compared to the single core they are running on), many of them are 
sporadic low CPU usage tasks so they will not find a lot of use for more 
than a few CPUs.

It is not an easy problem even if the API information was available. It 
is not clear that every library call should be looking at CPUs and 
coming up with a # of threats to start for every low level operations 
(e.g. sort, matrix multiply, etc).

Having said that, building components with build in support for 
arbitrary numbers of tasks (when appropriate) does allow the person 
architecting the final program the flexibility to limit the non-portable 
calls to a small subset of the program and/or to simply make reasonable 
guesses when putting the program together.