Speedup for guarded allocator
authorSergey Sharybin <sergey.vfx@gmail.com>
Thu, 15 Aug 2013 12:13:01 +0000 (12:13 +0000)
committerSergey Sharybin <sergey.vfx@gmail.com>
Thu, 15 Aug 2013 12:13:01 +0000 (12:13 +0000)
commit1a8119781942ef157586ae2a67288b69710e040d
tree6d4e11b2df1e2f8e6dd52692fda0232b5d8aa6d6
parentc4f6340f7d2389b81cab5fa6340fba0268dc1ba0
Speedup for guarded allocator

- Re-arrange locks, so no actual memory allocation
  (which is relatively slow) happens from inside
  the lock. operation system will take care of locks
  which might be needed there on it's own.

- Use spin lock instead of mutex, since it's just
  list operations happens from inside lock, no need
  in mutex here.

- Use atomic operations for memory in use and total
  used blocks counters.

This makes guarded allocator almost the same speed
as non-guarded one in files from Tube project.

There're still MemHead/MemTail overhead which might
be bad for CPU cache utilization.

TODO: We need smarter 32/64bit compile-time check,
      currently i'm afraid only x86 CPU family is
      detecting reliably.
intern/atomic/atomic_ops.h
intern/guardedalloc/CMakeLists.txt
intern/guardedalloc/SConscript
intern/guardedalloc/intern/mallocn.c
source/blender/blenlib/intern/threads.c
source/blender/makesdna/intern/CMakeLists.txt
source/blender/makesdna/intern/SConscript
source/blender/makesrna/SConscript
source/blender/makesrna/intern/CMakeLists.txt
source/gameengine/GamePlayer/ghost/GPG_ghost.cpp