AMD Quad Cores, Oh My 423
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?"
Ah... history fails to be remembered again... (Score:5, Insightful)
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...
Doesn't have to be threads (Score:5, Insightful)
Re:Yes, we need quad cores (Score:3, Insightful)
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.
Too Many Cores = Unbalanced Design (Score:2, Insightful)
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?
To take advantage of this in the PC: (Score:2, Insightful)
Re:Doesn't have to be threads (Score:4, Insightful)
Even gamers now do stuff like run skype side-by-side with their resource-hogging game.
Yes, you need multi-core, multi-processor, whatever.
Re:Do we really need the extra cores? (Score:5, Insightful)
Re:No more Mhz! (Score:2, Insightful)
Re:Intel working on silicon laser to link cores (Score:5, Insightful)
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.
What we need (Score:3, Insightful)
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.
Re:Too Many Cores = Unbalanced Design (Score:2, Insightful)
What does hyperthreading have to do with it? (Score:5, Insightful)
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!
Re:Ah... history fails to be remembered again... (Score:5, Insightful)
My current graphics card has 256MB of RAM.
Even if none of my apps can take advantage of 4 cores, my PC can - I could be running a lengthy compile and transcoding some video while playing a game and still be contributing to SETI@home or something.
More to the point, you could have a long-running process (like video transcoding/encoding) running on one or two cores, with the remaining core(s) doing something else for you while you wait.
Failure to communicate? (Score:4, Insightful)
Re:Hyperthreading (Score:5, Insightful)
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.
Re:Intel working on silicon laser to link cores (Score:4, Insightful)
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.
Re:Don't count the processes (Score:5, Insightful)
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.
Re:Hyperthreading (Score:4, Insightful)
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.
Re:Hyperthreading (Score:4, Insightful)
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?
Do we really need the extra cores? Well...um... (Score:2, Insightful)
Re:Ah... history fails to be remembered again... (Score:4, Insightful)
You don't want that 32-way CPU? Well, give it to me and I'll let you have this old Pentium.
Re:Hyperthreading (Score:2, Insightful)
Re:Hyperthreading (Score:4, Insightful)
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
Uh, you do know what scheduling is, right? (Score:3, Insightful)
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.
Re:Ah... history fails to be remembered again... (Score:2, Insightful)
Spectrums came in 16KB and 48KB variants only.
Re:New programming paradigm? Um, no (Score:1, Insightful)
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.