Re: Does Ada tasking profit from multi-core cpus?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 05 Mar 2007 23:33:31 -0600, tmoran@acm.org wrote:

>> 1. Whether protected object's functions are indeed executed concurrently
>> when come from the tasks running on different cores?
> 
>    A quick test with a single protected object containing a single,
> long-duration, function appears to have just one call of the function
> active at a time, even if the function is called from two different tasks.
> 
>   global_flag : integer := 0;
> 
>   protected body pt is
>     function f(id : integer) return natural is
>       change_count : natural := 0;
>     begin
>       global_flag := id;
>       for i in 1 .. 10_000_000 loop
>         if global_flag /= id then
>           change_count := change_count;
>           global_flag := id;
>         end if;
>       end loop;
>       return change_count;
>     end f;
>   end pt;
> 
> One task calls pt.f(id=>1) and the other calls pt.f(id=>2).  They both get
> a result of zero back from their function call.  This was with Gnat 3.15p
> Windows 2000 on a dual core Pentium.  If I change it from a single
> protected object to two instances of a protected type, then the function
> calls are overlapped and return non-zero results.

Not very promising, sigh. Probably GNAT uses a critical section for all
protected actions, so the result.

>> 3. Can a task switch cores? If yes, what is the overhead of switching?

>   By "switch cores" do you mean that the particular hardware stack
> pointers swap which stack they are pointing to?  I think this is an OS
> question

That depends on the mapping of Ada's schedulable units to the OS ones. But
it is Ada question too. Because the processor affinity of a task is not
specified, the scheduler should be able to switch it from processor to
processor to achieve an optimal performance. Otherwise multi-core would
make no sense for Ada. AFAIK, Windows indeed switches thread's processors,
so GNAT 3.15p should follow it as well (provided, tasks are mapped on
threads and no thread affinity mask is set). Interesting would be to know
the penalty of such switching.

> and, for Windows, I don't know how one asks "which core am
> I currently running on" - or indeed if that questions makes any sense.

I suppose it should be NtGetCurrentProcessorNumber under Windows.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de