SIMD support...

[Andrei Alexandrescu]

On 1/7/12 12:48 PM, Walter Bright wrote:
> On 1/7/2012 8:10 AM, Don wrote:
>> Moving AAs from a built-in to a library type has been an unmitigated
>> disaster
>> from the implementation side. And it has so far brought us *nothing*
>> in return.
>> Not "hardly anything", but *NOTHING*. I don't even have any idea of
>> what good
>> could possibly come from it. Note that you CANNOT have multiple
>> implementations
>> on a given platform, or you'll get linker errors! So I think there is
>> more pain
>> to come from it.
>> It seems to have been motivated by religious reasons and nothing more.
>> Why should anyone believe the same argument again?
>
>
> Having a pluggable interface so the implementation can be changed is all
> right, as long as the binary API does not change.
> If the binary API changes, then of course, two different libraries
> cannot be linked together. I strongly oppose any changes which would
> lead to a balkanization of D libraries.

In my opinion this statement is thoroughly wrong and backwards. I also 
think it reflects a misunderstanding of what my stance is. Allow me to 
clarify how I see the situation.

Currently built-in hash table use generates special-cased calls to 
non-template functions implemented surreptitiously in druntime. The 
underlying theory, also sustained by the statement quoted above, is that 
we are interested in supporting linking together object files and 
libraries BUILT WITH DISTINCT MAJOR RELEASES OF DRUNTIME.

There is zero interest for that. ZERO. No language even attempts to do 
so. Runtimes that are not compatible with their previous versions are 
common, frequent, and well understood as an issue.

In an ideal world, built-in hash tables should work in a very simple 
manner. The compiler lowers all special hashtable syntax - in a manner 
that's MINIMAL, SIMPLE, and CLEAR - into D code that resolves to use of 
object.di (not some random user-defined library!). From then on, 
druntime code takes over. It could choose to use templates, dynamic type 
info, whatever. It's NOT the concern of the compiler. The compiler has 
NO BUSINESS taking library code and hardwiring it in for no good reason.

This setup allows static and dynamic linking of libraries, as long as 
the runtimes they were built with are compatible. This is expected, by 
design, and a good thing.

> (Consider the disaster C++ has had forever with everyone inventing their
> own string type. That insured zero interoperability between C++
> libraries, a situation that persists even for 10 years after C++ finally
> acquired a standard string library.)

It is exactly this kind of canned statement and prejudice that we must 
avoid. It unfairly singles out C++ when there also exist incompatible 
libraries in C, Java, Python, you name it.

Also, the last time the claim that everywhere invented their own string 
type could have been credibly aired was around 2004.

What's built inside the compiler is like axioms in math, and what's 
library is like theorems supported by the axioms. A good language, just 
like a good mathematical system, has few axioms and many theorems. That 
means the system is coherent and expressive. Hardwiring stuff in the 
language definition is almost always a failure of the expressive power 
of the language. Sometimes it's fine to just admit it and hardwire 
inside the compiler e.g. the prior knowledge that "+" on int does modulo 
addition. But most always it's NOT, and definitely not in the context of 
a complex data structure like a hash table. I also think that adding a 
hecatomb of built-in types and functions has smells, though to a good 
extent I concede to the necessity of it.

We should start from what the user wants to accomplish. Then figure how 
to express that within the language. And only lastly, when needed, 
change the language to mandate lowering constructs to the MINIMUM EXTENT 
POSSIBLE into constructs that can be handled within the existing 
language. This approach has been immensely successful virtually whenever 
we applied it: foreach for ranges (though there's work left to do 
there), operator overloading, and too little with hashes. Lately I see a 
sort of getting lazy and skipping the second pass entirely. Need 
something? Yeah, what the hell, we'll put it in the language.

I am a bit worried about the increasing radicalization of the discussion 
here, but recent statements come in frontal collision with my core 
principles, which I think stand on solid evidential ground. I am 
appealing for building consensus and staying principled instead of 
reaching for the cheap solution. If we do the latter, it's quite likely 
we'll regret it later.


Andrei