guile 1.6.4 a bit faster?

guile 1.6.4 a bit faster?

[Doug Evans]

While the explicit symbol/string conversions introduce some minimal slowness
on the cgen side, guile 1.6.4 appears to be faster thus making up for it.
[or maybe the gcc that compiled 1.6.4 is much improved over the gcc
that compiled 1.3 :-)  guess I should verify that ...]

This is to generate all opcodes files with a sample size of 3, whoop de do.

guile 1.3:
94.89user 1.04system 1:41.28elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
94.78user 0.79system 1:40.96elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
94.89user 0.91system 1:42.35elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k

guile 1.6.4:
82.38user 0.93system 1:28.39elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
82.32user 0.88system 1:28.63elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k
82.46user 0.78system 1:28.60elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k

Re: guile 1.6.4 a bit faster?

[Ben Elliston]

Doug Evans <dje@transmeta.com> writes:

> While the explicit symbol/string conversions introduce some minimal
> slowness on the cgen side, guile 1.6.4 appears to be faster thus
> making up for it.  [or maybe the gcc that compiled 1.6.4 is much
> improved over the gcc that compiled 1.3 :-) guess I should verify
> that ...]

So are you now getting over the demise of Hobbit? :-)

Ben

Re: guile 1.6.4 a bit faster?

[Ben Elliston]

Doug Evans <dje@transmeta.com> writes:

> While the explicit symbol/string conversions introduce some minimal
> slowness on the cgen side, guile 1.6.4 appears to be faster thus
> making up for it.  [or maybe the gcc that compiled 1.6.4 is much
> improved over the gcc that compiled 1.3 :-) guess I should verify
> that ...]

So are you now getting over the demise of Hobbit? :-)

Ben

Re: guile 1.6.4 a bit faster?

[Doug Evans]

Ben Elliston writes:
 > Doug Evans <dje@transmeta.com> writes:
 > 
 > > While the explicit symbol/string conversions introduce some minimal
 > > slowness on the cgen side, guile 1.6.4 appears to be faster thus
 > > making up for it.  [or maybe the gcc that compiled 1.6.4 is much
 > > improved over the gcc that compiled 1.3 :-) guess I should verify
 > > that ...]
 > 
 > So are you now getting over the demise of Hobbit? :-)

It cost nothing to have the support.
If it bitrots let me fix it.
And the fun factor was just way too huge, which was the whole point of cgen.
After several miserable years on (pre-egcs) gcc, I desparately needed to
rediscover a joy of hacking.

The cynic in me wonders if there was some internal political
reason for its removal.

Re: guile 1.6.4 a bit faster?

[Ben Elliston]

Doug Evans <dje@transmeta.com> writes:

> It cost nothing to have the support.
> If it bitrots let me fix it.

That's not true.  It was costing something, because there were kludges
in CGEN to handle differing Scheme syntax supported by Guile and
Hobbit.  It also made the Makefiles slightly more complex and, at the
time, I opted to remove it for clarity.

> And the fun factor was just way too huge, which was the whole point
> of cgen.  After several miserable years on (pre-egcs) gcc, I
> desparately needed to rediscover a joy of hacking.

I don't disagree :-)

> The cynic in me wonders if there was some internal political reason
> for its removal.

Where have I heard that before?  No, it was just me trying to get my
head around CGEN at the time and the simpler, the better.

Ben

Re: guile 1.6.4 a bit faster?

[Doug Evans]

Ben Elliston writes:
 > Doug Evans <dje@transmeta.com> writes:
 > 
 > > While the explicit symbol/string conversions introduce some minimal
 > > slowness on the cgen side, guile 1.6.4 appears to be faster thus
 > > making up for it.  [or maybe the gcc that compiled 1.6.4 is much
 > > improved over the gcc that compiled 1.3 :-) guess I should verify
 > > that ...]
 > 
 > So are you now getting over the demise of Hobbit? :-)

Oh, btw.
Any speed issues I treat as a Guile problem.
cgen would smoke on a Scheme implementation that did dynamic compilation.
[and of course there's my pie-in-the-sky dream of having that implementation
use cgen for the backend of its dynamic compilation engine]
Not that hard to do, maybe someday in my dreams.
[and as for the bootstrapping issue, I'd imagine the Scheme implementation
would have both a computed-goto based engine and a dc engine]