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?"
What does a developer have to do to take advantage of this? When will compilers, or are there, compilers written that will automatically take full advantage of multi-core proccessors?
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?
There's another 'minor' issue that nobody else has mentioned yet. Regular Windows XP only supports up to 2 processors. This could cause some nasty issues between Microsoft and AMD.
Perhaps a nice job scheduler would be nice. Perhaps, if one of the cores ran at 4x or in a very low latency mode and the other ones ran at 0.5x, the critical very interrupt-driven tasks could live on the fast core, and other tasks (like Word, Excel, etc.) could be scheduled on the other core(s). That way, even if a user app locked up on one of the non-critical cores, the rest of the system stays up and accessible.
I'd even take a multi-core 1GHz chip (with only a passive heatsink on it...) vs a 3.x GHz with its gas-powered 150K RPM turbine blower on it to keep enough air blowing over it.
Oh, wait. I already have a dual-processor (2x833 MHz P3) server, and it's quite a bit more responsive than my single-CPU workstation. SCSI of course has something to do with that as well.
Thats why I still run BeOS with a complete lack of application support! Every app is fully threaded... so might as well run fewer of them!
"Martha Stewart can lick my Scrotum......do i have a scrotum?" -- Sharon Osbourne
Then you'll want to look into YAWS.
Basically, a web server written in Erlang, which supports lightweight processes and high concurrency. In other words, each connection is a completely separate process and shares no information with other processes except by message passing.
Also, a recent paper from the primary designer of Erlang, Joe Armstrong.
The key points are that Erlang process creation and message passing are orders of magnitude faster than Java/C# threads. Also, YAWS could handle dedicated traffic from a 16 machines. It handled over 80,000 connections, maintaining 800 kB/s traffic. Apache died around 4,000 connections. The key graphic is on page 4 of the paper. The red lines denote YAWS; notice haw it maintains that bandwidth (even though particular connections may drop, the web server keeps chugging along). Threaded Apache is in green; process-forking Apache is in blue.
I always get the shakes before a drop.
Until recently it was thought the long pipelines were at fault. But the boys at X-bit labs took a closer look at Intel patents and did some detailed performance measurements.
Turns out that it goes further. The long P4 pipes require "replay buffers" to reissue instructions with unresolved dependencies. These buffers more often than not end up causing further performance losses and power dissipation in case of common patterns of instruction dependency.
See http://www.xbitlabs.com/articles/cpu/display/replTry 9 cores. Yes, its a Cell. And yes the SPE's _are_ general purpose cores - read some more if youd like: http://www.research.scea.com/research/html/CellGDC 05/index.html
0 525/105050/
The last part about programming architecture.. is interesting reading. From job queuing.. to micro kernels to streaming.. multi-cores are are a very good way to do things. And on Cell.. they are all seperate cores.. And for a server with 14 of these in one box.. coming soon..
http://techon.nikkeibp.co.jp/english/NEWS_EN/2005
Its pretty obvious why Intel and AMD are going multicore.. because it works.. and they have to catch up before they are lost in the dust.
Hyperthreading isn't necessarily a kludge. It works very well and is often well worth the sliver of a die to implement, so long as the operating system knows the difference. It was never intended to be a replacement for a full dual processor system, I don't think it was ever sold as such.
It isn't Intel's technology either, Intergraph invented it, although Hyperthreading (TM) is Intel's branding of the idea. Alphas were supposed to get it, maybe EV7 has it, I'm not sure, it might have been something suposed to go into EV8.
Linux does a pretty reasonable job. I use XP at work and when it's doing something CPU-bound (generating a key pair with putty sticks out in my mind) the machine becomes unresponsive, but doing the same thing on my Linux machine doesn't have any perceptible effect. 2.4 kernels kinda sucked at that, but 2.6 classifies threads based on whether they use up all their CPU time. If they sleep voluntarily or wait for I/O, they are given higher priority.
Even if the CPU usage is at 100%, benchmarks have shown that interactive processess generally respond in under a millisecond. It's really impressive how a system can be under heavy load but you wouldn't even be able to tell if you couldn't see the network lights blinking like mad, hear the hard drive, and see the CPU temperature going up.
I rarely criticize things I don't care about.
Consider this:
Imagine a PC where there is only the hypervisor directly accessing the hardware (and please, NOT one that also loads Outlook Express, IE7, WSH and Media Player). Now imagine all of your operating systems running on top of the hypervisor. All hardware is virtualized for these operating systems, right? So, your physical video card no longer needs a 3-d engine; in fact it doesn't need much more than a 2-d chip and enough memory to show all the pretty colors at whatever resolution is popular. Why, you ask? Because the 3-d rendering will be done by the *virtualized* 3-d card(s) in each virtual machine, and THAT, my friend, will take as many CPU cores on the host machine as you are able to give it. And, since virtual GPU's don't require foundries, it just might mean an Open Source video card. The key is to ensure that the vitualized "hardware" is modular enough to be replaceable.
It's the next step in the ongoing cycle between having the CPU do everything and offloading to specialized chips or subsystems. By virtualizing all of the "offloading" chips such as the GPU, 3-d wavetable synth, some networking functions, etc., the pendulum swings back toward centralizing all of the processing.
Yeah 32 cores would be great for gentoo users. Then i can change my O setting a bit higher and all my crap will actually compile without having to wait overnight.
Tell that to the folk whose machines have been made completely unstable by filthware.
The type of programers you can get to write code that is utterly unwanted and corrupt tend to apply the same work ethic towards their employers. Getting a good programmer is difficult enough for honest companies.
Most of the spyware I have looked at has serious security issues, some of these may even be deliberate, a way of creating a deniable backdoor.
The spyware attempts to make itself uninstallable. Often the programers use O/S facilities that they do not understand properly to do so.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/