[dmd-concurrency] real

[Andrei Alexandrescu]

I don't understand. This view is in stark contrast with everything D has 
been so far, and also embodies everything you told me many times you 
dislike about C.

For one thing there's no precedent of what you say in D. Data types from 
char to long and also float and double are guaranteed to be in the 
language. If a processor does not support IEEE754, you insert routines 
do to things for you. Same with 64-bit integers, vector operations, and 
probably in a number of other places. But the point is that you do offer 
a platform for writing portable programs, not a balkanized federation of 
sublanguages. Why the sudden change?

I'm ok with leaving real assignment atomicity to the compiler, but I 
think attempting to take that any further will kill babies.


Andrei

Walter Bright wrote:
> 
> 
> Andrei Alexandrescu wrote:
>> It's a slippery slope. If we leave real's compilation to the 
>> installation, we should also allow atomic shared array assignment for 
>> machines that support 128-bit atomic assign. I just don't think this 
>> is a tenable approach to designing a language.
>>
> 
> I don't think the message D should send is: "Yes, I know you're using a 
> machine that can do atomic 128 bits, but because some machines you don't 
> have and don't care about don't, you have to go the long way around the 
> block and use a clumsy, awkward, inefficient workaround."
> 
> The choices are:
> 
> 1. allow atomic access for basic types where the CPU supports it, issue 
> error when it does not. The compiler makes it clear where the programmer 
> needs to pay attention on machines that need it, and so the programmer 
> can select whether to use a (slow) mutex or to redesign the algorithm.
> 
> 2. allow atomic access only for basic types supported by the lowest 
> common denominator CPU. This requires the user to use workarounds even 
> on machines that support native operations. It's like the old days where 
> programmers were forced to suffer with emulated floating point even if 
> they'd spent the $$$ for a floating point coprocessor.
> 
> 3. allow atomic access for all basic types, emit mutexes for those types 
> where the CPU does not allow atomic access. Keep in mind that mutexes 
> can make access 100 times slower or more. Bartosz suggested to me that 
> silently inserting such mutexes is a bad idea because the programmer 
> would likely prefer to redesign the code than accept such a tremendous 
> slowdown, except that the compiler hides such and makes it hard for him 
> to find.
> 
> 
> As I've said before, I prefer (1) because D is a systems programming 
> language. It's mission is not the Java "compile once, run everywhere." D 
> should cater to the people who want to get the most out of their 
> machines, not the least. For example, someone writing a device driver 
> /needs/ to get all the performance possible. Having some operations be 
> 100x slower just because of portability is not acceptable.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency