On Feb 24, 2013, at 8:46 AM, Marko Topolnik wrote:
> On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote:
> FWIW, I, for one, am really glad that Clojure allows us to select precisely
> which nice tools we want (have to) throw away (persistent data structures,
> dynamic typing, synchronized) when the need arises. Reminds me of the "don't
> pay for what you don't use" motto of C++ except done right (i.e. the other
> way around, because you don't want to pay wrt simplicity rather than
> performance, cf. "premature optimization…")
>
> Don't you think that the real goal is to have performant idiomatic code? That
> was certainly the aim of the Common Lisp community of the '80s and, from what
> I hear, idiomatic Haskell is a performance devil as well. Static typing isn't
> just about type safety, after all; it's also about performance. When the
> compiler knows everything about your code, it has a much easier time
> producing killer machine code.
For both Common Lisp and Haskell, the most straightforward code you would
typically write for many problems allocates more memory than code specifically
written to avoid allocating memory, and if other things are equal (which they
often aren't), code that allocates less memory can be faster.
At least for Common Lisp, it can often generate faster code with appropriate
type declarations, especially for arithmetic.
Take a look at any of the Common Lisp or Haskell submissions to the Computer
Language Benchmarks Game web site, and you will see some programs that are
nowhere near what people typically write in those languages, and certainly not
what people would write if they weren't concerned with squeezing out the last
drop of performance. Lots of mutable data structures in both, and lots of type
declarations in Common Lisp.
Common Lisp (SBCL) vs Java
http://benchmarksgame.alioth.debian.org/u64q/lisp.php
Haskell vs. Java http://benchmarksgame.alioth.debian.org/u64q/haskell.php
Then again, even for C and Java programs on that site, people will do some
pretty amazing tricks they wouldn't normally do in those languages, either,
e.g. performing I/O in parallel with computation, even when it makes the
computation code more complex to give the correct answer.
For Clojure, I'd recommend doing the same thing I'd recommend in just about any
language: write the code that occurs to you first to get it correct. If it is
fast enough for your purposes, whatever those are, you are done. If not, use a
profiler to see where most of the time is spent, and then start working on
optimizations in the same language if they are worth your time to do so. If
they get too difficult in the original language, dropping down to a lower-level
language (e.g. Java, C, assembler) is often a choice you can make, depending
upon your deployment restrictions.
Andy
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
