Re: multicore-multithreading benchmarks

[tmoran@acm.org]

>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.