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
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.
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
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?
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