Page 11 of 24 FirstFirst ... 91011121321 ... LastLast
Results 101 to 110 of 235

Thread: PathScale Open-Sources The EKOPath 4 Compiler Suite

  1. #101
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by codestr0m View Post
    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

  2. #102
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    250

    Default 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

  3. #103

    Default

    Quote Originally Posted by djdoo View Post
    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.

  4. #104
    Join Date
    Oct 2008
    Posts
    2,915

    Default Thanks codestr0m

    for the informative replies you've been giving everyone.

  5. #105

    Default

    Quote Originally Posted by smitty3268 View Post
    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

  6. #106
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    250

    Default

    Quote Originally Posted by codestr0m View Post
    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?

  7. #107
    Join Date
    May 2010
    Posts
    20

    Default

    Quote Originally Posted by djdoo View Post
    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:

    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.
    pathcc-4.0.10 -O3 -TARG:ssse3=on -TARG:sse4_1=on -TARG:sse4_2=on -ipa:

    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.
    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.

  8. #108

    Default

    Quote Originally Posted by djdoo View Post
    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

  9. #109
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    250

    Default

    Quote Originally Posted by codestr0m View Post
    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...

  10. #110
    Join Date
    May 2011
    Posts
    1,297

    Default

    Quote Originally Posted by djdoo View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •