PathScale Open-Sources The EKOPath 4 Compiler Suite

[Michael]

This is probably a stupid question but just to be sure - what exactly was compared in the tests? A benchmark program A compiled with GCC against the same benchmark program A compiled with PathScale, with the rest of the system being exactly same?

Yes, including maintaining all of the same compile flags.

[mastah]

Another question...

So improvement in speed wont be that magnificant with an old CPU, right?
But nontheless there should be improvement in comutational apllications?
So, what about archiving tools, like rar, 7z etc...

I got a Laptop here, running (nearly with light speed ) with a "AMD Turion(tm) 64 Mobile Technology ML-37 (1 cpu cores)" @2GHz (2 gigs RAM).

Extracting huge archives takes up time time time time.... Is improvement 2 be expected just for compression? or rather decompression? or both?
As I'm really working with that laptop even 5% (thinking of like 20 minutes for extracting bigger archives) would be fantastic!

Thanks in advance and thank you Phoronix for the wonderful time i was able to spend while enjoying your articles and thank you PathScale as well for your great decision!

[steckdenis]

Hello,

I tested the bechmark given above, testing the STL (http://pastebin.com/YhXxb3km), and I found how to make EKOPath faster than Clang and GCC :

1: g++ -O3 -fwhopr -o test test.cpp
2: clang++ -O3 -o test test.cpp
3: .../pathcc -Ofast -c -o test.o test.cpp -IPA -apo && .../pathcc -o test test.o .../lib/4.10.0/x8664/64/*.a -lpthread -ldl -ipa
4: .../pathcc -Ofast -c -o test.o test.cpp -IPA -apo -stl_not_threadsafe && .../pathcc -o test test.o .../lib/4.10.0/x8664/64/*.a -lpthread -ldl -ipa

The EKOPath command is split because I had to do that in order to have the program compiling.

And the results :

1: 20.080s
2: 21.652s
3: 19.989s
4: 17.720s (the fastest)

We can see that disabling the STL thread-safety can have a good impact for single-threaded programs, but that even without this option EKOPath is a little bit faster (but slower if we don't use its advanced options like interprocedural optimization (equivalent of GCC's LTO) and vectorization).

A good compiler (event if it produces very long assembly code full of rare instructions like ldmxsr, fldcw and fnstcw that I never encountered before.

[marwi509]

Should I expect a speedup with C++ as well? I tried the compiler and my path tracer took almost twice as long with ekopath (-Ofast) than with GCC (-O2) or ICC (no extra flags). Nice to see it go open source though.

[codestr0m]

Should I expect a speedup with C++ as well? I tried the compiler and my path tracer took almost twice as long with ekopath (-Ofast) than with GCC (-O2) or ICC (no extra flags). Nice to see it go open source though.

-Ofast isn't always the best flag. Also did you mean compile time or resulting binary speed? Please follow-up with [email protected] to give more details. Compile time performance is known and we're working on it.

[mjkerpan]

One thing that I wanted to point out is the fact that the mere availability of Pathscale isn't going to magically make things faster. A lot of common code won't properly compile with special compilers like PathCC or ICC or Open64 and even when it does, it often won't do any better than a decent "normal" compiler like GCC. I seem to recall a "compiler shootout" in January that compared GCC, Open64 and LLVM. Open64 did almost as well as the recent PathCC numbers on many of the same tests, but on other tests didn't produce a working result and for a few others (including things like 7zip compression and FLAC compression, which are probably a good approximation of the sorts of computationally intesive tasks most often undertaken on personal Linux boxen) didn't do any better than GCC. Granted PathCC and Open64 aren't the same, but given their shared heritage and the extensive borrowing that Open64 has made from the already-open bits of PathCC, I would predict that it's not going to be much better (at least not out of the gate, if the community decides that it wants better perfomance on home desktop-grade tasks, I'm sure it will work on fixing those bits of the newly open PathCC).

[codestr0m]

One thing that I wanted to point out is the fact that the mere availability of Pathscale isn't going to magically make things faster. A lot of common code won't properly compile with special compilers like PathCC or ICC or Open64 and even when it does, it often won't do any better than a decent "normal" compiler like GCC. I seem to recall a "compiler shootout" in January that compared GCC, Open64 and LLVM. Open64 did almost as well as the recent PathCC numbers on many of the same tests, but on other tests didn't produce a working result and for a few others (including things like 7zip compression and FLAC compression, which are probably a good approximation of the sorts of computationally intesive tasks most often undertaken on personal Linux boxen) didn't do any better than GCC. Granted PathCC and Open64 aren't the same, but given their shared heritage and the extensive borrowing that Open64 has made from the already-open bits of PathCC, I would predict that it's not going to be much better (at least not out of the gate, if the community decides that it wants better perfomance on home desktop-grade tasks, I'm sure it will work on fixing those bits of the newly open PathCC).

This is exactly part of the reason I hate Open64. It gives us a bad reputation to overcome. Admittedly we're far from perfect, but I'd like to think we're driven by real demands and not just paper numbers.

For HPC codes (C/Fortran) I would say we do very well at compiling them. For C++ this is an area we're work hard to make significant improvements. We've been quietly engaging with open source communities (like libav) more and more. We'll be taking a more proactive approach to building open source codes later this year when other projects are out of beta (ENZO).

Direct download link added to the products page - So please test and let us know what if any issues you hit.

[energyman]

apart from that qt bug - how 'compatible' is the pathscale generated code with gcc generated code?

can I, for example, just recompile vegastrike or kde 4.6.4 - or do I have to rebuild all the libs pulled in too?

[zester]

Would you mind elaborating more on the issue with Qt4?

[marwi509]

-Ofast isn't always the best flag. Also did you mean compile time or resulting binary speed? Please follow-up with [email protected] to give more details. Compile time performance is known and we're working on it.

-Ofast gave better performance than -O2 on ekopath though. It's the binary speed I'm benchmarking. My program is a pretty simple monte carlo path tracer I've written that's mostly just simple math. (nested in loops and recursion)

I'll follow-up with the support if it'll help you hunt down performance problems. I'll check the docs a bit first though, so I haven't done something wrong while installing or something like that. (I took the nightly build)