Linked by Thom Holwerda on Wed 15th Jun 2011 14:23 UTC, submitted by Valhalla
General Development "PathScale announced today that the EKOPath 4 Compiler Suite is now available as an open source project and free download for Linux, FreeBSD and Solaris. This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers." More here.
Thread beginning with comment 477322
To view parent comment, click here.
To read all comments associated with this story, please click here.
CodeMonkey
Member since:
2005-09-22

Will the suite make for faster binaries? That i could not find a definite answer for on phoronix.


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.

Reply Parent Score: 5

Alfman Member since:
2011-01-28

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?

Reply Parent Score: 2

Valhalla Member since:
2006-01-24


Like everyone else, I didn't find any open source code. Technically they might not distribute the source code to non-customers.

https://github.com/path64/repositories

AFAIK these are the source code repositories for path64 compiler and debugger. However, unless I'm mistaken not all proprietary path64 features has yet been added to this repo but they will be (it's after all the whole point of this announcement).

Meanwhile you can try out prebuilt nightlies from the homepage: http://www.pathscale.com/ekopath-compiler-suite


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.

The compiler suite is open sourced under GPLv3, the debugger is released under BSD (same goes for their libcxx runtime).

Reply Parent Score: 5

pabloski Member since:
2009-09-28

No, there's the code and the binaries too http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-4....

The compiler and runtime libraries have been released under gplv3.

If the compiler gives an error about crt1.0, you just need to create a symlink /usr/lib64 who points to /usr/lib

Reply Parent Score: 1

CodeMonkey Member since:
2005-09-22

Like everyone else, I didn't find any open source code.

When the announcement was made they didn't have code published yet. According to PathScale it should be ready "soon". I believe it will first be on thier website and then pushed to github (not path64 on github, no further commits will be made there).

Technically they might not distribute the source code to non-customers.

About 6 months ago I reached out to PathScale along with several other compiler vendors. I asked if they'd be willing to donate a license to thier compiler for use with the LAPACK project and it's nightly build and test infrastructure. So I wasn't a customer but they were will to help support the open source community and did in fact donate a license to us.

Reply Parent Score: 2

Valhalla Member since:
2006-01-24


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.

(often HPC code will depend heavily on an optimized math library) and everybody's codebase and workload is different,

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.

Reply Parent Score: 2

kargl Member since:
2007-10-16

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.

Reply Parent Score: 1

CodeMonkey Member since:
2005-09-22

Is this wall-clock or cpu-time?

Wall clock time

Your timings are meaningless without details!
What compiler versions? What compiler options?

These weren't with super aggressive optimizations but with "safe" optimizations. Trying to do things like -Ofast on most compilers will often break the numerical accuracy of the LAPACK code so anything over O2 is recommended to be avoided.
gfortran 4.4.0 : -O2 -march=native
ifort 12.0 : -O2 -xHost
pgif90 13.1 : -O2 (pgi does the equiv. of march=native by default)
pathf90 4.0.10 : -O2 -march=native

With pathf95, built from today sources, I
cannot compile lapack from netlib without
hitting an internal compiler error.

Perhaps an issue to take up with PathScale and your particular setup but two of the nightly LAPACK svn builds are with the previously linked to 4.0.10 nightly build from 2 days ago.

This, of course, means that the execution time of any lapack benchmark cannot be obtained.

Please note that this is not designed to be a benchmark but simply the test suite for the code base. It was just one example of code that I've seen and worked with that shows great gains from the PathScale compiler.

And for those who might be wondering, this is not using an optimized BLAS imlementation but instead the netlib fortran BLAS was built as part of the LAPACK build. On larger datasets and matricies building against an optimized BLAS (like goto, atlas, mkl, or acml) can make a big difference but for the small data sizes in the software test suite the difference is not significant.

Reply Parent Score: 2