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 -~----------~----~----~----~------~----~------~--~---