From: Nicolas Neuss on
Christophe Rhodes <csr21(a)cantab.net> writes:

> Nicolas Neuss <lastname(a)kit.edu> writes:
>
>> As the optimization notes indicate, the reason is probably what Hugh
>> described earlier: there are assembler ops multiplying two 32-bit
>> numbers directly (same for division), 32-bit Forth uses those, while
>> SBCL does not and uses bignum arithmetic.
>
> Finally, a use for sb-regpair.
>
> Christophe

Ah, thanks! (Probably this SBCL contrib by David Lichteblau was what I
wrongly attributed to CMUCL and Raymond Toy.)

Nicolas
From: Hugh Aguilar on
I am trying to collect together all of the LC53 benchmarks mentioned
so far, but I'm confused because we seem to have used more than one
computer. I think these were all on the same machine:

SBCL (the original lc53.lisp): 197 seconds
SBCL (my version with types): 144 seconds
Clozure (with types): 330 seconds
gforth 67 seconds

And these were on a different machine, and involved the original CL
version that didn't provide type information:

SBCL 1.0.35.8 : 81 seconds
Allegro 8.2 : 194 seconds

Gforth 0.7.0 : 29 seconds
iForth 4.0.11 : 6 seconds

Would it be possible to obtain benchmarks all on one machine? Thanks
once again for all of your interest in LC53!
From: Helmut Eller on
* Hugh Aguilar [2010-03-12 22:37+0100] writes:

> Would it be possible to obtain benchmarks all on one machine? Thanks
> once again for all of your interest in LC53!

You could run it yourself :-P

But here we go:

The text was "abcdefghijklmnopqrstuvwxyz".

naive Lisp version:
SBCL 1.0.35.8 : 85 seconds
Allegro 8.2 : 193 seconds
CCL r13524M : 201 seconds

Nikolaus' version:
SBCL 1.0.35.8 : 60 seconds
Allegro 8.2 : 220 seconds
CCL r13524M : 319 seconds

Factor 0.92 : 110 seconds from http://paste.factorcode.org/paste?id=998

Gforth 0.7.0 : 29 seconds
iForth 4.0.11 : 7 seconds

Note that the declarations didn't help Allegro and CCL at all. I guess
that closing over seed was also not a good move. The Lisp version
should probably be written more like the Factor version without global
variables. I looks like the Factor version inlines everything into a
single (recursive) function. Allegro could probably do much better if
safety and debug were turned off.

After looking at the Factor version I also recognized that haw-far could
have been written more elegantly with POSITION-IF.

But yeah, that even Gforth seems out of reach is a bit embarrassing.

Helmut
From: Slobodan Blazeski on
On Mar 11, 10:18 pm, Hugh Aguilar <hughaguila...(a)yahoo.com> wrote:
> On Mar 11, 12:49 pm, Slobodan Blazeski <slobodan.blaze...(a)gmail.com>
> wrote:
>
> > I've installed VfxForth and gForth but I don't know how to load forth
> > file with them nor how time them.
>
> To load the files, type:
> include novice.4th
> try LC53.4th
>
> The TRY function is something I wrote; it is in novice.4th. It is like
> INCLUDE except that if the file is already loaded it will delete all
> that code before reloading it. This saves memory and also prevents
> getting a lot of redefinition warnings during compilation, which can
> be annoying.
>
> My LC53 contains ANS-Forth standard code for timing itself. It is only
> accurate to the second though. To get accuracy to milliseconds or
> microseconds you would need to delve into non-standard Forth. This
> isn't necessary with LC53 as it takes quite a long time to run.
> Besides that, super-accurate timing isn't very meaningful on a
> multitasking OS anyway.
No luck for me me :

bobi(a)deus:~$ gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
include novice.4th redefined try redefined Defer with defer
redefined IS with is redefined s>f redefined <= redefined >=
redefined d>= redefined d<= redefined d> redefined 2tuck redefined
NIL with nil redefined ," redefined { redefined field redefined
2nip redefined 0>= redefined ftuck redefined f0>= redefined f>=
redefined f2* redefined f2/ redefined pi ok
try LC53.4th redefined Debug? with debug? *** LC53 requires a 32-bit
system ***

LC53.4th:11: Aborted
w 4 <> [if] .( *** LC53 requires a 32-bit system ***) cr
>>>abort<<< [then]
Backtrace:
$7F2121302A78 thr


VFX Forth for Linux IA32
© MicroProcessor Engineering Ltd, 1998-2010

Version: 4.40 [build 0422]
Build date: 20 January 2010

Free dictionary = 7922527 bytes [7736kb]


include novice.4th
Including novice.4th
Err# -13 ERR: Undefined word.
Source: "novice.4th" on line 227
-> 1 floats constant f \ the size of a float
^
try LC53.4th
Including LC53.4th
Err# -13 ERR: Undefined word.
Source: "LC53.4th" on line 19
-> 123456789 seed ! ;
^
From: Nicolas Neuss on
Helmut Eller <eller.helmut(a)gmail.com> writes:

> * Hugh Aguilar [2010-03-12 22:37+0100] writes:
>
>> Would it be possible to obtain benchmarks all on one machine? Thanks
>> once again for all of your interest in LC53!
>
> You could run it yourself :-P
>
> But here we go:
>
> The text was "abcdefghijklmnopqrstuvwxyz".
>
> naive Lisp version:
> SBCL 1.0.35.8 : 85 seconds
> Allegro 8.2 : 193 seconds
> CCL r13524M : 201 seconds
>
> Nikolaus' version:
> SBCL 1.0.35.8 : 60 seconds
> Allegro 8.2 : 220 seconds
> CCL r13524M : 319 seconds
>
> Factor 0.92 : 110 seconds from http://paste.factorcode.org/paste?id=998
>
> Gforth 0.7.0 : 29 seconds
> iForth 4.0.11 : 7 seconds
>
> Note that the declarations didn't help Allegro and CCL at all.

SBCL does more type inference than Allegro or CCL, so I guess one would
simply have to introduce somewhat more declarations (e.g. byte in the
loop code) there to get also faster convergence.

> I guess that closing over seed was also not a good move. The Lisp
> version should probably be written more like the Factor version
> without global variables. I looks like the Factor version inlines
> everything into a single (recursive) function. Allegro could probably
> do much better if safety and debug were turned off.
>
> After looking at the Factor version I also recognized that haw-far could
> have been written more elegantly with POSITION-IF.
>
> But yeah, that even Gforth seems out of reach is a bit embarrassing.

Out of reach *on 32-bit architectures* (if we refrain from using the
special SBCL/sb-regpair branch)! On 64-bit architectures (which are not
that rarely encountered nowadays) I observe:

> naive Lisp version:
> SBCL 1.0.35.8 : 67 seconds
>
> Nikolas' version:
> SBCL 1.0.35.8 : 15 seconds

I would estimate that this would lie in the range of gForth. I cannot
test it, because when including LC53.4th I obtain the error message

*** LC53 requires a 32-bit system ***

Nicolas