Hi!
>> A few weeks ago, I complained about a slow down in SBCL's performance =
by
>> about 15% between versions 1.0.4 and 1.0.5.
>>
>> In the mean time, I had some hours left and could track down the probl=
em
>> to changes in the file src/compiler/x86/parms.lisp on April 30. These
>> changes are all concerning memory layout.
>=20
> That's strange. I wouldn't have expected that to have any measurable
> performance effect. Just to verify, does just reverting the
> src/compiler/x86/parms.lisp changes fix the problem, or do you need to
> revert the whole patch?=20
cvs update -D "2007-04-30 14:48" src/compiler/x86/parms.lisp
does the whole magic.
before (todays cvs-version) 53,6s
after (old parms.lisp) 46,4s
>=20
> If your benchmark program can be distributed, I'd be interested in
> having a look at it.
Sure. I'm doing cognitive modeling research using ACT-R
(http://act-r.psy.cmu.edu/)
In order to run it using sbcl, you have to apply some patches that you
can find here: http://www.unibw.de/lrt11/halbruegge/ACT-R
The actual benchmark task is a cognitive model written in ACT-R. I can
put that one online if you're interested.
>> My question: Is there a vital reason for these parameter changes, or i=
s
>> it ok to mix the current SBCL code with the older - in my case faster =
-
>> parameter set?
>=20
> Using the old parameters is ok. The new parameters are there mainly to
> decrease the chances of address space randomization causing problems,
> and to make it more feasible to run sbcl on systems where the maximum
> amount of memory / address space that a program may use has been
> limited.
ok.
Thanks for your quick answer!
Greetings
Marc
|