It might be fun to benchmark against Gentoo. Of course, no self respecting Gentoo user would ever believe them if they came out not showing Gentoo to be far superior.

No one seems to believe results unless they show their distro being the best... just look at this thread!

I don't expect Slackware to be the fastest, in fact I'd bet on Gentoo, but certainly I don't believe that Slackware is much slower than the other distros like the biased phoronix benchmark shows. I don't expect huge differences, just small ones. My own benchmark, although not in-depth shows that it's not possible for Slackware to be much slower.

1 members found this post helpful.

With proper settings I expect Gentoo to be superior. But how would you test it anyway? Package-specific tests do not really reflect the overall performance of the system. One could have Slackware and just rebuild a specific package with native settings and it would be almost the same as Gentoo already i.e. if the package does really call much libraries routines. Tests would also vary depending on the instructions that could be included during build and other flags like -floop-block and -fgraphite-identity from graphite. -O3 seemed to yield faster builds (before) but I'm not sure about newer machines now. -unroll-loops as well is not essentially helpful most of the time and just cause too much memory usage. Using graphite is much better to arrange loops to make them work optimized within the native processor's cache.

I would never use '-O3' unless I wanted an unstable system, but I suppose that's normal for Gentoo.

I used -O3 before with stronger options and my system was stable.

I'm quite skeptic. Are you sure that's always true?
Parallel-processing? Not always true in -most- operations, afaik.
I'm not sure if that's the best, but do you think that could even be done with normal packages as well? Or do you mean the packages should be hacked first to have them optimized?

Too bad, but I did consider that. That's old info. I read that page a long time ago. And I don't use unroll-loops. Also, we're not talking about principles here. We're just describing how things really are.

Basically I just used the term cycles and it's just an example. The concept of gaining efficiency by using encapsulated functions is what I meant.
Well I was actually thinking about some newer SSE2 instructions over SSE or lower, not old ones.

Actually Gentoo's documentation recommends using the -O2 compile flags, not -O3. In fact any and all "from source" distributions all default to using -O2 as their environmental default compile flag.

Being the "fastest" isn't always equal to being the most "stable" in any regards. Real world usage and longevity of a system's stability factors against other software and added dependencies will outweight any synthetic benchmarks by huge volumes.

Here's a suggestion, let you're own usage be your own benchmark and trust distributions you've used that have been stable, offered what you needed, and were the easiest to use, administrate, and maintain over time.

I don't need a benchmark to tell me which system is the best. I just had to figure it out for myself and then use it.

@ReaperX7: A vague part of my memory tells that there was actually a time in Gentoo when "-O3 -fomit-frame-pointer -pipe" was recommended, but I'm no longer certain about that. Perhaps if not on the official documentation, it was on a forum post or some updates of list of stable flags somewhere. There might have been a time in Gentoo that even -O3-based compilation was also heavily tested.

With respect to choosing Slackware for stability (and probably, adaptability as well), I won't really question that after all I myself would still prefer Slackware for normal, simple and easier deployments, but with respect to pointing out that Slackware is naturally slower due to the fact that it's more generic and less system-specific, I don't think I could deny myself about that, rationally. It's also based from experience. Anyhow it's not only Slackware that distributes packages generically, I think. There are many distros that are generic as well, but mainly as how I composed my first post I mainly compare it to more optimized distros especially Gentoo or else the thought would be without meaning.

I would like to add something more to the idea: There might be not much difference perhaps on 64 builds as I'm not sure if the compiler makes use of SSE3+ instructions already as I tried to force it but it didn't show on binary dump analysis; maybe the tasks are just rare for the new instructions to be used or perhaps just bad config on my part, or the compiler was patched, not sure, but on 32/i486 there are notable ones. I'm not also sure if Slackware 64 makes use of SSE2 already since it's also available in AMD products I think.

Any x86_64 CPU has SSE2 capabilities, so it would be somewhat foolish not to use it.

@TobiSGD: I had the idea but I just gave an allowance. Reading wikipedia somehow confirms it.

1 members found this post helpful.

Mainstream compilers like Visual C++ only use generic instructions, so CPU vendors are optimizing there to look good in mainstream application benchmarks. They don't go to Phoronix.

Even on a dual core Atom CPU, you can gain almost factor 4 by just using openssl -multi 4 with AES128. And of course you can skyrockit it by employing AESNI (not on the Atom though), which a compiler can't do automatically.

What do you mean with "encapsulated functions"?

SSE is just single-precision floating-point, which isn't very useful outside of games. SSE2 sometimes is faster than i387, but also at the cost of precision. So you can break applications by applying SSE2 via GCC flags.

Instruction set extensions are best to be used by developers of performance-sensitive applications at the corresponding hot-spots in the code.

So these instructions do processing silently in multiple internal threads?
Well just like AESNI. It does one big step easily with one instruction as compared to calling many generic instructions. I refer that one instruction as an encapsulated function.
I haven't examined instructions much yet but it's not only SSE2 that's around now. What do you think about STTNI of SSE 4.2?