The Old Joel on Software Forum: Part 4 (of 5)

Is 64-bit worth it?

Would those of you with 64 bit processors and 64 bit versions of Windows care to comment on how you like them? Is Linux/GCC up to 64-bit yet?

I'm thinking of building a new computer but I can't seem to decide whether or not I should go with a 64-bit processor. I'm currently leaning towards a 3.4GHZ Pentium 4.

Software Craftsman
Wednesday, May 12, 2004

If you really want speed, you should also look into a dual-proc system. My dual P3 800MHz still feels generally snappier than my P4 1.8GHz system.

I'm figuring a dual 2.66GHz Xeon would scream. :-)

[I can't comment on equivalent AMD systems, but the same logic applies - two CPUs are better than one]

Philo

Philo
Wednesday, May 12, 2004

I would think that you wouldn't notice a difference with two processors unless you are running a server or perhaps compiling in the background while playing a game or some other out of the ordinary tasks. Why is it that two processors make a difference? I believe the Pentium 4 has hyperthreading technology which make the processor appear to the OS as 2 processors?

Software Craftsman
Wednesday, May 12, 2004

Two processors are better than one because Windows has bunches of threads running at the same time even when no applications are open.

As for P4 hyperthreading - doesn't software have to be specifically compiled to take advantage of that?

Ankur
Wednesday, May 12, 2004

"I'm thinking of building a new computer but I can't seem to decide whether or not I should go with a 64-bit processor. I'm currently leaning towards a 3.4GHZ Pentium 4."

AMD64 is a sweet architecture. Your OS choices are rather limited, though--a Microsoft beta and three or four bleeding edge Linux distros (for servers, SuSE Linux 64 is probably quite stable by now).

GCC supposedly works pretty well, and the Linux kernel is supposed to be fine. You could run a 32-bit Linux distro with a 64-bit kernel and a 64-bit toolchain for experimentation.

Apparently, though, you can't use the proprietary nVidia or ATI drivers with a 64-bit kernel.

Speaking as an occasional compiler geek, AMD64 is really compelling, and the forthcoming Intel chips will all be compatible. From an end-user's perspective, it won't matter until the video games get 64-bit acceleration.

J. Random Hacker
Wednesday, May 12, 2004

The main benefit of moving from 32 to 64 bits is the increase in addressable memory. Most programs will actually run slower in 64 bits, all else being equal, since data structures get larger with the larger pointers. It seems the additional efficiency of the AMD64 instruction set (more general-purpose registers) could overcome this.

Dan Maas
Wednesday, May 12, 2004

Dan: Preliminary Linux benchmarking suggests that AMD64's 64-bit mode is about 10% faster than 32-bit mode, thanks to the extra registers. Of course, this is heavily application dependent--I/O-bound programs will slow down, but programs with lots of gnarly computation will speed up.

And if you're doing anything which can actually take advantage of 64-bit registers, you may see performance increase dramatically. Multiplication of really large integers, for example, can get a lot faster.

J. Random Hacker
Wednesday, May 12, 2004

Regarding hyperthreading: your CPU appears as two processors to the operating system. So any OS which can take advantage of dual processors can also take advantage of hyperthreading. Any multithreaded software will then take advantage of the functionality.

However, it's best to use an operating system specifically optimized for hyperthreading. (It has to do with the way that the OS manages idle CPU resources.) Windows XP was the first version of Windows to contain explicit hyperthreading support. Presumably Windows 2003 Server does too; I don't know about Linux

Ryan
Wednesday, May 12, 2004

If you run a vldb, yes by all means.

Mike
Wednesday, May 12, 2004

In my experience, once you have enough RAM, the single largest factor in perceptible performance is not CPU, but rather speed of the disk. The more excess RAM you have, the better off you are, because that means there are more space available for caching.

For example, the first time I do a commit from TortoiseSVN on my main source directory, it takes about 45 seconds to scour the drive in search of changed and non-versioned files. The disk goes nuts. After the directory structure is in RAM (which, in my case, never leaves... 2GB of RAM), it takes about 3 seconds. Compiles are ridiculously fast, too.

As a gamer, I'd pick an Athlon 64 for raw performance. As a developer, I have to say Hyperthreaded P4, because it really helps uncover threading issues. If I absolutely had to have multi-proc, I wouldn't touch the 2 year old Xeon architecture. That's nuts... the Opteron 2-series is much more cost effective, and WAY faster.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, May 13, 2004

The biggest reason for me to prefer an AMD64 over the latest Intel is Cool and Quiet. It's a laptop type feature where the processor power dissipation drops back to 22 Watt when idling. And when the CPU cooler fan lowers its RPM with it, your box will be much cooler and quieter.

The Intel Pentium 4 Prescott is using about 100Watt. It makes very much sense that Intel cancelled its successor (Tejas) and decided to develop future CPUs on basis of the great Pentium-M.

Plus, the AMD64 is faster when compiling code.

And while it's handy to have a processor that will be able to run 64 bits Windows or Linux, I would stick with 32 bits while somebody else is finding the bugs in all those new drivers.

Jan Derk
Thursday, May 13, 2004

Linux has been doing 64 bits perfectly for over ten years now (UltraSPARCs, Alphas and PowerPCs, probably others I'm not aware of too). It has also been doing 64-bit AMD for quite some time now, and --- as previously mentioned here -- support has already started to appear from mainstream distributions.

It will take lots of time until you feel the difference under Windows, because unless a new 64 bit version of software you use comes out, you're still stuck in 32 bit mode.

If you plan to upgrade within a year or two, don't give the 64-bit factor too much weight - unless you mostly use Linux / BSD, the 64-bitness won't be felt (except, possibly, by your purse).

Ori Berger
Thursday, May 13, 2004

Regarding the value of dual processors - if you're using a single-CPU system, especially one with an older IDE card, you know all those times that your system stops responding during disk accesses? Doesn't happen. When an application has a single-threaded UI with a blocking thread that ties up your system? Doesn't happen. When there's *something* going on in your system that means right-clicking on the task bar and waiting two minutes for the task manager to come up? Doesn't happen.

In addition, with an SMP-aware OS, doing two things at once means you're getting the full benefit of both processors.

My understanding of HT is that it's "mostly" dual-pipelined, but not completely. But I'll grant that HT would be better than non-HT.

Philo

Philo
Thursday, May 13, 2004

"Regarding the value of dual processors - if you're using a single-CPU system, especially one with an older IDE card, you know all those times that your system stops responding during disk accesses? Doesn't happen. When an application has a single-threaded UI with a blocking thread that ties up your system? Doesn't happen. When there's *something* going on in your system that means right-clicking on the task bar and waiting two minutes for the task manager to come up? Doesn't happen."

Err... I thought that one of the principal aims of pre-emptive multitasking was to ensure that processes only received a certain slice of CPU time before control was wrested from them an returned to the OS itself or, in the absence of any pressing system requirement, to the next (user) process. Doesn't this happen even to I/O blocked processes, which is why one's supposed to check for the 'interrupted' return code (E_INTR? can't remember as it's been a long time since is actually had to look) when calling routines like read().

Am I to infer from Philo's comments that Windows doesn't do this?

David Roper
Thursday, May 13, 2004

If it's the OS loading virtual memory from the disk, it shouldn't pre-empt itself. . .

Elephant
Thursday, May 13, 2004

I'll have to second Philo on the dual processors. I also run dual P3's 800 mhz with SCSI HD's with windows XP. The system just feels much more responsive than faster single processor machines.

Bill Rushmore
Thursday, May 13, 2004

There is a lott more to it than just the dual proccies.
I have two Dell servers running side-by-side, both Dual PIII's 1Ghz, both 512Mb Ram, both running W2K Server. Different chipsets, both SCSI but different type disks, different network adapters.
Running the same set of tasks on one machine screams, whereas the other is a dowg.

Just me (Sir to you)
Thursday, May 13, 2004

The only time my single proc boxes feel sluggish is when two things are competing for the disk, NEVER when two things are competing for the CPU.

Why? Because Windows gives slightly higher priority to the app with the focus, and the NT kernel is fully re-entrant, which means it's basically impossible to have priority inversion. The window with the focus is responsive, even when other things are chewing the CPU up.

We're mostly developers here. This is easy to check. Write a simple program that thrashes the CPU, and another that thrashes the disk. Now, tell me which one causes the most issues, even on a single proc box.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, May 13, 2004