<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Andrei Alexandrescu wrote:
<blockquote cite="mid:4B619846.8070703@erdani.com" type="cite">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.
<br>
<br>
</blockquote>
<br>
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."<br>
<br>
The choices are:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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 <i>needs</i>
to get all the performance possible. Having some operations be 100x
slower just because of portability is not acceptable.<br>
</body>
</html>