Protected Objects And Many Processors

Protected Objects And Many Processors

[Georg Bauhaus]

Suppose I have a computer that has P processors of C cores each.
A program to be run on this computer has two shared data objects
and a number N of tasks, plus one.  Each task is a member of one
group of tasks, and one group communicates via exactly one of
the shared data objects.  The additional task can synchronize
data between the two shared objects.


    T(1,1)                          T(2,1)
  T(1,2)                               T(2,2)
   ...       PO1  --- TPlus ---  PO2   ...
  T(1,N/2-1)                           T(2,N/2-1)
    T(1,N/2)                        T(2, N/2)

The presence of shared data almost always triggers the idea
of employing protected objects, since these avoid the overhead
of task switching.  But availability of computing hardware seems
to renders this a weaker argument.

Are protected objects still the best choice on a computer
that has many processors and/or cores?

Will the program run just as well when written with only task
objects if and when the number of available processors is
sufficient, that is, C > N?

Re: Protected Objects And Many Processors

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 19:09:34 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> The presence of shared data almost always triggers the idea
> of employing protected objects, since these avoid the overhead
> of task switching.  But availability of computing hardware seems
> to renders this a weaker argument.

Yes, The “Ada 95 Rationales” agree that efficiency is a key point:
http://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-p2-9.html#1
Just that there is also semantic, protected objects are not just  
efficient, they also Protects (so their name) against simultaneous access  
to some data, i.e. one reading while another writing or one writing while  
another is writing too.

If you feel there may be a better solution, we first should now what that  
other solution could be (you did not say). You still need a  
synchronization mechanism, aren't you ?

I feel I did not understood the argument about the hardware. Would you  
like to be more explicit ?

> Will the program run just as well when written with only task
> objects if and when the number of available processors is
> sufficient, that is, C > N?
What was your criteria to decide one task here and there ? Use of tasking  
is directed by what the program is running, and we do not know anything  
about it. Here as well, tell more if you would like to.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Protected Objects And Many Processors

[Dmitry A. Kazakov]

On Fri, 21 Jan 2011 20:31:49 +0100, Yannick Duch�ne (Hibou57) wrote:

> If you feel there may be a better solution, we first should now what that  
> other solution could be (you did not say).

Tasks marshaling parameters. There existed architectures in early 90s,
which used networked massively parallel processors rather than cores. I
mean transputers. Arguably, they came to early and targeted the high end
segment. Most likely they will return, now in the middle and low end of the
scale. Presumably, in a long term perspective, multi-cores will have no
chance to compete with such architectures. Consider 10**2, 10**3, 10**4
processors on one chip.

> You still need a synchronization mechanism, aren't you ?

That depends on the case.

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

Re: Protected Objects And Many Processors

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 21:35:47 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Tasks marshaling parameters. There existed architectures in early 90s,
> which used networked massively parallel processors rather than cores. I
> mean transputers. Arguably, they came to early and targeted the high end
> segment.
What a pity these architectures did not end to be more popular. Before the  
Pentium was released (I knew a bit about CPUs at that time), I expected  
there will drop this kind of architecture and go to multi-processor  
motherboard instead. But they did not, they increased the speed of one CPU  
only. I feel for long, parallelism is more important than clock speed (and  
you can add CPUs like you add memory).

I do not know enough about the architecture based on Core, I do not know  
the relevant differences between two cores and two CPUs, so I could not  
tell (I just guess something is shared, but what and with which  
implications… I do not know).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Protected Objects And Many Processors

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 21:35:47 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> I mean transputers.
As you talked about it, I just had a look at Wikipedia for details, and as  
a side note, I noticed something I enjoyed to read:

http://en.wikipedia.org/wiki/Transputer
> The TDS was itself a transputer application written in occam.
> The TDS text editor was notable in that *it was a folding editor,
> allowing blocks of code to be hidden and revealed, to make the
> structure of the code more apparent*.
Exactly what I am (wish) to talk about a later day :)
These Transputer must be amazing.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Protected Objects And Many Processors

[comp.lang.php]

On Jan 21, 10:32 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Fri, 21 Jan 2011 21:35:47 +0100, Dmitry A. Kazakov  
> <mail...@dmitry-kazakov.de> a écrit:> I mean transputers.
>
> As you talked about it, I just had a look at Wikipedia for details, and as  
> a side note, I noticed something I enjoyed to read:
>
> http://en.wikipedia.org/wiki/Transputer> The TDS was itself a transputer application written in occam.
> > The TDS text editor was notable in that *it was a folding editor,
> > allowing blocks of code to be hidden and revealed, to make the
> > structure of the code more apparent*.
>
> Exactly what I am (wish) to talk about a later day :)
> These Transputer must be amazing.
>
> --
> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
> les chiens.
>
> “I am fluent in ASCII” [Warren 2010]

Interesting, I had once a compiler for the transputer in Ada(83) from
Alsys.

Ken

Re: Protected Objects And Many Processors

[Dmitry A. Kazakov]

On Mon, 24 Jan 2011 03:29:19 -0800 (PST), comp.lang.php wrote:

> On Jan 21, 10:32 pm, Yannick Duchêne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
>> Le Fri, 21 Jan 2011 21:35:47 +0100, Dmitry A. Kazakov  
>> <mail...@dmitry-kazakov.de> a écrit:> I mean transputers.
>>
>> As you talked about it, I just had a look at Wikipedia for details, and as  
>> a side note, I noticed something I enjoyed to read:
>>
>> http://en.wikipedia.org/wiki/Transputer> The TDS was itself a transputer application written in occam.
>>> The TDS text editor was notable in that *it was a folding editor,
>>> allowing blocks of code to be hidden and revealed, to make the
>>> structure of the code more apparent*.
>>
>> Exactly what I am (wish) to talk about a later day :)
>> These Transputer must be amazing.
>>
>> --
>> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
>> les chiens.
>>
>> “I am fluent in ASCII” [Warren 2010]
> 
> Interesting, I had once a compiler for the transputer in Ada(83) from
> Alsys.

Was it for T800, native or cross? For the Parix OS? How did they mapped Ada
tasks? Did they use TP links?

Back in 90's I looked for an Ada compiler for T800, but found nothing.

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

Re: Protected Objects And Many Processors

[Jeffrey Carter]

On 01/21/2011 11:09 AM, Georg Bauhaus wrote:
>
> Are protected objects still the best choice on a computer
> that has many processors and/or cores?
>
> Will the program run just as well when written with only task
> objects if and when the number of available processors is
> sufficient, that is, C>  N?

I presume you refer to using tasks in place of the protected objects (perhaps 
what were called "passive tasks" back in the Ada-83 days).

There are 2 ways I can think of in which protected objects might be better than 
tasks when you have a processor for each task. Both relate to protected functions:

1. In theory, you can have multiple simultaneous calls to protected functions. 
I'm not sure there's any implementation that does this, but it is possible.

2. Protected functions can return indefinite types with actual values determined 
by the function; task entries are constrained to the size of objects provided by 
the caller.

Whether these are important considerations for a given application is a 
different matter.

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

Re: Protected Objects And Many Processors

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 20:55:22 +0100, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> 2. Protected functions can return indefinite types with actual values  
> determined by the function; task entries are constrained to the size of  
> objects provided by the caller.
Ah, I see. There is indeed nothing like a real function with tasks, and  
will not allocate on the caller's stack.
But there is still room to return a reference to some dynamically  
allocated memory, even indirectly, or no ? (I do not see anything which  
would prohibit this, although I did not try it)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Protected Objects And Many Processors

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.vpodylunule2fv@garhos...
Le Fri, 21 Jan 2011 20:55:22 +0100, Jeffrey Carter
<spam.jrcarter.not@spam.not.acm.org> a �crit:
>> 2. Protected functions can return indefinite types with actual values 
>> determined by the function; task entries are constrained to the size of 
>> objects provided by the caller.
>Ah, I see. There is indeed nothing like a real function with tasks, and 
>will not allocate on the caller's stack.
>But there is still room to return a reference to some dynamically 
>allocated memory, even indirectly, or no ? (I do not see anything which 
>would prohibit this, although I did not try it)

Right, but remember that the storage pool from which allocated memory comes 
is a global object that requires synchronization. So if you use that sort of 
solution, you have done nothing to solve the synchronization problem (you 
may have moved it to the storage pool, but it is still there).

                        Randy.

Re: Protected Objects And Many Processors

[Yannick Duchêne (Hibou57)]

Le Sat, 22 Jan 2011 06:16:53 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> Right, but remember that the storage pool from which allocated memory  
> comes
> is a global object that requires synchronization. So if you use that  
> sort of
> solution, you have done nothing to solve the synchronization problem (you
> may have moved it to the storage pool, but it is still there).
If the purpose a storage pool is this one exactly (and has not other use),  
then moving the problem to the storage pool, solves the problem. This may  
be an item to add to the thread about use case of Ada's storage pools.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Protected Objects And Many Processors

[Gene]

You mean using rendezvous instead of protected types?  With rendezvous you'd need a "server" task for each shared object to serialize operations on it. (You would not want to use the single connecting task shown in your diagram for this purpose because giving it different  jobs like this would decrease available parallelism.)  Even if there is no contention, every object access would require execution in two threads with this scheme. With protected types, only a single thread runs in the no-contention case.  

Queueing a thread on a lock and then restarting it would have to be free to erase the difference in cost. 

While it might be cheaper to queue and restart across cores and/or CPUs than to swap contexts in a single core, it will never be free, and the exact overhead will be extremely architecture dependent, including cache, OS (thread affinity policy especially), and RTL implementation.  You'd have to find out how bad the news is by studying documentation and finally by testing.  In most environments the protected type will still be considerably more efficient.  As its name implies, rendezvous is best for synchronizing execution control flow, passing at most one chunk of data between tasks at a time.