Anybody willing to decipher Forth program
in [Lisp]
|
From: Duane Rettig on 13 Mar 2010 15:09 On Mar 12, 5:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: > > Note that the declarations didn't help Allegro and CCL at all. I haven't been following this thread too closely, and so I don't know if source code has been posted for whatever you're testing, but Allegro CL doesn't even trust declarations unless speed is declared to be greater than safety. So if you were going with the default optimization settings, I wouldn't expect declarations to help at all. Duane
From: Duane Rettig on 13 Mar 2010 15:20 On Mar 13, 2:15 am, Nicolas Neuss <lastn...(a)kit.edu> wrote: > Helmut Eller <eller.hel...(a)gmail.com> writes: > > Note that the declarations didn't help Allegro and CCL at all. > > SBCL does more type inference than Allegro or CCL, That's not necessarily true. SBCL, as part of its CMUCL tradition, has always been very good at type inferencing especially with numerics, but Allegro CL has also always done a lot of type inferencing, and has gotten better as time goes on. You just don't see so much of it because the compiler keeps much more quiet about its thinking than CMUCL and SBCL do; you have to use the :explain declaration to explicitly get the verbosity of the type inference and optimization decisions. 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. That is likely not necessary; it is usually a mistake to assume that if something doesn't run quickly that all that is needed is more declarations. Sometimes the declarations get in the way of the type inference, especially if there are mistakes in the declarations. I suspect that the real reason for the lack of improvement is something simple, like (as I explained to the OP) the fact that Allegro CL doesn't trust declarations unless (by default) speed is greater than safety. Duane
From: Hugh Aguilar on 13 Mar 2010 15:31 On Mar 12, 6:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: > The text was "abcdefghijklmnopqrstuvwxyz". This file is too short. There may be more than one key value that encrypts the file identically, and there is no guarantee that LC53 will find the same key value that was originally used; LC53 just stops on the first key value that decrypts the entire file in sync with the known plaintext (the high bit of each byte should be zero). So long as LC53 does find the correct value (123456789) though, then the benchmarking information should be correct. Use the function TEST-HOW- FAR to find out the minimum size needed for the file. It is a good idea to count how many visits there are to <FIND-SEED> and make sure that this value is the same (464723587) as what I got with my Forth program. It is possible to get the correct answer, but to still have a bug. This was messing me up on my assembly language version because I had the less-than coded as a greater-than. Bugs like this aren't normally going to happen in a high-level language, but a little verification never hurts. > Factor 0.92 : 110 seconds fromhttp://paste.factorcode.org/paste?id=998 This Factor time is way better than what I had found previously (9-min 14-sec on my laptop). Did you run your benchmark on a 64-bit machine? That might speed up the PRNG bottle-neck significantly. Another possibility is that Slava improved the compiler so that it would handle mixed-precision integer arithmetic more efficiently. He told me that he was going to do this, so maybe he did. Good for him! The program posted on factorcode is pretty much the same program that I wrote. The big difference is that Slava is using a different method for escaping out of <FIND-SEED> than I was using. I don't even know what CALLCCL is; that must be a new feature in the language since the time when I was working with Factor. Or maybe it existed then and I just didn't know about it. There are a lot of aspects of Factor that I don't know about! My method of escaping out of <FIND-SEED>, which is also used in the Forth program, is actually supposed to be for error-handling. I'm using it for success-handling, which has raised some eyebrows. I don't know of any other way to do this in Forth. In Factor, apparently, they do have more than one way to escape out of a recursive function. > After looking at the Factor version I also recognized that haw-far could > have been written more elegantly with POSITION-IF. One of my big problems with learning Factor was that I never learned Factor's extensive vocabulary. I was always writing code that worked, but which everybody complained was unidiomatic. I am used to Forth, which is a purposely thin language --- you are expected to write everything yourself (even very basic things like arrays and record). Factor is a fat language --- you are expected to learn the vocabulary and use already-provided solutions rather than do things your own way. My tendency to just write code and ignore the documentation resulted in my getting criticism for being unidiomatic --- this is at least part of the reason why I chilled out on Factor. By switching to Common Lisp though, I might be jumping out of the frying pan and into the fire! :-) PLT Scheme seems to be a purposefully thin language though, so that might be more Forth-like. > But yeah, that even Gforth seems out of reach is a bit embarrassing. I always considered GForth to be a toy compiler because it is written in C. It does generate remarkably fast code though, so maybe I should take it more seriously. I have only recently begun using it at all. I have found it to be about two or three times slower than SwiftForth. By most accounts, SwiftForth is two or three times slower than VFX or iForth, but I've never used either of those compilers, so I can't say according to my own experience.
From: Nicolas Neuss on 13 Mar 2010 15:36 Duane Rettig <duane(a)franz.com> writes: >> >> SBCL does more type inference than Allegro or CCL, > > That's not necessarily true. SBCL, as part of its CMUCL tradition, > has always been very good at type inferencing especially with > numerics, but Allegro CL has also always done a lot of type > inferencing, and has gotten better as time goes on. You just don't > see so much of it because the compiler keeps much more quiet about its > thinking than CMUCL and SBCL do; you have to use the :explain > declaration to explicitly get the verbosity of the type inference and > optimization decisions. > >> 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. > > That is likely not necessary; it is usually a mistake to assume that > if something doesn't run quickly that all that is needed is more > declarations. Sometimes the declarations get in the way of the type > inference, especially if there are mistakes in the declarations. I > suspect that the real reason for the lack of improvement is something > simple, like (as I explained to the OP) the fact that Allegro CL > doesn't trust declarations unless (by default) speed is greater than > safety. Thank you for the explanation. Yes, the optimized code which I posted was optimized using the optimization notes of the SBCL compiler, so we have to be careful not to draw conclusions about other the other implementations (Allegro, CL) without investing a similar optimization effort (and expertise - you have to know the details you mention above) there. Nicolas
From: Hugh Aguilar on 13 Mar 2010 15:54
On Mar 13, 3:23 am, Helmut Eller <eller.hel...(a)gmail.com> wrote: > * Slobodan Blazeski [2010-03-13 10:40+0100] writes: > > > No luck for me me : > [...] > > LC53.4th:11: Aborted > > w 4 <> [if] .( *** LC53 requires a 32-bit system ***) cr > >>>>abort<<< [then] > > I think you could just delete that line; I'm pretty sure that the result > would be the same on a 64bit machine. I put that line in there to prevent people from using a 16-bit Forth system, which definitely won't work. I think LC53 will work on a 64- bit system, so you could change the <> to < to accept everything but 16-bit systems. I don't actually have a 64-bit Forth system though, so I can't test this myself. > > 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 to load the float stuff first: > include /usr/share/doc/VfxForth/Lib/Ndp387.fth > include novice.4th > include LC53.4th The Forth standard has a core vocabulary, and then several extension vocabularies --- one of which is the floating point stuff. This was done because Forth is used on a wide variety of platforms, from the 8051 up to the DEC Alpha. A lot of those small platforms aren't going to support things like floating point. I mentioned this in the documentation. It is kind of sticky situation because a lot of people would get discouraged when the program doesn't compile, and they won't look into the problem any further --- I would feel the same way if I were to be given a Lisp program that didn't compile. Some of your results from Forth compilers have been totally screwed up. I don't know what is causing this. I tested the program on GForth and SwiftForth and it ran just fine. My guess is that you are using a 64-bit Forth system and it is not calculating PRNG correctly. I don't have a 64-bit system of my own to test this hypothesis with. Try again with a 32-bit system and see if that works. As I said above, Forth is designed to work on a wide variety of platforms. This makes it difficult to write a Forth program that will run anywhere. On the plus side though, you can get Forth to run on most anything. By comparison, there aren't many 8051 versions of Lisp available! :-) |