This trivial change is just to mark the revision which suprisely

give 2.5% speedup the bzip2 in SPEC2000int benchmark. 2.5% is kind of
big improve to bzip2. As of I write this commit log, I have no idea
where the speedup is coming from. This revision might expose some
opportunity of malloc implementation.

I only run bzip2 with only one ref-input, the "input.souce".

o. If I run bzip2 with following command:
    time -p (./bzip2 input.source 58 >run.source.out 2>run.source.err)
    the user time is 15.39s.

o. If I run the same command line but with ptmalloc3 on and ljmm off,
time -p (ENABLE_LJMM=0 LD_PRELOAD="/home/syang/develop/luajit/ljmm.gh/libptmalloc3.so /home/syang/develop/luajit/ljmm.gh/libadaptor.so" ./bzip2 input.source 58 >run.source.out 2>run.source.err)
    the user time is about the same (if not exactly the same).

  (this implies ptmalloc3 and the malloc implementatio in GNU libc 2.19
   have about the same performance).

o. However, if I change the above command line by flipping
   ENABLE_LJMM=0 to ENABLE_LJMM=1, time-command to 14.9s.
   (Yes, the ouput the command line *is* correct).

The performance improvement deserve a closer look.
master
Shuxin Yang 2014-08-25 11:15:41 -07:00
parent bea77ba9cb
commit e6c87e266c
2 changed files with 3 additions and 2 deletions

View File

@ -6,7 +6,7 @@ default : all
AR_NAME := libljmm.a
SO_NAME := libljmm.so
OPT_FLAGS = -O0 -g -DDEBUG
OPT_FLAGS = -O3 -g -DDEBUG
CFLAGS = -fvisibility=hidden -MMD -Wall $(OPT_FLAGS)
CXXFLAGS = $(CFLAGS)

View File

@ -187,7 +187,8 @@ __wrap_munmap(void *addr, size_t length) {
}
void*
__wrap_mremap(void *old_addr, size_t old_size, size_t new_size, int flags, ...) {
__wrap_mremap(void *old_addr, size_t old_size, size_t new_size,
int flags, ...) {
if (!init_done || old_addr > (void*)LJMM_AS_UPBOUND) {
void* p = NULL;
if (!(flags & MREMAP_FIXED)) {