Re: [Asymptote-developers] autotoolization

[John B. <bo...@ma...>]

> On 20 Aug 2007 09:30:36 +0200, John Bowman <bo...@ma...> wrote:
> > There is a good reasons for having Asymptote build a single-threaded
> > version of gc. From the manual:
> >
> Yes, I saw that; but that's a reason to _use_ a single threaded gc;
> it's not a reason for Asymptote to assume responsibility to _build_
> the gc.  If the user has already built and installed a single-threaded
> gc, for example, it would be pointless and presumptuous to repeat the
> exercise in a client source tree. After all, it's an optional package,
> and Asymptote doesn't build fftw/gsl.  Better to put the user in
> control.
> 
> Note that I made a note in the INSTALL file about pros/cons of
> different memory management configs; "single threaded is faster" might
> be sufficient, but a little more detail would be nice too - is it
> faster on all platforms?  Even on multi-core machines? etc. - one
> would think a multithreaded version would be faster, after all.

On my IBM T60 dual core processor under FC6 (g++ 4.1.2), building with the
system Boehm GC slows asy down by 30% relative to using the default
single-threaded non-shared gc-7.0.

In my opinion the increased performance of a locally installed gc-7.0 justifies
the slight nuisance of downloading an extra tar ball. I think the procedure is
clearly explained in the documentation and by the configure script. 

Moreover, we test releases carefully only against the version of gc the
release was built for. These gc releases tend to come out about every six
months and most system versions of gc are very much older than that. 

Of course, if the user wants, he or she may override these defaults with
the appropriate configure options. But using an old unknown system version
of gc is too much of an unknown for us to make this the default, given the
delicate nature of garbage collection in the first place (especially on 32
bit machines). That would add one more set of unknowns for us to first sort
out when addressing reports of memory leaks and segmentation faults.

Interestingly, though, when I tried doing a local build of gc-7.0 with
GCOPTIONS=""
and linking with pthreads, I noticed no difference in speed relative to
default single-threaded build.

-- John