PathScale Open-Sources The EKOPath 4 Compiler Suite
-
PathScale announced today that the EKOPath 4 Compiler Suite is now available as an open source project and free download for Linux, FreeBSD and Solaris. This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers.
EKOPath 4 carries full support for the SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, SSE4A, and AVX instruction sets. The run-time is GNU compatible and with the GCC tool-chain, provides optimized C/C++ debugging, excellent multi-core support, provides the PathDB debugger, a PathAS assembler, and supports OpenMP 2.5. The PathDB debugger was previously open-sourced and ported to FreeBSD on GitHub as the Path64 debugger.
Nightly download
http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-2011-06-12-installer.runCompiler
git clone git://github.com/path64/compiler.gitDebugger
git clone git://github.com/path64/debugger.githttp://www.pathscale.com/ekopath4-open-source-announcement
This is great news for Linux and Qt
-
[quote author="kidproquo" date="1308033594"]Apparently there's one issue in their front end which means you can't currently compile Qt. Luckily they're onto it and it should be sorted in around 1 month.[/quote]
So, this announcement is a bit premature in a Qt forum, perhaps.
-
Yeah, I'd say it's a bit premature. It's a good sign that they've obviously been working on Qt support though.
For reference, "this":http://phoronix.com/forums/showthread.php?55896-PathScale-Open-Sources-The-EKOPath-4-Compiler-Suite is the forum thread which I'm basing my "Qt doesn't currently work" claim on - in particular the comments from "codestr0m" from PathScale.
-
I think speed (in the sense of quality of the object code that the compiler produces) is negligible in most of the GUIs. CPUs are dead idling in 99.5 % of the time here.
Hardly any developer (not one that I talked to) has ever heard of that compiler - should be for a reason :-)
It's definitely an interesting alternative if you're doing number crunching.
Speaking of new compilers, I would be more excited if Qt would officially run on LLVM and had support in Creator, due to it's more advanced code parsing and debugging capabilities ;-P
-
[quote author="Volker" date="1308043384"]
Hardly any developer (not one that I talked to) has ever heard of that compiler - should be for a reason :-)[/quote]What compiler now?[quote author="Volker" date="1308043384"]It's definitely an interesting alternative if you're doing number crunching.[/quote] I imagine just number crunching wouldn't be enough to go for a compiler switch, or an extra compiler to support. I do wonder by how much this compiler outperforms gcc and to what extent that would actually have an effect on desktops. On the other hand, why not share the knowledge with gcc and make gcc compiled code perform better?
-
[quote author="Franzk" date="1308050748"][quote author="Volker" date="1308043384"]
Hardly any developer (not one that I talked to) has ever heard of that compiler - should be for a reason :-)[/quote]What compiler now?
[/quote]I meant EKOPath.
[quote author="Franzk" date="1308050748"]
[quote author="Volker" date="1308043384"]It's definitely an interesting alternative if you're doing number crunching.[/quote] I imagine just number crunching wouldn't be enough to go for a compiler switch, or an extra compiler to support. I do wonder by how much this compiler outperforms gcc and to what extent that would actually have an effect on desktops. On the other hand, why not share the knowledge with gcc and make gcc compiled code perform better?
[/quote]Reads like another good idea.
-
[quote author="Volker" date="1308051598"][quote author="Franzk" date="1308050748"][quote author="Volker" date="1308043384"]
Hardly any developer (not one that I talked to) has ever heard of that compiler - should be for a reason :-)[/quote]What compiler now?
[/quote]I meant EKOPath.
[/quote]sigh Another piece of irony failed miserably... :P[quote author="Volker" date="1308051598"][quote author="Franzk" date="1308050748"]
I imagine just number crunching wouldn't be enough to go for a compiler switch, or an extra compiler to support. I do wonder by how much this compiler outperforms gcc and to what extent that would actually have an effect on desktops. On the other hand, why not share the knowledge with gcc and make gcc compiled code perform better?
[/quote]Reads like another good idea. [/quote]
That's what I thought.
-
Franzk :
The benchmarks at Phoronix ("1":http://www.phoronix.com/vr.php?view=16119 , "2":http://www.phoronix.com/scan.php?page=news_item&px=OTU1MQ , "3":http://www.phoronix.com/scan.php?page=news_item&px=OTU1Mg ) indicate that, at least for some workloads, the advantages are significant. (note: "Dirndl" was the codename used for this announcement on phoronix before it was official)
There was also some discussion as to why it wouldn't be easy to combine EKOpath with GCC in the thread I linked to earlier.
I'm also not sure how much benefit this compiler would have for your average desktop application, but I do think it looks interesting.
-
It's meant as a complimentary addition to Gcc for HPC once we get into
building your interfaces on the graphics stack using OpenGL then you will see were the PathScale
compiler shines.If you have heard of Open64 and know of it's histroy, then you would know that Open64 compiler exists because of PathScale. Granted they don't share much in common anymore. Lol all I had to do was type in
CUDA click on the Wikipedia link and not even a paragraph down we see mention of the PathScale compiler.I can point out a dozen different areas in Qt where you would switch over to using the PathScale compiler
for performance reasons (anywheres a pixel is drawn for one in OpenGL/OpenCL/Physics). -
[quote author="zester" date="1308058359"]It's meant as a complimentary addition to Gcc for HPC once we get into building your interfaces on the graphics stack using OpenGL then you will see were the PathScale compiler shines.[/quote] That would mean it is binary compatible with gcc? That would be a nice one for using this compiler for certain parts (files/libs) of the project alone.
[quote author="zester" date="1308058359"]I can point out a dozen different areas in Qt where you would switch over to using the PathScale compiler for performance reasons (anywheres a pixel is drawn for one (OpenGL/OpenCL/Physics)).[/quote] I'm quite sure a lot of companies and projects will benefit from this compiler if the numbers are correct. However, it seems PathScale isn't too sure yet about the overall performance on other projects, but I might have interpreted this incorrectly from their forums. Once it becomes available on Gentoo I might just try it out on some of our own mathmagic and see what the benchmarks do.
-
bq. That would mean it is binary compatible with gcc?
yes, in most cases. There might be some c++ cases where this won't work.
But you can always file a bug report when you find one of those cases.Qt - There's one blocking bug there working on fixing.
They expect it may take them another month or less to get that resolved. -
I think the reason so few people outside of HPC have heard of Pathscale or EKOpath is that the compiler was so expensive. I think it was somewhere north of $1800 per licence before the made it available under the GPL!
Until they get Qt compiling there's not really any way of knowing what it'll be like. It could be that the optimisations they use just don't have that much of an effect on the Qt codebase.
-
If the benchmarks that are on phoronix are correct and can be applied to the Linux Kernel or projects like Ext4 or Btrfs then Qt will see a dramatic speed increase for those that use Linux or one of those filesystems.
I personally work with OGRE3D/Bullet alot and use Qt for everything
from HUD elements, Input, Networking, Scripting, XML, ...OGRE3D/Bullet are the areas that I am hoping to see a performance boost.
And no 90% of all Qt users probably won't have any use for it. But it benefits OpenBSD, FreeBSD, NetBSD
Qt users directly sooo its a win. :)
