Dual-core Systems Necessary for Business Users?

Lam1969 writes "Hygeia CIO Rod Hamilton doubts that most business users really need dual-core processors: 'Though we are getting a couple to try out, the need to acquire this new technology for legitimate business purposes is grey at best. The lower power consumption which improves battery life is persuasive for regular travelers, but for the average user there seems no need to make the change. In fact, with the steady increase in browser based applications it might even be possible to argue that prevailing technology is excessive.' Alex Scoble disagrees: 'Multiple core systems are a boon for anyone who runs multiple processes simultaneously and/or have a lot of services, background processes and other apps running at once. Are they worth it at $1000? No, but when you have a choice to get a single core CPU at $250 or a slightly slower multi-core CPU for the same price, you are better off getting the multi-core system and that's where we are in the marketplace right now.' An old timer chimes in: 'I can still remember arguing with a sales person that the standard 20 Mg hardrive offered plenty of capacity and the 40 Mg option was only for people too lazy to clean up their systems now and then. The feeling of smug satisfaction lasted perhaps a week.'"

Comments

Of course it's not necessary

[Sycraft-fu]

In general, for office productivity type stuff, processor speed isn't much of a problem. We find that older CPUs like 1.5GHz P4s are still nice and responsive when loaded with plenty of RAM, and we still use them. Office use (like Word, Excel, e-mail, etc) is a poor benchmark by which to decide how useful a given level of power is, since it usually lags way behind other things in what it needs. I mean an office system also works fine with an integrated Intel video card, but I can think of plenty of things, and not just games, that benefit or mandidate a better one.

Dual cores are useful in business now for some things, a big one I want one for is virtual computers. I maintain the images for all our different kinds of systems as VMs on my computer. Right now, it's really only practical to work on one at a time. If I have one ghosting, that takes up 100% CPU. Loading another is sluggish and just makes the ghost take longer. If I had a second core, I could work on a second one, while the first one sat ghosting. It also precludes me form doing much intensive on my host system, again, just slows the VM down and makes the job take longer.

Overkill Dragging Customers Along

[Anonymous Coward]

Obviously, few (if any) business users need anything more than a Pentium III running at 500 MHz. That processor is perfectly acceptable for business applications like OpenOffice.

Unfortunately, ultimately, most business users will be forced to upgrade to new systems simply because there will no longer be replacement parts for the old systems.

Consider the case of memory modules. 5 years ago, 64MB PC100 SODIMMs were plentiful. Now, they are virtually extinct. By 2010, you will not be able to find any replacement memory modules for your 1999 desktop PC because it requires PC100 non-DDR SDRAM, and no one will sell the stuff. In 2010, the only thing that you can buy is DDR2 SDRAM, Rambus DRAM, or newer-technology DRAM.

In short, by 2010, you will be forced to upgrade for lack of spare parts.

Memory bound, not CPU bound ...

[gstoddart]

In my experience, and I'm a software developer so take that with a grain of salt, the vast majority of people will get more performance from more memory than more CPU speed.

I'm almost never CPU bound if I have enough memory. If I don't have enough memory, I get to watch the maching thrash, and it crawls to a halt. But then I'm I/O bound on my hard-drive.

Dual-CPU/dual-core machines might be useful for scientific applications, graphics, and other things which legitimately require processor speed. But for Word, IM, e-mail, a browser, and whatever else most business users are doing? Not a chance.

Like I said, in my experience, if most people would buy machines with obscene amounts of RAM, and not really worry about their raw CPU speed, they would get far more longeivity out of their machines.

There just aren't that many tasks for which you meaningfully need faster than even the slowest modern CPUs. If you're doing them, you probably know it; go ahead, buy the big-dog.

Repeat after me ... huge whacking gobs of RAM solve more problems than raw compute power. Always has.

Re:Apple is pretty good at this

[Weedlekin]

"Meanwhile, back in non-fanboy reality, most major Windows programs were multithreaded for backgroaund tasks 10 years ago"

This is total BS. I'm a programming contractor, and have been working on Windows since it was in version 2.1 for companies all over the world, exclusively writing code for commercial applications (i.e. not in-house corporate stuff). In nearly 20 years of Windows programming, I have come across _one_ Windows application that is designed for multi-threaded operation besides those that I've written entirely on my own.

Furthermore, read what the GP actually said: much in the Cocoa library adds multi-threading (and automatic scheduling of said threads to multiple CPUs) "free of charge", i.e. you don't have to specifically write multi-threaded code for applications to take advantage of muliple threads (BeOS did this a lot better than OS X). In Windows on the other hand, you have to craft threaded code by hand, which means dealing with both synchronisation using no less than three different types of synchronisation objects, and possible contention issues. This is hard to do and even harder to debug because getting one thing slightly wrong can result in crashes, resource leaks, locked resources that are only released after a re-boot, "orphaned" threads, and a host of other issues that only manifest themselves when two or more threads are performing a specific set of actions concurrently, which is a rare occurrence in code that by definition operates asynchronously.

Which means that multi-threaded code _which works as intended_ is extremely difficult to write under Windows, so few applications bother with it because it adds a whole bunch of issues that single-threaded apps just don't have to deal with. And in the real non-fanboy world of commercial software, more issues means higher costs in both programming and support.

Note that most of the above is true of nearly all multi-threaded environments if one deliberately writes multi-threaded code. Java simplifies a lot of things by having threading built into the language rather than supplied by library calls, and its GC will automatically remove threads when they've finshed executing, even if this happens after the host application has been closed (thereby reducing the probability of permanently orphaned threads cluttering up the system). It cannot however prevent deadlocks due to contention issues because these are caused by poor program design or coding, usually by people who have little or no idea of how design or write multi-threaded code.

in summary then, you (like many on /.) are spouting a bunch of shite based on some stuff you've read somewhere, hence the fact that you do not realise the massive difference between "supports mulñti-threading" and "implicitly adds multi-threading, irrespective of whether an application is explicitly written to be multi-threaded or not". So you paraphrase you, "Meanwhile, back in Slashdot reality, a Windows fanboy is talking out of his arse."