tag:blogger.com,1999:blog-33042626.post1289325364669233139..comments2008-04-29T13:31:40.134-07:00Comments on Paul Buchheit: Optimizing everything: some details matter a lot, most don'tPaul Buchheithttp://www.blogger.com/profile/08521809827597159995noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-33042626.post-10887892070064224162007-06-09T21:38:00.000-07:002007-06-09T21:38:00.000-07:00Paul Buchheit wrote As for the flags, if someone c...Paul Buchheit wrote <I>As for the flags, if someone can demonstrate a real performance improvement, then I'm interested...</I><BR/><BR/>afaict the same applies to<BR/>-server <B>-XX:CompileThreshold=1</B><BR/><BR/>Java Elapsed 6.734<BR/>Java Elapsed 3.988<BR/>Java Elapsed 4.033<BR/><BR/>and just <BR/>-server <BR/><BR/>Java Elapsed 4.893<BR/>Java Elapsed 3.995<BR/>Java Elapsed 3.996<BR/><BR/><I>and of course those times vary</I>Isaac Gouyhttps://www.blogger.com/profile/02902123247585964087noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-20334186718682350722007-06-08T13:30:00.000-07:002007-06-08T13:30:00.000-07:00>Fix them, in the order of highest benefit/cost to...>Fix them, in the order of highest benefit/cost to lowest<BR/><BR/>Paul, it looks to me like a classical _optimization problem_ and you're solving it the wrong way around :) <BR/>You've got those task with their costs and benefits, and you've got a limitated resource - time. It's a 0-1 kanpsack problem! So why not solve it with dynamic programming as opposed to greedy algorithm you're using right now?<BR/><BR/>Welcome to the meta-optimization world...Anonymoushttps://www.blogger.com/profile/04743746440345628118noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-64393748266045630372007-06-08T06:30:00.000-07:002007-06-08T06:30:00.000-07:00Paul,Interesting article. I have used OptimizeIt, ...Paul,<BR/><BR/>Interesting article. I have used OptimizeIt, JProbe profilers to profile J2EE applications. I usually face a problem when I try to do cost vs benefit analysis for J2EE applications<BR/><BR/>For example, usually profilers suggest the following approach for profiling J2EE applications<BR/><BR/>a) Find out hotspot methods or statements (expensive methods) using profiler.<BR/>b) Try to fix them by replacing the hotspot method with an efficient one.<BR/>c) Profile again and see the top most method will be different one.<BR/><BR/>After step c, if the application is load tested to check how much throughput improvement is achieved because of a fix to the top hotspot method, there will be either a positive improvement or no improvement at all.<BR/><BR/>Most of the times it's very difficult to estimate cost(algorithmic) of one request going through multiple layers using asymptotic analysis. <BR/><BR/>My biggest problem is to determine max throughput that I can expect to achieve with my code improvements, before actually putting together code improvements. <BR/><BR/>There is a way to find this out at least in J2EE world where applications are usually built using layered architecture. I can find out throughput (pages/sec) of a system by disabling layers one by one. I can also find out which layer needs attention first and use profilers to profile and fix problems. <BR/><BR/>The disabling of a layer can be done by introducing a cache in front of that layer. I wrote an <A HREF="http://pbn.weblog.com/2007/6/Effective-Profiling-8.html" REL="nofollow">article </A> about it.<BR/><BR/>I had used the above method to categorize which layer (UI(server-side), Business, DTO, DA) contributed to system performance cost and introduce code improvements per layer.<BR/><BR/>It's one more way to approach optimization and do cost vs benefit analysis for J2EE applications. <BR/><BR/>We can definitely estimate cost using asymptotic analysis if we can isolate performance problems to a specific algorithm.<BR/><BR/>My 2 cents.Babuhttps://www.blogger.com/profile/04111724691227318397noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-4469154647560558532007-06-08T04:28:00.000-07:002007-06-08T04:28:00.000-07:00Ben, thanks for the thoughtful comment.I added a n...Ben, thanks for the thoughtful comment.<BR/><BR/>I added a note about the 80/20 not always applying.<BR/><BR/>I realize that a lot of the attention comes from the c++/java aspect of it -- people get very religious about their languages for some reason.<BR/><BR/>As for the flags, if someone can demonstrate a real performance improvement, then I'm interested (and in fact I noted a few of those flags), otherwise they are irrelevant.Paul Buchheithttps://www.blogger.com/profile/08521809827597159995noreply@blogger.comtag:blogger.com,1999:blog-33042626.post-83158830255397681342007-06-08T04:13:00.000-07:002007-06-08T04:13:00.000-07:00Paul,Obviously, talking about optimization tends t...Paul,<BR/><BR/>Obviously, talking about optimization tends to bring up emotion in a lot of people, and adding a language comparison in just adds gasoline to the fire.<BR/><BR/>I think something important to recognize, and something you appear to overlook in your blog, is that optimization in different fields means different things. Specifically, typically in domains where performance (size & space) is truly important (games, HPC, embedded), a lot of the classic truisms don't hold.<BR/><BR/>The most obvious example is the 80/20 rule -- generally performance profiles are <I>much</I> flatter, as the easy things have already been done (or instinctively avoided). See Tim Sweeney's talk (http://programming.reddit.com/info/zshf/comments) for a mention of this. As well, things causing a slow-down are often very difficult to detect (cache misses, excessive synchronization, excessive inlining).<BR/><BR/>Second, waiting until the 'end' to profile & optimize is often too late, for multiple reasons. You may need to change your whole design (or language, or art pipeline, or whatever) if you originally made a poor, non-performant choice. Or you may just not be able to squeeze out that 50% faster you suddenly realize you need, three weeks before your shipping date.<BR/><BR/>One final note regarding the truism to always 'profile before you optimize': this is, in general, good advice, and is much too often ignored, but it shouldn't be blindly followed. How can you consider performance at the design stage with profiling? Generally you need to go with experience, algorithmic complexity analysis, and mini-tests.<BR/><BR/>On a separate issue, regarding people nit-picking compiler flags and such, I think that's more a case of your mistake having raised warning flags (along with the, at least from a C/++ perspective, inflammatory title). Small changes can have big results on micro-benchmarks, and some setting you consider arcane may be standard for someone who cares about that environment. Combined with an apparent agenda, people get worked up and loud. Imagine I set the JIT threshold to 1 million, and used BigNums, and wrote an article about how crappy Java still was. (I'm not saying this is what you did, I'm just pointing out why your mistakes may have caused a stronger reaction than you expected)Unknownhttps://www.blogger.com/profile/14610516076295063011noreply@blogger.com