PathScale Open-Sources The EKOPath 4 Compiler Suite

[XorEaxEax]

yeah we call it FDO - Feedback Driven Optimization and had it for many years :P

Awesome! Given it's name (FDO) I assume path64 uses the same options as open64 (fb-create, fp-opt)? Does it accept -fprofile-generate, fprofile-use, and link-time optimization options like -flto? With accept I don't mean silently ignore

[djdoo]

Well I am not a programmer, but I have done some compiling work myself at the past...
I used to believe that a better compiler suite just ''creates'' the executable program faster and with less problems let's say, I was not aware that it could help the executable also run faster or generally speaking better! That's something I discovered today from the article about EKOPath 4 and this thread...

My questions now are:
- How will the linux community take advantage of this new hightech opensource compiler suite?

- Is this the end of our old friend GNU GCC, or it can also take advantage from EKOPath?

-What's Linus opinion about this and how can EKOPath actively speed up the Kernel or trace long standing bugs (like the power drainer one we discuss lately) via the relative debugger I was reading previously?

-Will we see immediate usage of EKOPath, or will we have to wait for the developers to agree first, debate, disagree, fork projects, shoot each other and all these nice damn slow stuff?

-Lastly can we trust Pathscale or will it end up like Sun and the <<beloved>> Oracle with openoffice?

Just my first thoughts about the subject...

Jim

[codestr0m]

Well I am not a programmer, but I have done some compiling work myself at the past...
I used to believe that a better compiler suite just ''creates'' the executable program faster and with less problems let's say, I was not aware that it could help the executable also run faster or generally speaking better! That's something I discovered today from the article about EKOPath 4 and this thread...

My questions now are:
- How will the linux community take advantage of this new hightech opensource compiler suite?

- Is this the end of our old friend GNU GCC, or it can also take advantage from EKOPath?

-What's Linus opinion about this and how can EKOPath actively speed up the Kernel or trace long standing bugs (like the power drainer one we discuss lately) via the relative debugger I was reading previously?

-Will we see immediate usage of EKOPath, or will we have to wait for the developers to agree first, debate, disagree, fork projects, shoot each other and all these nice damn slow stuff?

-Lastly can we trust Pathscale or will it end up like Sun and the <<beloved>> Oracle with openoffice?

Just my first thoughts about the subject...

Jim

1) Only if we get enough people aware and testing the compiler will it get any traction. We need to spread the word, file bug reports and make it better than everything else. (iow - lots of work)

2) GCC is going to be around for many years and really there's no way they can benefit from the work we're doing.

3) Ask Linus and let us know what he says

4) We're a technical company and if you send a contribution it won't have ego involved. It'll either pass a technical code review or not. We all want to maintain high quality codebases so no hacks

5) Trust is a personal thing. I work at PathScale and clearly biased. Continue to track our open source progress and make the decision for yourself.

[smitty3268]

for the informative replies you've been giving everyone.

[codestr0m]

for the informative replies you've been giving everyone.

Source quality, performance, community and support all must be strong for this to work out for everyone

[djdoo]

1) Only if we get enough people aware and testing the compiler will it get any traction. We need to spread the word, file bug reports and make it better than everything else. (iow - lots of work)

2) GCC is going to be around for many years and really there's no way they can benefit from the work we're doing.

3) Ask Linus and let us know what he says

4) We're a technical company and if you send a contribution it won't have ego involved. It'll either pass a technical code review or not. We all want to maintain high quality codebases so no hacks

5) Trust is a personal thing. I work at PathScale and clearly biased. Continue to track our open source progress and make the decision for yourself.

Consider me also happy like the previous friend above for your immediate reply codestr0m, for your behavior shows that the Pathscale seems to have serious plans about the opensourced EKOPath compiler and not just throwing to the community an old and useless for immediate profit piece of software like other companies did in the past and continue to do...
One thing to add about my 4th question, I was referring to the developers of applications, desktop environments, drivers etc not your own EKOPath developers..

Your answer there leads me to another synthetic question:
- What's your view about the community? How will you use its efforts? Just bug reports and feedback, or also straight coding on the compiler suite?

In other words, do you want community just to help you track down bugs and regressions of the suite or do you want-expect also straight native coding from the community devs?

[signals]

Well I am not a programmer, but I have done some compiling work myself at the past...
I used to believe that a better compiler suite just ''creates'' the executable program faster and with less problems let's say, I was not aware that it could help the executable also run faster or generally speaking better! That's something I discovered today from the article about EKOPath 4 and this thread...

I would caution you that this is not a "magic bullet." While it seems like an excellent compiler, it will not speed everything up. It appears to come from the HPC world and does a great job on heavy number-crunching code, but its performance seems to be on-par with gcc 4.5 in most other code. At least as far as the very limited tests I carried out this afternoon. Since your typical workload is probably not heavy computation, you are not likely to see a noticeable speed up just from changing compilers.

For example, I ran the extremely old "nbench" BYTEmark benchmark with it because it seemed like something that would show the difference in compilers fairly well, and it was quick and easy to build. (I'm not using PTS. Shame on me.) Here are the results:

gcc-4.5.2 -O3 -march=native -flto:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1891.4  :      48.51  :      15.93
STRING SORT         :            1035  :     462.48  :      71.58
BITFIELD            :      7.8577e+08  :     134.79  :      28.15
FP EMULATION        :          398.48  :     191.21  :      44.12
FOURIER             :           47374  :      53.88  :      30.26
ASSIGNMENT          :          54.898  :     208.90  :      54.18
IDEA                :           12136  :     185.62  :      55.11
HUFFMAN             :          4004.8  :     111.05  :      35.46
NEURAL NET          :           98.12  :     157.62  :      66.30
LU DECOMPOSITION    :          2872.8  :     148.83  :     107.47
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 158.287
FLOATING-POINT INDEX: 108.114
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 8 CPU GenuineIntel Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 4010MHz
L2 Cache            : 8192 KB
OS                  : Linux 2.6.39-gentoo-r1
C compiler          : x86_64-pc-linux-gnu-gcc
libc                : 
MEMORY INDEX        : 47.797
INTEGER INDEX       : 34.235
FLOATING-POINT INDEX: 59.964
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

pathcc-4.0.10 -O3 -TARG:ssse3=on -TARG:sse4_1=on -TARG:sse4_2=on -ipa:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1946.6  :      49.92  :      16.39
STRING SORT         :          1106.4  :     494.37  :      76.52
BITFIELD            :      7.5471e+08  :     129.46  :      27.04
FP EMULATION        :          551.04  :     264.41  :      61.01
FOURIER             :           64584  :      73.45  :      41.25
ASSIGNMENT          :          77.458  :     294.74  :      76.45
IDEA                :           13156  :     201.22  :      59.74
HUFFMAN             :          3378.6  :      93.69  :      29.92
NEURAL NET          :          102.72  :     165.01  :      69.41
LU DECOMPOSITION    :          3607.7  :     186.90  :     134.96
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 173.296
FLOATING-POINT INDEX: 131.326
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 8 CPU GenuineIntel Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 4010MHz
L2 Cache            : 8192 KB
OS                  : Linux 2.6.39-gentoo-r1
C compiler          : pathcc
libc                : 
MEMORY INDEX        : 54.082
INTEGER INDEX       : 36.567
FLOATING-POINT INDEX: 72.839
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

You will see that in many of the tests the code generated by pathcc and gcc performs about the same. In HUFFMAN gcc clearly wins, and in FP EMULATION, FOURIER, ASSIGNMENT, and LU DECOMPOSITION pathcc clobbers gcc.

Remember, all of these tests are computational in nature, and only in a few of them do you see the massive gains from building with pathcc. I do not think it will help that much for normal end-user desktop software like KDE SC or Firefox... But, maybe they can speed the Folding@home supercomputer up by using EKOPath to compile gromacs.

But, even if it won't magically make your computer run 50% faster in all cases, it's still petty amazing that it can make the gains that it does, and it's fantastic that Pathscale has decided to open the source. Big thank you to everyone involved.

[codestr0m]

Consider me also happy like the previous friend above for your immediate reply codestr0m, for your behavior shows that the Pathscale seems to have serious plans about the opensourced EKOPath compiler and not just throwing to the community an old and useless for immediate profit piece of software like other companies did in the past and continue to do...
One thing to add about my 4th question, I was referring to the developers of applications, desktop environments, drivers etc not your own EKOPath developers..

Your answer there leads me to another synthetic question:
- What's your view about the community? How will you use its efforts? Just bug reports and feedback, or also straight coding on the compiler suite?

In other words, do you want community just to help you track down bugs and regressions of the suite or do you want-expect also straight native coding from the community devs?

Q: What's your view about the community?
A: We want everyone in the world to use and benefit from the compiler now.

Q: How will you use its efforts?
A: Some users/engineers/developers demand production quality products and support. We'll deliver on that.

Q: Just bug reports and feedback, or also straight coding on the compiler suite?
A. D) All of the above

[djdoo]

Q: What's your view about the community?
A: We want everyone in the world to use and benefit from the compiler now.

Q: How will you use its efforts?
A: Some users/engineers/developers demand production quality products and support. We'll deliver on that.

Q: Just bug reports and feedback, or also straight coding on the compiler suite?
A. D) All of the above

Well let me welcome you and EKOPath personally to Linux community!
I believe you did a very pioneering move as a company and I am certain you won't regret it cause after all we are all people who love computers and know their value as tools and even entertainment centers. Everything that helps them do their job more reliable and faster is very welcome and furthermore if its development is organized via high quality and strict standards!

For me your last answer is the most important of all cause it is straight to the point that Pathscale is not here to take advantage of the community to make its software better by track down bugs and regressions and then put again a proprietary licence on it just like other open source ''friendly'' companies did in the past...

Hope I understood well cause english is not my native language and maybe I didn't get the meaning correct...

[johnc]

My questions now are:
- How will the linux community take advantage of this new hightech opensource compiler suite?
- Is this the end of our old friend GNU GCC, or it can also take advantage from EKOPath?
-What's Linus opinion about this and how can EKOPath actively speed up the Kernel or trace long standing bugs (like the power drainer one we discuss lately) via the relative debugger I was reading previously?

NIH-ism seems to be somewhat rampant in the linux community so I might be a bit on the pessimistic side. As a software developer it interests me for my own projects... though the thought of programming in C / C++ is enough to make me want to throw up.