On 05/12/2010 07:03 PM, Stefan Monnier wrote: >> 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? You can push twice the data, which means faster CPU to memory utilization for CPU intensive applications. Flash anyone? >> * 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. You must not have run into this issue much. 4:4 kernel splits are the best you can do on a 32-bit system, but it comes at a performance cost. Splitting and performance are never an issue on 64-bit until you've reache 17 EB of RAM. >> * 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. >> * more breathing room for mmap()'d files > > Again, unlikely he'll ever notice it (otherwise he wouldn't have asked). See above. >> * 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. >> * 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. Poor software development is hardly an argument against choosing a CPU architecture. >> If you have the hardware, you should definitely be running a 64-bit >> operating system, even if you don't have 4GB+ of RAM. > > If you have to ask, you probably won't notice any difference > either way. 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? -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O
Attachment:
signature.asc
Description: OpenPGP digital signature