If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Announcement

Collapse

No announcement yet.

The Performance Of Five Linux Distributions From Early 2016 To The End Of 2018

The Performance Of Five Linux Distributions From Early 2016 To The End Of 2018

12-21-2018, 11:10 AM

Phoronix: The Performance Of Five Linux Distributions From Early 2016 To The End Of 2018

With the end of another year upon us, there has been the start of many year-end benchmark comparisons looking at how various aspects of Linux performance has evolved over 2018. In this comparison though is going back further than that and seeing how five Linux distributions have experienced performance changes over the past nearly three years -- using the CentOS, Clear Linux, Fedora, and openSUSE Linux distribution releases from early 2016 to their latest releases as of right now with their stable updates.

Comment

I was just wondering recently if we took some really old gnu/linux (as in with gcc etc.) and managed to back-port drivers to it if it might not outperform today's stuff even with older optimizations and unutilized CPU instructions.

it almost seems like things are just getting slower and slower

4 likes

Comment

Heh. I just installed OpenSuse 15.0, finished all the updating and rebooting, and I'm on the first real working bootup so I'm in the process of getting it all customized to my liking (just finished browser safety plugins). I was going to use the 15.1 Alpha and tried it for a few hours last night, but I came to my senses and realized I shouldn't really learn Suse with it's alpha release.

Since it's been a painless experience, everything just works, and the desktop is fast and responsive, as long as it stays like that I don't really care if the numbers in benchmarks aren't necessarily the best.

Comment

They are, especially with Intel hardware and the spectre/meltdown fixes.

It would be interesting to see how an AMD FX 8350 handles in the same tests. AFAIK, AMD CPU's aren't effected by the mitigation fixes nearly as bad as Intel processors.

It's perplexing tho. New processors add things like vectors and other niceties and compilers improve all the time with better optimizations.

Where's the issue? I'm not even considering "userland bloat" here, just same thing compiled and run on an older software setup and newer. If it really is slower then something went wrong somewhere. Spectre/Meltdown notwithstanding.

Comment

I was just wondering recently if we took some really old gnu/linux (as in with gcc etc.) and managed to back-port drivers to it if it might not outperform today's stuff even with older optimizations and unutilized CPU instructions.

it almost seems like things are just getting slower and slower

Really the only thing that is getting slower are browsers. And we use the interweb more and more so things seem slower where actually they are faster if it wasn't for an idiotic piece of garbage that is HTML5/JavaCrap

Comment

It's perplexing tho. New processors add things like vectors and other niceties and compilers improve all the time with better optimizations.

Where's the issue? I'm not even considering "userland bloat" here, just same thing compiled and run on an older software setup and newer. If it really is slower then something went wrong somewhere. Spectre/Meltdown notwithstanding.

Processors might be getting more/better instructions, faster speeds, and more threads as well as constant compiler improvements, but none of that matters if all the software available isn't taking advantage of them.

Just look at the average Linux distribution for an idea of what I mean. They're damn near all compiled with support for x86_64 processors from the earliest of generations. Running Debian x64 on a Ryzen is like running Debian i386 on a Pentium 4 because of what's essentially legacy support due to using march=generic. Clear doesn't do that and they run with more aggressive compiler settings so they come out on top.

I'm honestly surprised some sort of Ubuntu Source or Suse Source type of distribution hasn't been created -- something LTS with optimized & native compiled packages where people don't have to worry about useflags and compiler settings, just a "compiling packages, come back in a day or two" updater. Most people wouldn't need it, but those who do need all the performance they can get might appreciate an easy to use source based distribution.

1 like

Comment

Processors might be getting more/better instructions, faster speeds, and more threads as well as constant compiler improvements, but none of that matters if all the software available isn't taking advantage of them.

Just look at the average Linux distribution for an idea of what I mean. They're damn near all compiled with support for x86_64 processors from the earliest of generations. Running Debian x64 on a Ryzen is like running Debian i386 on a Pentium 4 because of what's essentially legacy support due to using march=generic. Clear doesn't do that and they run with more aggressive compiler settings so they come out on top.

I'm honestly surprised some sort of Ubuntu Source or Suse Source type of distribution hasn't been created -- something LTS with optimized & native compiled packages where people don't have to worry about useflags and compiler settings, just a "compiling packages, come back in a day or two" updater. Most people wouldn't need it, but those who do need all the performance they can get might appreciate an easy to use source based distribution.

I'd say the benchmarks tend to suggest that even Clear Linux shows the same trend of performance regressions from then to now, so your argument doesn't entirely hold water. Aggressive optimizations isn't the problem according to those benchmarks. Or at least, it's not so simple as just adding -march=native to GCC. A quick glance at the numbers is roughly along the expected slowdown with the introduction of Spectre mitigations + some on top of that. It would be worthwhile for the FLOSS community to find out what exactly the problem is rather than waving it off as simply a lack of not using generational targeted binaries.