Announcement

Collapse
No announcement yet.

PathScale Open-Sources The EKOPath 4 Compiler Suite

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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?

    Comment


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

      Comment


      • 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

        Comment


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

          Comment


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

            Comment


            • Originally posted by djdoo View Post
              - Is this the end of our old friend GNU GCC, or it can also take advantage from EKOPath?
              Jim
              Heh, afaik path64 only targets Intel/AMD 64bit, Linux/BSD's needs to run on alot more architectures than that. GCC isn't going away, but path64 (just like LLVM) seems like a great complement.

              GCC is obviously licence compatible with Path64 (GPLv3) but still I can't really see any code crossing over, like codestr0m said compilers are REALLY complex things. Closest thing I can imagine would be a Path64 backend plugin or something like that, but I still find it doubtful.

              Comment


              • Originally posted by XorEaxEax View Post
                Heh, afaik path64 only targets Intel/AMD 64bit, Linux/BSD's needs to run on alot more architectures than that. GCC isn't going away, but path64 (just like LLVM) seems like a great complement.

                GCC is obviously licence compatible with Path64 (GPLv3) but still I can't really see any code crossing over, like codestr0m said compilers are REALLY complex things. Closest thing I can imagine would be a Path64 backend plugin or something like that, but I still find it doubtful.
                the most likely scenario in the near term for path64(in my view) is that some distros with will use it in heavy fpu code like ffmpeg and likes and provide nice integration so commercial developers feel better to use it since is more tested and integrated in the ecosystem than the competence in sstuff like heavy physics and games,etc

                gcc will remain that is for sure since gcc support everything including a ducktaped arm cpu in a trashcan and in many non fpu intensive apps like kopete or pidgin for example there won't much difference anyway, so distros will always prefer gcc since they know it and put path64 where real perfomance gain can be measured, lets say virtualbox for example and probably with a payed support plan later on VMware including stuff like lapack, etc

                Comment


                • I must admit that I never heard of this compiler before (the hints by Michael a while ago were the first time I heard the name "PathScale".) Looks very promising. I wonder if I can use this for MPI (using OpenMPI).

                  Comment


                  • I tried compiling wine (both wine64 and the 32bit version). With wine64 it compiles for a while but then fails with this:

                    Code:
                                                                                                                                                        
                    ../../include/winbase.h:1574: warning: 'ms_abi' attribute directive ignored                                                                                                                                         
                    ../../include/winbase.h:1575: warning: 'ms_abi' attribute directive ignored                                                                                                                                         
                    ../../include/winbase.h:1576: error: expected declaration specifiers or '...' before '__builtin_ms_va_list'                                                                                                         
                    ../../include/winbase.h:1576: warning: 'ms_abi' attribute directive ignored                                                                                                                                         
                    ../../include/winbase.h:1577: error: expected declaration specifiers or '...' before '__builtin_ms_va_list'
                    Which is similar to what happens with gcc versions 4.3 or earlier, so it should be fixable.

                    With the 32bit version of wine it fails to find the 32bit development libraries. And if I remove the check it still fails to find any 32bit libraries later (as expected). I'm using a Gentoo multilib setup which is a bit nonstandard, but compiling wine with GCC works fine.

                    Comment


                    • Originally posted by spykes View Post
                      They are big differences in performance.
                      Even if the applications have been well chosen, I would never expect to see such differences by just using another compiler.
                      Maybe this should be considered as bugs in GCC (it must obviously do something wrong to see such a difference).

                      That would be very interesting to compare compilations options, and to see how that works on different configurations as well.

                      And why not using Fedora 15 with GCC 4.6 to perform benchmarks?
                      It's a bit more bleeding edge than Ubuntu.
                      Hm, that's what I think too. I don't remember ICC beating GCC by a comparable margin on Intel's own CPUs, though I could be wrong. Could it be aggressive autovectorizing?

                      I'm curious how it performs in other benchmarks too. Compiling times could also be useful to get a fair assessment.

                      Note GCC probably isn't all that bad, though standard optimization levels are more or less conservative. I don't mean to defend GCC on this, but EKOPath (like ICC and other compilers in the high performance market) does get a better chance to enable optimizations behind the scenes.

                      Comment


                      • Originally posted by Eduard Munteanu View Post
                        Could it be aggressive autovectorizing?
                        That's what I'm hoping. Especially given how freaking horrendously GCC, Clang, and even MSVC totally cocks up with SIMD instructions. (Which I'm told is especially hilarious in MSVC's case given how the Xbox shader compiler works, which is basically the most successful and extreme auto-vectorizing compiler ever.)

                        When I have time and the source is fully available, I'm going to dig into this. Compilers are my first love, and I'm really curious to see what techniques EKOPath4 is using.

                        Comment


                        • Originally posted by markg85 View Post
                          Let me quote someone (don't know who buy the line is nice)
                          "assumption its the mother of all screw ups"

                          And I think you made one by posting the article. Not that I mind
                          Another classic is:
                          "Assume" makes an Ass out of U and Me

                          Comment


                          • I am by no means a programmer, or all that experienced with compiling complex software. (disclaimer)

                            I use a lot of Fortran code (i know, i know, not my choice), seeing as the Fortran 90/95 are a superset of the Fortran 77 standard will the EKOPath compiler be suitable for my needs?

                            Currently the research i'm involved in uses the ifort compiler, but i would always like to move to an opensource alternative.

                            Comment


                            • Hello.

                              Is path64.org going to be the official site of the project? I think the project needs a proper site for promoting in the open source community.

                              Other than that, maybe being governed by a corporation instead a community or foundation can scare some people. You know because of certain issues in the past with Open Source and corporate decisions in the past, also because certain ones fork the code for a closed source branch too (CUPS, OOo, Virtualbox?...).

                              Regards.

                              Comment


                              • I'm afraid that even with both projects being GPLv3, gcc won't get any ports of optimizations or the like. Doesn't gcc still want copyright assignment?

                                Comment

                                Working...
                                X