On 11/12/13 05:41, Marc Glisse wrote:
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
I am trying to get something to actually work and be accepted in
gcc. That may mean being conservative.
That also may mean that you will cover only cases where it is not needed.
A malloc will have a small per-thread cache for small requests that does
not need any locking. A performance difference will be quite small and
there may be a define which causes inlining constant size mallocs.
Sizes from 256 bytes are interesting case.
I have to disagree here. When the allocated size is large enough, the
cost of malloc+free often becomes small compared to whatever work you
are doing in that array. It is when the size is very small that speeding
up malloc+free is essential. And you are underestimating the cost of
those small allocations.
I have to agree with Marc here. Start with something small and we can
always look to extend it to handle more cases over time.
The whole point is to avoid going into the allocator which can be damn
expensive. Allocating on the stack is orders of magnitude cheaper. If
you can collapse down to a _DECL, then, well, that's the holy grail.
[soapbox]
And doing this kind of thing intelligently is something I strongly would
encourage. I can't express my disdain for folks directly using alloca.
Programmers have consistently shown they are unable to do so in a safe
manner. The amount of time I have personally had to dedicate to dealing
with the fallout from such practices is absurd.
Banning alloca in favor of malloc is something every project should
seriously consider. Having the ability for the compiler to
intelligently and safely take a malloc/free pair and turn that into
alloca or DECL reference removes one more reason for programmers to
directly use alloca.
[/soapbox]
Jeff
