xs0 <xs0@xs0.com> wrote:

[...]
> AFAIK, multi-core processors are almost exactly the same as having multiple cpus, except they're in a single box and share a single bus to the outside world.

Thanks for your opinions, I have read them carefully several times.

There is one fundamental difference between dual-cores and dual- cpus: dual-cores can exchange data over the internal bus and do not need any bandwidth on the bus to the "outside world".

I.e. if you have a multi dual-core machine and knows that two threads have to communicate intensively you loose performance if you cannot control to have both threads running on a single dual- core die.


> So, I'd say that there's
> nothing much that can be done beyond what is already done (which
> is basically multi-threading support and synchronization
> objects).
[...]

I do not find the hook in your arguments to the explanation why control of the two points of execution (which are implied by a dual core machine) is not necessary.

In the example of the throw statement you even explicitely say, that you are not interested in guiding the machine, instead the machine is allowed to do what ever _randomly_ occurs first

To explain why this might be wrong imagine security rules for a
train:
- if the pressing of the alive-knob for the driver times out then
stop the train as if you are joining in to a sattion
- if fire alarm is issued then bring the train to a stop as fast as
possible except you are in a tunnel, then delay the stopping of the
train until you have left the tunnel

Now what will your machine do if fire alarm is issued in a tunnel and the pressing of the alive-knob is timing out also?

-manfred

Sean Kelly <sean@f4.ca> wrote:

> I need to read up a bit on multi-core systems, but they act the same as SMP systems, correct?

Dual-cores _are_ an implementation of SMP.

> So your concern is having library
> facilities which allow you to assign tasks to different
> processors and so on?

No. I have somewhere seen an argument, that if concurrency is not implemented into the language then no compiler can be guaranteed to deliver correct code under all circumstances---therefore concurrency must be implemented into the language.

-manfred

Manfred Nowak wrote:
> Thanks for your opinions, I have read them carefully several times.
> 
> There is one fundamental difference between dual-cores and dual-
> cpus: dual-cores can exchange data over the internal bus and do not need any bandwidth on the bus to the "outside world".
> 
> I.e. if you have a multi dual-core machine and knows that two threads have to communicate intensively you loose performance if you cannot control to have both threads running on a single dual-
> core die.

I don't know what can or can't be done over the internal bus, but as far as thread control is concerned, it's not something that can be done by user apps, no matter what you do to the language they were coded in, because it's in the OS domain. If/when OS supports it, the functionality is available through an OS library, so, everything that D needs for multi-core CPU support is already there (access to OS :)

Again, I think it'd be better to focus on providing constructs that allow optimization in general. When/if it is feasible to optimize them by utilizing multi-core cpus in the way you'd want, the only thing that needs to be done is improve the compiler. In the meantime, they can be optimized for other cases, like by making use of MMX/SSE instructions, which I think are totally underutilized generally, and which could easily provide comparable gains in speed.

Well, writing all this, I think I'm not sure what are you actually proposing to be done. You seem to want some sort of multi-core support, but what would that be? Can you give an example or two?


>>So, I'd say that there's
>>nothing much that can be done beyond what is already done (which
>>is basically multi-threading support and synchronization
>>objects). 
> 
> [...]
> 
> I do not find the hook in your arguments to the explanation why control of the two points of execution (which are implied by a dual core machine) is not necessary.

I'm not saying it's not necessary, I'm just saying it's not something that can be done in the language itself.


> In the example of the throw statement you even explicitely say, that you are not interested in guiding the machine, instead the machine is allowed to do what ever _randomly_ occurs first

In a general-purpose OS, everything is basically random - at any time, the OS can switch to another task. In a real-time OS, things are different (although, admittedly, I don't know how much), but I guess most software we're writing won't be running on such an OS.

Even regardless of all this - considering the two simultaneous exceptions case: if they can occur simultaneously, it's almost certain that they can also occur within, say, 1 microsecond. If that is so, you must handle both cases of which occurs first anyway; when that is done, it doesn't matter anymore which comes first..


> To explain why this might be wrong imagine security rules for a train:
> - if the pressing of the alive-knob for the driver times out then stop the train as if you are joining in to a sattion
> - if fire alarm is issued then bring the train to a stop as fast as possible except you are in a tunnel, then delay the stopping of the train until you have left the tunnel
> 
> Now what will your machine do if fire alarm is issued in a tunnel and the pressing of the alive-knob is timing out also?

Hmm, I'm not sure where you see randomness in all this (hopefully, the software would be coded to handle the case where both things occur), but as for "my machine" - for something this simple (stop if (at_station && !alive) || (on_fire && !inside_tunnel)), I wouldn't use a CPU at all, this can be done far more reliably with a few really big logic gates :)


xs0

xs0 <xs0@xs0.com> wrote:

> You seem to want some sort of multi-core support, but what would that be? Can you give an example or two?

Please have a look at

http://plg.uwaterloo.ca/~usystem/pub/uSystem/uC++book.pdf

Thanks for "Marco A"'s post 29355 in the old D group for directing me to this reference.

-manfred

>> I need to read up a bit on multi-core systems, but they act the same as SMP systems, correct?
>
>Dual-cores _are_ an implementation of SMP.
>
>> So your concern is having library
>> facilities which allow you to assign tasks to different
>> processors and so on?
>
>No. I have somewhere seen an argument, that if concurrency is not implemented into the language then no compiler can be guaranteed to deliver correct code under all circumstances---therefore concurrency must be implemented into the language.

There are some problems with optimizers that can move code around so things might get called before a libray-lock-directive if the compiler isn't aware of that it musn't move code in fromt of or behind this function call.

In article <d90h6h$134$1@digitaldaemon.com>, Manfred Nowak says...
>
>xs0 <xs0@xs0.com> wrote:
>
>[...]
>> AFAIK, multi-core processors are almost exactly the same as having multiple cpus, except they're in a single box and share a single bus to the outside world.
>
>Thanks for your opinions, I have read them carefully several times.
>
>There is one fundamental difference between dual-cores and dual- cpus: dual-cores can exchange data over the internal bus and do not need any bandwidth on the bus to the "outside world".
>
>I.e. if you have a multi dual-core machine and knows that two threads have to communicate intensively you loose performance if you cannot control to have both threads running on a single dual- core die.

Yikes.  So you're saying you'd have lockless sharing of data between the cores and only force a cache sync when communicating between processors?  Makes sense, I suppose, but it sounds risky.

>In the example of the throw statement you even explicitely say, that you are not interested in guiding the machine, instead the machine is allowed to do what ever _randomly_ occurs first
>
>To explain why this might be wrong imagine security rules for a
>train:
>- if the pressing of the alive-knob for the driver times out then
>stop the train as if you are joining in to a sattion
>- if fire alarm is issued then bring the train to a stop as fast as
>possible except you are in a tunnel, then delay the stopping of the
>train until you have left the tunnel
>
>Now what will your machine do if fire alarm is issued in a tunnel and the pressing of the alive-knob is timing out also?

Perhaps I'm missing something, but I don't see why this example requires special assembly-level handling of exceptions.  If the button failure exception is thrown before the fire warning is signalled, then the train will begin to slow down.  Then when the fire warning is signalled I assume the train will continue on at its existing speed until it exits the tunnel, then it will stop?  And if the reverse happens, the train will ignore the stop button time-out because it's handing a more important directive.

Is the issue that you don't want to use traditional synchronization in the error handling mechanism and would rather prioritize at the signalling level?  I'll admit I haven't done this sort of programming before.


Sean

In article <d90hkm$134$2@digitaldaemon.com>, Manfred Nowak says...
>
>Sean Kelly <sean@f4.ca> wrote:
>
>> I need to read up a bit on multi-core systems, but they act the same as SMP systems, correct?
>
>Dual-cores _are_ an implementation of SMP.

Just making sure I wasn't missing something.

>> So your concern is having library
>> facilities which allow you to assign tasks to different
>> processors and so on?
>
>No. I have somewhere seen an argument, that if concurrency is not implemented into the language then no compiler can be guaranteed to deliver correct code under all circumstances---therefore concurrency must be implemented into the language.

This is an issue with C/C++.  Specifically, it relates to the "as if" rule and the fact that the theoretical virtual machine optimizers target has no concept of concurrency.  So there's no real way to ensure volatile instructions aren't being reordered unless you use a synchronization library.  D addresses this particular issue somewhat in its reinterpretation of "volatile," and I'm sure Walter is keeping an eye on the C++ standardization talks about this issue as well.


Sean

Sean Kelly <sean@f4.ca> wrote:

[...]
> This is an issue with C/C++.  Specifically, it relates to the "as if" rule and the fact that the theoretical virtual machine optimizers target has no concept of concurrency.  So there's no real way to ensure volatile instructions aren't being reordered unless you use a synchronization library.  D addresses this particular issue somewhat in its reinterpretation of "volatile," and I'm sure Walter is keeping an eye on the C++ standardization talks about this issue as well.

Are you able to prove, that the argument holds for C++ only, which would be a contradiction to a paper accepted by ACM and available here:

http://plg.uwaterloo.ca/~usystem/pub/uSystem/LibraryApproach.ps.gz

-manfred

Sean Kelly <sean@f4.ca> wrote:
[...]
> Yikes.  So you're saying you'd have lockless sharing of data between the cores and only force a cache sync when communicating between processors?  Makes sense, I suppose, but it sounds risky.

Why lockless?

>>In the example of the throw statement you even explicitely say, that you are not interested in guiding the machine, instead the machine is allowed to do what ever _randomly_ occurs first
>>
>>To explain why this might be wrong imagine security rules for a
>>train:
>>- if the pressing of the alive-knob for the driver times out
>>then stop the train as if you are joining in to a sattion
>>- if fire alarm is issued then bring the train to a stop as fast
>>as possible except you are in a tunnel, then delay the stopping
>>of the train until you have left the tunnel
>>
>>Now what will your machine do if fire alarm is issued in a tunnel and the pressing of the alive-knob is timing out also?
> 
> If the button failure exception is thrown before the fire warning
[...]
> And if the reverse happens
[...]
> Is the issue that you don't want to use traditional synchronization in the error handling mechanism and would rather prioritize at the signalling level?

I see, that you catched the basic principal behind my example. And as you may see above it is difficult to the human brain to think in concurrency: you serialized the events but do not handle the case when depending on an unlucky implementation both cores might independently raise both exceptions, one core the fire exception and the other the alive-knob exception.

In this case you have a control leak.


There is one more thing to mention: it is not seldom, that specifications are incomplete or even contradictory and that detection of this specification faults occurs late in the software production process.

Depending on the awareness of the implementators such a fault might traverse into the final product.

Have a look at your two cases: you are handling the case that the alive-knob exception comes first, but you missed that the fire-knob exception might be thrown, when the train stopped already, but in a tunnel.

-manfred

In article <d948ms$2feb$1@digitaldaemon.com>, Manfred Nowak says...
>
>Sean Kelly <sean@f4.ca> wrote:
>
>[...]
>> This is an issue with C/C++.  Specifically, it relates to the "as if" rule and the fact that the theoretical virtual machine optimizers target has no concept of concurrency.  So there's no real way to ensure volatile instructions aren't being reordered unless you use a synchronization library.  D addresses this particular issue somewhat in its reinterpretation of "volatile," and I'm sure Walter is keeping an eye on the C++ standardization talks about this issue as well.
>
>Are you able to prove, that the argument holds for C++ only, which would be a contradiction to a paper accepted by ACM and available here:
>
>http://plg.uwaterloo.ca/~usystem/pub/uSystem/LibraryApproach.ps.gz

Not at all.  I imagine many languages target a single-threaded virtual machine. Java is probably one of the few exceptions.


Sean