There was a bug in the 32-bit compiler that was preventing Slava's LC53 from running, but that has been fixed in the latest release. Here are the times:
Factor (Slava's)-- 11 minutes 14 seconds http://paste.factorcode.org/paste?id=998 Factor (mine) ----- 9 minutes 14 seconds www.rosycrew.org/LC53.factor SwiftForth ----------------- 22 seconds www.rosycrew.org/LC53.4th assembly-language --------- 17 seconds It is unclear why Slava's Factor program is slower than mine, but I suspect that the DIP in HOW-FAR is the culprit. Slava assures me that an upcoming release of Factor (within a few weeks) will be more oriented toward integer-arithmetic and should run faster. In the meantime, I would like to port LC53 over to the following languages for comparison. If anybody here has experience in any of these languages (or in any languages not listed), please volunteer to do the porting. Java Clojure Scala GCC Lazerus Pascal Erlang Haskell Python Ruby Visual C++ Visual Basic My Forth program should run under any ANS-Forth system, but SwiftForth is the only one that I use. If anybody uses iForth, VFX, BigForth, etc., we can test those as well. You may need a calender to time the Python and Ruby programs, but these are popular languages so we should include them. I'm going to do the Erlang, although anybody else who knows Erlang is welcome to do so also (this will actually be my first Erlang program, so it might take me a while to write it). The LC53 search uses the HOW-FAR value to determine if it should test a 1 or a 0 first. Considering that the HOW-FAR value is typically in the range [0,3], the two values being compared are often equal. In this case, LC53 arbitrarily chooses to test 1 first and 0 second. In the Erlang program, it will test both 1 and 0 simultaneously. Given a computer with multiple processors, this should result in a hella fast program, possibly even faster than the assembly-language program. We will see. Does anybody here have access to a computer with multiple processors? If so, then we can use that computer as our official testing platform for all of the languages. This will tilt the table toward any languages (Erlang, Clojure, Haskell) that take advantage of multiple processors. That seems fair to me --- any serious effort at encryption cracking is going to involve using concurrency. > Message: 4 > Date: Tue, 20 Oct 2009 23:16:19 -0500 > From: Slava Pestov <[email protected]> > Subject: Re: [Factor-talk] LC53 encryption cracking > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Oct 20, 2009 at 8:58 PM, Hugh Aguilar <[email protected]> > wrote: >> In regard to Factor, all that I did was inlining as I wasn't able to >> figure out >> what Slava was talking about in regard to rewriting HOW-FAR. This shaved >> off >> about 3 minutes from the Factor time, which was pretty good, although not >> as >> significant as the effect on Forth. > > Here is a version of LC53 that doesn't use dynamic variables: > > http://paste.factorcode.org/paste?id=998 > > It also uses TYPED: in one place to make the Factor compiler generate > a specialized 'find' loop over byte arrays, instead of dispatching on > each iteration. I got a 30% speedup with these changes, they also have > the nice effect of making the code simpler. > > Once Factor's compiler has support for native-size integers, it will > be able to run this program much faster without any changes to the > code, since it will not need to allocate bignum objects and dispatch > between fixnum and bignum types anymore. > > On the other hand, I find the Forth version of the benchmark to be > completely unreadable. > > Slava ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
