From: Nicolas Neuss on 11 Mar 2010 16:48 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 12 Mar 2010 16:37 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 12 Mar 2010 20:33 * 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 13 Mar 2010 04:40 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 13 Mar 2010 05:15
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 |