Hugh,
I would look into porting your LC53 to Clojure and Java
Regards,
Emeka
On Mon, Oct 26, 2009 at 11:37 PM, 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
> <http://www.rosycrew.org/LC53.4th%0Aassembly-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
>
------------------------------------------------------------------------------
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
