To view parent comment, click here.
To read all comments associated with this story, please click here.
As most modern compilers, they know to optimize patterns, sometimes with a wider applicability or lesser one.
EkoPath is optimized for HPC workloads (similar with Intel Compiler to one level) and for Amd64 bit only, meaning that they had in some cases opportunities to make the best code.
So at the end: if you have tight scientific code there will be a visible at least 20% speedup over GCC. Also the runtime have more optimized runtime methods, so if the application will use them, can see more benefits, but who knows!?
At the end, will a distro recompile everything to EkoPath? I think that is unlikely: the binaries are a bit bigger as far as I've sow and the speed is not obtained most likely just from this. Will a browser vendor recompile their products to obtain a bit faster layouting? Maybe.
At the end I think you will simply win if you will have to render a thing for a week and worth the price to recompile the raytracer to finish if things will work smooth in 5 days, and one day of you will be free.
I've been maintaining the LAPACK build and test infrastructure for ~ 6mo now and we've seen great performance numbers out of the PathScale compilers. Typical runtimes for the LAPACK test suite running 4 tests in parallel for 98 tests (this is on a 2 year old quad core xeon):
GNU Fortran : 1.5 min.
Intel Fortran : 0.7 min.
PGI Fortran : 0.7 min.
PathScale Fortran : 0.4 min.
I was blown away by it myself and almost didn't beleive it. I've seen comparable results with other C++ code bases. There are many contributing factors to the performance of your code (often HPC code will depend heavily on an optimized math library) and everybody's codebase and workload is different, but speaking from experience, for math intensive code the PathScale compiler is really top notch.





Member since:
2005-10-10
Some of your questions are answered in the linked article.... I think all of them in the forums at Phoronix.