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
    If you think of a compiler as a front-end and a backend then most of the source level compatibility happens at the front-end. In the case of GCC it has also adds a bunch of extensions for developers to use. The path64 front-end is gcc-4.2 which makes the parsing/semantic analysis easy, but the problem comes for handling those extensions on the backend. In some cases it's trivial and we just haven't gotten around to it. (Maybe they are rarely used or worse a stupid idea :P) For the most part we handle the most common ones and as a result it's easier for people to migrate code from GCC to Path64/EKOPath. The linux kernel poses a couple additional challenges
    Yes, i do tend to think of compilers as both front-end and backend. (hence, why i mentioned "internally, they may be very different". but obviously my language wasn't very concise Thanks for clarifying, not only for myself - but for anyone else following this thread.

    1) Heavy GNU extension use (We're missing some here)
    2) Heavy inline asm
    3) Debugging the bootup process (It's not easy to debug why the SMP built kernel doesn't boot)
    yup, i am not surprised both 1 and 2 pose issues. there is a lot of code in Linux that does not conform to C standards, and heavily relies on GCC specifics... it would be nice if this wasn't the case, but it is what it is. - and obviously there are some advantages and disadvantages in both cases...

    slightly off-topic but...

    does ekopath require having your modules builtin, or can it build initrd okay??? (with ICC they must be built in - unless something has changed). - also by the same token - would having the modules built in, improve the situation / problems related to #3 ???

    Another example is glibc. In this case making our GCC front-end emit IR that is correct for the backend was a major pita. With ENZO we've made *huge* changes around this area and now a lot easier. (GCC/GNU code is gone entirely and why you may see ENZO building an small linux distribution from the ground up before EKOPath)
    interesting, I did some reading on ENZO, and I'll be interested in testing that out, when it is available for you guys at ekopath - developing ENZO must be a little more flexible, eh?? (being as it seems to allow a more 'fresh' approach).

    Thanks for the insights codestrom - i'm sure you can appreciate this, but often it is hard to get the quality of inside information - that you seem to be quite transparent about. it's really great...!

    cheerz

    Comment


    • Originally posted by mlau View Post
      @codestr0m:

      do you also support other architectures, specifically MIPS (mips32) ?
      I know I'm not codestr0m, but although my initial reaction was "lol no", it seems that (depending on which specific bits they open source) MIPS might be a possibility. See http://www.pathscale.com/node/234 for details.

      Although I would speculate that, based on sheer popularity, they probably put most of their (man-hour) effort into optimizing AMD64 and Intel 64.

      Comment


      • Benchmark update

        Hi!

        As an uptate to my last posting, I added the results of the intel compiler to the GCC/Pathscale bench.

        http://openbenchmarking.org/result/1...GR-1106167GR06
        Code:
        export CFLAGS="-O3 -msse2"
        export CXXFLAGS="-O3 -msse2"
        export CC=icc
        export CXX=icpc
        export FFC=ifort
        export F90=ifort
        export F95=ifort
        export cc=icc
        export cxx=icpc
        export ffc=ifort
        export f90=ifort
        export f95=ifort
        
        rm -Rf $HOME/.phoronix-test-suite/installed-tests/pts/
        phoronix-test-suite batch-install pts/linux-system
        phoronix-test-suite batch-run     1106167-GR-1106168GR02
        The intel compiler is mostly in between those two, rarely worse.

        Thoughts?

        Comment


        • Originally posted by leidola View Post
          Hi!

          As an uptate to my last posting, I added the results of the intel compiler to the GCC/Pathscale bench.

          http://openbenchmarking.org/result/1...GR-1106167GR06
          Code:
          export CFLAGS="-O3 -msse2"
          export CXXFLAGS="-O3 -msse2"
          export CC=icc
          export CXX=icpc
          export FFC=ifort
          export F90=ifort
          export F95=ifort
          export cc=icc
          export cxx=icpc
          export ffc=ifort
          export f90=ifort
          export f95=ifort
          
          rm -Rf $HOME/.phoronix-test-suite/installed-tests/pts/
          phoronix-test-suite batch-install pts/linux-system
          phoronix-test-suite batch-run     1106167-GR-1106168GR02
          The intel compiler is mostly in between those two, rarely worse.

          Thoughts?
          interesting results. I'm not surprised that ICC doesn't tend to produce worse benchmarks, very often. I remember using ICC with Firefox a long while back (with -ipo) - the difference over gcc was very noticable. however, i now use firefox4 with gcc (-pgo) which is also very good - but i never got to compare the 2 head to head.. a friend of mine uses ICC to compile his libraires for transcoding (i don't really know the specifics) but he swears by it's performance gains.. - ICC is a good compiler - but also comes with some caveats; like it's licensing, which in turn makes it less useful to developers and the open-source community as well. hence, why it doesn't really have much adoption..in this way i think in the long run PathScale's technologies will be much more useful to everyone...

          beyond that, based on these tests alone - it would seem each compiler tends to have it's own strong points. however, something important to note is -03 isn't always the best flag to use, as it doesn't always produce the fastest binaries.. sometimes it can introduce performance regressions (depending of course, on a number of different factors, probably from compiler to compiler - may vary).

          a more interesting set of benchmarks would be if each compilation was fine-tuned for each compiler'. however, obviously, this is easier said than done. - I know myself, i have way too little experience with ekopath 4 to be confident enough in my ability, to really exploit it.

          anyways, that my 2 cents - thanks for posting your results. - great stuff!

          cheerz
          Last edited by ninez; 16 June 2011, 07:00 PM.

          Comment


          • Originally posted by pszilard View Post
            When I have a bit of time I'll try and get back with numbers - assuming that i will be able to compile the code.
            Compiling Gromacs fails in the linking phase with -Ofast.

            Code:
            Signal: Segmentation fault in Assembly phase.
            Error: Signal Segmentation fault in phase Assembly -- processing aborted
            [backtrace...]
            pathcc INTERNAL ERROR: /home/pszilard/programs/ekopath-4.0.10-nightly/lib/4.0.10/x8664/be died due to signal 4
            INTERNAL ERROR: /home/pszilard/programs/ekopath-4.0.10-nightly/bin/pathcc returned non-zero status 1make[3]: *** [src/kernel/mdrun] Error 1
            The compilation of fftw similarly fails with -Ofast and -ipa seems to be the source of the problem.

            I guess I should file a bug report.
            Last edited by pszilard; 17 June 2011, 09:43 AM.

            Comment


            • Got Gromacs 4.5.4 compiled without -ipa (-march=auto -O3 -OPT:Ofast -fno-math-errno -ffast-math). I was hoping that the conclusions will be straightforward, but they're not:
              • some parts of the code get up to 15% speedup;
              • in other parts of the code there's a horrible slowdown, up to 2.5x;
              • I get occasional segfaults.

              The performance was compared to gcc 4.5.1.

              Comment


              • This is getting really intriguing... Looks like I have a boatload of stuff to read before grasping the practical implications for my user cases though heh.

                Comment


                • Originally posted by pszilard View Post
                  Got Gromacs 4.5.4 compiled without -ipa (-march=auto -O3 -OPT:Ofast -fno-math-errno -ffast-math). I was hoping that the conclusions will be straightforward, but they're not:
                  • some parts of the code get up to 15% speedup;
                  • in other parts of the code there's a horrible slowdown, up to 2.5x;
                  • I get occasional segfaults.

                  The performance was compared to gcc 4.5.1.
                  The segfault seems to be caused by -march (running on Ubuntu 10.04 X86_64, AMD X6 1090T).

                  Comment


                  • Other than a couple of makefile issues (notably requiring the addition of -lrt to LDADD), the fox gui toolkit compiles fine, and the tests build and run ok. reswrap doesn't build, but it looks to rely upon a GNU extension (so it's not a bug), and I can't be bothered to dig further right now.
                    Now, to see if I can't get my own project to build...

                    Comment


                    • can someone tell me where i can find the documentation for ekopath4 especially c/c++ and AS?

                      thx in advance

                      Comment

                      Working...
                      X