Page 12 of 24 FirstFirst ... 2101112131422 ... LastLast
Results 111 to 120 of 235

Thread: PathScale Open-Sources The EKOPath 4 Compiler Suite

  1. #111
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by djdoo View Post
    - Is this the end of our old friend GNU GCC, or it can also take advantage from EKOPath?
    Jim
    Heh, afaik path64 only targets Intel/AMD 64bit, Linux/BSD's needs to run on alot more architectures than that. GCC isn't going away, but path64 (just like LLVM) seems like a great complement.

    GCC is obviously licence compatible with Path64 (GPLv3) but still I can't really see any code crossing over, like codestr0m said compilers are REALLY complex things. Closest thing I can imagine would be a Path64 backend plugin or something like that, but I still find it doubtful.

  2. #112
    Join Date
    Jun 2009
    Posts
    1,137

    Default

    Quote Originally Posted by XorEaxEax View Post
    Heh, afaik path64 only targets Intel/AMD 64bit, Linux/BSD's needs to run on alot more architectures than that. GCC isn't going away, but path64 (just like LLVM) seems like a great complement.

    GCC is obviously licence compatible with Path64 (GPLv3) but still I can't really see any code crossing over, like codestr0m said compilers are REALLY complex things. Closest thing I can imagine would be a Path64 backend plugin or something like that, but I still find it doubtful.
    the most likely scenario in the near term for path64(in my view) is that some distros with will use it in heavy fpu code like ffmpeg and likes and provide nice integration so commercial developers feel better to use it since is more tested and integrated in the ecosystem than the competence in sstuff like heavy physics and games,etc

    gcc will remain that is for sure since gcc support everything including a ducktaped arm cpu in a trashcan and in many non fpu intensive apps like kopete or pidgin for example there won't much difference anyway, so distros will always prefer gcc since they know it and put path64 where real perfomance gain can be measured, lets say virtualbox for example and probably with a payed support plan later on VMware including stuff like lapack, etc

  3. #113
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,795

    Default

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

  4. #114

    Default

    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.

  5. #115

    Default

    Quote Originally Posted by spykes View Post
    They are big differences in performance.
    Even if the applications have been well chosen, I would never expect to see such differences by just using another compiler.
    Maybe this should be considered as bugs in GCC (it must obviously do something wrong to see such a difference).

    That would be very interesting to compare compilations options, and to see how that works on different configurations as well.

    And why not using Fedora 15 with GCC 4.6 to perform benchmarks?
    It's a bit more bleeding edge than Ubuntu.
    Hm, that's what I think too. I don't remember ICC beating GCC by a comparable margin on Intel's own CPUs, though I could be wrong. Could it be aggressive autovectorizing?

    I'm curious how it performs in other benchmarks too. Compiling times could also be useful to get a fair assessment.

    Note GCC probably isn't all that bad, though standard optimization levels are more or less conservative. I don't mean to defend GCC on this, but EKOPath (like ICC and other compilers in the high performance market) does get a better chance to enable optimizations behind the scenes.

  6. #116
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by Eduard Munteanu View Post
    Could it be aggressive autovectorizing?
    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.

  7. #117
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    405

    Default

    Quote Originally Posted by markg85 View Post
    Let me quote someone (don't know who buy the line is nice)
    "assumption its the mother of all screw ups"

    And I think you made one by posting the article. Not that I mind
    Another classic is:
    "Assume" makes an Ass out of U and Me

  8. #118
    Join Date
    Mar 2010
    Posts
    60

    Default

    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.

  9. #119
    Join Date
    Feb 2008
    Posts
    210

    Default

    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.

  10. #120
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,113

    Default

    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?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •