#154776 investigation on how to get built specially-tuned versions of libgc

Package:
libgc
Source:
libgc
Submitter:
Yann Dirson
Date:
2005-07-18 03:53:37 UTC
Severity:
wishlist
#154776#5
Date:
2002-07-29 22:13:01 UTC
From:
To:
Note: I file this as a wishlist so that the discussion gets archived in a
place where it is retreived easily.

The fact:

Currently, bigloo ships its own version of libgc, which is compiled with
some special parameters in order to get the best performance for the
application.

The problems:
- Although upstream does a good job at tracking CVS, it is not sufficient
for our needs, and the build of libbigloogc regularly breaks on some archs.
- We use 2 slightly different versions of the same sources, with little good
reasons.

My basic idea:
Using the same libgc source for both packages (and possibly for other
packages that would need otherwise-tuned versions of the libs).

Some possibilities I thought about:

- use the libgc from the libgc6 package.  Upstream kindly added the option
  of doing that, specially for us (I believe that could be used as well to
  point to an optimized libgc, with some minor modifications)
 => problem: upstream did some benchmarks recently, and that would really be
    a measurable loss

- have the libgc source package build the libbigloogc package
 => problem: puts the burden over the libgc maintainer

- have a libgc-source package, somewhat similarly as we have kernel-source
  packages, and have both libgc and libbigloogc built with this libgc-source
  as a build-dependency.
 => problem: puts most of the burden over the libgc maintainer as well


What do you think of this ?
#154776#10
Date:
2002-07-29 21:26:41 UTC
From:
To:
I think this bug has no information in it of the actual details of what
options you are talking about, and if they aren't added, I'll close it.
#154776#15
Date:
2002-07-29 22:58:18 UTC
From:
To:
Manuel Serrano wrote:
| everything is compilation options + the file runtime/Clib/inline-alloc.c

The files he refers to contains specific allocation functions for a couple
of data types (cons and floats).

Manuel: what difference does this one make when this is not in libbigloogc ?


The Makefile reads:

CFLAGS= -O -I$(srcdir)/include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS

Manuel: is this only those options you're using for tuning purposes ?


Regards,
#154776#20
Date:
2002-07-30 10:35:14 UTC
From:
To:
If this is really important. I will try to see with Hans Boehm (the author
of the GC) what could be done.
#154776#25
Date:
2002-07-30 10:28:05 UTC
From:
To:
You can live without the runtime/Clib/inline-alloc.c file but you have
to take care not to define the CPP symbol BGL_GC_CUSTOM, so that in
runtime/Include/bigloo.h the expansion of the macro MAKE_PAIR is correct.

runtime/Clib/inline-alloc.c is optional. It impacts performance. With
runtime/Clib/inline-alloc.c Bigloo is about 10% faster. The GC
file gc_inl.h could be improved so that a portable version of
inline-alloc.c could be written with close performance to the
current one.

I will try to remember to send a mail to Hans Boehm about that.
#154776#30
Date:
2002-07-30 22:11:28 UTC
From:
To:
You mean it 10% faster when used as part of libgc rather as used otherway ?