On Wed, 2010-01-27 at 10:20 -0500, Nathan Froyd wrote:
On Wed, Jan 27, 2010 at 9:17 AM, Charlie McMackin <email@example.com> wrote:
> Boinkmarks seems to support the core size claim along with speed
> regressions in TAK family, FPRINT-UGLY, and a couple others.
As a wild guess, I'm going to guess that this was due to 220.127.116.11,
which turned on threads on x86oid Linux by default. Access to special
variables becomes somewhat more expensive in thread-enabled builds.
This hypothesis doesn't explain everything (SEARCH-SEQUENCE on x86,
for instance), but it's a good first approximation.
I always built SBCL with threads, so that probably isn't it.
Also, to reiterate for David Owen, as I must not have been clear, the earlier AMD-64 core size was about the same (within 1-2M) of the i386 core size.
Good to know about the special variable access. Does that include defconstants and defvars or just defparameters?