AMD lifts veil on six-core AMD has demoed its upcoming six-core server processor, code-named Istanbul, claiming that it remains on track for release in the second half of this year. The demo came hot on the heels of Intel's confirmation that its four-core Nehalem-EP will be released by the end of this quarter, along with that company's recent detailing …
Reminds me of the "Digital Zoom" race in the camcorder market. Pointless apart from some very specialised applications (El Reg audience only, not Joe Public or MS Office business user).
New machines are getting shipped with 64 bit Vista - but there is still a lack of software to make use of this - MS Office 2007, Open Office, Adobe Photoshop and Premier 7 Elements... mostly all software is 32 bit - again apart from specialist applications (i.e. expensive specialist professional software). How many mainstream applications are engineered to make maximum use of 4 cores with hyperthreading ?
Software seems to be lagging behind hardware at the moment.
I think its aimed at server apps. Apache or java app servers start more threads to cope with new connections. More cores mean more threads.
I do have to wonder if the engineering required and compromises made to get more cores into a cpu makes it more worthwhile to add another dual/quad core blade.
Socket F is their server socket, Socket F has been around since the introduction of the second generation Opteron's, IE dual cores, and it has made its way around the world quite nicely, starting in Santa Rosa, heading through Barcelona, Shanghai and now Istanbul, so i'd say socket F is well traveled... There will be AM2 / AM3 versions of these new opterons, they are the single socket versions.
in all actuality, AMD hasnt changed sockets since the change from socket 754 to 939. Socket AM2 is 939 with DDR2 support and AM3 is a one pin varient of AM2 with support for DDR3.
So all in all, AMD has done a good job with not changing sockets like underwear...
I personally cant wait to get my hands on a pair of Istanbul chips, i've built dual CPU servers based on all of the above mentioned cores and each have kicked ass, so i'm looking forward to see what the Turkish smoked Opterons have to offer...
Are they hinting at the food they eat?
I would personally love to see a review of Shanghai vs Istanbul, would be rather interesting imo.
Then compare Istanbul to Dunnington.
Either way, its gna beat the crap outta any current MP Server that isnt Dunnington, I should hope anyway.
PS. Do I get chinese with Shanghai or Turkish Delights with Istanbul?
As has been pointed out already (I just thought I'd add to the noise), what is the point? Nobody has come up with a useful software model for USING all these cores. Even specialised stuff in the lab struggles to use more than a handful of cores effectively.
Until this issue is solved (and many many computer engineers question how long that will be, IF it's possible at all in any meaningful way using current technology), it's a complete waste of time creating processors with zillions of cores. Ok, you can argue that it's a chicken and egg problem and either the hardware or the software has to move forward at some point to allow the other to move forward. But there comes a point where the leader in the race (the hardware in this case) may as well take a breather and wait for the software to catch up (if it can). That wait could be quite long and lonely though.
> Nobody has come up with a useful software model for USING all these cores. Even specialised stuff in the lab struggles to use more than a handful of cores effectively.
How very, very wrong. There are plenty of scientific uses for many core machines. Why do you think thousand-commodity-core clusters continue to be built? The more CPU you can fit in a rack, the better (cooling and power notwithstanding)...
One of Google's big observations is that Java programming style tends to be very threaded, so idiomatically-written Java programs do tend to spread nicely over multiple cores once you have the multiple cores available. Writing explicit threading in C++ is three kinds of pain, so people are generally not willing to do that, but it's much less uncomfortable in the managed languages which have threads as a primitive.
I have a lot of software that isn't terribly communicative nor terribly memory-intensive, and the advent of quad-cores is wonderful for this; I can run a dozen copies of the software while having only three loud fan-heaters on my flimsy desk. If two six-cores cost less than three four-cores, one motherboard and a case, I'll buy them; if not, not.
"One of these would be very good in virtualisation environments to name just one example."
No it wouldn't!! Being a virtualised environment doesn't change anything. At the base level, you are still dealing with the problem of distributing multiple processes (ie - the processes that form each individual virtualised environment) across multiple cores. You still have the same memory bandwidth and contention problems. You still have the same inter-core co-ordination issues (the vitualised environments are just a smokescreen to the applications - something has to co-ordinate them all)
Virtualisation doesn't fix anything in this regard.
Keep in mind Istanbul is the code name for the server parts...not desktop. The current generation of AMD Opteron servers have been using Socket F since 2005. Since the release they have supported dual core Santa Rosa, QC Barcelona, QC Shanghai, and now 6C Istanbul, all using the same socket architecture. Pretty amazing.
A word about Dunnington. Most people and jounalists forget that Dunnington is just for 4 Socket servers. Intel doesn't have a 6-core product in the 2-socket space. Istanbul should be a 6-core product for 2S, 4S, and 8-socket.
Also, QC Shanghai does a decent job of competing with 6C Dunnington in a lot of workloads and benchmarks. Just take a look at VMware's VMmark for example. Virtualization results based on Shanghai lead the charts. Even the 16-core VMmark scores top the 24-core results (Dunnington).
Not bad using a platform that has been designed and leveraged across 4 processor generations over the last 4 years.
For anyone who thinks multi-core chips are pointless they desperately need to get "Clueless" tattooed backwards on their forehead so they can remind themselves of their lack of clue each morning in the mirror. Multi-core chips have been in the server farm for ages (which is of course what these are intended for). Web servers, databases, etc. all make extremely good use of multi-core or general multi-processor boxes. Most big data centres now worry most about power usage, and multi-core chips have helped a lot with reducing power consumption per giga-flops.
I should be getting my 8 socket Shanghai boxes soon and it's going to make a huge difference to my processes.
Also see Istanbul images here: http://www.flickr.com/photos/amd_unprocessed/
And view a blog post written by John Fruehe, Director of Business Development for Server/Workstation products at AMD here: http://blogs.amd.com/work/archive/2009/02/24/istanbul-not-constantinople.aspx
Let me relinquish my normal restraint and indulge in a bit of hi-tech geekery. I, for one, shall welcome our 4-socket 24-core server box manufacturing overlords. For HPC nerds, boxes like these fill a gap between the email-checking, report-writing, and Register-surfing desktops, and the number-crunching, MPI-enabling cluster farms used for the serious simulation work: ie. the test bed.
Bespoke Beowulf clusters don't cut it here; scientists soon find out that sharing the communication bus between interprocessor chit-chattery and mounted drives, on a single gigabit ethernet card, leads to blisteringly ZX81-esque performance. A simple to administrate UNIX machine cuts the mustard nicely - provided it packs a suitable punch. Nvidia's Tesla desktops are a step in the direction; here CUDA's CUBLAS is a masterstroke. But even CUBLAS requires recoding, and so a small server with plenty of memory shared between double-digits of cores fills a niche - and 24 is a good number.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
