On Tue, 12 Nov 2013, Ondřej Bílka wrote:
Seems to be missing some bits.
A example, its purpose is to show a idea not to be complete.
I agree, but when too many bits are missing or wrong I fail to get the
idea :-(
How will you find small constant allocations with this in place?
I won't. If your code is already optimized, the compiler has nothing
left to do, that's fine. (not that I am convinced your optimization
works that well)
What if it decreases running time of all constant allocations by 6%.
Converting to stack allocation would eliminate overhead but eliminated
sites contributed to 5% of runtime.
Then you may keep using your code, the optimization will be useless on it
but it won't break it.
I started on this because of an application that spends more than
half of its time in malloc+free and where (almost) no allocation is
larger than 100 bytes. Changing the code to not use malloc/free but
other allocation strategies is very complicated because it would
break abstraction layers. I used various workarounds that proved
rather effective, but I would have loved for that to be unnecessary.
See my memory pool that uses custom free functionality where you need
only change malloc, free is handled automaticaly.
Do you mean the incomplete macro above, or your STACK_ALLOC macro
from the other post? (don't know how that one works either, "size"
appears out of nowhere in STACK_FREE)
Also a example where actual logic could be supplied later, should be
__stack_new instead size.
Ok, then that relies on the user calling STACK_ALLOC and STACK_FREE in a
suitably nested order. I clearly don't know enough from a C++ constructor
to use it.
This is more about using for allocation libraries that are flexible
enough.
We have different targets. I am concerned with very small allocations. The
overhead of 2 function calls is already noticable. I don't want to pay for
flexibility.
I believe the 2 approaches are really complementary and shouldn't hinder
each other.
(note that the limits of alias analysis mean that gcc often has no
idea which free goes with which malloc).
Wait, you have a free with same SSA_NAME as malloc and alias analysis
cannot tell which malloc corespond to that free?
Here it does, but I wanted to warn you that it isn't such a common case.
In addition to this patch, I'll also need some alias analysis changes for
the code I started with to be optimized.
--
Marc Glisse
