[Ecls-list] Slow bignums
Waldek Hebisch
hebisch at math.uni.wroc.pl
Thu Jan 28 00:09:14 UTC 2010
Juan Jose Garcia-Ripoll wrote:
> On Mon, Jan 25, 2010 at 4:26 AM, Waldek Hebisch <hebisch at math.uni.wroc.pl>wrote:
>
> > I have noticed that ecl seem to be quite slow on some bignum
> > operations, namely bignum addition and multiplication of
> > bignum by a fixnum. [...]
> > clisp and Closure CL cons comparably to ecl (gcl does not report
> > consing).
>
>
> ECL's consing numbers are not very accurate: they are an estimate produced
> by the garbage collector.
>
> What I have done is profiling ECL with your code and looking for performance
> sinks. The result is quite surprising: bignum computations are just 10% of
> the total time, so ECL could be 10 times faster, but the problem is garbage
> collection, which takes the 90% remaining time.
>
> Your code is thus not actually testing bignum computations, but rather the
> ability of the garbage collector to allocate bignums which are increasing in
> size and quickly discarding it.
Yes, I know this. I am slightly surprized by 10% in actual computation,
given results from other implementations I expected closer to 30%.
> I expect these numbers to get better depending on the platform and the
> version number of the garbage collector, but I am unsure on how to further
> improve this.
If ECL's consing numbers have anything common with reality, then
ECL is consing too much. AFAIK sbcl bignum routines takes a lot
of effort to allocate temporaries on stack, so only final results
of arithmetic operations are allocated on the heap. AFAIK
GMP may want to allocate some temporaries, so there is some
possibility for losage here. The consing numbers reported by
sbcl are smaller than expected so possibly sbcl is also doing
some higher level optimization, like using fused multiply and
add or using mutable bignums for intermediate results (it seems
that moderately smart analysis could notice that intermediate
will became garbage). It would be nice if ECL could do
such optimizations. Let me add while I care very much
about bignum performance in future I will probably bypass ECL
for time critical parts and use mutable buffers + direct calls
to GMP, so ECL overhead does not bother me too much.
--
Waldek Hebisch
hebisch at math.uni.wroc.pl
More information about the ecl-devel
mailing list