Re: multicore-multithreading benchmarks

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

<tmoran@acm.org> wrote in message 
news:TOCdnecag8P5qA_YnZ2dnUVZ_qunnZ2d@comcast.com...
> >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?).
>  The Windows API call GetProcessAffinityMap tells how many CPUs/cores are
> available.  In this (sorting) case, one could give a lower priority to one
> of the tasks, so if multiple cores are available, you would have
> multitasking, while if only one core wasn't busy, it would run the tasks
> sequentially - essentially the same as if they weren't multitasked.
>  The programmer of a library routine would ideally like to be able to ask
> "what's the current cost of CPU cycles, RAM, and cache space" and then
> decide how much multitasking to do, or dynamically how to make
> compute/memory tradeoffs, and he'd like to write his routines to change
> behavior when the relative costs/scarcities change.  Pending that
> desirable situation, I just throw up my hands, include a CPUs_To_Use
> parameter to the sort routine, and let someone who knows more about the
> particular application and its likely environment make that decision.

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?

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?

Thanks.

Chip