[Ecls-list] Ecl crashes on binarytrees benchmark

[Juan Jose Garcia-Ripoll]

On Thu, Jul 10, 2008 at 7:00 PM, Marko Kocić <marko.kocic at gmail.com> wrote:
> While we are at it, what are recommended condofgure options, and which
> ones are considered beta.
> I can't see any reason why threads, unicode and asmapply are disabled
> by default. Also, should I enable smallcons?

--enable-gengc might not work on all platforms. You just found out it
is broken in Mingw32.

--enable-smallcons seems pretty stable by now and does not add
significant code overhead. It will become default in next release.

--enable-longdouble does not seem very useful. I added because of
somebody's request.

--enable-threads slows down ECL signficantly. Not everybody needs
threads. So no need to impose them on everybody.

--enable-unicode does not make sense right now. Why do you need
unicode strings if we do not have proper means to read utf-8 files
yet?

--with-cxx, building with a C++ compiler is an interesting option, but
we do not want to force people to use a C++ compiler unless they want,
do we ;-)

--with-clx is by default off. I had no time to port portable-clx yet.

--with-__thread is normally off. Not all compilers support it and even
those that do sometimes produce wrong code.

--enable-c99complex is not implemented. I do not remember who added
it, but the person has definitely not finished that part.

--enable-opcode8 is not active, but it may become so. The question is
whether 8 bit opcodes do add something to the performance vs. 16 bit
ones. Not yet clear. Needs further testing

--enable-asmapply in  my experience only makes the core image smaller,
but not faster. and currently only suports IA32

All other options are on by default.

> Shouldn't all those features (if considered stable) be enabled by
> default on all platforms that support them?

Please do not feel offended, but I have frequently found out that
people suffer from featuritis. That is a terrible disease, frequent in
free software communities that causes affected people to think all
features are good and everybody should have everything on. Really,
this is not the case. There is a rationale for not including things
that are not so often needed, incomplete, or may slow other's people
programming experience. Furthermore, even though we have somehow
departed from this line, ECL's aim has always been to be a lean and
simple implementation, by default.

> Another question is why is ecl using old gc (6.8) and gmp (4.2.1)? I'm
> using gmp-4.2.2 without problems. I'll try with
> gc-7.1 to see if it works ok.

The rush to go for the latest. gc-7.0 was deemed unstable for quite a
long time and it has only been marked stable recently. 7.1 is
definitely _unstable_. The point is that if something works, there is
no need to update yet. gmp is a different beast. They tend to break
things with new releases and in particular support for OS X has been
in my experience a PITA. I do not want to look at it until I see some
real benefit from upgrading. Unfortunately, I have to optimize every
minute I devote to this project.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com