Re: Guile and speed (Re: [Freeciv-Dev] Adding scripting language)
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Artur Biesiadowski wrote:
>
> Lalo Martins wrote:
>
> > Actually Guile is very good at that; it's awfully slow (at least
> > with the version people have today) to _load_ code, and to start
> > itself, but once code is `memoized' it runs as fast as any
> > partially compiled stuff - like perl or python, and faster than
> > java in my experience.
>
> I'm not sure for what types of programs have you used these languages,
> but my experiences are totally different. As all these languages'
> strengths lies in different areas, I have to decide on some area - I've
> chosen one that none of them is designed for - number crunching.
>
> Attached are sources for java and guile. I don't know if I haven't made
> any major performance mistake in guile - if so then please correct me,
> I'll rerun the tests.
>
> Test is very simple - in fact it could be solved at compile time. I
> thought that guile will show it's power here - smart inlining is one of
> functional languages domains. I've done same program in perl and in C
> for comparison. Here are the results (measured with time - so overhead
> of loading is included, but I don't think it is important; also
> computation starts with small value (1000) to give everybody chance to
> optimize function)
>
> C 9,7s
> java 26,0s
> perl ~3270,0s (give up after 5th step, which gave 30s, so it is about
> 109x as much..)
> guile ~12200,0s (give up after 5th step, with 112 s)
>
> Before somebody will jump on me that guile isn't fortran, JAVA IS
> NEITHER, NOR PERL. I'm sure that scheme/guile has programming constructs
> that make coding easier/faster maybe even more readable(I doubt this
> one:), but it is slow as a dog. 500x slower than java on simple algo -
> I'm afraid to think about more complicated things...
Java is actually fairly well designed for numerical algorithms.
But, you know what they say... lies, damned lies, and statistics.
Which JVM are you using for this test? I'm guessing that you're using
an extremely fast one., because I wouldn't expect a result anything like
that fast.
Running the test on a machine I have access to, I get a result of 90s!
And this is on a Pentium II 350, using jikes to compile and kaffe to run
it. So, I'm guessing you're using a high-quality JIT - probably
microsoft's or symantec's. Those buggers are superb, and will have
JITed the java into a tight assembler loop almost as good as the C one.
Number crunching is probably not a relevant test for what we're trying
to do - although devising a good one would be hard.
All that aside, yes, you're right, Java is a fast language. Java wins
here because it is statically typed - arithmetic will always be faster
in a statically typed language.
Jules
|
|