Announcement

Collapse
No announcement yet.

PathScale Open-Sources The EKOPath 4 Compiler Suite

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

  • #91
    thanks PathScale

    trolls/fear/technicalities apart, this is an awesome news, thanks to PathScale (and Michael for reduce the wait), i am looking forward to see this beauty working on.

    Comment


    • #92
      Originally posted by bug1 View Post
      Im sure we have all seen an _ideological_ debate about restrictive vs permission open source license, whether restrictions are along term benefit etc, so lets not go there.

      I wonder how in a _practical_ sense how the GPLv3 would have encumbered their debugger ?
      It would encumber parties who may be interested in using the debugger in other non GPL3 projects which may have another license on which the GPL3 frowns upon. This could also include other projects that they have that they might not want to release under GPL3 but still have the debugger code free to use how they want.
      Last edited by deanjo; 06-13-2011, 07:55 PM.

      Comment


      • #93
        I guess their debugger is of little value, that's why they choose BSD license. But their crown jewel, the compiler suite, is GPL + copyright assignment if I'm not mistaken. So they can offer it under a dual-license, while not letting the competition take a free-ride with a proprietary version of what's mostly their codebase.

        Comment


        • #94
          Originally posted by inot View Post
          I have run some tests which show that std::map and std::set performance of EKOPath is worse than gcc. The following test runs in 8.8s when compiled with gcc, but takes 11.7s compiled with EKOPath: http://pastebin.com/YhXxb3km
          I suspect it's our STL. To verify you could build Path64 which will use the GNU system installed STL. If the performance regression goes away we'll know exactly who to blame. We use the RogueWave STL and generally it outperforms GNU. Anyway thanks for the bug report

          Comment


          • #95
            Originally posted by AnonymousCoward View Post
            I guess their debugger is of little value, that's why they choose BSD license.
            We pity the BSD community and were trying to do everything in our power to introduce some competition for GDB. Admittedly our drop-in GDB replacement could be better. (About 50% passing in GDB test suite) The design and PathDB code is really clean and awesome design though. If you like hacking on a debugger I'm sure you'd not say it's little value. More to the point is we'll continue slowly improving it more and more.

            Comment


            • #96
              Originally posted by HokTar View Post
              I really don't want to be the whiny little boy here, but the others seem to get replies so I'd like to point out that my previous post likely went under your radar:
              Our Fortran robustness is great - Any Fortran bug you hit will likely get fixed quickly. I know Intel is very competitive on performance and gfortran I'm not sure how many people actually use it in HPC. The best benchmark as always it your code. Try it and let us know.

              Comment


              • #97
                Originally posted by XorEaxEax View Post
                One of the most powerful optimizations added to gcc in the past years is PGO (profile guided optimization), anyone know if it is it supported on ekopath4?
                yeah we call it FDO - Feedback Driven Optimization and had it for many years :P

                Comment


                • #98
                  Originally posted by ahlaht View Post
                  I have been trying to speed up Python programs with this, but so far they only run slower.

                  Tried with CFLAGS "-O2", "-O3", "-march=core -O3" and some others. I'm not sure what to use for -march since "native" is not accepted. I found out by accident that "core" works.

                  -Ofast didn't compile.

                  I guess this doesn't help Python. Or I could be doing something wrong...
                  File a bug report <joking>or switch to a real programming language</joking>

                  This sort of feedback is great and exactly what we want.

                  Comment


                  • #99
                    Originally posted by bug1 View Post
                    "PathDB has been released under a permissive license, in response to requests from the open source community for a modern debugger that is not encumbered by the GPLv3."

                    en·cum·ber
                       /ɛnˈkʌmbər/ Show Spelled[en-kuhm-ber] Show IPA
                    –verb (used with object)
                    1. to impede or hinder; hamper; retard: Red tape encumbers all our attempts at action.
                    2. to block up or fill with what is obstructive or superfluous: a mind encumbered with trivial and useless information.
                    3. to burden or weigh down: She was encumbered with a suitcase and several packages.

                    Why does PathScale go out of their way to insult the GPLv3 in this PathDB release note, while in the same document describign the release of the compiler under that very license ?


                    Thanks for the contribution.
                    Encumbered is a legal term and not an insult. It just referred to the restrictions of the GPL. Our goal for PathDB is/was to build an initial community of users inside the BSD community.

                    Comment


                    • Originally posted by deanjo View Post
                      It would encumber parties who may be interested in using the debugger in other non GPL3 projects which may have another license on which the GPL3 frowns upon. This could also include other projects that they have that they might not want to release under GPL3 but still have the debugger code free to use how they want.
                      If GPL incompatible products are being _distributed_ with runtime dependencies to the debugger then it would be a problem if the debugger with GPL. Ive never heard of that happening myself, but maybe im out of the loop.

                      I think the real reason is hinted at in the response from PathScale, they want to encourage _development_ by other parties.

                      If other parties where to develop restrictive additions to the debugger it wouldnt be a problem to PathScale because its really just their to support usage of their compiler.

                      EDIT: re previous post, maybe im oversensitive, point taken.
                      Last edited by bug1; 06-13-2011, 08:42 PM. Reason: didnt see previous post.

                      Comment


                      • Originally posted by codestr0m View Post
                        yeah we call it FDO - Feedback Driven Optimization and had it for many years :P
                        Awesome! Given it's name (FDO) I assume path64 uses the same options as open64 (fb-create, fp-opt)? Does it accept -fprofile-generate, fprofile-use, and link-time optimization options like -flto? With accept I don't mean silently ignore

                        Comment


                        • Questions...

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

                          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?

                          -Will we see immediate usage of EKOPath, or will we have to wait for the developers to agree first, debate, disagree, fork projects, shoot each other and all these nice damn slow stuff?

                          -Lastly can we trust Pathscale or will it end up like Sun and the <<beloved>> Oracle with openoffice?

                          Just my first thoughts about the subject...

                          Jim

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

                            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?

                            -Will we see immediate usage of EKOPath, or will we have to wait for the developers to agree first, debate, disagree, fork projects, shoot each other and all these nice damn slow stuff?

                            -Lastly can we trust Pathscale or will it end up like Sun and the <<beloved>> Oracle with openoffice?

                            Just my first thoughts about the subject...

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

                            Comment


                            • Thanks codestr0m

                              for the informative replies you've been giving everyone.

                              Comment


                              • Originally posted by smitty3268 View Post
                                for the informative replies you've been giving everyone.
                                Source quality, performance, community and support all must be strong for this to work out for everyone

                                Comment

                                Working...
                                X