Re: multicore-multithreading benchmarks

["Chip Orange" <Chip.Orange@psc.state.fl.us>]

<tmoran@acm.org> wrote in message 
news:itydnQzMmL9XTBHYnZ2dnUVZ_r-onZ2d@comcast.com...
> >We can note that with N= 10000, 8 CPUs are often slightly slower in
>>Nyberg's; Alexander's; and my measurements (below) than 7 so-called
>>"CPUs", though this is not nearly as dramatic as the erratic timings
>  The timings are short and thus highly subject to other things going on.
> Trysortn already does four runs and returns the average, but, especially
> when the "noise" is bursty, the result is still very erratic.  The N=1000
> case should probably be dropped since it's too fast for good timings, and
> too small for a multitasking advantage.  Even N=10_000 is pretty small.
> It would be interesting though to see the results for N=10**7 since that
> ought to show some cache contention under multi-tasking.
>  Thanks for posting the timings on your 4 core machine.  They seem
> broadly in agreement on the value of additional CPUs/cores.

Hi Tom,

I'm just beginning to learn Ada, but one of the attributes that drew me to 
it was the chance to learn a new paradigm of programming: that is, dividing 
a programming goal into tasks that can be performed concurrently in order to 
achieve much higher efficiencies.

I appreciate TrySortn very much as a learning aid, but I'm wondering how a 
programmer should go about determining the number of cores dynamicly in 
order to make the best guess as to how many tasks to break his problem into? 
Is there a standard Ada library that would give some system info on the 
number of cores, and/or, perhaps some info on how heavily loaded the system 
is (perhaps if it's already heavily loaded you wouldn't necessarily want to 
try to set a task going to each core?).



Thanks for any suggestions.

Chip