Microbenchmarks are as useful as any other type of benchmarking. The problem is, they are very very very difficult to get right. You need to do a lot of work to validate the results you get from any benchmark, large or small. I've missed the beginning of the conversation so I never saw all of the code but then maybe it was never published. My instinct tells me that this is yet another naive attempt at benchmarking.... so be it, this is how we learn. BTW, even the experts get it wrong.. for example, SpecJMS is a benchmark for JMS implementations. It's a great way to measure the disk speed on your machines ;-) IOW, it's yet another busted benchmark published by an organization that is dedicated to providing our industry is a set of standard benchmarks. Lesson learned, know where your bottleneck is and understand if it's where it should be 'cos you're always going to have one.
I can show you plenty of problems where the language of implementation can never be an issue w.r.t. performance. Choosing a language based on "performance safeness" is the ultimate premature optimization. There are just so many other factors that need to be considered. Regards, Kirk On Jul 29, 2010, at 7:47 AM, Alan Kent wrote: > On 29/07/2010 3:05 PM, Reinier Zwitserloot wrote: >> That's not to say what you're doing is at all useful, really. You >> can't microbenchmark code for the JVM. End of discussion. Stop doing >> it. >> > > Agreed completely. Microbenchmarks are interesting, but dangerous to rely > on. It was a loop run 100,000,000 times so I would have hoped the JIT would > have jumped in, but it is one small part of an overall problem. > > I have a choice between writing something in C++ or Java (maybe Scala if I > can swing it). My take on the state of the universe is C++ is safer from a > performance perspective (for my project which has high throughput > requirements), Java is safer from a speed of code development and > maintainability perspective. I don't need lots of memory allocations, so the > GC benefits of Java are not relevant. Java also has issues being a less > friendly citizen on a box shared with other processes (more memory hungry). > > > But thanks Casper, sun.misc.Unsafe was an interesting find that I never knew > about! > > Thanks to everyone else for contributions. Interesting stuff. > Alan > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
