Thread performance (was Re: dynamic context transitions)
Michael B Allen
mba2000 at ioplex.com
Sun Dec 5 04:25:05 GMT 2004
On Sun, 5 Dec 2004 09:30:09 +1100
tridge at samba.org wrote:
> able to approach the speed of processes. For this sort of thing, you
> can't beat hardware with software.
You can if you dump the locks alltogether. Do you really need a thread safe
malloc? The malloc API is pretty stupid if you think about it. It would be
much better if the user could create an allocation context to be used
exclusively by the caller thereby eliminating the need for locks to protect
malloc calls. Using my suba "sub-allocator" module [1] you can initialize an
arbitrary chunk of memory as an allocator:
unsigned char mem[0xFFFF];
struct allocator *al = suba_init(mem, 0xFFFF, 1, 0);
barrier_wait(&barriers[0]);
for (j=0;j<500;j++) {
for (i=1;i<NMALLOCS;i++) {
ptrs[i] = suba_alloc(al, i, 0);
...
[note: The suba module requires the memory be a fixed size because I use it
with shared memory (i.e. must be one continuous chunk) but you could easily
modify it to dynamically malloc a new chunk and add a cell to the end of the
list.]
Below are results of your thread_perf.c with the above modification [2]:
linux$ ./thread_perf 10 malloc
NOTE! for accurate process results please compile with -DNO_THREADS and
don't link to -lpthread
Running test 'malloc' with 10 tasks
Threads 0.83 +/- 0.02 seconds
Processes 0.84 +/- 0.00 seconds
linux$ ./thread_perf 10 suba_alloc
NOTE! for accurate process results please compile with -DNO_THREADS and
don't link to -lpthread
Running test 'suba_alloc' with 10 tasks
Threads 0.18 +/- 0.00 seconds
Processes 0.19 +/- 0.00 seconds
Of course this is much faster because the locks are basically subverted. If
you're using a multi-threaded server that passes these memory fragments
around you would have to add back some locking. But you have a *choice*.
Mike
http://www.ioplex.com/~miallen/libmba/dl/src/suba.c
http://www.ioplex.com/~miallen/c/thread_perf.c
--
Greedo shoots first? Not in my Star Wars.
More information about the samba-technical
mailing list