[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Immediate fixnums below .text

From: Camm Maguire
Subject: [Gcl-devel] Immediate fixnums below .text
Date: 27 May 2005 18:45:28 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Robert Boyer <address@hidden> writes:

> > The experimental fixnum_times function which accelerated your
> > benchmark is in this build,
> I confirm your amazing speed-up of the matrix multiply.  Wow.
> > please let me know if you therefore feel that testing now is a
> > waste of time
> > it appears quite easy to make use of the address space below
> > 0x8000000 for immediate fixnums
> Intuitively, I bet that this would be a huge, huge win.  Not having to go to
> memory for the type and value of probably 99% of the fixnums ever used seems
> like a gigantic advance, giving the crucial "stay in the cache" issue of
> today.  But my bet is not worth much.  Only experience is likely to settle
> the matter.  I can tell you that I have always thought of FIXNUMS as the
> worst part of the design of GCL.

OK, I've compiled a first pass at immediate fixnums below 0x8000000
(on x86).  For now, I've left-shifted by 3 to avoid confusing the mark
bits now in use on two word cons', so the effective range is ~
+=8,000,000, with no extra memory usage (The existing
small_fixnum_limit is +=1,000).  As you may recall, I got about 3.5
sec after the fixnum_times improvement on your benchmark --  with this
first attempt it is now:

(time (m-mm))

real time       :      2.410 secs
run-gbc time    :      2.410 secs
child run time  :      0.000 secs
gbc time        :      0.000 secs

So the promise appears there, especially as I haven't done things
particularly optimally.

The question is portability.  In principle, er have the area below
.text, or the area between MAXPAGES and the maximum stack, to use as
this area, with the latter being considerably larger.  From a design
point of view, though, it might not be as wise to count on space in
this latter area, condiering as how both the heap and the stack grow
into it.  All of this needs to be determined portably at compile time,
of course.  On some machines, .text starts at 0, which would deprive
us of even the existing small_fixnums.  Here is the Debian table:

      DBEGIN    CSTACK start
mips 0x10000000 2147449568
m68k 0x80000000 -268436688
arm  0x00000000 -1073743052
spar 0x00000000  -268436876
ppc  0x10000000 2147482280
s390 0x00000000 2147482256
hppa 0x00000000 -84933176
ia64 0x6000000000000000 6917546619827108400
alph 0x120000000 4831836640
x86  0x08000000 -1073749452
am64 0x08000000 -8888

Suggestions are always most welcome.

Take care,
Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]