Hey, I translated Slava's program in Haskell. You can find it here : http://paste.factorcode.org/paste?id=1019 Please note I have very little haskell experience and it's mostly rusty, so for all haskell pros here, please don't cry your eyes out! But please annotate :) I had trouble with types so I had to cast everything to Integers before doing Bits operations. That can probably be optimized.
I couldn't download the test file from rosycrew.com (site is down?) so I benchmarked it on a random short file. $ ghc -o main LC53.hs $ time ./main ./main 988,61s user 4,66s system 94% cpu 17:28,24 total Slava's factor version runs in 600 seconds on the same file. Also, I'm running on : Linux zouglou 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux, with only 1 core On Tue, Oct 27, 2009 at 8:37 AM, Hugh Aguilar <[email protected]> wrote: > 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 > -- Jon Harper ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
