PathScale Open-Sources The EKOPath 4 Compiler Suite

[XorEaxEax]

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

[jrch2k8]

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

[RealNC]

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

[AnonymousCoward]

I tried compiling wine (both wine64 and the 32bit version). With wine64 it compiles for a while but then fails with this:

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

[Eduard Munteanu]

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.

[elanthis]

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.

[Azpegath]

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

[xir_]

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.

[timofonic]

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.

[curaga]

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?