Anybody willing to decipher Forth program
in [Lisp]
|
From: Hugh Aguilar on 11 Mar 2010 14:59 On Mar 11, 3:02 am, Nicolas Neuss <lastn...(a)kit.edu> wrote: > But before starting premature optimization we should really have > "test.txt" so that we can compare the output and the CPU time with what > was written before: I forgot to include TEST.TXT in the novice package, although it is in the slide-rule package. Actually, *any* text file will work. The program assumes that the file is 7-bit ascii --- the known plaintext is the upper bit of each byte, which is assumed to be zero. The program should run exactly the same no matter what the prose in the text file is. Your test file, which was the alphabet, is too short however. There may be two or more keys that encrypt the file identically. Run the function TEST-HOW-FAR to find out how long your test file has to be to obtain a unique key. Also, note that my program has a DEBUG? compiler switch. If this is turned on, the program will count how many visits were made to <FIND- SEED>. A good indication that your program is doing the same thing as my program, would be that the number of visits is the same. Thanks for the work Helmut Eller and Nicolas Neuss! This will be an interesting way to learn Lisp --- to study my own program written in Lisp. That is not an opportunity that most students get! :-)
From: Nicolas Neuss on 11 Mar 2010 15:51 Tamas K Papp <tkpapp(a)gmail.com> writes: > If you are in the benchmarking mood, would you try this on Clozure CL? > I keep hearing good things about it. Just throwing the code as it is > (ie with declarations you used for SBCL) at it would be informative. 64bit-Clozure takes 157 seconds on my AMD64 machine, i.e. it is much slower. But here is another interesting (and somewhat disappointing) data point: On my 32bit x86 laptop, everything is much slower: SBCL (the original lc53.lisp): 197 seconds SBCL (my version with types): 144 seconds Clozure (with types): 330 seconds 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. So, bad luck on 32 bit architectures, at least with SBCL and Clozure. [I dimly remember that Raymond Toy once implemented these for CMUCL, but I might be wrong.] Nicolas
From: Hugh Aguilar on 11 Mar 2010 16:18 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.
From: Christophe Rhodes on 11 Mar 2010 16:29 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
From: Nicolas Neuss on 11 Mar 2010 16:40
Nicolas Neuss <lastname(a)kit.edu> writes: > SBCL (the original lc53.lisp): 197 seconds > SBCL (my version with types): 144 seconds > Clozure (with types): 330 seconds For completeness: gforth on my laptop needs 67 seconds, probably iforth would be even faster. Nicolas |