[dmd-concurrency] real

[Andrei Alexandrescu]

You're making the wrong argument in two distinct ways.

First, I'm not talking about disabling 64-bit support on 64-bit 
machines, but instead about dealing with 64-bit machines that don't have 
128-bit atomic assignment.

Second, your argument with 16 to 32 bit transition is entirely 
inapplicable. This is about enabling the feature two-words-assignment on 
both kinds of machines. I'm sorry this is via email - in real life I 
could have stopped you at the first words so you could rebuild your 
argument in alternative terms.


Andrei

Walter Bright wrote:
> 
> 
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>> [snip]
>>> I've already made the argument for supporting 64 bit atomics where 
>>> allowed by the architecture, and the tradeoffs, so I won't repeat it.
>>
>> I'm a bit lost. Are you saying that we should allow this:
>>
>> shared int[] a, b;
>> ...
>> a = b[2 .. 3];
>>
>> on some machines but not others?
> 
> Yes.
> 
>> How is then anyone expected to write reasonably portable code?
> 
> How do you propose one write such code portably on a 32 bit machine?
> 
>>
>> One great thing about Linux distros is that you are able to compile 
>> code on your machine. You get the source code, you run configure, you 
>> run make, you run make install, and you're good to go. How would it be 
>> to see messages like "On this machine this entire feature and 
>> consequently design doesn't work"?
> 
> This is deja vu all over again <g>. I remember the 16 <=> 32 bit 
> transition. Lots of people tried to take 32 bit code and make it work on 
> 16 bit machines. While C is presumably portable, in practice you had to 
> /redesign/ the code to make it work well on 16 bit machines, not just 
> mess around with a few details. I can't remember one port from 32 to 16 
> bits that was a significant success on 16 bit machines compared with 
> ones that were /designed/ for 16 bits from the ground up.
> 
> One example was Stroustrup's cfront. It reigned supreme on 32 bit 
> machines in the 80's. It was ported to 16 bits and sold (Glockenspiel 
> C++). It got its butt kicked on 16 bit machines by every C++ compiler 
> that was designed for 16 bits.
> 
> On the other hand, major apps in the 16 bit world were able to migrate 
> to 32 bits without too much difficulty, though they still benefited from 
> a redesign.
> 
> All the C apps you see that you can make for 32 or 64 bits in Linux have 
> already been ported, tested, and verified to work. I've never seen any 
> non-trivial C application built for 32 bits that survived unmodified 
> when compiled for 64. Not one. Not even mine, and I'm experienced at 
> doing such ports.
> 
> I suspect that we'll see that (for C, C++ and D) apps developed natively 
> for 64 bits will not port very well to 32 bits for many reasons. 
> Remember when we talked about the large address space on 64 bits meaning 
> that different algorithmic strategies can be used (even if there isn't 
> more physical memory)? How about on 64 bits we can at last get rid of 
> thread stack size problems? Won't that change the strategic tradeoffs 
> one applies when multithreading?
> 
> 64 bit machines are going to support multithreading better than 32 bit 
> ones. I don't see that as a reason to deliberately cripple those advantages.
> 
> Back to your question:
>> Are you saying that we should allow this:
>>
>> shared int[] a, b;
>> ...
>> a = b[2 .. 3];
>>
>> on some machines but not others?
> 
> Consider the analogy:
> 
>    char *p = new char[100000];
> 
> which works fine on 32 bits, but doesn't on 16 bits. Yes, there were 
> LOTS of attempts to transparently make this work in 16 bit languages. 
> Every one of them worked on paper (so-called "huge" pointers), but were 
> unacceptably slow in practice. Having the compiler kludge it to make it 
> appear to work was not acceptable, and neither was disabling such code 
> in 32 bit compilers.
> 
> Should we disable reading 8 Gb files using memory mapped I/O in 64 bit D 
> because the same code will not work in 32 bits? Or do we accept that 
> yes, the programmer will have to use a different strategy to read 8 Gb 
> files in 32 bit code?
> 
>>
>> I agree with disabling some feature on an odd machine, but not with 
>> conditioning entire areas of the language on the machine they work on. 
>> What is this, assembly language?
> 
> If we disable 64 bit atomic support on 64 bit machines, all we will be 
> doing is leaving a wide open door for other languages without such 
> compunctions. We will not be benefiting 64 bit D programmers.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency