[nSLUG] Software Freedom Day

Daniel Morrison draker at gmail.com
Sun Sep 13 00:15:10 ADT 2009


I forgot to mention in my previous email that I agreed with your
comments regarding compilation optimization for specific processor
features being the main performance advantage in the 64-bit builds.
This is probably the main reason why Slackware performance increases
would be greater than other distros. Slackware's 32-bit version, by
design, will run on a 386. By moving to 64-bit, new baseline options
are set for much more modern processors.

That was the main reason for my interest in Gentoo, some time back. I
figured I could make better us of my hardware by custom-compiling
everything. But in the end, the lure of having all the work done for
me (by the Slackware maintainers) was worth the small performance hit.
After all, the computer spends most of it's time waiting for our slow
brains.

I'm prepared to trust that Slackware64 will be up to the same high
standard of quality as traditional Slackware, and since I have a
64-bit platform, I'm going to try it. It may turn out that there are
lots of problems (particularly in packages I compile myself); I'll
have to see. But unless there are evident problems, I'm not concerned
about moving to 64-bit, even if the rationale (better optimizations)
is just a side effect of policy, and not directly related to technical
limitations.

I'm not at all convinced that it is "only applications that take
advantage of those extensions that get any significant speed boost".
Of course I'm not providing real data, but then again, neither are
you. It is my understanding that there are many CPU-specific
optimizations that gcc applies to any/all code, as well as some
math-specific extensions that may apply to ordinary calculations. And
as an extreme case... oops, I was going to give the example of default
slackware kernels still having FPU emulation (whereas the 64-bit
versions, obviously, would not need this). However, contrary to my
opening paragraph, I find that slackware.com states minimum
requirement is a 486, not a 386. So I suppose they really mean 486DX
(486SX had no FPU) and that an FPU is now required. Hehe, that's some
pretty old memories.

Anyhow, I'm going to give it a try one day and if it's a disaster,
I'll go back. But I'm fairly confident.

-D.

2009/9/12 Ian Campbell <ian at slu.ms>:
> On Sat, Sep 12, 2009 at 09:59:55PM -0300, Daniel Morrison wrote:
>>
>> http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks
>
> What they mention, but don't mark particularly clear, is that it's not
> a comparison between 32 and 64bit it's a comparison between optimized
> and unoptimized code.
>
> What's funny is that even without modern flags for GCC there are still
> only 3 convincing victories for 64bit (kernel, ogg, blender) and of
> those only the kernel one is actually a benefit of a 64bit proc as GCC
> benefits from more GP registers.
>
> Ogg has cpu-specific ASM code, on a 32bit compile it's just using
> stock instructions. On the x86_64 builds it's using SSE2 so it gets a
> performance increase -- shocking. On the other hand, if they'd tested
> with LAME instead they would have gotten matching results for the two
> installs, LAME determines which optimizations to use at runtime.
>
> I've never looked at Blender's code but I'd be very surprised if it
> wasn't the same issue at play.
>
> Note as well that it's ONLY applications that take advantage of those
> extensions that get any significant speed boost, the vast majority of
> your applications will run exactly the same. As a Slackware user,
> you're better off just building anything like that by hand and keeping
> a 32bit system unless you're over 4G ;)



More information about the nSLUG mailing list