[nSLUG] Software Freedom Day
draker at gmail.com
Sat Sep 12 21:59:55 ADT 2009
That article with benchmarks (thanks for the link) dates from 2006,
using Ubuntu 6. And I agree -- I am still running 32-bit on my 64-bit
hardware that dates from roughly 2006.
As many of you may remember, Slackware is my distro of choice. And
once again, Slackware has been taking the common sense approach. There
has been no official 64-bit Slackware... until now.
Slackware32/64 13.0 was released two weeks ago. There is an excellent
article about it in Linux Magazine:
Eric Hameleers, the principal mover behind Slackware64, says:
"During those years, there was no real pressure to develop an official
Slackware port - suitable hardware was not yet a commodity, and a lot
of software needed to be moderately to heavily patched in order to
compile on a x86_64 platform. That was a sign to me that it was worth
waiting for things to mature a bit more."
"Pat [Volkerding] was still not convinced about the necessity for an
official 64-bit port, so I decided that I should just go ahead and let
him judge based on what I could produce."
"somewhere in December 2008... [Pat] ran several computational
benchmarks on Slackware64 and was instantly hooked when he saw speed
increases between 20 and 40 percent for some of the benchmarks,
compared to 32bit Slackware. That marked the moment when it became a
[10 months of work and testing and then]
CS: What issues are there with the current 64-bit version of
Slackware? What is still to be finalised?
EH: To be honest, it looks like there are no issues specific to the
64-bit port left. The development cycle for 13.0 has been extremely
intensive (if not completely exhausting) in order to get everything
working the way Pat and the team wanted.
This is why I like Slackware. Much like Linus and the kernel, if asked
when the next version of Slackware will be released, the answer is
"when it's ready". Decisions regarding Slackware are made on a
technical basis, rather than from a marketing standpoint.
I haven't tried Slack64 for myself, but I have burnt the DVD, and will
slowly be clearing space on my disk in preparation. Also, RAM prices
are lower nowadays, so the timing is good -- I'm thinking of doubling
to 4 GB once I have the 64-bit OS installed.
As for the benchmarks -- no I don't have any hard data... I just trust
the Slackware team, and I can do some tests on my system later.
However with regard to Ubuntu, recent tests with version 9 do show a
2009/9/12 Ian Campbell <ian at slu.ms>:
> On Sat, Sep 12, 2009 at 08:54:25PM -0300, jwark at eastlink.ca wrote:
>> I have a laptop with an AMD64 processor and 1GB of RAM on which
>> I run Debian 64bit. I use gkrellm to monitor the system. I have tried
>> various 32bit distros on this system and find that CPU utiliztion is
>> significantly *less* with the 64bit distro.
> Saying I'm skeptical is perhaps a bit harsh given that... I mean
> you're seeing what you're seeing, but this:
> shows approximately what you'd (general you, not you specifically I
> suppose) expect.
> 64bit gives you more address space and more general purpose registers.
> The latter, under some circumstances, *can* give you a performance
> boost although in most cases it won't. As you can see from the charts,
> GCC gets a bump, with everything everything else it has a minimal
> effect (positive or negative.)
> On the other hand, the former can easily worsen performance. Pointers
> are now twice the size, with predictable effects... I have a client
> with a perl script that fetches all of a poorly designed database
> (think hundreds of columns, tens of thousands of rows) into an array
> of hashes. The machine he was on was replaced with a 64bit install and
> his RAM usage absolutely exploded.
> I'm not sure why you would see a lower load.
> Actually that's not true, one possibility is that the x86 packages for
> most distros are compiled with a 486 or 686 target, which means none
> of the newer instruction set extensions. x86_64 guarantees that at
> least SSE and SSE2 etc. will be there.
More information about the nSLUG