Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
AMD Upgrades

AMD Launches Piledriver-Based 12 and 16-Core Opteron 6300 Family 133

MojoKid writes "AMD's new Piledriver-based Opterons are launching today, completing a product refresh that the company began last spring with its Trinity APUs. The new 12 & 16-core Piledriver parts are debuting as the Opteron 6300 series. AMD predicts performance increases of about 8% in integer and floating-point operations. With this round of CPUs, AMD has split its clock speed Turbo range into 'Max' and 'Max All Cores.' The AMD Opteron 6380, for example, is a 2.5GHz CPU with a Max Turbo speed of 3.4GHz and a 2.8GHz Max All Cores Turbo speed."
This discussion has been archived. No new comments can be posted.

AMD Launches Piledriver-Based 12 and 16-Core Opteron 6300 Family

Comments Filter:
  • by Hadlock ( 143607 ) on Monday November 05, 2012 @08:08AM (#41879091) Homepage Journal

    I'm not even sure how you could post a story about AMD, what with it's recent decline this entire last decade, and not directly compare them to intel.
     
    Are these even desktop or server chips? It's been so long since I bought AMD, I really couldn't tell you which line Piledriver sits in anymore, or if they've consolidated them.
     
    The general gist I've read is that AMD is cheaper than Intel, and in the past has been "more green" due to power consumption, but with Ivy Bridge, your bang for the buck and much, much smaller lithography process has given intel the advantage in both areas.

  • by jiteo ( 964572 ) on Monday November 05, 2012 @08:31AM (#41879201)

    AMD have been dying for 20 years now.

    Except they haven't. They've been dying since Intel started their tick-tock stratgey with the Core series, and AMD hasn't been able to keep up with Intel's gains in performance.

  • Re:shared FPU (Score:2, Insightful)

    by Anonymous Coward on Monday November 05, 2012 @08:44AM (#41879269)
    For some people, that's true. Others, not. Don't presume to know other people's applications. Multithreaded != FPU intensive
  • Re:shared FPU (Score:5, Insightful)

    by neyla ( 2455118 ) on Monday November 05, 2012 @08:48AM (#41879301)

    *shrug* Todays "top of the line" is tomorrows facebook-renderer. I've got an 8-core CPU, and didn't even want one, it was just a side-effect of buying a reasonable-speced machine on other factors (that I -did- care about) and the 8 cores being standard in a workstation in that performance-range. If there'd been a $25 off for half-the-cores option I'd gladly have taken it, but there wasn't. (yes I know I could roll-my-own)

  • Re:shared FPU (Score:5, Insightful)

    by Anne Thwacks ( 531696 ) on Monday November 05, 2012 @08:59AM (#41879361)
    If its MONEY you are talking about, they are probably integer calculations. I am fairly certain our servers only ever execute floating point instructions by accident
  • Re:shared FPU (Score:2, Insightful)

    by ByOhTek ( 1181381 ) on Monday November 05, 2012 @09:03AM (#41879393) Journal

    Probably not. We don't say 'that there are' here in America. We would use 'than'. Come on over some time, it might help alleviate some of that burden of ignorance you have.

    There are also these things called 'typos', when people make a mistake in their typing, usually because they are thinking faster than they can type.

  • Re:shared FPU (Score:5, Insightful)

    by ByOhTek ( 1181381 ) on Monday November 05, 2012 @09:08AM (#41879417) Journal

    Yep. Lots of servers where I work. Lots of high-CPU-use stuff. About 30-40 different applications across the servers.
    The vast majority of what they do is integer math. I doubt we'd notice if the CPUs were sent with the floating point math faked by the integer side of the house in the CPU.

    Mind you, another place I worked, had twice as many applications, and less than a dozen were integer intensive, and the rest were FP intensive.
    i.e., not everyone would need the large number of FPUs. There are different use cases, and if cutting the number of FPUs down reduces the CPU price, and the power consumption, some of us would be all over it.

  • by serviscope_minor ( 664417 ) on Monday November 05, 2012 @09:14AM (#41879451) Journal

    MD continues to push the number of cores upward more aggressively, but there's not many workloads where that matters enough for their slim advantage to result in a net win.

    I disagree: that's exactly what Xeon and Opteron are about. What differentiates those two from the Core and Phenom processors is that the former have multiple crazy fast and very expensive low latency links to allow glueless multi socket systems. Once you've got an (16)8 (hyper)thread Xeon or 16 core opteron and have more than one socket, you're already expecting a workload to scale to 32 distinct units.

    Basically these chips only make sense for pretty parallel work loads.

    Load up a Dell 815 for example and you'll find the CPU pricing seems small compared to what filling its RAM capacity up costs.

    I use this as my go-to online quoter.

    http://www.woc.co.uk/default6.aspx?nquoter=13 [woc.co.uk]

    I have no affiliation except that I've bought such machines from them before.

    Maxing out the RAM (512G) costs £3300. Maxing out the processors costs £2300. It's not quite as much, but it's substantially over half the price.

    That said, I've heard rumours that the new opterons can drive 32G DIMMS, in which case you could load it up with 1T RAM for the low, low price of £30,000. In which case, your point certainly stands.

    The 40% performance per watt gain claimed here--from AMD's own hand-picked best case scenario benchmark--is only enough to make the Intel performance and gap decrease in size, not go away

    True, but the Opterons are substantially cheaper. If you factor in lifetime cost including bang for buck, power and cooling, it's basically a wash and really dependent on the specific workload.

    If they have closed the gap this much, then they will be a substantially cheaper option overall.

  • by serviscope_minor ( 664417 ) on Monday November 05, 2012 @09:16AM (#41879473) Journal

    They've been dying since Intel... bribed vendors not to use Opteron processors so that even when AMD were clearly superior, they could never get ahead of Intel. That of course meant that they never had the revenue to capitalise on their very substantial advantage. Intel, of course got away with paying only $1bn, substantially cheaper than it would have been not to engage in illegal business practicses.

    FTFY.

  • by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Monday November 05, 2012 @09:38AM (#41879633) Homepage

    PostgreSQL versions from 8.3 to 9.1 did pretty well using up to 16 cores. 9.2 was the version that targeted scalability up to 64 cores, released this September [postgresql.org].

    The licensing model of commercial databases is one part of why PostgreSQL is become more viable even for traditional "enterprise" markets. PostgreSQL doesn't use processors quite as efficiently as its commercial competitors. The PostgreSQL code is optimized for clarity, portability, and extensibility as well as performance. Commercial databases rarely include its level of extensibility. This is why PostGIS as an add-on to the database is doing well against competitors like Oracle Spatial. And they're often willing to do terrible things to the clarity of their source code in order to chase after higher benchmark results. Those hacks work, but they cost them in terms of bugs and long-term maintainability.

    But if the software license scales per-core, nowadays that means you've lost Moore's Law as your cost savings buddy. What I remind people who aren't happy with PostgreSQL's performance per-core is that adding more cores to hardware is pretty cheap now. Use the software license savings to buy a system with twice as many cores, and PostgreSQL's competitive situation against commercial products looks a lot better.

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Working...