Advanced

More Details From The EKOPath Open-Source Launch

Posted by Scott_Ruecker on · 11 comments
Phoronix; By Michael Larabel
Mail this story
Print this story

Yesterday we delivered the news that PathScale was open-sourcing their high-performance EKOPath compiler suite, which in previous days was talked about on Phoronix under the Dirndl codename when showing how fast this compiler was in relation to GCC. The community indeed is excited for EKOPath now being open-source (GPLv3) and in the Phoronix Forums are currently 15+ pages of comments. In this news posting are some more EKOPath details from the forums and some of what Christopher Bergström, PathScale's CTO, has relayed in our community portal.

Full Story

  Nav
» Read more about: Story Type: News Story; Groups: Community

» Get new stories by e-mail: nightly or as they are published

« Return to the newswire homepage

Comments (11)

GCC has always been there, incredible in its ability to compile on and for just about any piece of hardware. Just recently compiled dig for my shovel, meaning that I can check domain ownership while gardening...

OK, maybe not, but GCC's claim to fame is the broad level of support.

Not speed.

Like Tony Shalhoub's quirky detective, it's biggest gift is a blessing -- and a curse. Other compilers can get away with being fussy about where they'll run, allowing them to be optimized in ways that gcc apparently can't (or simply isn't). As a result, free software tends to give proprietary stuff a head start going out the door.

Nice to see the potential for eating up some of that head start. The non-free eko compiler will take advantage of GPUs as well as managing multiple cores. The price of that puppy will put it out of hobbyist range, but may give distros another reason to exist -- highly optimized software.

Who knows?

Good news at any rate.



Hmm, those like me who compile KDE4 themselves may be interested I suggest.

KDE really looks bloated, but maybe that's only the part that doesn't need compilation. Like 300 Mb for Oxygen.

Yet another KDE-Win! "The longer the discussion, the bigger the chance of KDE4 bashing!"

Yeah, sorry for that. Nepomuk and KDE-libs compiling atm, already taking over three quarters on my dualcore 3GB desktop. Just because I wanted to upgrade my KWallet. Thank the ubercreature KDE-PIM meta compiled overnight.
Is compiler performance really that big a deal for many people?

I would prefer that they concentrated on the performance of the resultant code.
Compiler benchmarks usually include testing for both code compilation, and speed of the native executable.
skelband its important to those of us who compile everything, too many variables in the end result to pin the speed of the resultant code execution on the compiler alone, so while not a meaningless metric its a pointless one.
@skelband --

In this case, compiler performance is referring to code performance on 64-bit multi-core systems. One reason for eko's performance advantage is it's ability to exploit multi-core processors in the compiled code.
skelband: Try Gentoo, and then please revisit your question. It will no longer be a question anymore.
I have used this compiler for 5 years now on opteron clusters. My main applications have been number crunching codes with many do loops (fortran). The executables run so fast compared to other compilers executables it isn't funny. I have heard that binary blob sizes are big but of course that hasn't bothered me. You have to be a bit careful with the high optimization flags as you can get inconsistent results. On the -O3 flag it flies though so -O5 isn't often needed.

It will be very interesting to see the effect on desktop interfaces and apps like open office. I would not be shocked to see speed ups of 100% based on my fp work but we shall see.....
Quoting:It will be very interesting to see the effect on desktop interfaces and apps like open office


Well, good compilers might matter a lot for number-crunching apps, but it's much, much less visible in interactive apps. But I hope I can be surprised here :)
>but it's much, much less visible in interactive apps

Fail. Good compilers matter as much in interactive apps as in anything else. Lots and lots of work going on there. I suspect what you mean is that they matter less in the application layer of an interactive act that relies on toolsets --- ie, if the toolset is slow, the app will be slow.
@hkwint: Try Gentoo, and then please revisit your question. It will no longer be a question anymore.

Ah yes, I did used to use Gentoo at one point and the compilation of everything was a bit of a pain.

I was never really sure if the performance advantages of compiling specifically for my platform was sufficient to justify the compilation of everything although I guess that depends on the kind of computation that you do.

At that stage IIRC, practically all distributed binaries were compiled for 80386 code compatibility.

Post a comment

A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.

Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help

Sign up and post (it is free)  or  Log in and post