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?"
You must be new here.
Of cores we do!
4 cores on one chip... I guess they will have to call it the earth simulator as the temprature of the chip will be reaching that of the earths core.
At least it will open up innovative new designs like built in coffee pot as well as new uses for old technology, like making pizza pops in your old cd burner.
flinging poop since 1969
Anything to go faster for Gentoo's sake, the better! Anything to make compiles go fast!
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
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...
See MIT Technology review article: http://www.technologyreview.com/articles/05/07/iss ue/feature_intel.asp
The silicon laser, being made from the same material as the rest of the chip, would replace the copper wires that need to connect cores, thus letting Intel 'keep Moore's Law alive for decades', the article says. It would do this by permitting many, many cores in fast communication with less heat and less energy required than current copper-wired chips.
Question: will Intel's possession of si-lasers shut AMD out?
1.21 Jigawatts!
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
Don't forget Gator, HotBar, and iFrame!
My other car is a Popemobile
What we have here is a failure to communicate.
Yes, the poster should have used 'multithread' instead of the Intel branded and copyrighted term, 'HyperThread' which is in regards to their proprietary virtual processor technology on Pentium 4's and Xeons.
Let's not let Intel get the next 'Kleenex'ing of the English language, shall we?
It's more an issue of programs taking advantage of multiple cores or multiple processors than the compiler. Using multiple cores means that a single program must either have multiple concurrent processes or multiple threads, you can't just magically compile that sort of thing in, IPC can be a complex beast. That, or you need to run multiple programs at the same time to take advantage of more than one core at a time.
Game! - Where the stick is mightier than the sword!
The word "Hyperthreading" describes a specific hardware kludge by Intel to make a single-core CPU pretend it's dual-cored. Apps that utilize multiple CPUUs are called multithreaded. All you dorks parroting the article submitter and calling it "hyperthreading" are idiots.
If a job's not worth doing, it's not worth doing right.
Yes, Virginia, we can use mutli-core. I mean, we're all into SMP heavily in the non-desktop role (does anyone actually make a "server" that doesn't have SMP?)
There are two big things I love about the multi-core Opterons: They draw less power than equivalent SMP machines (acutally, quite a bit less), and they allow multiple "CPUs" to use the same memory controller. Nominally, the second isn't a big win, but it can be for practical purposes.
Opterons have dedicated memory channels on them, so a current dual-socket Opteron has two DISTINCT DIMM banks - that is, on a motherboard with 8 DIMM sockets, 4 are allocated to each CPU socket. So if you have only one CPU, you can only use 4 DIMM sockets. Since those 4 sockets are often configured as a single bank (i.e. they all have to be filled to work), you can't add another CPU to the system without buying more RAM. This is wasteful. But with a multi-core opteron, all on-chip cores share the same memory bank.
The jist of this is that it'll be easier to have High-Compute, lower RAM configurations than it currently is reasonable to do. There are a lot of tasks out there which it is really nice to have a modest amount of RAM (say 4GB), but with huge crunch. Currently, it's hard to buy a config to do that, since you generally either end up way over-paying for CPUs, a huge number of tiny DIMM chips (which sucks for future expansion), or a larger number of motherboards, which draws more power.
And, hey, they're not tooo bad in price. Sun's dual-core v40z is less than twice as expensive as their single-core v40z, and you save lots on power/cooling/space.
Overall, a nice win.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
He shows demos and explains several driving forces:
An example of video analysis is demonstrated. You can get a stable image out of a cell phone, and get a much higher resolution to boot, simply by analyzing lots of images in sequence. Right now, it takes a lot of time to crank out the analysis. But the problem is parallelizable, and Intel thinks we'll have this sort of things in cell phones by 2015.
This is also the technology behind automatic construction of 3D from images. This is where you pull your cell phone out, walk around, waving it around the room, and get back a 3D model of the room.
People ask: "Do we really need all this computing power?" Yes, yes we do. There's plenty of stuff to do with it.
Scott talks about sitting in front of the computer, and not needing to log in, because the computer knows who you are by your face.
There's all kinds of stuff to do with it.
SMP or multiple cores is (obviously) more than one real processor and one will see huge benefits with any application that is multithreaded as well as when running multiple processes. Single threaded processes should never have issues running on an SMP system, though there will be a small loss of speed due to the overhead of SMP (Dual 2 Ghz processors will probably run a single threaded process ~1% slower than a single 2 Ghz processor).
Game! - Where the stick is mightier than the sword!
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
The Cell's SPEs aren't really general purpose. They're limited to a 256KB local storage. In order to utilize main memory, they have to use explicit DMA operations. That drastically limits their usefulness for code that isn't explicitly written for Cell.
A deep unwavering belief is a sure sign you're missing something...
So spywear authors should write better code so their programs don't tie up the processor? :)
My guess is that most current spywear is not multithreaded due to universiality and size contraints, but as you state, we can soon look forward to better quality, bug free, multithreaded spyware soon.
Perhaps Microsoft should hire some of these guys. Anyone who can write code that allows hundreds of instances of a program run without swamping the processor is a better programmer than the current crop that is designing Office, for example.
Tequila: It's not just for breakfast anymore!
Dual mice buttons?
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.
When he said nice he didn't mean nice(1).
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