On Jul 13, 5:51 pm, Morgan Allen <alfred.morgan.al...@gmail.com>
wrote:
> > It's definitely not necessary to implement the bulk of your code in Java to
> > get performance. On the other hand, getting performance out of Clojure can
> > be tricky.
>
> Well, yeah, that's the thing- getting maximal performance out of
> clojure seems to require a degree of expertise and patience that I
> certainly don't possess and that seemingly few, in practice, do: I
> tend to be skeptical of claims that clojure can *always* be made to
> run as fast as equivalent java code when much more proficient
> programmers than myself struggle to get 1/6th of equivalent
> speed...http://gnuvince.wordpress.com/2009/05/11/clojure-performance-tips/
>
Honestly, you think about it and *of course* Clojure can be made to
run just as fast as equivalent Java. Clojure is written in Java, so
equivalent Java would be Clojure... admittedly a bit tautological. :-)
The question then, would be, 'can I write Clojure that is as powerful
as Clojure and as fast as less powerful (and more verbose) Java'. I
personally think that the answer is that you can, although I have no
way to prove it (and a lot of it relies on Hotspot and similar JVMs
being very very clever...)
I read that wordpress blog and after doing a bit of analysis (it took
me a couple of evenings) I have a patch that 'fixes' some of the
arithmetic operators and destructuring bind speed issues.
On my version of clojure (+ 1 2 3 4) is == (in terms of speed) to (+ 1
(+ 2 (+ 3 4))). (They are exactly the same code).
I also have a destructuring bind that is the same speed as using
'manually destructured' vector access.
They were both relatively simple changes. (I ain't no java expert
here!)
To that point, I think a big advantage that Clojure has in terms of
optimising for speed over something like a Common Lisp is that the
default library is relatively small (and the implementation of such
relatively accessible). This means if I *really* need something to be
faster, I can go into core.clj and hack at it a little bit and see
what might end up being a better implementation (as opposed to Common
Lisp where I might end up dredging through an incomprehensible guru-
level 'assembly VOP emitter' (whatever that even is) that 'just
works'). With Clojure I (at worst) end up looking at java or fairly
well documented asm.
> ...1/6th native speed is fine for my present purposes, but I don't
> want to rewrite my vertex/normal transforms or A* pathfinding in
> clojure unless and until I'm a lot more confident of my ability to
> tease out performance.
>
I personally wouldn't rewrite perfectly good Java code that is already
written and tested. I mean, ask yourself 'how would this benefit from
being rewritten in Clojure' and if the answer is, 'it would be in
clojure' (rather than, idk, 'my genetic algorithms would run faster',
or 'the code will be much more reliable and easier to understand' or
'I will have an easier time unit testing it' or 'I really want to take
advantage of STM'), you might not want to rewrite it.
Is probably better to just import it and maybe write macro wrappers
for appropriate things (not because you have to, just for ease of
use).
> > NetBeans, which I use, does better at this. You have to restart the REPL
> > after any change to Java classes, which is a nuisance, but you don't have to
> > restart the IDE or muck with anything else (project libraries, classpath).
> > Even if you have separate projects and some are dependencies of others, and
> > all are undergoing active development, you just have to reboot the REPL
> > after changing Java code. Changing Clojure code, even in a separate project
> > that's a dependency of your main project, can typically be handled with a
> > load-file of the changed file. Only if your refactoring moves a Clojure
> > function or other object from one namespace to another (same or different
> > project) do you generally have to restart the REPL, since it won't let you
> > intern a name in a package that imports the same name from another one, and
> > uninterned symbols won't go away. It's a good idea to occasionally restart
> > your REPL anyway to clear out cruft and avoid having a running image that's
> > become dependent on something that isn't in your code base, and also to find
> > anywhere where you are missing forward-declarations.
>
> I actually couldn't get the Netbeans plugin REPL to run at all, but
> that was a couple of months back... I might try again with the (more
> recent?) version. That does sound like a very handy dev system.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
