
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.
So at the end: if you have tight scientific code there will be a visible at least 20% speedup over GCC.free.
Whoa, let's not make such sweeping statements shall we, even in the very small current Phoronix testbed there's a benchmark where ekopath loses out to gcc 4.5 (which is what it was benchmarked against). That said, judging by most of the benchmarks there's potentially alot of performance to be had from this specifically Intel/AMD 64-bit targeted compiler suite.
Also hoping it will have alot better GCC compability than ICC had last time I tried it.
For those of us with Intel/AMD 64-bit systems there could be alot of performance to be had in heavily computational applications, and Pathscale is obviously very set on keeping the bar high, given that ekopath failing to beat GCC or any other compiler in performance is considered a bug by Pathscale.
Gentoo ricers, mount up!

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.
CodeMonkey,
"I was blown away by it myself and almost didn't beleive it. I've seen comparable results with other C++ code bases."
If this is true, I'll need to take a look into it.
I downloaded the trial, but it wouldn't run on this 32bit system (silly me).
Unfortunately I cannot afford the price "Starting at $1795", which is a yearly price?
Like everyone else, I didn't find any open source code. Technically they might not distribute the source code to non-customers.
Does anyone know what they mean by "open source"? The following statement gives me the impression they're not going to use GPL3 for the debugger or the compiler.
"In addition to the compiler, this release also includes PathDB, a modern debugger. PathDB has been released under a permissive license, in response to requests from the open source community for a modern debugger that is not encumbered by the GPLv3."
I hate speculating, does anyone know the details?
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.
Wow, that is good.
Yes we've joked about that in development, compiler benchmarking (and even language benchmarking) in many cases end up being a comparison of which one comes with the most optimized math lib for your particular platform.
Your timings are meaningless without details!
What compiler versions? What compiler options?
Is this wall-clock or cpu-time?
With pathf95, built from today sources, I
cannot compile lapack from netlib without
hitting an internal compiler error. This,
of course, means that the execution time
of any lapack benchmark cannot be obtained.
Member since:
2006-07-12
Ok i will look into it more deeply. Thank you.
EDIT: Will the suite make for faster binaries? That i could not find a definite answer for on phoronix.
Edited 2011-06-15 15:18 UTC