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; 13 June 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; 13 June 2011, 08:42 PM. Reason: didnt see previous post.

                      Comment

                      Working...
                      X