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