On Wed, Aug 12, 2009 at 8:02 AM, Luc Prefontaine<lprefonta...@softaddicts.ca> wrote: > C++ has nothing to do with my previous statement. C++ is object oriented. > It's plagued with similar > problems than Java in terms of performance. > > I was talking about writing the machine code by hand, not relying on a > compiler's optimizer to do so. > > C is a bit better than C++ but if you use a cross platform compiler (like > GNU) and you end up > on a platform for which not all the optimizations have been tweaked into the > compiler you are lost... > If you write in C and are concerned by performance, you should at least look > at the machine code > generated by the compiler to make sure that it does the job correctly. > > Writing machine code directly, you can tune your code for your specific > needs taking into account the available hardware optimizations > even on RISC type architectures, you need to read the hardware specs.... > > Of course this alternative is non-portable but it will be faster than Java > or C#
I assume that you have more knowledge about coding at that level, since I personally only brushed it, so take it with a grain of salt. The reference to C++ in the linked question is a bit unfortunate, but let's have a look at these two about the Colt library: http://forums.sun.com/thread.jspa?threadID=241797&tstart=120945 (last comment, and notice the date) http://acs.lbl.gov/~hoschek/colt/ (same library, different performance quote, see again the date) Colt targets a historically performance sensitive area (large scale number crunching), and Java did exceedingly well compared to the traditional tools (hand tuned Assembler and optimized Fortran). At the time the articles were written (8 and 4 years ago), Java didn't do better than the traditional tools, but came close. And that was 4.5 or more JVM (incl. JIT) generations ago (1.4.2, 1.5, 1.6, 1.6u10 (1.7 is the half)). > If your algorithm is single threaded and performance is a must then even Java > should be tossed away. > Any native machine code equivalent would be faster than Java... I think your first statement shouldn't have been phrased like an invariant. The condition is not precise enough to come to the given conclusion. (I know you used 'should', still..). I don't really want to get into a fight over the second statement, because I basically agree with you. But at some point that statement is only of theoretical value IMHO. And not only because creating that piece of software might have a prohibitive price tag attached and it might not be maintainable (your arguments). But also because you're asking a human to figure out an equivalent or better transformation of a program based on rules (some of which are implemented in the JIT compiler). I just doubt that _on average_ the human will perform as well at the task as the JIT compiler. And the larger your codebase for the library, the more that ratio is going to change in favor of the JIT compiler (same argument as for STM, and GC). But well, I guess we agree about the basic message ;) Cheers, Daniel PS: I didn't find any recent articles about how the Colt library or similar number crunching tools running on the JVM compare to Assembler and Fortran. I'd be interested in links... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
