Announcement

Collapse
No announcement yet.

PathScale Open-Sources The EKOPath 4 Compiler Suite

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

  • #46
    1. Mesa is CPU bound
    2. Better compiler available
    3. ???
    4. Profit

    Comment


    • #47
      Hmm....

      OpenSimulator uses the OpenDynamicsEngine physics software to do server-side physics. AFAIK, physics is one of the more CPU-intensive calculations you can have on a server.

      I wonder how much of a speedup in ODE we could get by compiling it with EKOPath?

      Michael, is there an easy way to write a PTS test for ODE? Have you looked into this in the past?

      Comment


      • #48
        Originally posted by markg85 View Post
        I wonder of this will be of benefit to mesa then specially the software renderer! Also, how is the c++ 2011 support and can it build qt for example? Even if it can, will that improve performance?

        this release raises a lot of questions but I'm happy anyway
        I think you've been in our IRC channel before and apologies if I'm mistaken.

        mesa - I believe you have to turn off asm support for it to build. Not sure if that will improve or degrade performance. I suspect the latter, but could be surprised.

        c++0x - ENZO will get it much sooner than EKOPath since we're using a different front-end.

        QT - There's one blocking bug we're working on fixing. I expect it may take us another month or less to get that resolved.

        If someone files a bug we'll take a look at it. Smaller test cases are generally fixed faster. (Even better would be patches now that it's going open source.)

        Comment


        • #49
          Originally posted by curaga View Post
          1. Mesa is CPU bound
          2. Better compiler available
          3. ???
          4. Profit
          I tried last week and had problems with the Assembly optimizations (that can be disabled) and then problems building the R600 Gallium3D driver, but don't remember offhand what those issues were.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #50
            Originally posted by allquixotic View Post
            Michael, is there an easy way to write a PTS test for ODE? Have you looked into this in the past?
            Yes, test profiles can be made easily... I've looked into ODE long ago but don't remember finding an easy/simple test case for ODE that could be automated.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #51
              [13:15:06] <codestr0m> mupuf: you can give them a link and tell them to download and try it - http://c591116.r16.cf2.rackcdn.com/e...-installer.run

              Comment


              • #52
                git clone git://github.com/path64/compiler.git

                Comment


                • #53
                  Originally posted by PsynoKhi0 View Post
                  No and/or no.
                  website updated

                  prnewswire - waiting on editors

                  actual source availability - blame phoronix for it being leaked.. Source forthcoming, but may take a couple days.. Sorry about the binaries until then

                  #pathscale on irc.freenode.net to complain and bug us

                  Comment


                  • #54
                    Originally posted by markg85 View Post
                    That might not be the best thing to do. Remember, the things benchmarked stop far are computational apps and those seem to benefit a lot from it. Buy we both don't have the slightest idea how this will perform on non computational apps like for example kde, gnome, firefox, office suits.. Besides that I'm also interested in the compiled binary size

                    More information is needed.
                    Note, I'm guessing firefox and chrome won't compile.
                    For chrome I have a personal interest in making it build. With that it still make take some time. There's two issues I know of currently
                    1) QT bug in our front-end
                    2) Missing gnu extensions to turn on some java script related stuff

                    Binary size doesn't matter in reality as much as locality. C++ is going to see a lot of improvements this year. If we're not faster than g++ or other compilers file a bug report

                    Comment


                    • #55
                      Originally posted by zester View Post
                      git clone git://github.com/path64/compiler.git
                      Actually, I don't think that includes any of their proprietary components. This is just their open source fork of Open64.

                      I don't know all the details, but here's my GUESS:

                      1. They forked Open64
                      2. They made changes to Open64 sources, and had to release those changes to comply with the GPL
                      3. They made some additional changes that they deemed "mere aggregation" and were able to keep those proprietary
                      4. Since the "path64" github branch has been around a while and hasn't received a commit in 2 days, it's safe to assume that it doesn't include the proprietary addons

                      So, likely only the binaries are available for now.

                      Comment


                      • #56
                        Originally posted by codestr0m View Post
                        If we're not faster than g++ or other compilers file a bug report
                        I love you guys already .

                        I switched to an SSD recently. And due to space, I no longer have my gentoo partition... I might have to reconsider this!

                        Comment


                        • #57
                          @codestr0m:

                          What about Fortran? Do you happen to have any recent benchmarks against gfortran and ifort? I remember seeing a few from about 2006.

                          @Michael:

                          Does the HIMENO benchmark use the C or Fortran source?

                          Thanks for your answers and keep up the good work! (Both of you, obviously. )

                          Comment


                          • #58
                            Originally posted by Jake: View Post
                            Maybe I'm wrong, but according to wikipedia the PathScale compiler is a branch of Open64, a compiler released under the GPL http://en.wikipedia.org/wiki/Open64#Versions.

                            I think they are just complying with the gpl.
                            There's really too much confusion about Open64 + EKOpath. To set the facts straight.

                            EKOPath is a "fork" of SGI's Pro64 and never has imported code from Open64. Partial sources for EKOPath were previously available, but not all. Large portions of those sources were merged into Open64 as a result of previous PathScale management not supporting open source. Slowly the PathScale ship is changing direction and trying to build a real community of users/developers.

                            Comment


                            • #59
                              Originally posted by puelapisse View Post
                              where can we find this patch please?

                              also, I understand this compiler is Intel® 64 & AMD64 performance tuned but does anybody knows if it will run on 32bit?
                              If you subscribe to path64-dev I believe you can find it in the archives. If not ping wash in #pathscale when he's online as he'll maybe be able to dig it up.

                              Comment


                              • #60
                                Originally posted by codestr0m View Post
                                I think you've been in our IRC channel before and apologies if I'm mistaken.

                                mesa - I believe you have to turn off asm support for it to build. Not sure if that will improve or degrade performance. I suspect the latter, but could be surprised.

                                c++0x - ENZO will get it much sooner than EKOPath since we're using a different front-end.

                                QT - There's one blocking bug we're working on fixing. I expect it may take us another month or less to get that resolved.

                                If someone files a bug we'll take a look at it. Smaller test cases are generally fixed faster. (Even better would be patches now that it's going open source.)
                                yea, i was in that irc room some 8 months ago back then i asked the same for open64 or path64
                                It sucks to see c++ support lagging behind but awesome job anyway. Any eta for c++ 2011?
                                Last edited by markg85; 06-13-2011, 01:59 PM.

                                Comment

                                Working...
                                X