Re: What to choose for Core i5 64 bits?
>>> The 64-bit vs 32-bit argument is multi-faceted. It gets much deeper than
>>> just addressing more than 3GB of RAM:
>>> * twice the transfer width on the bus
>> Nope, no difference on the bus. Most accesses will be
>> cache-line-sized anyway at that level.
> You're kidding, right?
Not at all.
> You can push twice the data, which means faster
> CPU to memory utilization for CPU intensive applications.
You can push twice as much data, yes, but only for some data (e.g. not
floating point, nor SSE2 vectors, nor pointers) and that's only really
true between the CPU and the 1st (and maybe 2nd) level of cache.
Depends a lot on the detail of your workload, but in most cases above
that you're limited by your memory bandwidth and the cache ensures that
most transfers between the main memory and the various levels of cache
take place in cache-line chunks.
>>> * no memory split issues
>> For <=3GB systems, that makes no difference. And as someone running
>> a bigmem kernel on a 4GB system, I can say that even for other systems,
>> it's not necessarily relevant.
> It's very relevant.
It can be relevant. But not necessarily so. For heavily loaded servers
it may make a significant difference. For a home (desk|lap)top you'd
have to make a dedicated effort to be able to measure the difference,
let alone notice it without measuring it.
> You must not have run into this issue much.
Indeed. And that's exactly my point.
>>> * increased virtual address space
>> Right. Unlikely he'll ever notice it.
> Whether he will or won't isn't the issue. I'm not discussing use cases,
> I'm discussing the facts on why 64-bit is superior to 32-bit.
And you conveniently disregard the reasons why 32bit can be superior to
64bit. I don't claim 32bit is always superior, mind you.
As a compiler writer, I know that some parts of the amd64 architecture
like the 16 registers make the system faster, but I also know that for
pointer-heavy and/or dynamically typed languages (Python, Javascript,
..., in some cases Java) most objects end up being twice as large, so
the "extra oomph" you might get from 64bit ops is all eaten up by having
to manipulate twice as many bits, which reduces the effectiveness of
your caches.
>>> * deeper nested system calls with increased stability
>> I see no evidence of increased stability and have no idea what you want
>> to say with "deeper nested system calls".
> I'll give you an example. Use XFS on LVM, and export the mount over NFS.
> The nested system calls in this scenario will cause a kernel oops on any
> 4K 32-bit kernel nearly every time (the default for Debian GNU/Linux,
> Fedora, Ubuntu, openSUSE, etc). On a 64-bit kernel, because you have the
> ability to make deeper nested system calls, you have stability in your
> infrastructure. Something that couldn't be achieved with a 32-bit kernel.
I didn't know that the amd64 kernels had larger kernel stacks.
Tho I guess it makes sense: they need them to be larger since the 64bit
pointers eat up the stack faster. Clearly, it's not a big deal for most
people since it's trivial to increase the kernel stack space and yet the
prevailing choice has been not to increase it for x86.
>>> * certain applications and operations will execute faster
>> Yup. And others will be slower since you'll have to move around more
>> data (up to twice as much if your data is made up mostly of pointers),
>> which means that the apparent cache and RAM size will end up
>> being reduced.
> The same would be said for a 32-bit application implemented the same way.
A 32bit application will use 32bit pointers, a 64bit application will
use 64bit pointers (other than very rare corner cases), no matter how
you implement them. So any application will use twice as much
space per pointer when compiled for amd64 than for x86.
> Poor software development is hardly an argument against choosing a
> CPU architecture.
If you mean that applications that use a lot of pointers are poorly
designed, then you're welcome to improve them, but for most end users
it's not an option, and for many implementation fields noone knows how
to even start doing it. So it's often not so much an issue of software
design but of the kind of application. For numerical software and some
classes of "web server or database server" applications this is not much
of an issue. For compilers it's a whole other ball game.
> To each their own. I for one want to get my money out of my hardware.
> If you don't want a 64-bit system, then why did you pay for it?
Nowadays if you want a modern (desk|lap)top machine, you'll get
a processor that understands the amd64 ISA, whether you want it or not.
And for many benchmarks, the results will be pretty much the same
whether you run x86 or amd64 software on it. Given the OP's question he
probably did not buy his machine because it's 64bit, but just because he
wanted "a new PC".
Stefan
Reply to: