More Details From The EKOPath Open-Source Launch
|
|
Comments (11)
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.
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.
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.
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.....
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.
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.
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: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

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.