This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Fri, Nov 29, 2013 at 01:29:49PM +0100, OndÅej BÃlka wrote: > On Thu, Nov 28, 2013 at 11:26:03PM -0500, Carlos O'Donell wrote: > > In the end AS-safety may even limit your flexibility, but I don't > > discount the possibility of writing the allocator such that it performs > > well. > > > Not on x86, I did a benchmark to see how big is overhead, after > eliminating sources of noise a signal safe variant is pretty > indistingushible from normal. There were two preventable slowdowns, > first was that dynamic tls is access slower so we need to use static tls. > Second was caused by gcc which emmited storing five registers at start > of free for unlikely code for returning memory that is suppressed by > appropriate expect. Benchmark is here, it does repeated allocation and deallocation, I ran frequency/10 iterations of malloc/free with given wrapper on ivy bridge, A plain version takes around 107 cycles, intercepting and tls cost around 10 cycles, if we look to tls only it is around 3 cycles in malloc. You would need to make allocator a magnitude faster to make this noticable factor, costs for other architectures differ. plain real 0m10.753s user 0m10.757s sys 0m0.000s normal real 0m11.518s user 0m11.521s sys 0m0.000s signal safe real 0m11.733s user 0m11.737s sys 0m0.000s plain real 0m10.753s user 0m10.757s sys 0m0.000s normal real 0m11.274s user 0m11.274s sys 0m0.003s signal safe real 0m11.732s user 0m11.736s sys 0m0.000s
Attachment:
malloctest.tar.bz2
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |