headers
Christophe Rhodes | 4 Jul 2003 15:11
Picon
Picon
Favicon

Re: [Sbcl-devel] Re: string type uncertainty?

[ belatedly... ]

Nikodemus Siivola <tsiivola <at> cc.hut.fi> writes:

> I don't have any examples handy, but runtimes dropped from approx. 90
> seconds to around 10. The code in question is mainly floating point
> arithmetic with the floats stored in structs, and with plenty of consing.

I think this may have been a bug, though without going back through
sources a couple of months I can't really be sure... I think the
problem was that we used to PROCLAIM, not DECLAIM, accessors, and
consequently under certain circumstances the function bodies were
being discarded when they should have been saved for future inlining.
I've audited the codebase for this kind of error, but I think in the
intervening time Alexey converted ordinary slot accessors to use
compiler-internal source-transforms instead of inline functions.

In any case, the performance problem you noted should not appear any
longer; please let us know if it persists.

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 4 Jul 2003 15:59

Re: [Sbcl-devel] Re: string type uncertainty?

On Fri, Jul 04, 2003 at 02:11:41PM +0100, Christophe Rhodes wrote:

> > I don't have any examples handy, but runtimes dropped from approx. 90
> > seconds to around 10. The code in question is mainly floating point
> > arithmetic with the floats stored in structs, and with plenty of consing.

..

> I've audited the codebase for this kind of error, but I think in the
> intervening time Alexey converted ordinary slot accessors to use
> compiler-internal source-transforms instead of inline functions.

I can't remenber that dataset that resulted in the times I reposted,
but at least declaiming them inline no longer has effect on
performance.

On the other hand, *IF* I remember the scene correctly then I'm
getting runtimes of 30 secs now. I'll do a proper comparison with a
couple of older SBCL's later.

Cheers,

 -- Nikodemus
Permalink | Reply | 0 comments |
headers
Edi Weitz | 17 Jul 2003 18:00
Picon

Bug in WITH-OUTPUT-STRING

Hi!

CMUCL, SBCL, and ECL all barf on this one

  (with-output-to-string (s nil :element-type 'character)
    (princ 3 s))

obviously because of the ELEMENT-TYPE keyword argument which should be
accepted if my reading of the CLHS is correct.

Cheers,
Edi.

-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
Permalink | Reply | 0 comments |

Gmane