[Ecls-list] Slow bignums

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> On Sat, Jan 30, 2010 at 3:12 AM, Waldek Hebisch <hebisch at math.uni.wroc.pl>wrote:
> >
> > Yes, typically copy is cheap enough.  But in this case main operations
> > are adding 1 and multiplication by fixnum.  Adding 1 costs basically
> > the same as copy.  Multiplication by fixnum is slightly more expensive,
> > but should be no more expensive than two copies.
> >
> 
> Waldek, sorry if I sound rude, but really, you are talking out of
> conjectures without paying attention to my previous emails. I told you the
> results from profiling when using registers: 80% time on my Mac is spent in
> the garbage collection routine (most of it in the conservative mark phase),
> 10% in allocation, 10% in the bignum library or less. Now without registers
> those numbers only changed by 5% or so. I also offered you the numbers from
> a 64-bits platform where the garbage collector is much better because
> pointers are very much more spread and only a tiny fraction of the address
> space is filled. There ECL can beat SBCL without problems, and I bet the
> profiling numbers regarding garbage collection are still large.
>

Here is what oprofile tells me on my machine (this is not
the newest ECL, if register change is commited I can retest
with newest version):

Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
unit mask of 0x00 (Unhalted core cycles) count 1000000
Counted INST_RETIRED.ANY_P events (number of instructions retired) with
a unit mask of 0x00 (No unit mask) count 2000000

   16656 91.2658      8935 94.3307 ecl
        CPU_CLK_UNHALT...|INST_RETIRED:2...|
          samples|      %|  samples|      %|
        ------------------------------------
            10640 63.8809      6884 77.0453 libgc.so.1.0.3
             4214 25.3002      1679 18.7913 libgmp.so.3.4.2
             1756 10.5427       355  3.9731 libc-2.8.so
               38  0.2281        17  0.1903 libecl.so.9.10.2
                4  0.0240         0       0 ld-2.8.so
                4  0.0240         0       0 expinv.fas

Top symbols:

8276     45.3479  5423     57.2530  libgc.so.1.0.3   ecl  GC_mark_from
3149     17.2548  738       7.7914  libgmp.so.3.4.2  ecl  __gmpn_add_n
1699      9.3096  349       3.6845  libc-2.8.so      ecl  memcpy
1130      6.1918  688       7.2635  libgc.so.1.0.3   ecl  GC_header_cache_miss
1046      5.7315  932       9.8395  libgmp.so.3.4.2  ecl  __gmpn_mul_1

Gc part looks bad.  But 10% in memcpy is not negligibe compared to 25%
in libgmp.so.3.4.2.

I understand that reducing gc time is more important than
other possible savings...  

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl