PathScale Open-Sources The EKOPath 4 Compiler Suite

[ninez]

If you think of a compiler as a front-end and a backend then most of the source level compatibility happens at the front-end. In the case of GCC it has also adds a bunch of extensions for developers to use. The path64 front-end is gcc-4.2 which makes the parsing/semantic analysis easy, but the problem comes for handling those extensions on the backend. In some cases it's trivial and we just haven't gotten around to it. (Maybe they are rarely used or worse a stupid idea :P) For the most part we handle the most common ones and as a result it's easier for people to migrate code from GCC to Path64/EKOPath. The linux kernel poses a couple additional challenges

Yes, i do tend to think of compilers as both front-end and backend. (hence, why i mentioned "internally, they may be very different". but obviously my language wasn't very concise Thanks for clarifying, not only for myself - but for anyone else following this thread.

1) Heavy GNU extension use (We're missing some here)
2) Heavy inline asm
3) Debugging the bootup process (It's not easy to debug why the SMP built kernel doesn't boot)

yup, i am not surprised both 1 and 2 pose issues. there is a lot of code in Linux that does not conform to C standards, and heavily relies on GCC specifics... it would be nice if this wasn't the case, but it is what it is. - and obviously there are some advantages and disadvantages in both cases...

slightly off-topic but...

does ekopath require having your modules builtin, or can it build initrd okay??? (with ICC they must be built in - unless something has changed). - also by the same token - would having the modules built in, improve the situation / problems related to #3 ???

Another example is glibc. In this case making our GCC front-end emit IR that is correct for the backend was a major pita. With ENZO we've made *huge* changes around this area and now a lot easier. (GCC/GNU code is gone entirely and why you may see ENZO building an small linux distribution from the ground up before EKOPath)

interesting, I did some reading on ENZO, and I'll be interested in testing that out, when it is available for you guys at ekopath - developing ENZO must be a little more flexible, eh?? (being as it seems to allow a more 'fresh' approach).

Thanks for the insights codestrom - i'm sure you can appreciate this, but often it is hard to get the quality of inside information - that you seem to be quite transparent about. it's really great...!

cheerz

[allquixotic]

@codestr0m:

do you also support other architectures, specifically MIPS (mips32) ?

I know I'm not codestr0m, but although my initial reaction was "lol no", it seems that (depending on which specific bits they open source) MIPS might be a possibility. See http://www.pathscale.com/node/234 for details.

Although I would speculate that, based on sheer popularity, they probably put most of their (man-hour) effort into optimizing AMD64 and Intel 64.

[leidola]

Benchmark update

Hi!

As an uptate to my last posting, I added the results of the intel compiler to the GCC/Pathscale bench.

http://openbenchmarking.org/result/1106162-GR-1106167GR06

export CFLAGS="-O3 -msse2"
export CXXFLAGS="-O3 -msse2"
export CC=icc
export CXX=icpc
export FFC=ifort
export F90=ifort
export F95=ifort
export cc=icc
export cxx=icpc
export ffc=ifort
export f90=ifort
export f95=ifort

rm -Rf $HOME/.phoronix-test-suite/installed-tests/pts/
phoronix-test-suite batch-install pts/linux-system
phoronix-test-suite batch-run     1106167-GR-1106168GR02

The intel compiler is mostly in between those two, rarely worse.

Thoughts?

[ninez]

Hi!

As an uptate to my last posting, I added the results of the intel compiler to the GCC/Pathscale bench.

http://openbenchmarking.org/result/1106162-GR-1106167GR06

export CFLAGS="-O3 -msse2"
export CXXFLAGS="-O3 -msse2"
export CC=icc
export CXX=icpc
export FFC=ifort
export F90=ifort
export F95=ifort
export cc=icc
export cxx=icpc
export ffc=ifort
export f90=ifort
export f95=ifort

rm -Rf $HOME/.phoronix-test-suite/installed-tests/pts/
phoronix-test-suite batch-install pts/linux-system
phoronix-test-suite batch-run     1106167-GR-1106168GR02

The intel compiler is mostly in between those two, rarely worse.

Thoughts?

interesting results. I'm not surprised that ICC doesn't tend to produce worse benchmarks, very often. I remember using ICC with Firefox a long while back (with -ipo) - the difference over gcc was very noticable. however, i now use firefox4 with gcc (-pgo) which is also very good - but i never got to compare the 2 head to head.. a friend of mine uses ICC to compile his libraires for transcoding (i don't really know the specifics) but he swears by it's performance gains.. - ICC is a good compiler - but also comes with some caveats; like it's licensing, which in turn makes it less useful to developers and the open-source community as well. hence, why it doesn't really have much adoption..in this way i think in the long run PathScale's technologies will be much more useful to everyone...

beyond that, based on these tests alone - it would seem each compiler tends to have it's own strong points. however, something important to note is -03 isn't always the best flag to use, as it doesn't always produce the fastest binaries.. sometimes it can introduce performance regressions (depending of course, on a number of different factors, probably from compiler to compiler - may vary).

a more interesting set of benchmarks would be if each compilation was fine-tuned for each compiler'. however, obviously, this is easier said than done. - I know myself, i have way too little experience with ekopath 4 to be confident enough in my ability, to really exploit it.

anyways, that my 2 cents - thanks for posting your results. - great stuff!

cheerz

[pszilard]

When I have a bit of time I'll try and get back with numbers - assuming that i will be able to compile the code.

Compiling Gromacs fails in the linking phase with -Ofast.

Signal: Segmentation fault in Assembly phase.
Error: Signal Segmentation fault in phase Assembly -- processing aborted
[backtrace...]
pathcc INTERNAL ERROR: /home/pszilard/programs/ekopath-4.0.10-nightly/lib/4.0.10/x8664/be died due to signal 4
INTERNAL ERROR: /home/pszilard/programs/ekopath-4.0.10-nightly/bin/pathcc returned non-zero status 1make[3]: *** [src/kernel/mdrun] Error 1

The compilation of fftw similarly fails with -Ofast and -ipa seems to be the source of the problem.

I guess I should file a bug report.

[pszilard]

Got Gromacs 4.5.4 compiled without -ipa (-march=auto -O3 -OPT:Ofast -fno-math-errno -ffast-math). I was hoping that the conclusions will be straightforward, but they're not:

• some parts of the code get up to 15% speedup;
• in other parts of the code there's a horrible slowdown, up to 2.5x;
• I get occasional segfaults.

The performance was compared to gcc 4.5.1.

[PsynoKhi0]

This is getting really intriguing... Looks like I have a boatload of stuff to read before grasping the practical implications for my user cases though heh.

[pszilard]

Got Gromacs 4.5.4 compiled without -ipa (-march=auto -O3 -OPT:Ofast -fno-math-errno -ffast-math). I was hoping that the conclusions will be straightforward, but they're not:

• some parts of the code get up to 15% speedup;
• in other parts of the code there's a horrible slowdown, up to 2.5x;
• I get occasional segfaults.

The performance was compared to gcc 4.5.1.

The segfault seems to be caused by -march (running on Ubuntu 10.04 X86_64, AMD X6 1090T).

[mirv]

Other than a couple of makefile issues (notably requiring the addition of -lrt to LDADD), the fox gui toolkit compiles fine, and the tests build and run ok. reswrap doesn't build, but it looks to rely upon a GNU extension (so it's not a bug), and I can't be bothered to dig further right now.
Now, to see if I can't get my own project to build...

[jrch2k8]

can someone tell me where i can find the documentation for ekopath4 especially c/c++ and AS?

thx in advance