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 RealNC View Post
    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).
    We should build OpenMPI no problem. If you've got an AMD cluster I bet you'll be happy you did. (Intel will heavily depend on your code)

    Comment


    • Originally posted by AnonymousCoward View Post
      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.
      For 64bit build issues please file a bug report with a reduced testcase. (If you can attach a patch or a lot of details that's awesome)

      For 32bit - let it die (All joking aside a patch would be welcomed as well)

      Comment


      • Originally posted by xir_ View Post
        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.
        Use EKOPath

        1) We may give you better performance (Even Intel on Intel code - you'll have to test though)
        2) We'll likely support everything you need for Fortran now
        3) If you hit trouble there's a community of people to help you

        Comment


        • Originally posted by elanthis View Post
          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.
          The code around the autopar is already out. Check github.com/path64/compiler

          You'd be looking in what we call the "middle end" and for more in-depth answer please post the question on path64-dev, email me personally or drop on by #pathscale - irc.freenode.net to see if one of the engineers can help point you in the right direction

          Comment


          • Originally posted by timofonic View Post
            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.
            I think some companies do a good job of handling open source and they aren't all scary acquisition targets.

            We need to update our main website #1 (work-in-progress) and then see what doesn't fit and push the rest to the path64 community site. This way we get the message out the most people. (Someone bug me if this isn't fix this week)

            Comment


            • Codestr0m, I'm curious to know if you guys plan on providing any distro specific packaging? Something like using the openSUSE build service to create native packages for the more popular distros.

              Comment


              • Originally posted by deanjo View Post
                Codestr0m, I'm curious to know if you guys plan on providing any distro specific packaging? Something like using the openSUSE build service to create native packages for the more popular distros.
                path64 is already up on buildservice

                We've fought packaging a ton, received feedback from users and in the end what we have now is likely the best general solution imho.

                Comment


                • While I don't see GCC going anywhere in a hurry, having another compiler suite around is a good thing. I see this as more complementing existing solutions - just as there's some languages better suited to various tasks, there are compilers better suited to various projects. I may have to see about testing this out.

                  Sorry if it's already mentioned somewhere, but how's the C++0x support?

                  Comment


                  • Originally posted by mirv View Post
                    While I don't see GCC going anywhere in a hurry, having another compiler suite around is a good thing. I see this as more complementing existing solutions - just as there's some languages better suited to various tasks, there are compilers better suited to various projects. I may have to see about testing this out.

                    Sorry if it's already mentioned somewhere, but how's the C++0x support?
                    I don't want to mix things up here, but EKOPath probably won't see C++0x for a while. (Maybe next major release, but don't hold me to that)

                    ENZO will *maybe* get C++0x around the same time the standard actually becomes an official standard. (Yes we could push it out much sooner, but many people would have to request it tbh)

                    Comment


                    • Originally posted by codestr0m View Post
                      I don't want to mix things up here, but EKOPath probably won't see C++0x for a while. (Maybe next major release, but don't hold me to that)

                      ENZO will *maybe* get C++0x around the same time the standard actually becomes an official standard. (Yes we could push it out much sooner, but many people would have to request it tbh)
                      Cheers for the quick response. About what I figured, but never hurts to ask.

                      Comment


                      • The software vendors are getting it but hardware vendors are not

                        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.[/QUOTE]


                        Pathscale proves once more that the hardware vendors don't get it. Softwarevendors are open but they need open platforms. We need PCIe cards with co-processors that do OpenCL/OpenGL/OpenAL in software via a standardized interface with the card (to feed it with commands). Audio and gfx chipsets then could be simplified. For example I can buy a standardized framebuffer (VESA) with simple 2D acceleration (like a FireWire/USB PCI card) to interface to my various vga/dvi whatever monitors and use the CPU or the accelerator card to do 3D. NO 3D in GFX cards. Use the CPU (a six core phenom e.g. ) or buy an accelerator card (even for audio signal processing) and retarget your compiler . Go go go go PathScale.

                        Comment


                        • Originally posted by codestr0m View Post
                          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.
                          This doesn't match with the information provided in the website of Open64:
                          Open64 is the final result of research contributions from a number of compiler groups around the world. Formerly known as Pro64, Open64 was initially created by SGI and licensed under the GNU Public License (GPL v2). It was derived from SGI's MIPSPro compiler.
                          ....
                          Open64 has been retargetted to a number of architectures. Pathscale modified Open64 to create EkoPath, a compiler for the AMD64 architecture...

                          Comment


                          • Originally posted by ahlaht View Post
                            I'm not sure what to use for -march since "native" is not accepted.
                            "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

                            Comment


                            • Originally posted by mirv View Post
                              Cheers for the quick response. About what I figured, but never hurts to ask.
                              c++ 2011 is still too new but you could use gcc 4.6 and try lots of flags combinations to get closer to ekopath and having c++ 2011

                              the most important thing for heavy performance apps is not just some magic compiler but to code properly and use the hardware accel properly (sse, avx, etc) and be strict checking your cache alignement and when possible reduce the use of loops to the minimum possible or at least try to beef them up with as many operations as you can safely put every cycle

                              Comment


                              • Originally posted by jrch2k8 View Post
                                c++ 2011 is still too new but you could use gcc 4.6 and try lots of flags combinations to get closer to ekopath and having c++ 2011

                                the most important thing for heavy performance apps is not just some magic compiler but to code properly and use the hardware accel properly (sse, avx, etc) and be strict checking your cache alignement and when possible reduce the use of loops to the minimum possible or at least try to beef them up with as many operations as you can safely put every cycle
                                I'll be using gcc4.6 once it comes out of hard masking on gentoo. I'm only playing with the new C++0x features for the sake of learning right now, though admittedly it's nice to see threading finally be part of STL.

                                The first line I gave to embedded C students: know your hardware.

                                Comment

                                Working...
                                X