Small Vectors Proposal

[Andrei Alexandrescu (See Website For Email)]

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Having read the proposal, I think it can likely be accommodated 
>> entirely with current and up-and-coming language features. To expand:
> 
>>> Moreover, many architectures are specially optimized for the lower 
>>> dimensional cases, and offer special registers which are virtually 
>>> impossible to properly exploit using libraries alone.  The situation 
>>> is analogous to floating point arithmetic, proper hardware support 
>>> requires language level integration.
>>
>> I don't see much of an analogy, but this is also a minor point. 
>> Floating point arithmetic was weird way before it was implemented in 
>> hardware, and the weirdness reflected in languages. But on many 
>> machines adding two floating point numbers required a routine call, 
>> which didn't add or subtract anything to the equation.
> 
> Your responses to the other points seem reasonable and encouraging, but 
> your response to this issue concerning performance is... what?  That 
> making optimal use of the hardware is not important?

Nonono. I just meant that the fact that today's architectures have 
dedicated operations and hardware for floating point did not change the 
semantics of floating point operations in programming languages.

> For more specifics of what Mikola finds problematic on the efficiency 
> front see:
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=47596 

Thanks. I'm seeing:

1. Function calls

I agree that optimization of compound operations a la d = a * b + c is 
hard, but it should be addressed in a principled way (e.g. expression 
templates).

2. Register allocation

This has been discussed in an older thread on comp.lang.c++.moderated. 
Basically current compiler technology conservatively puts every 
"serious" data structure (e.g. structs with constructors) in registers. 
I see this as more of a limitation of current compiler technology, than 
a fundamental issue. Of course, I do no work on improving said 
technology, which lessens my point. :o)

3. Data alignment

D must add primitives to define types aligned at arbitrary boundaries. 
This will not only help small vectors, but a host of other systems-level 
software as well (e.g. allocators).


Andrei