Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
AMD Hardware

AMD's Six-Core Istanbul Opterons 123

EconolineCrush writes "AMD's latest 'Istanbul' Opterons add two cores per socket, for a grand total of six. Despite the extra cores, these new chips reside within the same power envelope as existing quad-core Opterons, and they're drop-in compatible with current systems. The Tech Report has an in-depth review of the new chips, comparing their performance and power efficiency with that of Intel's Nehalem-based Xeons. Istanbul fares surprisingly well, particularly when one considers its performance-power ratio with highly parallelized workloads."
This discussion has been archived. No new comments can be posted.

AMD's Six-Core Istanbul Opterons

Comments Filter:
  • by IYagami ( 136831 ) on Tuesday June 02, 2009 @09:33AM (#28181135)

    From http://www.sun.com/processors/UltraSPARC-T2/features.xml [sun.com]

    "Features and Benefits
    With eight cores and 64 threads on one chip, integrated 10 GbE networking, crypto, and PCI-Express expansion, you have the jump on anything else on the market. The opportunities for system consolidation and virtualization are here like never before. Consumes less power per core and thread than any processor in its class - without compromising on performance. The UltraSPARC T2 processor gives OEMs a massively threaded, multi-core alternative to more power-hungry, less threaded processors from competing vendors."

  • by Gazzonyx ( 982402 ) <scott,lovenberg&gmail,com> on Tuesday June 02, 2009 @09:39AM (#28181193)

    [...] Not only that, but it's hitting the market early. AMD had originally planned to introduce this product in the October time frame, but the first spin of Istanbul silicon came back solid, so the firm pulled the launch forward into June. Even with the accelerated schedule, of course, Istanbul comes not a moment too soon, now that Nehalem Xeons are out in the wild.

    Does anyone else think that this seems a little convenient? I'm really hoping that they didn't just tone down the testing to make it to market. I'm thinking they'll go to market and then quickly release a new revision to fix the corners that they cut the first time around. I hope I'm wrong, but AMD has been slipping lately.

    Any EE's out there know the process well enough to confirm or deny my suspicions?

  • by Narishma ( 822073 ) on Tuesday June 02, 2009 @11:27AM (#28182991)
    From an interview with bit-tech [bit-tech.net]:

    bit-tech: Has the launch of Istanbul been brought forward in response to Nehalem EX's updated launch date?

    Patler: Istanbul being pulled in by five months is a result of excellent execution by our design and manufacturing teams who were about to take it from first stepping of silicon to production. Also, the fact that Istanbul is based on our existing socket infrastructure, enables our OEMs to save time on validation cycles that are normally associated with a new processor that delivers the performance Istanbul can.

  • by Vancorps ( 746090 ) on Tuesday June 02, 2009 @01:02PM (#28184373)

    I believe Anandtech is showing it's bias here. I had heard great things about the Xeon 55xx series CPUs so I went and bought a couple of servers. Specifically one web server and one database server. I also had Opteron-based servers performing the same tasks. My webservers are load balanced using a hardware load balancer. During January I was under an extremely heavy load scenario. I ended up having to weight more traffic to the Opteron servers because the Xeons were choking under 100% cpu load. I barely squeaked by as all my servers were quite overloaded but once you get to a certain threshold Xeon performance seems to drop sharply.

    Rendering Intel has always been king but everywhere else Opterons have performed better for me again and again. I'm 100% 64bit though and I haven't tested virtualization performance yet.

  • by Anonymous Coward on Tuesday June 02, 2009 @04:41PM (#28187467)

    Actually, testing was increased for 6Core... As our 4Core tests no longer stressed a system with 50% more cores the same way.

    What changed was Process. 6Core uses all of the 'good' tech from Shanghai, then implements a few things differently (rev upgrades, etc). The reason 6Core launched soo quickly, is we learned all of our lessons on the initial quad core fiasco. We did things 'right' this time, and the result is... a launch date that is nearly 12mos ahead of the initial schedule (which was set 2yrs ago).

    Personally, I trust the 6Core parts moreso than our 4Core parts... but maybe that's cause i've been testing the 6Core parts for over 8 mos and have had realatively few problems.

    Trust me, we can't afford to fail, so there's no way they're going to cut corners. The last thing we want is another Cache Disable fiasco. Mark my anonymous word, 6Core is a fully tested and mother approved processor.

  • by Zork the Almighty ( 599344 ) on Tuesday June 02, 2009 @10:03PM (#28190887) Journal
    Hyperthreading shows you eight fake cores which map to four real cores. I benchmarked it extensively. Computationally intensive routines with a small memory footprint can gain up to 20%. Bandwidth or memory intensive routines can lose up to 50%. In the extreme case, 8 threads on virtual cores can be half the speed of 4 threads on 4 real cores on a Core i7. Keep in mind, this is on a crazy application that generates lots of data.

    If your algorithm is designed to break up the problem to exploit the cache then hyperthreading is a bigger mess. The data for thread 1 and thread 2 (out of 8) might be complementary, but the operating system will run those threads different actual cores, because all it sees is the virtual cores. This can be very inefficient if you need the whole cache.

    Perhaps worst of all, you are stuck always running 8 threads. 2-6 threads may not be distributed evenly across the real cores, leading to inconsistent performance. Therefore, you may lose performance by attempting to scale the problem further than it is efficient to do so. With real cores, I can decide (based on problem size) the correct number of core to use.

    In conclusion, hyperthreading has its uses, but operating systems are oblivious to it and that's a major problem with more than one core.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...