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