to turn it off.
The obsession comes from people who use their computer as a dedicated
machine for a single application running at a time and need/want as much
performace as possible. Read that as gamers playing first-person type
games. FP gamers are not going to have more than one intensive program
running at a time as games are not only full-screen apps but it's
probably about impossible to play two of those kinds of games at once.
The obsession for performance comes partially from these kinds of games
requiring boatloads of system resources to run smoothly (ask a gamer
about "Crysis" if you need an example.) The other part is that a bunch
of serious gamers also have a big one-upsmanship thing going on with
hardware. They want their new $1200 3.0 GHz Core 2 Extreme QX9650 to be
much faster than their buddy's ~$300 3.0 GHz Core 2 Duo E6850 just
because they paid a bunch more for it to get "bragging rights."
Bragging rights isn't really a software issue. Most games though can be split easily into multiple tasks that run individual systems and all you have to do is let them talk to each other. Most of the real number crunching happens in the GPU. Physics can be pretty intense and can take advantage of parallelization but that is hardly the entire program that needs to be chopped up and again it is largely a math problem. AI can benefit from parallelization but is mostly pretty easy to split up into systems. A game engine is in many ways a specialized operating system. It's not really one program running so much as an OS running many sub-apps that work together.
People who use their computer for real work often have many programs
open at once and the extra cores help to make that much more seamless
and smooth. They also don't care about one program being able to utilize
the whole CPU. For example, I did some scientific programming work this
summer and had some very compute-intensive work. The particular work was
for a genetics project and this I needed to run the program on all 23
chromosomes. It didn't matter if I had the program multithreaded so that
I could get one chromosome done in half the time on my dual-core machine
or if I could run two chromosomes at once. The net result is that two
chromosomes were analyzed in roughly the same time. Actually, the two
concurrent single-threaded instances were faster due to a lack of
needing to sync threads, but that is besides the point.
It's not entirely beside the point - you could still effectively take advantage of your multi-core CPU without doing a lot of crazy, complicated, programming.
The other reason most people do not care about multithreading is that
many programs simply do not use much for CPU resources. How much CPU
time does an office computer actually use? My guess is that it's
somewhere well under 1%. Multithreading would make a 1-second load time
turn into a 500-msec load time. Big deal.
I don't know. I don't think people know what the difference is but I think they notice it. Even if your system has a light load it still feels more responsive with a multi-core processor. It's common to have several applications open at once too. You can feel the difference. You get fewer spikes of slow behavior too which is very noticable. Say you're listening to some tunes and open a spreadsheet - no pause in your music while a bloated office app kicks into gear.
> I'm pained when I have to use somebody's old single core Pentium 4
> even if it is a fairly fast CPU (3+ GHz). Doing multiple tasks is
> noticeably slower. Running multiple operating systems on those CPUs
> just feels like it's going at a crawl.
It also depends on the OS and the HDD. The *nixes tend to handle
multiple thread time-sharing much better than Windows and Vista actually
handles it better than XP. But the biggest problem with many other
peoples' computers is that the HDDs are so slow and fragmented as to
require a 5-minute boot time.
Thread handling is an issue (OS X on PPC had some serious issues.) but I don't think it's the only issue.
I'd say the biggest problem is that they have to little RAM. I build mine so that they don't need swap or virtual memory. This alone makes the systems much faster. Windows fights with you over the issue though which is sort of annoying.
> Having a single app use multiple cores is mostly useful for games and
> heavy number crunching. For most people it's more useful to be able to
> rip a cd, use your web browser, work on a document, and check your
> email all at the same time. Most of the time people use several apps
> at a time and not just a single app.
>
And among those tasks, only the CD ripping takes very much CPU time.
Even then, the speed of the CD-ROM drive is the limiting factor unless
you're running something like a 500 MHz K6-2.
I don't agree. You can feel a pronounced difference between a fast P4 and a multi-core CPU when ripping a CD or DVD. You can feel a major difference when opening apps, loading a large directory of files, etc. Some of this is, as you say, based on the hdd but I've experimented with a lot of different drives including flash and ram based drives and you can still feel a difference.
> For most cases it's not that hard to write a multi-threaded program
> anyway. If nothing else write each thread as it's own service and
> enable your services to communicate as needed. Problems that don't
> easily divide into services are usually easily parallelized stuff like
> 3D rendering. It's not like we have 100 core processors right now
> where you'd want to start splitting normal logic down into parallel
> tracks to peak every lil bit of power out of the system.
It can get quite tricky with certain algorithms to write MP code.
Sometimes MP code will be slower than single-threaded code due to the
thread syncing taking up an enormous amount of resources.
It can get tricky but most of the problems I've seen come when programmers try to cram a single process program into a multi-process program. Programs designed from the ground up as MP have far less issues. It's more a matter of learning to think in the right way. Of course certain types of problems are just hard to split up. :)
Home | FAQ | Server | Presentations | Mailing Lists/Archives | Member Tools | Links | Sponsors | Contact