Re: Take some lowhanging fruit to speed up R6RS fixnum operations

[Andreas Rottmann <a.rottmann@gmx.at>]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 23 Mar 2011 00:20, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> In porting dorodango[0], I have noticed that Guile's R6RS fixnum
>> operations are quite slow; here's a patch to remedy that a bit.
>
> What is the state of things here?  I'm a bit lost in the discussion :)
>
> You said that decompressing the zip file takes 74 seconds with Guile as
> it is now.  What if you change to use Guile's arithmetic instead of
> fxops?  That would give is a good baseline so that we can know how much
> overhead the fxops have.
>
OK, here are a bunch of numbers that will hopefully help to determine
the desired course of action:

| Codebase         | fixnum? | fxxor | unzip |
|------------------+---------+-------+-------|
| vanilla          |    5.66 | 24.69 |  65.9 |
| generic          |    5.62 |  1.92 |   7.7 |
| smart            |    3.42 | 21.29 |  56.3 |
| smart + opt        |    3.42 |  6.99 |  21.9 |
| smart + opt-macros |     3.4 |  5.56 |  21.0 |
| vmop             |    1.78 | 18.83 |  47.9 |
| vmop+opt         |    1.77 |  3.94 |  14.1 |
| vmop+opt-macros  |    1.78 |   3.7 |  13.3 |

As you can see, in the "vanilla" case (i.e. current stable-2.0), it's
65.9 seconds -- I do not know where I got the 74 second number from,
perhaps it was from a profiling run.

The "generic" case is the one where all fixnum checks have been
eliminated, thus allowing the compiler to emit VM primitives for most of
the operations.

Now, with these baselines established, I implemented the following
optimizations, and benchmarked combinations of them as can be seen from
the above table.

-- 
Andreas Rottmann -- <http://rotty.yi.org/>