Registered: Sep, 2003
Re: The Holistic Approach to Software Engineering as a Way to Handle Complexity
Posted: Dec 1, 2010 10:28 AM
> > I don't see many Intel cpu's being moved to the desktop
> > mimic Crays ("Mr. Cray, why are your computers so much
> > faster than the others?" "Shorter wires."), A niche,
> > sure, but Intel needs hundreds of millions of units out
> > the door every year.
> Our Cray cluster uses intel chips. We also use Condor on
> our desktop machines as a second cluster. After a
> machine's been idle with no user interaction for 15
> minutes, it starts working on the current job submitted to
> Condor. But once again, it's fairly esoteric, and involves
> jobs that can run for days before you get a result.
No disagreement, beyond that such machines/software won't amount to a tear drop in the ocean of chips Intel needs to ship. That's the problem with finding parallel problems.
> > I don't know enough about how games run these days to
> > disagree, but IIRC most of the load is carried by the
> > GPU(s) and not the cpu/cores. And that the GPU code is
> > already thread/core optimized. Yes? No?
> No. We've pretty much reached the point where most games
> are CPU bound, unless using Intel graphics chips.
> Typically, when games are made multithreaded, each
> subsystem (sound, graphics, AI, networking) gets its own
> thread. Graphics is usually broken down further into
> several threads.
> Both the 360 and PS3 are multicore, although the PS3
> doesn't do SMT. (And you can access the cores/threads on a
> 360 using XNA, the public tool for developing for the
> 360.) We're also starting to see multicore ARM chips, so
> your next phone/tablet could be multicore as well.
360 and PS3 run on PPC chips (sort of), which is small potatoes for IBM, and none at all for Intel/AMD, which are the chip suppliers in need of justification.
> > The
> > Fortune X00 may well drift back to where it was pre-PC:
> > with centralized databases talking to terminals, now
> > w mid-power PC's.
> Sure. My team does web development which is essentially
> this model. However, the trend for web servers is more
> CPUs, rather than faster CPUs. Fortunately, web requests
> parallelize really well. We still have pages which spin
> off long running work into a background thread or worker
Again, the server market is a fraction of the desktop/mobile markets, which is where the disconnect is happening. Mainframes/minis/servers have had multi-stuff capabilities for decades; how to make use of multi-stuff in a common desktop/client (and not behave slower to the user than the last generation machine) is the conundrum. For iStuff (and similar), where there isn't as much user history, probably less of an issue. Planned obsolescence still rules the sector, so there's less pressure. Everybody knows what Office does on their machine (often about 5% of Office can do, naturally), so a new machine that doesn't do it any faster will be noticed.
> I've been writing multithreaded code for over a decade,
> off and on, and it's really not that hard, although it
> requires discipline. I've also come to the following
> conclusion, if your program is slow because it's
> processing a lot of data, or if your program is structured
> into a bunch of mostly independent modules, than writing
> multithreaded code can be a big win.
That old canard, the three main applications for the desktop: spreadsheets, word processing, spreadsheets. There are small opportunities for multi-threading, but I've seen no evidence that there's a major win there for multi-core. The archetypal desktop application is single threaded because the user has only one brain and two hands. The OS can benefit, but the number of OS writers is even smaller than game or database engine or web server writers.
If your application
> is slow because it's got a lot of code to execute, not so
> (And it's not just multicore. I've seen massive
> performance increases in C/S desktop apps after they've
> gone multithreaded, even on single core machines when they
> have to deal with lots of data.)
"C/S desktop apps" is, I'd say, a synonym for Engineering Workstation. Important to those that do that sort of thing, but it won't keep the lights on at Intel or AMD (certainly not both).