Microsoft working on new systems language

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Tue Dec 31 13:56:37 PST 2013


On Tuesday, 31 December 2013 at 20:29:34 UTC, Chris Cain wrote:
> On Tuesday, 31 December 2013 at 19:53:29 UTC, Ola Fosheim 
> Grøstad wrote:
>> 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.

Well, there is a comment in the DMD source code that suggest that 
it is being thought about, at least. :)

Anyway, I think threading, locking and memory management are 
areas that should not be controlled by black boxes. Partially for 
optimization, but also for partial correctness "proofs".

> 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.

The way I see it: programmers today avoid the heap and target the 
stack. They shouldn't have to. The compiler should handle that. 
C++ compilers do reaaonably well on low level basic blocks, but 
poorly on higher levels, so programmers are used to hand 
optimizing for that situation.

I think many allocations could be dissolved and replaced with 
passing values in registers, or simply reused with limited 
reinitialization with better high level analysis, or maybe have 
allocations take place at the call site rather than in the 
repeatedly called function. Automagically!

> 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

Well, l think c++ish programmers in today are hand optimizing 
everything at the medium level, in a sense. Less so in Python (it 
is too slow to bother :-)


>> 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?

Actually I want meta-level constructs, like:
- this new will allocate at least 1000 objects that are 100-400 
bytes,
- all new allocs marked by X beyond this point will be released 
by position Y
- this new should not be pages if possible
- i dont mind if this new is mapped to disk
- this new is a cache object, destroy whenever you feel like
- this new will never hit another thread

> 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.

He shouldn't have to. You dont write your own paging or scheduler 
for the OS either. You complain until it works. :)


More information about the Digitalmars-d mailing list