On Aug 10, 11:08 pm, fft1976 <fft1...@gmail.com> wrote:
> On Aug 10, 2:19 pm, Jonathan Smith <jonathansmith...@gmail.com> wrote:
>
> > 1.) use something mutable
> > 2.) unroll all the loops (mapping is a loop)
> > 3.) try not to coerce between seq/vec/hash-map too much.
>
> Are you saying this w.r.t. my code or in general? If the former, be
> specific, better yet, show us your code. I avoided (1) on purpose, as
> I explained. The other choices I think are reasonable already. It
> makes no sense to unroll a procedure that runs once, or macro-ify
> something that gets inlined.
>
w.r.t your code.
At compilation you know a lot about the computation you are doing, so
there is a lot of room to unroll and 'cheat' instead of actually
looping. Obviously you won't bother optimizing the offset momentum
part of the code, but you will optimize your simulate-1 function a
lot.
The way your code is setup, you will spend a lot of time in funcall
overhead just because you used a lot of functions instead of doing the
calculation in bigger chunks. You can still have an elegant
implementation and good performance if you definline a few things.
Also it is good to put local constants in a let form at the top of the
file, they are faster to access by quite a bit.
And a last thing is that if you hack your clojure's implementation of
nth to inline the 3ary version of nth, you will see a big speedup in
the destructuring binds that you use in your 3-d library.
> > in real world, stuff like the shootout is pretty useless, as generally
> > you'd reach for a better algorithm rather than implementing the
> > shackled, crippled, naive algorithms that the benchmark forces you to
> > implement.
>
> Some of us prefer facts and measurements, flawed as they may appear to
> blind faith.
>
I kind of approach it as knowing that I get better abstraction from
lisps and knowing that I will pay the price somewhere down the line.
(most of the time in heavily looping numerics). :-)
> Many of the Shootout benchmarks are quite contrived, I agree, but the
> N-Body benchmark is nice. I think it started elsewhere.
>
> You'll have a hard time coming up with a better algorithm, unless you
> are familiar with the field of numerical solutions of ordinary
> differential equations. There are Runge-Kutta methods that can give a
> constant factor speed-up, but they are just as easily implemented in
> any other language.
I dunno, manipulating systems of equations seems to be one of lisps'
strong suits.
My current solution (I wrote it a few months ago) is up on github
here:
(It isn't as good as Andy's, i wrote it mostly to test a def-inline
that I wrote).
http://gist.github.com/165670
As I said, using mutable objects and loop unrolling will give definite
performance advantages.
My thought was to use a regular old java array and write accessor
macros to slot positions (similar to a struct in CL), but I never got
around to implementing it as it started to seem like all too much
mental masturbation.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
