Slashdot Mirror
AMD Quad Cores, Oh My
Lullabye_Muse writes "From engadget we learn that AMD has plans for putting 4 cores on one die by the time Apple has fully gone to Intel processors. Full story here. They say they could eventually have up to 32 cores with scalable technology, but most programs haven't even got the ability to hyperthread, so do we really need the extra cores?"
but most programs haven't even got the ability to hyperthread, so do we really need the extra cores?
Once upon a time, most programs didn't have the ability to do IEEE754 floating point either so did we really need the FPUs?
Once upon a time, most programs didn't have the ability to do 3D graphics at 30fps. Do we really need dedicated high performance graphics cards?
The list goes on... but no one learns...
Who still uses one application at a time, really? I know there's less benefit when it's different applications because of register sharing, but if it's cheaper to get 4 cores than 2 cpus it's probably worth it.
I am trolling
It's a bit like the chicken-egg problem.
There could be no better incentive for software writers to support multicore than to start actually producing them for the masses! It should be normally like this, that someone comes up with hardware and people write software for it, not the other way around.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
It is relatively easy to add multiple cores (copy and paste in your IC layout program) but I wonder if this is just another manifestation of that "megahertz myth" (multicore myth?). Adding bunches of cores is fune and dandy but you have to keep those cores fed with a wide and fast bus.
The largest chip packages currently available have fewer than 2000 pins (and I don't expect that to scale as quickly as the number of cores grow) and you can only cram so many DDR/Rambus channels before you run out of I/Os. Perhaps it is time to revisit optical interconnect or chip scale packaging?
one would need either a ton more ram or faster I/O for the HDD than is standard tosday or even in the near future. the bottleneck is non volatile storage throughput, fix that and even todays systems could be much faster than they are with SATA/scsi/ata100/133
I once fixed some lady's machine where about 20 spyware processes were running. Now imagine she has 32 cores. I guess 640 spyware processes will be running on that thing by the time she calls anyone to fix it.
Cache may well be reaching the point of diminishing returns. I seem to recall reviewers' benchmarks of 1MB vs. 2MB showing almost no gain, although I'm sure Intel has a set of benchmarks showing massive improvements.
No, because AMD and Intel crosslicense their patents. Under the same agreement Intel gets to use AMD's AMD64 instruction set and call it EM64T.
SCO employee? Check out the bounty
That said, most users run word processors, web browers, and other simple productivity software that doesn't even fully exploit the old P2s we were running a few years ago. But if you want to run the latest graphic-intensive games, you better have the lastest hardware.
This statement makes no sense. And, besides:
zcat foo.gz | bzip2 -c > foo.bz2
Look, ma! Code that will run twice as fast on a multiprocessor system!
Well, the answer to that is obvious. We need terabit optic fibre to all houses in the US, immediately. This will cure all communications problems - or, at least, all communications problems involving Quake VI.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
" What does a developer have to do to take advantage of this?"
Easy use threads.
Multi-threaded code is very difficult to write correctly and debug. It's hardly 'easy'.
Multi threading is not all that hard. And yes I have written code that uses threads.
When, for a school project? There are very few cases where integrating a multi-threaded handler into a progrom doesn't introduce a formidable degree of complexity. What really needs to take root is a new programming paradigm. One that assumes all procedures, functions and system calls are designated as concurrent from the get-go. People smarter than most of us need to design a language/compiler that doesn't burden the programmer with the responsibility of 'keeping track' of when to use threads and when not to.
The government has a defect: it's potentially democratic. Corporations have no defect: they're pure tyrannies. -Chomsky
What? Not all of them silly. Improvements in chip making process and related technology are the heart and core of how these companies compete. Negitiating a truce on the instruction set architecture with another company, partly to avoid antitrust concerns and partly to just keep it a larger market, is a completely different matter than giving away your entire market advantage from sucessful r&d.
Second, most spyware is well written. Badly written spyware is ineffective -- by screwing up your system, it calls attention to itself, and encourages you to run a scan. Spyware and adware wouldn't have spread so thoroughly if it were all written by hacks.
There are very few cases where integrating a multi-threaded handler into a progrom doesn't introduce a formidable degree of complexity.
I would not be so categoric. It's a design issue - making a program that was designed from the ground up with single thread of "logic" play nicely with many different threads is stupidly complex and usually winds up being very kludgy - much of the threaded advantage is eaten away by the hacks that are needed to make it work. Design it from scratch to work this way, however, and the multi threading may not be simple, but it is at least "obvious", and that makes for good efficient threaded code. Lot's of tasks can be broken up quite easily and once the designer has understood inter-process communication and its constraints and overhead, the decision to create a new thread for a particular task or keep it in the exisiting one, is often far more straightforward than you make out, and yields good results.
Try NetBSD... safe,straightforward,useful.
That, or you need to run multiple programs at the same time to take advantage of more than one core at a time.
On my home XP Pro box, freshly after a reboot, I currently have 15 distinct processes running, with FireFox as the only obviously user-interactive one.
And that on a box with all the useless default XP crap turned off - I frequently see machines at work where, with nothing user-interactive running, the task list doesn't fit on one screen.
The whole red herring about not having enough multithreaded apps yet (BTW, please write "Hyperthreading does not equal multithreading, nor does it equal multicore" a hundred times on the black board, please) has not mattered since the first version of Windows 95. I can find ways to use a few more CPUs, multithreaded apps or not. Just having a second core, so you can keep your "boring" processes like the OS and antivirus separate from your interactive programs, makes a system immensely more responsive.
If you want a single-threaded program to run faster, more cores won't help. If you want your entire system to run faster, throw CPUs at it. However, looking at both Intel and AMD's roadmaps, I'd say the days of a MHz race have (finally!) neared their conclusion. They'll keep pushing their clocks, sure, but major leaps will move increasingly toward number of cores and how those cores interconnect (those two will basically need to alternate: A few doublings of core counts leading to memory bottlenecks, then a new way to keep the cores fed, then a few more doublings, rinse wash repeat).
I wonder, though... Will Microsoft, Apple, or Linux (or some entirely new player) take the first leap to requiring one (or even a few) cores dedicated solely to the OS?
Taken from elsewhere: "If we build it, they will come..."
Check out functional programming. Languages like Haskell and Sisal are eminently suitable for the kind of automatic, pervasive threading you want.
Once one knows about the issues in multithreaded programming it is actually quite simple. However, as the original poster pointed out, it is also very hard to debug and easy to make mistakes. This is where design comes in. Those mistakes shouldn't be made in the first place. Today, programmers have a nasty tendency to jump into code too quickly and rely on tools to debug and evolve the code into the final product. This approach works surprisingly well for simple programs, but you'll crash and burn if you try to use this approach with a multithreaded application.
For my undergraduate I concentrated on learning to program using threads. I took courses like Distributed Systems, Concurrent Systems, Parallel Computing... I observed first hand many of the problems associated with using threads - and I also learned by making most of the common mistakes. Looking back, I see that I learned a great deal. I see how multithreaded applications will play a bigger and bigger part of programming in the future. I also see how all those programming habits picked up in previous years will have to be thrown out and how proper software engineering practices must be adopted...
William
When I run PS, I see 1 program running: PS. bash, my shell, is blocked because ps has control of the terminal.
If I turn around and run top, I see that, indeed, the main program running is top. All the rest are usually sleeping on some event. Unless that event occurs, they won't be woken up. The speed with which Linux can react to my keypresses, read the key presses, send those keypresses into a user-land safe buffer, wake up the userland program waiting on it (in this case, Mozilla), and then schedule X to run and let it update the screen to display the characters I just typed (which Mozilla also copies to its own local buffer) happens so fast as to not even register as 1 10th of 1 percent on my AMD64 3000+.
Seriously, no one needs a fucking 32-way CPU, not unless they are doing some massively parallel scientific work, or they are emulating many virtual computers at once. To deal with blocking IO that can't be slept, then multiple cores look sexy, but not really past 4 cores -- most applications are single threaded. Perhaps this would be different if we were running BeOS.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Both of these things are really simple. In C, just make sure that you don't have any variables (other than constants) declared outside of the scope of a function.
In Java, it's the same thing. Just make sure that you have no non-constant static members of your classes. That's it. That's all you need to do for your code to be thread-compatible. As a side-effect, you'll have much less bugs and strange interactions in your code.
Tell me, how do you write any real software like that, where you're not allowed to keep an internal data representation for the duration of the program to share between threads? Essentially what you propose is to write your code forcibly singlethreaded, because that's what that style of writing boils down to.
Real multi-threading requires locking parts of your internal data representation from the various threads in ways that don't just not corrupt your data, but also avoid deadlock and livelock. It is very, very hard. It is so hard that even java's own Thread class is not free of threading bugs (see Thread.suspend's documentation).
The real danger with writing multithreaded code is that it is easy to think you understand it, and to think your code works right, and to see that affirmed by your code doing its job. But then one day you get a call from a customer who has intermittent and unpredictable problems with your software. And that's when you're really screwed. That's why we need better language-level constructs, that are so simple it is impossible to use them wrong. No language comes to mind that is like that.