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.
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?
Yes, Yes we do.
Of cores we do!
Now that Intel is running with Apple, Intel must be Doomed (tm).
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
Well if there is more than one thread running on the OS, it should be able to distribute execution between processors...
Hyperthread(ing) is a term for a CPU that has two sets of states but one execution unit.. shouldn't the article use the phrase multithread?
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...
Only a few programs can use multiple processors/cores (CAD, Animation, Scientific). But just unloading some of the OS processes onto other cores leaves more power for each standard programs. (Limewire + Firefox + Xvid compression)
Since we seem to have hit a wall as far as ramping up the actual clock speeds of processors, adding more cores so the processor can do more work will be where Intel and AMD will be focusing their development the next few years. So yes, we do need more cores otherwise Intel and AMD will have a hard time selling you a chip that's only 3-5% faster.
I just wasted your mod points! HA!
Ho ho, a battle of multicore processors versus cell processors we will have.
Insert witty Slashdot sig here.
I think I'll start saving for a quad system, featuring quad core-cpu's.... ;-) Hey, I don't know what all this thing is about "modern applications not supporting Hyperthreading". First Hyperthreading is a ugly hack not comparable to real SMP, and second: running more than one application will have an advantage when having multiple CPU's. I was astonished with the difference when I first had a (non-dual core) SMP machine. I wouldn't want to go back. Now, if I could get SMP laptops ;-))
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
You can never have too much interCORES.
Isn't there some limit to how much you can increase performance by just putting in more cores? And besides, if they get up to 32 cores, that thing's going to be huge, not to mention needing a huge heatsink and fan.
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!
And use something other than the FRONT SIDE BUS, for goodness sakes, to join their cores...
Me (Blog)
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
Could someone explain to me what the benifit of more cores is vs. hyperthreading?
I was under the impression that it much more like a multi-CPU machine. So wouldn't the use of the cores primarily be an OS thing anyhow? So as long as the OS is taking advantage of it, why not just keep adding them?
Again, I'm not sure of the differences.
""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?""
:)
Of course a core a day, keeps Linux at bay.
A computer that will burst into flame without being /.ed first... I want one.
flinging poop since 1969
What we have here is a failure to communicate.
1 core, 2 cores, 32 cores, OH MY!!
;)
I think it's great now that the hardware industry (more specifically AMD) is sitting around tapping their fingers waiting for the software industry to catch up. I'm sure the OSS community will be among the first to support the new chips from AMD. (unlike Redmond.) *cough* Saa-weeet!
- j
rm -rf
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
MAKEOPTS="-j12" or whatever, I'd got for it! :)
Multiple cores on a single chip is extremely important if you buy such sillily licensed software.
but most programs haven't even got the ability to hyperthread
Now.
There are two kinds of people: 1) those who start arrays with one and 1) those who start them with zero.
I apologize, I thought that hyperthreading merely referred to moving capabilites to the CPU that are normally realized in the OS.
To that end, I thought that hyperthreading was merely a hardware implementation of threading, as is normally provided by the OS.
Is this an incorrect assertion?
If it is a correct assertion, is it true that most software does not make use of multi-threading?
You can get your XP-box rooted that much faster. Just think how efficiently Joe Sixpack can finally work on his system while the leeches of the internet get their share too! It is about time...
(/sarcasm)
Actually, if I can ask a serious question, does multi-core work the same way as multi-processor? (ie. Two procs isn't twice is fast, but closer to 1.5x...) And if it is essentially the same, will this not inevitably lead to far denser blade servers? (Ie. Two 8-core chips on blade as opposed to two one-core chips on a blade.)
Who did what now?
AMD semiconductor manufacturer petitioneed the NRC for a rule change to allow small home use nuclear reactors, saying in the application "consumers will need it".
Also, they announced the acquisition of the frigidaire refrigeration company for an undisclosed amount, saying that "our product lines have a mutual synergy".
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
It's more a case of it's the only way forward.
Clock speeds have, for the foreseeable future, hit the wall but transistor counts are still going up.
Clock speeds have been the way forward to date because they require no change in the way programs are written, yet provide performance improvements.
Now that the only way to improve performance is to harness increased transistor counts, multi-cores are in, but this means a programming paradgym shift is needed, because current programming languages are insufficiently descriptive to permit compilers to generate usefully multi-threaded code.
Either the programmer must take responsibility for such behaviour, or new languages are required. A subtle yet fundamental change is on the way; we're about to shift from the single-threaded approach to the multi-threaded approach.
--
Toby
I just soiled myself.
Yes.
I just helping create multiple threads that say 'yes'.
BSD fans rejoiced when Apple made it part of their OS. Saved from death, their precious kernel exists in OS X. Now that Apple is dying, so is BSD. R.I.P.
/\/\<<
To
confirm
you're
not a
script,
please
type
the
text
shown
in this
image: CIQDGVS
It might be nice if these could use separate CPUs, since I never know when one of them might be busy (say, getting slashdotted).
I can almost guarantee that your computer (even just idle) has at least a dozen or so processes going on. On top of that, any time you've been browsing the web and visiting anything with javascript/java/flash/etc, you can be sure that there's at least 1-2 extra processes just to show you the shiny bits.
Where we REALLY need these is for future applications. As time goes on we seem to be demanding that our computers do more and more. Just typing stuff up has gone from a simple plain text editor to OOo/Word/etc where you have inline pictures, interesting formatting, macros, inline spreadsheets, data objects, and on and on...
Not to mention gaming. Every AI guy you see running around could be smarter. Every environment could be more reactive to your prescence, more shiny bits to go flying as you blow stuff up, or allow your strategy game to go into more detail.
Just because there's apps out there that aren't multithreading doesn't mean that multiple cores/HTT isn't worth it. It absolutely is worth it. We should be pressing forward as hard as possible, not resting on our laurels because what we have is 'good enough'. If that was the case, we definately wouldn't be where we are now.
By then, Intel is gonna have, like, a million BILLION cores, with super powers like laser eyes and an invisibility shield!
[/absurdity]
Let the macho dick-waving contests begin.
1) If the cores are there then developers will write the apps to use them.
2) Most of the apps I use (especially my devo environment) and write use threads quite extensively.
3) Even if an app doesn't use multithreading, most modern OSes can and will allocate a process running on another processor for each app - if the CPU is available. So all any user has to do to benefit from a multi-core or multi-CPU computer would be to use a multi-processing OS, like Windows or Linux.
The answer is yes! A thousand times yes!
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.
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.
...have a look at these slides of a technology presentation given last friday http://epscontest.com/presentations/05q2_analyst-d ay.htm?slide=1&a
Impressive. If they execute on all that, Intel will have to keep on playing catch up for the forseeable future.
The hardware always has to come first. No one would ever buy a DVD without a DVD player existing in the first place.
It's pretty obvious that the next wave of Moore's law seems to be moving computing towards parallelism.
This is pushing software developers to make their applications multi-threaded in order to exploit the performance gains of parallel processors.
The interesting thing about this is that writing concurrent multi-threaded applications is extremely diffucult. I expect there to be an increase in demand on skilled programmers in the near future to overcome this diffuculty.
Look at it this way: the increase in CPU speed has spawned the rise of programming languages with builtin memory management, thus making programming easier to do. By using higher level languages like Visual Basic, Python, and even Java, programmers generally no longer have to worry about memory leaks. This has made software easier to develop, and has made the programming profession possible for more people.
AFAIK, there exists no anlog for making multi-threaded applications easier to write. They're damn hard, and tracking down race-conditions where one thread's actions screw up another thread mid-step is a royal pain.
It seems to me that this is going to impose a pretty big limitation on the capabilities of entry-level developers. Until somebody develops some sort of fire-and-forget race condition prevention tool, it's going to pay to have skills as a multi-threaded app developer.
I guess all of those oldschool Solaris guys who have been bragging about having true threading with Java and C/C++ since 1995 are going to finally get their day.
For more reading, here's a good article about this stuff:
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
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.
More power the better. We need it. Lets advance the technology and not start worrying about if we need it :)
You bet your ass we need it.
In the current (single-core) 2-way Opteron world, there are two basic designs: (A) designs where both chips have their own local RAM and (B) designs where only one chip has local RAM and the second chip must, in effect, utilize the first chip's memory controller to fetch memory (via hypertransport). These are immediately identifiable since (A) has two groups of DIMMs slots while (B) has only one.
Obviously design (B) is a lot cheaper but it does offer measurably lower overall memory bandwidth and some very memory-intensive applications might suffer somewhat. But overall, it's not too bad and most apps probably won't notice.
Fast forward today/tomorrow where we'll have dual core Opterons. Now, if you were to put two of these chips in a B-type mainboard (they are supposedly drop-in compatible with the old single core chips, after all), it seems you'll effectively have four cores competing for the amount of memory bandwidth normally allocated for a single core. I would expect a noticible drop in bandwidth for many applications.
Quad core will be even worse. I realize AMD's new socket will probably feature double the number of memory lines as the current socket 940/939 but if AMD plans 32 cores on a single "chip," we're looking at enormous bandwidth requirements. What will the 32-core chip look like? Will it still be a chip form factor or will it be a 5000-pin monstrosity like IBM's POWER-5?
It's not the number of processes -- even with a single slow processor, you can handle any number of background processes, provided they're written by programmers who know what they're doing. (Indeed, systems have turned up that had thousands of spyware/adware processes.) But it only takes one badly-written spyware processes to tie up a processor. And even if you have multiple processors or cores, a single badly-written spyware program can bring a system to its knees by making Windows Explorer or other basic software inoperable.
Even if an application is single-threaded the Kernel isn't. If you are running several applications concurrently the total thread count on the machine is probably close to 100 because of the O.S. and services. While it's true that some of those threads may be tightly coupled and not able to be scheduled together, some won't and these will benefit from parallel processing. In the longer term when the O.S. has 16 or more processors it will make more sense to explcitly write data parallel code.
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
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.
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.
While multiple cores are very useful, does anyone know if there are plans to scale up SIMD processing capability? Some operations don't require multiple instruction streams, instead they apply the same operation to a set of data. The chip logic to implement SIMD is much simpler than MIMD to it would make sense to add bigger SIMD engines to the processor cores, how about a 64 x 64 SIMD processor, this would allow matrix operations to be processed in chunks of 4,096.
the answer is maybe! Depends on waht kind of application you are thinking about, i for example always will need more cores and processing power 8-). About software don't have capacity for this kind of hyperthreading is just a question of time and dont't worry software manufactors always find a usage for idle cores, even to run idle.exe prcess 8-P.
So, x86 is the pinnacle of arch development? The climax of human achievement in computing?
Apple folks know that once you go dual, you don't go back.
I have a shitty sig!
http://www.eweek.com/article2/0,1759,1772674,00.as p
8 core cpu with each core maxing at 8 threads.
these are for servers, scientific/business modeling.
Not to add any value to this grand slashvertisement; but according to propoganda, the VP series of 3DLabs graphics acceleraters are designed with no less than thirty and two smaller independent processors in a single core. Nothing more is said about the technology, other than "they work together." And wouldn't you know it, they are no longer advertising the fact on that 3dlabs.com website. Hmmm...
without prejudice
but most programs haven't even got the ability to hyperthread
How does a program "hyperthread"? Did you mean "thread"? but decide to use the former because it sounds cooler? Hyperthreading doesn't result any concurrent processing, it's a hardware scheme in with the processor's archictectural state is replicated in order to speed up context switching between threads. That's very different from replicating the whole CPU core.
Please ask yourself why Intel and AMD are doing this. Is it just for fun? No.
There is a reason that they MUST do this. The increase in gigahertz cannot last forever because there is a concept called the speed of light. I've seen numbers that say that at 10GHz it would take one entire cycle to move three centimeters.
So, as Andrei Alexandrescu puts it, the hardware guys put a dead body in our [software guys] trunks and make us take care of it with threading.
In fact, go to the expert: Alexandrescu with Meyers is leading an effort to define some sort of memory model in c++.
Also check out his lock-free data structures. That's right! Lock-free.
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!
Otherwise the L1 cache will thrash badly.
Why bother with the odd latency modes? Just have them all run with the same latency/speed. If one application pegs the processor for whatever reason, you still have another to use. I think you're hinting at processor affinities and the sort of thing you'd see in a much larger NUMA setup, but if you can have one processor run with said low latency, why not have both of them doing so?
Game! - Where the stick is mightier than the sword!
"Yeah?"
"So like, when you set out to overclock this thing, did you like, uh, intend to melt the desk with it or was that an accident?"
I was only joking when I mentioned this not that far back. Damn. Maybe I shouldn't joke about pyroclastic flows and pyrotechnic processors. They might do it.
"The new Intel ArcLamp. Sixteen sixty-four bit cores, each running at 4Ghz, with a maximum memory size of 17,179,869,184 gigabytes (availible pre-loaded with second mortgage approval). Frag your friends on Duke Nukem Forever when it is released (tentatively by the time we release the one hundred and twenty-eight core model running at 12Ghz). Run circles around your fellow SETI@Home users and even do quantum electrodynamics calculations to refine your spectral analysis at the same time. Compile code faster than the finished product will ever run on Windows. Toast bread. Cook whole sides of beef for your company picnic. Weld steel at your desk. Simulate fusion reactions by actually fusing tritium and deuterium (government contract purchasers only)."
Just give it time...
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
Ever since the last change in the Apple party line, I'm seeing a flood of why PC technology (once previously dismissed by the same people) will raise Apple to further glory. Geez, I liked it much better when they were segregated in their own ghetto instead of joining the other idiot fan-boys.
(i dont know in which century you are, but there is nothing like "banks" that have to be filled completely. In fact, your opteron will even run with only one dimm installed, although with rather limited memory bandwith. For optimal use, 2Dimms per processor).
A Dual socket opteron has a NUMA architecture. No bank-shit or anything. each processor has a simply dual channel memory config like ANY OTHER MAINBOARD out there (im sure you have seen p4s or AMD64 mainboards without any socket filled).
(with the added benefit of being able to share memory bandwith between the cpus)
So 4GB ram is a modest amount...
Ok, than use 4*1GB Dimm. Complete memory bandwith realisation for a dual cpu system.
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
--Bill Gates, in an address to the BSA, June 10th, 2005
Try 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.
Once again, this is a scientifically observable example of the Intelligent Design of microprocessor architecture. A dual-core Athlon cannot become a complex quad-core processor on its own no matter how many billions of years you wait. An Intelligent Designer is required!
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)
And 3D graphics was always needed - think medical applications - when it wasnt viable for desktop machines, it wasn't included.
You cant just get away with saying we always need more. The question asked was whether 4 cores will be needed on a desktop processor. Its valid. Few people run more than 2 tasks at once.
"AMD opened its meeting by touting its ties to Hollywood, a strategy that AMD executives said they will increasingly adopt going forward."
Ouch. In light of this, Intel's announcement (just a few days ago) that they would not include any unannounced DRM in the new pentium line sounds like a breath of fresh air!
They are chip manufacturers after all, can't they just focus on making fast chips and let Holywood worry about their business?
TODO: 753) write sig.
What's up with the x86 hating nowadays? If it works, don't fix it!
Perhaps a nice job scheduler would be nice.
Try Linux.
Find coupons in Greeley
Yet Another Misinformed Summary
Executives confirmed that the company plans to enhance its Opteron enterprise processor line to four cores in 2007
Server software that is likely to be running on these processors will be threaded. Whether or not hyperthreading would work is irrelevant since AMD doesn't support hyperthreading and hyperthreading != multiple cores
The logic that says the scarcity of hyperthreading programs means that multicore dies don't benefit from lots of cores is wrong. Once in the hyperthreading game, more cores is better. So few hyperthreading programs might mean less reason for multicores, but once there is a reason, the more cores the better. It's like saying that most people don't drive, so there's no need for really fast cars. That kind of fuzzy illogic is completely common in the media. On Slashdot, where we'd like to think we can think, it's really irritating.
--
make install -not war
If you hate x86, then go buy yourself a shiny new POWER or MIPS workstation.
Remember kids, work smarter, not harder
One way to work smarter is to not accept the convention wisdom that more == better, faster == better, and actually educate yourself. The problem with multiple cores is not necessarily keeping them fed, it is having something to feed them. If you can't parallelize the job that you need done well enough it does not matter how fast the bus is. You need something to put on the bus first.
Each time you double the processing units you get a diminishing return. I think quad is about the practical limit for much current software. Stuff that benefits from more than 4 tends to be specialized.
make -j5 here we come!
If you don't want someone to copy something, don't give it to anyone.
is, if you bought one of these, would a simple BIOS update let you run 4 quad cores together? *dribble*
Or, in the future, 4x32 core? In one single workstation? *drool*
His name is Robert Paulsen...
Software developers have to start taking the speed their software runs into their own hands, they cant just assume intel will up the mhz therfore their apps will run faster, if they want their apps to run faster their going to have to start taking advantage of those extra cores
hyperthread.
it's a brand name for intel's SMT method.
SMT (symmetric. multi threading) is the correct word.
it's the generic word that fits all situations without sounding like dumb.
Science : Proprietary , Knowledge : Open Source
Build the multi core cpus and the hyper threaded apps will come.
Meanwhile, AMD is also exploring developing and possibly embedding dedicated coprocessors to help with specific tasks, even computation, he said.
This is a mix between current x86 arch and a cell-like arch. Instead of generic processing elements, its areas dedicated to certain tasks. As long as AMD picks the correct things to make co-processors for...
The Doormat
If you're not outraged, then you're not paying attention.
I for one don't need your fancy multiple cores. If only elinks starts supporting CSS properly, I'd get another decade out of this P133 of mine.
Well...a 65,536 node computer that can do 360 Teraflops -- so quad core? piffle.
Dual mice buttons?
Come on folks, really, I know alot of you have run SMP servers, and you know for a desktop it really can't be necessary. I can sometimes agree with dual cores in the rare event you have 2 apps fighting each other for cpu, but 4 or greater?? I think this would be a very good server chip, but not for the average desktop. I'd take a faster speedier dual core over this for my desktop if possible. I think the industry needs to walk before it can run.
When he said nice he didn't mean nice(1).
Apple has already shown it's willing to completely switch processor architectures, and you're telling me that, once they've made the transition to x86, they won't avail themselves of the best technology available, including from AMD (as do other x86 vendors)?
The Intel announcement, specifically (vs, say, AMD), was one of political expedience, convenience, exclusivity, and simplicity. The analysts and press are happy because it's Intel, and no one in the mainstream media or financial circles freaked out about it. (Phase 1, complete.)
But after the x86 switch is over, utilizing the best technology from traditional x86 architecture vendors, including AMD, is a foregone conclusion.
Use your heads, people. Apple isn't wed to Intel any more than it was to IBM. Or Motorola/Freescale.
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.
Name five tasks that grow in performance faster with additional CPUs than they do with additional RAM.
Remember to account for caching.
Sorry, sir... but you fucking FAIL IT.
That's only 92 cores short of chips we're starting to use TODAY.
The scientific and hardcore computational people are almost oblivious to this whole Intel vs. AMD vs. PPC thing, and those that aren't are forgetting about it fast.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Of course we'll need the extra cores. Not right this second, but this is the future. The old way of ramping up the clock speeds on single cores for added performance is done and over with. It's time to start taking advantage of the extra cores instead of wondering why we even need them. Hell, with that way of thinking, we could also say, "Well why do we need anything more than 16 bit 8088s, 640kb of memory, twin 5 1/4 floppy drives, and MS-DOS? That's good enough. We don't need no stinking 64 bit CPUs, 1Gb of RAM, RAID arrays, DVD burners, blah, blah, blah..." Yeah, whatever. I'm not going to grab a pair of rose colored glasses and go with that backwards train of thought. We need progress, and we also need to open up those I/O bottlenecks while we're at it, or in really simple terms: More speed, dammit!! More speed!! ;-)
Even running a screensaver involves two processes, one to generate the display and one to write it to the hardware (the system in 'Doze and X11 in most other places).
If you have half a dozen browser windows open, odds are that half of them have Flash plugins doing stuff, so you have one core working on each Flash plugin and the fourth displaying the visible ones, plus background processes (LAN answering ARP requests, email program checking for more spam, and (on Wintendos) adware fetching next blandishment) squeezing in wherever they can. Meaning that you would benefit from having two CPUs - eight cores - at this point.
Maybe that's why the XboX360 has so many cores? They're pre-empting an onslaught of spyware...
Got time? Spend some of it coding or testing
Actually, yes it is the pinnacle of arch development. It's stable, mature, fast, compatible, and apparently highly expandable. It does it all, and everybody uses it, so why replace the damn thing when it's not broken? Or have we learned nothing from the Itanic disaster?
because they have chosen this cool new processor architecture that lets them take advantage of all these innovations. Xserve won't be just a zillion times faster than Windows and Linux servers, it will be a ZILLION zillion times faster and all because Jobs is so smart that he picked the x86 architecture, while Windows and Linux have to make do with ... oh, wait.
OK.. I'll be quiet now.
Believing something doesn't make it true. Not believing something doesn't make it false.
Taken from elsewhere: "If we build it, they will come..."
Well, it could be said that there aren't many multi-core-using apps because there aren't currently a lot of multicore CPU's out there. If multicore CPU's start proliferating on most desktops, then we'll likely see more programs taking advantage of it. Just like any other CPU/GPU/SPU/etc technology eventually they'll likely become common in most media apps/games
I don't understand how so many geeks can be falling for all this recent hype about multi-core CPUs. A system running a dual-core CPU is really no different than a dual-CPU system.
Multi-CPU systems have been around for ages. Sure, by putting multiple cores on a single die, the interconnects between the processors can be made faster, etc, but the performance difference between that and multiple single-core CPUs has really got to be pretty negligible.
As everyone should know by now, adding more CPUs doesn't necessarily yield any performance boost because software has to be specifically designed and written to take advantage of multiple CPUs well. There are very few end-user applications or needs which would lend themselves well to multiprocessing. It's not like throwing more RAM into a system, or adding disks to a RAID array.
As far as I can conclude, all the hype and news about multi-core CPUs is mostly smoke-and-mirrors marketing by the CPU manufacturers to try to get the consumer base excited over nothing, since the CPU manufacturers have run into a brick wall in terms of clock speeds and can't offer anything BUT parallelism as a next step.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
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.
Basically all Java classes are like this, because one of the major uses for Java is writing servlets (web applications). Guess what, the servlet container is multi-threaded, and in fact individual Servlet objects are used by multiple threads simultaneously. All "generic" or reusable Java code today is written with the idea that it could be used in a Servlet, so it's all thread-compatible.
Note that there is one more level of thread safety, which is called thread safe Thread safe code allows multiple threads to access and modify objects simultaneously. Thread safety has to be handled correctly, and even within a threaded application, most of the classes don't need to be thread-safe.
With this technology would it be possible for a routine to execute on one core, and its output immediately sent to one of the other cores to be further processed?
Since the CPU is the 'sweet spot' and is getting larger (ie from X registers to X * 4) all in the same place maybe this will change the way code can be written as well, have a routine process data from ram on core0, execute on core1, refine on core2, output on core3. Keeping all the work within the 'wheel house' would make at least stats, seti type stuff FLY because more work is being done by the 'chief'
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
If you build it they will come.
"...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."
Ada does a pretty good job. Ada calls threads "tasks" and it is a built-in part of the language spec. gcc is a pretty good Ada compiler too. I use threads whenever I can (I've not done a school project in 20 years) Using Posix threads in C is tricky but Ada was designed for real-time multi-threaded applications, like controlling radar guided air to air missles, fly by wire aircraft or railway switchyards.
I'd really hate to have to prove to a review commitee that my design for a flight control system that use C/Posix was correct
There, now will the "supply concerns" people kindly shut the hell up...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
The FSB, memory bandwidth and the general bandwidth through the northbridge as well as the hated disk bottleneck will be issues with multiple cores. More cores will mean more data into and out of the CPU, so we cant linearly increase cores. Some Intel motherboards do dual-channel memory. We'll need quad-channel DDR2 for memory not to be a bottleneck.
We'll also need more memory since more programs will be loaded before running, but that means the disk bottleneck will be less important.
As for the software, I wouldnt worry. If one OS takes advantage of the multiple cores, Microsoft, Sun and IBM will be hard pressed to use the cores too.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
You could run multiple things at once (one of the biggest reasons for going dual-core). As more cores start becoming common, developers will start writing apps that are better at running on multiple cores.
Developers always figured out a way to use any extra power our computers got in the past, so I doubt this will be any different.
Server apps will love more cores, especially when slashdot links to them, especially for highly dynamic but small pages.
Until we have enough cores, people won't take multi-threading seriously enough. Right now it's a pretty useless skill job market wise. I wish I had learned a more valuable skill like web authoring or windows administration.
Since when on slashdot did we start using "About the same time apple runs on intel chips" as a unit of time?
That sure looks familiar.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
they could eventually have up to 32 cores
And it'll still take two minutes to boot Windows!
4 independent cores on a single chip could be a godsend for professional audio engineers. I'm currently using an AMD-based digital audio workstation, and even with a high-end Athalon 64 playing back 48 audio tracks along with VST soft synths and plug-in reverbs and compressors can easily bring the system grinding to a halt if I don't keep my eye on the CPU usage meter. The latest version of Cubase supports clustering over Ethernet, but this is a PITA to set up properly and the last thing one wants in a music studio is a bunch of extra computers that have to be silenced with fanless cooling hardware or hooked up from another room.
There are some pieces of PCI and Firewire audio equipment that are dedicated to running audio plug-ins to take the load off the CPU, but they are a terrible value for the money. The least powerful of them cost about as much as a top of the line video card, nearly all of them only run proprietary plug-ins, and most of them are based on processors that are relatively ancient (the bottom-end Creamware Scope PCI card, costing over $500, has 3 SHARC processors that came out over 6 years ago).
To get to my point, with 4 independent cores, I could dedicate say 1 core to playing back pre-recorded audio, 1 to running virtual instruments, 1 to running plug-in effects, and still have a 4th to send MIDI data, or run a video-editing program linked to the sequencer, or whatever. I'm looking forward to this.
Microsoft and Sony both decided multi-cores are the future with their next generation of consoles. Thus, game developers will begin to write code to take advantage of multi-threading. This will translate pretty quickly onto the PC, since dual-core processors are becoming more readily available. Games have long been the software that pushes new technology onto the market before anybody else thinks it is necessary. And so it will be with multi-core CPUs.
If only A10 Tank Killer were multi-threaded ...
Most programs don't hyperthread b/c until recently there were no x86 chips that could support it. Now there are, now programs will.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
Good to see amd following Sun's lead
0
http://blogs.sun.com/roller/page/jonathan/2004091
"by the time Apple has fully gone to Intel processors" as a unit of measurement for time? It reminds me of my old friend who used to use microwave ovens as a unit of measurement for height and width.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Please, focus on the external interfaces (memory, I/O). HT is nice, but not enough for 32 cores. Two is fine. Four, maybe with a bit of work.
As someone who works in computer animation, let me just say this: HELL YES WE DO!
Friend: "The NIC is misconfigured..." Me: "No prob, I'll just telnet in and fix it." *Silence*
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.
Bloody hell, why is it that every time there is an advance, of any kind, some goof-ball has to say "Do we really need this?". Shut the hell up, the answer is always yes.
The move from 32 to 64 bit, yes we need it, the move from single to dual core, yes we need it.
It annoys me as much as people who say "Aren't cars fast enough already, what's the point for making them go 300kph when the speed limit is only 120 max?". What a sad little world you must live in.
I want more sophisticated and immersive applications, and so I want the technology now so developers can write it for me.
I also want a solid gold toilet.
most folks buy a new computer when their machine gets slow... most peoples machines get slow when the re's too much spyware for other apps to compete with...
there are people who upgrade from 2.4ghz machines to 3ghz+ because their old machine wasn't powerful enough to surf the web or compose emails...
i would imagine that much of the demand for faster chips is fueled by people who don't know enough to just format their machine and reinstall their os...
Get your torrents...
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.
Well, not unless I/O is free on your platform.
And since it appears you are decompressing and compressing to the same directory, and thus same volume, you'll likely be I/O bound anyway, specifically seek bound.
Multiple processors are nice, but are not nearly as good as a single faster core. Of course, if the price is right, I'll take it anyway.
http://lkml.org/lkml/2005/8/20/95
No, I don't expect Mozilla to write a multi-threaded version of Firefox. But Can they easily make a version of firefox that gives you an *option* of each separate window being a separate instance of Firefox? After all, we're already forced to open i.e. for a web-site every once in a while.
Wouldn't a new instance of firefox be the rough equivalant of a multi-threaded browser?
Don't you mean.. BIZZARO!
I read the artical and I was wondering if this the same Chuck Moore who invented FORTH in 1968 and build a Forth chip? I googled but couldn't find anything conclusive... even went to AMD and did a search.. //bob
most programs haven't even got the ability to hyperthread, so do we really need the extra cores?
It's when designers for pervasive products think like that when things become nasty in the future - for example, no program uses more than 640k of RAM right? So who needs more?
In the future when multi core / multi CPU processing is taken for granted, we will laugh at the current "who needs more than one core?" question as we laugh at "who needs more than 640k?"
That IS a first post. Learn to read, pls kthx.
does anyone actually make a "server" that doesn't have SMP?
Yes
The real benefits of having multiple cores. Weather that is 2 4, 8, 16 or 32 or 128 at the end of the day those sorts of cores at this stage are really designed for the server market or workstation market rather than the gaming/home user/general office computer usage patterns.
having multiple cores will really benefit database applications, rendering etc. The other benefit would be the ability to brute force encryption in a much faster time if the application used to crack it was mt ready.
2. AMD is going to make Intel's speeds trivial
Conclusion- Apple doesnt need the speed anyway.
We should label this the "Sour Grapes Fallacy".
Athlon 64x4?
With limitations to how much you can clock one core, it was only a matter of time. AMD is also trying to get ahead of intel as they have trouble with their architecture and get too hot.
Let's take a very simple class, which keeps track of an X/Y location. It has only two private fields, an int x, and int y. There's a method like this:
and another method that returns the coordinate:What do you think will happen when Thread 1 calls the setLocation method, is interrupted at Point A then a Thread 2 starts to run and calls the getLocation method on the same object? You'll get a Location object with the new x location, but still using the old y location.The correct code would involve either externally synchronizing the Location object or by adding a synchronized block on this object around the setLocation code.
Another solution would be to make your class Immutable (by making all fields final). The setLocation method would return a new Location object with the new Location, but would not alter the current Location object. Any other methods that do modifications will return a new Object as well. See the BigDecimal class for how this works; it is Immutable.
I would suggest going with the Immutable pattern, unless the overhead of creating a new Object of the same type for each modification is too great. Otherwise use synchronized blocks. Using synchronization is a bit more tricky to get right however.
I don't find the link now , is on linux kernel mailing list (Arnd Bergmann wrote/done it) and compilation is done in few seconds :) :
There is place for more cores on my desktop
What shocked me is this device with 32 threads and runs linux and shipping today!
"Raza Microelectronics is shipping six high-throughput, multi-core, multi-threaded MIPS64 The XLR family of chips clocks up to 1.5GHz, and offers 16-32 thread processing engines"
http://linuxdevices.com/news/NS8376430165.html
developer http://flamerobin.org
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.
It's more than just setting up an environment as immutable.. What the parent post was talking about what procedure-local variable usage.. Statics are obviously an obsticle to MT, but so are field-variables. If a class is instantiated w/in the method and used by the method and invoked methods, then you are inherently thread-safe. For the purposes of sharing objects between method invocations, you have immutable singleton "verbs", and noun immutable "Value Objects". What's left are noun mutable "Entity" Objects. By separating design into verbs, value-objects and entities, then you know where you have to focus your synchronization efforts.. Mind you it takes WORK to maintain the value-objectness of non entities.
s.getAttr();
..) ;
The typical process for "verbs" is to first call set-attributes, init, then execute, then get-attributes. The problem is that if the verb object is passed around there is a constraint of single-threadedness.
If on the other hand, the verb is written as a singleton which returns value-objects, then there is no dangerous of having multiple threads acceess the verb. But it often requires creating multiple transient objects.. For example:
State s = myFactoryObj.setupVerb(attr-list);
s.execute();
It's often easier to perform:
myEntityObj.setAttr(..);
myEntityObj.doVerb(..);
myEntityObj.getAttr(
But as the name implies, being an entity object, it is likely to be used in multiple contexts.
By separating verbs from shared mutable entities, your code is more thread-safe, and as a bonus, more unit-wise testable.. You can trust that the entire "login process" works independently of a user object.
The book domain-driven-design is an excellent read on such architectural separations.
Such techniques are applicatable to even non OO environments. Side-effects are evil and stand in the way of many things. Making state modification explicit, you can more correctly identify synchornization points and more importantly reduce the number of them.
-Michael
Beware... top can wildly overestimate numbers of processes. It gets fooled by mere threads.
Essentially what you propose is to write your code forcibly singlethreaded, because that's what that style of writing boils down to.
Not at all.. In another post, I suggested the following.
Collection input = repository.findE(...);
Collection output = MTCollectionUtils.map(input, myMapper).
The above essentially works like:
for (E e : input)
{
F f = operation on e;
output.add(f);
}
But allows the generic application of farming out to worker threads. Essentially explicit SIMD operation.
This could be the actualy hibernate re-materialization, or reporting or aggregation.
The point here is that this is a simple example of a procedure-local variables being used in an MT way.
As for concurrent access to "entities"; Objects which have uniquely identifiable properties (as opposed to value-objects like a date), systems like java provide a relatively easy way to access them.. Namely object-synchronization. This is most perfectly exemplified in Collection/Map synchornization. Maps are repeatedly used in MT environments in java, yet they are very reliable. (Rather when using Hashtable or the Collections.synchronizedMap() wrapper).
Concurrently entity modification in today's environment can easily utilize "optimistic" locking, whereby the entire transaction can be marked as repeatable.. You initiate a repeatable transaction. You load all relavent entities from a shared environment (such as hibernate or directly from the DB), then you update a version of some sort (like a modified-timestamp on each entity). Then you go to push the objects back to the share environment.. But in doing so, you check to make sure you have the latest version.. Otherwise you throw a concurrent modification exception... The transaction is rolled back as if nothing has happened.. At which point you minorly annoy the user by providing an error screen, or you intelligently catch the exception and restart the entire process.
The above obviously is most suitable when there are low probabilities of conflict, as this provides the highest concurrent execution performance. Not to mention is the least intrusive form of concurrent execution.. The only thing it requires is adherence to a transactional model.. But mysql's INNODB or postgres provide this nicely without an EJB framework.
When overlapping modification is too likely, then you can utilize explicit blocking locking methods. Often such locking occurs at the DB access point, not the application level. So assuming that you have an adaquate DB abstraction layer such as OJB or hibernate, then you're safe even here in terms of writing bug-free code.
When a mixture of performance and concurrent modification of the same items is paramount, then you'll probably have to resort to object locking (or even finer grained locking).. But I would venture to say that this is rarely needed.. As the benifits of writing the slower but bug-freer code and purchasing more expensive hardware is not to be under-estimated.
Of course there are programming models that don't exactly conform to a web servlet / mainframe (SIMD) work-flow. So your mileage may vary.
-Michael
Sure, there are going to be a few hardcore gamers with more cash than common sense, and some content creators who will love to have something like this, but the majority of the desktop-using world doesn't even need the power they have... this just seems like overcompensation for the next-gen consoles like PS3.
It's cool that the option is going to be out there, but I can just imagine having to wear hearing protection while using my standard bargain-basement 6-core workstation because of the ungodly mass of cooling apparatus required to keep it ticking. If that happens, to hell with computing power, I'm going to take the PC I can run in a residential area without breaking any noise bylaws. Laugh now, but just look at how loud they've already become since they days a CPU didn't REQUIRE a fan.
It's not like it's an intel chip :)
hawk
Where did you get that strange idea?
Buffering does not reduce the amount of I/O you do. If you need to read data, you need to read it. It has to come from the drive. Even if it comes from a buffer, it came from the drive to get into the buffer.
No amount of buffering will fix a problem with being truly I/O bound.
Caching doesn't help either, if you are reading a large, sequential data set and producing another. Look ahead caching can maybe help with that, but if you are truly I/O bound, you won't get a chance to read ahead, because you'll be using the I/O for needed operations constantly, with no time for speculative operations.
http://lkml.org/lkml/2005/8/20/95