> Interesting. I have been testing the intel compiler with various > releases from time to time, but hardly find it producing binaries which > show any significant improvement. > For example I have just recently compared icc8 againt gcc3.4.0 with gzip > and bzip2 (as I use those programs fairly heavily). I was not able to > measure any performance increase with icc8, when testing the programs on > pII cpus. For sure I'd like to see the icc compiler really in action but > so far I've yet to discover a program where it actually makes any > improvement over gcc. Those programs are too "simple" and one has a cache-spill footprint which ends up limiting its performance more than actual instruction scheduling and data access reordering. BZIP2 (Block sorting compressor) for example will spill the cache of ANY modern CPU, given the fact that its working memory set is at least 4-5MB (up to 20MB or so, depending on the compression level selected). For BZIP2, memory speed is everything. If you benchmarked an 800FSB 3.0GHz processor against a 400FSB 3.0Ghz processor, the 800FSB processor would blow its doors off. For gzip, the performance would be pretty close to identical. GZIP has some assembler helpers in the core guts (alas, written against the Pentium as the newest CPU)... so there's little ability to distinguish itself there. If you disable all of the ASM stuff in GZIP builds, you might see small deltas between the compilers in your comparison, but there's little room for code-gen area improvements in performance there. Try out LAME (mp3 encoding), OpenSSL's "speed" benchmark, etc. > About the link you sent in another email: I am sceptical about claims > coming directly from Intel That link isn't from Intel. It's from MySQL, AB, the developers of MySQL. MySQL, AB has been touting this advantage for a while now, just less publicly. In fact, I think up until very recently, you could only get ICC builds of MySQL from them if you PAID for MySQL - it was probably one of the little "perks" of purchasing it. It was certainly never available for (public) download, again, up until very recently. In less formal settings, developers from within MySQL, AB have acknowledged the solid gains in speed from using the Intel compiler. You can find them with google. > as I suspect them to be just marketing blurb. > If some independant sysadmin confirms their figures with a mysql > running in a real world production system I would be more satisfied. Well, it *IS* a marketing document after all, but it's mostly MySQL's marketing document, insofar as they are touting their speed advantage over their competitors. Yes, Intel is taking some limelight as well... but it's MySQL's marketing document. MySQL, AB includes a very comprehensive set of SQL torture tests for performance evaluation, which comes with their source code. The document includes all compiler settings used for both compilers' builds, so the claims are easily verified. In any event, I have seen the difference in my own code - it manages to discover vectorising code generation possibilities in surprising places. If you don't see any differences, maybe it's not for you. If you're earnest about investigating it, then try it out with at least the following settings: Assuming a P4: CFLAGS='-xW -tpp7 -march=pentium4 -mcpu=pentium4 -O3 -ipo' Assuming a P3/AthlonXP: CFLAGS='-xK -tpp6 -march=pentium3 -mcpu=pentium3 -O3 -ipo' Some very large projects create intermediate libraries - you may find you need to build those with -ip instead of -ipo I'm neither an Intel employee, nor an employee of MySQL, AB. I poo-poo'ed Intel until about a year or two ago when I gave their compiler an honest try on a modest 400FSB P4-1.6GHz CPU and was very pleasantly surprised. If you don't discover the same results, I'm sorry. I didn't design the CPU or the compiler, so THAT'S not MY fault. :) =MB= -- A focus on Quality.
