Slashdot Mirror
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.'"
Not really. It all depends on your scheduler. There's just no telling without testing if a given application / OS combination will do better or worse on dual-core.
Remember, two active applications, or two threads in an active application, does not mean those two processes or threads get to be piped to separate cores or processors. That might possibly happen but it probably won't.
I had a boss who loved to get dual-CPU systems. Why? "Because that way one CPU can run the web server and one CPU can run the database." No matter how often I tried to shake that view from his head it never left. (In point of fact, both were context switching in and out of both CPUs pretty regularly).
In short: dual core, like most parallelized technologies, doesn't do nearly as much as you think it does, and won't until our compilers and schedulers get much better than they are now.
All's true that is mistrusted
I'm holding out for one of these.
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.
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.
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.
... huge whacking gobs of RAM solve more problems than raw compute power. Always has.
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
Lost at C:>. Found at C.
With dual processors, Norton AV is grabbing more than 100% CPU at times, even with their own throttling settings enabled.
Maybe Symantec wants us to turn off scanning compressed files. I won't try, nor will I ever put them on a 4 CPU system.
in our financial world, users often have several spreadsheets open (deeply linked to other spreadsheets), Bloomberg, Outlook, several instances of IE, antivirus software and antispyware software running in the background... you get the idea.
the more memory and horsepower I can provide them, the better experience they have with their machines. and empirically it seems that underpowered machines crash more; they sure generate more support calls (app X is slooowwww!!!)
same goes for gigabit to the desktop; loading and saving files is quicker and those aforementioned linked spreadsheets also benefit from the big pipes...
IF one can afford it, and the load is heavy as is our case, every bit of power one can get helps...
-=- mf
As above poster notes Mg is 1,000,000 grams, not 1/1000.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
all flash sold today contains wear levelling technology. the lowest that i've seen is 400,000 writes mtbf.
actualy most mau's dont even list that anymore, and give hours of use.
and... flash has been this way for at least 5 years.
... hi bingo
Most flash is rated for 100,000 writes, mean.
Nothing I'm aware of is realistically rated anywhere in the millions.
If we're only talking cache, what's the point of flash? That's dumb, use ram, and sram if you can afford it.
What the fuck are you talking about? Whether the filesystem is "fragmenting files around the flaw" or not is completely irrelevant, because flash is random access. The file could be completely contiguous or have blocks alternating between either end of the address space, and the access speed would be exactly the same.
Or are you trying to talk about how filesystems designed for flash memory try to spread out writes evenly over the chip, and failing completely because that's not called "fragmentation," but instead is referred to as "wear leveling?"
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I think you missed the point. The point wasn't that it is possible to write multithreaded code under OS/X -- obviously, that is possible under any modern OS. The point was that for many operations under OS/X you don't have to write multithreaded code to get the benefits of multiprocessing: you just call the regular system libraries and the multithreading goes on "behind the scenes". Your program neither knows nor cares about the number of processors being used, the only difference it notices is that the OSX::SuperRenderImageFunction() system call returns much more quickly when running on a dual-CPU system.
I don't care if it's 90,000 hectares. That lake was not my doing.
"Meanwhile, back in non-fanboy reality, most major Windows programs were multithreaded for backgroaund tasks 10 years ago"
/.) 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."
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
I'm not going to change your sheets again, Mr. Hastings.