tooling quality and some random rant

[Don]

bearophile wrote:
> Don:
> 
>> But still, cache effects are more important than instruction scheduling 
>> in 99% of cases.
> 
> I agree.
> CPUs have prefetching instructions, but D doesn't expose them as intrinsics. A bit more higher level visibility for those instructions may be positive today.

A problem with that, is that the prefetching instructions are 
vendor-specific. Also, it's quite difficult to use them correctly. If 
you put them in the wrong place, or use them too much, they slow your 
code down.

> 
> Being D a system language, another possible idea is to partially unveil what's under the "array as a random access memory" illusion. Memory hierarchy makes array access times quite variable according to what level of the memory pyramid your data is stored into (http://dotnetperls.com/memory-hierarchy ). This is why numeric algorithms that work on large arrays enjoy tiling a lot now. The Chapel language has language-level support for a high level specification of tilings, while Fortran compilers perform some limited forms of tiling by themselves.

I think it is impossible to be a modern systems language without some 
support for memory heirarchy.
I think we'll be able to take advantage of D's awesome metaprogramming, 
to support cache-aware algorithms. As a first step, I added cache size 
determination to core.cpuid some time ago. We have a long way to go, still.