On Jan 11, 9:41 pm, Mark P <pierh...@gmail.com> wrote:
> The programs I write perform applied mathematical
> optimization (using mainly integer arithmetic)
> and often take hours (occasionally even days)
> to run. So even small percentage improvements
> in execution speed can make a significant
> practical difference. And large problems can use
> a large amount of memory - so memory efficiency
> is also a concern.
Would you happen to know exactly what the bottlenecks in your
applications are? Is performance bound by integer arithmetic, by
memory bandwidth (due to lack of temporal locality), or by memory
latency (due to lack of spatial locality)? It's important to know
because garbage collection influences performance differently
depending on the performance bottlenecks in your application. For
example, if you're creating a lot of small objects in your C++ code
anyway, you're still calling destructors a lot and so replacing C++
with a garbage-collected language may even _improve_ performance. (I
recall this being the case with a particular C++ vs. OCaml benchmark,
as the OCaml GC implementation used had soft real-time guarantees
whereas the C++ destructor chain called at the ends of key functions
would cause significant latencies.)
> There are three key factors that still give me
> hope:
>
> 1. Some of the algorithms I use have the potential
> to be parallelized. I am hoping that as the number
> of cores in PCs increase, at some point Clojure's
> performance will beat C++'s due to Clojure's
> superior utilization of multiple cores. (Any ideas
> on how many cores are needed for this to become
> true?)
You could use OpenMP to parallelize your C++ code without much effort,
and it will be backwards portable to single-core machines. Getting
performance to scale nicely takes a little more effort with OpenMP.
Clojure needs to build up more infrastructure before parallel
programming for performance becomes practical (how's that for a tongue
twister! ;-P ), but building that infrastructure yourself can be fun
and educational. I would do it myself if I had the time. (I have a
fair amount of experience in parallel programming and consider myself
qualified at least to evaluate a parallel programming framework
design.)
> 2. The JVM is continually being improved. Hopefully
> in a year or two, the performance of HotSpot will be
> closer to that of C++. (But maybe this is just
> wishful thinking.)
Again, this depends on the bottlenecks in your app. Remember also
that C++ might be / is (I'm not sure -- you'll have to check this)
_managed_ code (i.e., running under the .NET runtime) in Windows.
Many developers seem to be willing to endure a small-percentage
performance hit in order to make debugging and deployment easier.
I've heard senior Windows engineers say that _every_ Windows app
should run with a tracer so that on a crash they can get a trace of
the last 30 seconds of the program.
> If all else fails, maybe I could use Clojure as a prototyping
> language. Then when I get it right, I code up the actual
> programs in C++. But probably a lot would get lost in
> the translation from Clojure -> C++ so would it be worth
> it?
The alternative mentioned in the discussion above was to use Clojure
as a coordination (a.k.a. "scripting") language for Java or C(++).
Combining high-level and low-level languages works great as long as
you set up the interface right (e.g., making it clear where
immutability is violated and avoiding errors that result from certain
Clojure operations assuming immutability). We use Lua as a
coordination language for our C library OSKI (bebop.cs.berkeley.edu/
oski) and it works just fine; it expresses an algebra of sparse matrix
transformations. I prefer Lispy languages but that's just my
taste ;-)
> I'd love to be convinced that Clojure is a viable choice,
> but I need to be a realist too. So what do people think?
> How realistic are my three "hopes"? And are there
> any other performance enhancing possibilities that I
> have not taken into account?
I've found that concerns about performance aren't productive unless
they are backed up both by performance models (i.e., expectations of
performance characteristics) and measurements. Also, you'll want to
consider your own productivity as a programmer: on the one hand,
rewriting everything in Clojure or any other language will take a lot
of time, and on the other, maintaining an application written in a low-
level language like C++ also will take a lot of time. The combination
of high-level coordination language and low-level performance language
is perhaps the best both for productivity and for performance:
Productivity:
* You can add the high-level coordination functions separately and
incrementally, instead of rewriting the whole application from
scratch.
* It's much easier and faster to add new higher-level functionality.
* Using two languages forces you to make a clean divide between high-
level interface and low-level implementation, which is good for
software maintenance.
Performance:
* Splitting up the app into "productivity" and "performance" layers
forces you to identify performance bottlenecks, which helps you
understand and improve performance better than if you just had a blob
of C++ to manage.
* Performance-oriented code is often simple and coordination code is
often complex. Complex code written in a low-level language is often
buggy, which can hurt performance (via memory leaks) or even make your
app crash ("infinitely slow" means "infinitely bad
performance" ;-) ).
I can find data on performance of parallel apps under low-level and
higher-level languages if you are interested.
mfh
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
