Originally posted by codestr0m
View Post
Announcement
Collapse
No announcement yet.
PathScale Open-Sources The EKOPath 4 Compiler Suite
Collapse
X
-
Questions...
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
Comment
-
Originally posted by djdoo View PostWell 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
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.
Comment
-
Originally posted by codestr0m View Post1) 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.
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?
Comment
-
Originally posted by djdoo View PostWell 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...
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:
Code: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.
Code: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.
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.
Comment
-
Originally posted by djdoo View PostConsider 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?
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
Comment
-
Originally posted by codestr0m View PostQ: 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
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...
Comment
-
Originally posted by djdoo View PostMy 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?
Comment
Comment