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 pszilard View Post
    As in Gromacs the great majority of the run-time is spent in hand-coded assembly kernels (SSE/SSE2 on X86/AMD64/X86_64), I doubt that EKOPath can give much speedup wrt gcc. For the same reason there is really not very much difference between the Intel C compiler and gcc (at least recent versions) either. Still, it would be interesting to see if my assumption is right.

    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.
    one big difference between the Intel C compiler and ekopath's compiler is that pathCC doesn't require near the modifications to source code that ICC usually requires. so far i have found it much easier to use then intel's compiler. - and i dove right in and started using it, no problem.

    Also, as mentioned to compile the linux kernel only requires a minimal patch.where as ICC required a crapload of patching to the kernel to work (different on every kernel release). So, i tend to think compatibility seems to be much better than ICC's - ekopath is also maintaining many of the same cflags as GCC, while ICC does not. (unless ICC has significantly changed in the last few months).

    PS: if anyone has the patch for compiling the linux kernel with pathhCC, please post it. I want to test it out, with kernel26-ck (Archlinux)...

    cheers
    Last edited by ninez; 14 June 2011, 03:06 PM.

    Comment


    • Originally posted by curaga View Post
      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?
      Ahh yes, didn't think about that. Also I assume Pathscale requires the same copyright assignment for code submitted to path64 so code won't be going either way (not that I found that likely even on a purely technical basis). That doesn't affect the chances of a GCC backend plugin (dragonegg is a prime example) but again I'm doubtful we'll see that happen (as always, someone has to do the work).

      Either way, it's wonderful having a compiler suite totally focused on Intel/AMD 64bit performance since we'll hopefully get to see just how much juice can be squeezed out of that cpu architecture.

      Early benchmarks look really promising, I'll be doing my own later this week.

      Again, thanks Pathscale! Stort tack c0destrom (antar att du kan svenska med ett s?dant svensk-klingande namn )!

      Comment


      • codestr0m, would you guys have any plans to support other archs like arm?

        Comment


        • Originally posted by simonbcn View Post
          This doesn't match with the information provided in the website of Open64:
          Ok so it's wrong and I can't say I really care. Tell them to fix it if it's important to you.

          1) I have full internal commit history on what's been done
          2) Check the early open64 commits. You'll see nobody @pathscale pushed a single change there and also their commit messages say pulled from PathScale.. etc etc..

          Open64 came from Intel's ORC project and shortly after that initial start pulled in a lot from PathScale. (Of all things which could be discussed this is extremely boring)

          Comment


          • Originally posted by ChrisXY View Post
            "march=native" should definitively do something. If not something useful, maybe just accept and omit it silently because there might be many configure scripts out there that assume it.
            I tried for example vlc-git.

            (but doesn't compile anyway:
            Code:
            ### Compiler Error during Writing WHIRL file phase:
            ### Add_Init_For_WHIRL: unexpected static init tree
            make[4]: *** [network/libvlccore_la-udp.lo] Fehler 1
            "Fehler"=Error
            Please file a reduced test case bug report to get this fixed. With regards to accepting native.. Send a patch as it should be trivial. See the code on github.com/path64/compmiler:src/driver

            Comment


            • Originally posted by ivank View Post
              Any pathscale representatives here?

              I've tried to use EKOPath 4 nightly build published currently on pathscale's site to compile one of my projects... it didn't get very far and crashed:

              ### Assertion failure at line 2183 of
              /var/jenkins/workspace/Linux_Packages/src/compiler/src/be/vho/vho_lower.cxx:
              ### Compiler Error in file city.i during VHO Processing phase:
              ### op OPR_RROTATE unexpected in vho_lower_set_st_addr_info

              Whom should I sent my bug reports to? I'm not asking for commercial support, just want to let developers know about the problem. I've tried [email protected], but it basically sent me in return a link to http://www.pathscale.com/buy.html, which makes me think bug reports from non-customers aren't wanted there...
              For now
              github.com/path64/compiler

              In the future we'll move our jira instance to being available for others to file public issues.

              Please make sure that a reduced test case is supplied

              Comment


              • Originally posted by Nobu View Post
                Lets see...
                1.) 'EKOPath is a "fork" of SGI's Pro64' <-/-> '[...]modified Open64 to create EkoPath'
                2.) Pro64 became Open64, which 'was initially created by SGI' <-> 'EKOPath is a "fork" of SGI's Pro64'

                So, either...
                a.) EKOPath is a "fork" of Pro64 and is very similar to Open64 because of their shared heritage.
                b.) EKOPath is a fork of Open64...because Pro64 was renamed to Open64?
                c.) EKOPath is a fork of Open64...period.
                d.) ...Eh?
                Correct answer : A

                ***yawns***

                Comment


                • Originally posted by Pickle View Post
                  codestr0m, would you guys have any plans to support other archs like arm?
                  MIPS 5kf which is used for the SiCortex machines still in production works now. We had ARM code in path64 until recently and ripped it out. We're looking at how we can do this in a much better way and hopefully you see something tangible materialize this year. (If anyone is interested to help out on this ping me)

                  Comment


                  • @Codestrom

                    phoronix article says;

                    The Linux kernel can even be built with this high-performance compiler after applying a trivial patch.
                    being as you are more familiar with EKOPath 4 compiler suite than anyone else in this forum, any idea where i can find this "trivial patch"...????

                    I'm really keen on testing pathCC with the linux kernel. I have googled to death and not found the patch that the article refers to... i figured being as you've been hanging around the forums, i would ask you, before jumping onto IRC or the mailing list..

                    any info would be great, and thanks for taking the time to answer people's questions,

                    take care

                    Comment


                    • Originally posted by ninez View Post
                      @Codestrom

                      phoronix article says;



                      being as you are more familiar with EKOPath 4 compiler suite than anyone else in this forum, any idea where i can find this "trivial patch"...????

                      I'm really keen on testing pathCC with the linux kernel. I have googled to death and not found the patch that the article refers to... i figured being as you've been hanging around the forums, i would ask you, before jumping onto IRC or the mailing list..

                      any info would be great, and thanks for taking the time to answer people's questions,

                      take care
                      Check the path64-dev mailing list. I think the patch was like 1-5 lines with .org blah blah in the subject. Honestly don't spend time on this unless

                      1) You're ready to dig into the boot issues you'll encounter afterwards
                      2) You're ready to file good bug reports so we can work with you in getting them fixed

                      Please don't take this as discouraging, but it's a lot of work before we can support building the kernel in a high quality manor.

                      Comment

                      Working...
                      X