Microsoft working on new systems language

[Chris Cain]

On Tuesday, 31 December 2013 at 19:53:29 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 31 December 2013 at 17:52:56 UTC, Chris Cain wrote:
>> 1. The compiler writer will actually do this analysis and 
>> write the optimization (my bets are that DMD will likely not 
>> do many of the things you suggest).
>
> I think many optimizations become more valuable when you start 
> doing whole program anlysis.

You're correct, but I think the value only comes if it's actually 
done, which was my point.

>> 2. The person writing the code is writing code that is 
>> allocating several times in a deeply nested loop.
>
> The premise of efficient high level/generic programming is that 
> the optimizer will undo naive code.

Sure. My point was that it's a very precise situation that the 
optimization would actually work effectively enough to be 
significant enough to discard the advantages of using a library 
solution. If there were no trade offs for using a compiler 
supported new, then even a tiny smidge of an optimization here 
and there is perfectly reasonable. Unfortunately, that's not the 
case. The only times where I think the proposed optimization is 
significant enough to overcome the tradeoff is precisely the type 
of situation I described.

Note I'm _not_ arguing that performing optimizations is 
irrelevant. Like you said, "The premise of efficient high 
level/generic programming is that the optimizer will undo naive 
code." But that is _not_ the only facet that needs to be 
considered here. If it were, you'd be correct and we should 
recommend only using new. But since there are distinct advantages 
to a library solution and distinct disadvantages to the compiler 
solution, the fact that you _could_, with effort, make small 
optimizations on occasion just isn't enough to overturn the other 
tradeoffs you're making.

>> 3. Despite the person making the obvious critical error of 
>> allocating several times in a deeply nested loop, he must not 
>> have made any other significant errors or those other errors 
>> must also be covered by optimizations
>
> I disagree that that inefficiencies due to high level 
> programming is a mistake if the compiler has opportunity to get 
> rid of it. I wish D would target high level programming in the 
> global scope and low level programming in limited local scopes. 
> I think few applications need hand optimization globally, 
> except perhaps raytracers and compilers.

You seem to be misunderstanding my point again. I'm _not_ 
suggesting D not optimize as much as possible and I'm not 
suggesting everyone "hand optimize" everything. Following my 
previous conditions, this condition is obviously suggesting that 
there isn't any other significant problems which would minimize 
the effect of your proposed optimization.

So, _if_ the optimization is put in place, and _if_ the code in 
question is deeply nested to make the code take a significant 
amount of time so that your proposed optimization has a chance to 
be actually useful, then now we have to ask the question "are 
there any other major problems that are also taking up 
significant time?" If the answer is "Yes, there are other major 
problems" then your proposed speed-up seems less likely to 
matter. That's where I was going.

>> Manual optimization in this case isn't too unreasonable.
>
> I think manual optimization in most cases should be privided by 
> the programmer as compiler hints and constraints.

In some cases, yes. An "inline" hint, for instance, makes a ton 
of sense. Are you suggesting that there should be a hint provided 
to new? Something like: `Something thing = new (@stackallocate) 
Something(arg1,arg2);`? If so, it seems like a really roundabout 
way to do it when you could just do `Something thing = 
stackAlloc.make!Something(arg1,arg2);` I don't see hints possibly 
being provided to new being an advantage at all. All that means 
is that to add additional "hint" allocators, you'd have to dive 
into the compiler (and language spec) as opposed to easily 
writing your own as a library.

>> Think of replacing library calls when it's noticed that it's 
>> an allocate function. It's pretty dirty and won't actually 
>> happen nor do I suggest it should happen, but it's actually 
>> still also _possible_.
>
> Yes, why not? As long as the programmer has the means to 
> control it. Why not let the compiler choose allocation 
> strategies based on profiling for instance?

Uhh... You don't see the problem with the compiler tying itself 
to the implementation of a library allocate function? Presumably 
such a thing would _only_ be done using the default library 
allocator since when the programmer says "use 
std.allocator.StackAllocator" he generally means it. And I find 
the whole idea of the compiler hard-coding "if the programmer 
uses std.allocator.DefaultAllocator.allocate then instead of 
emitting that function call do ..." to be more than a bit ugly. 
Possible, but horrific.