Slashdot Mirror
AMD Launches Piledriver-Based 12 and 16-Core Opteron 6300 Family
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."
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.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
Yes, they have a shared 256 bit FPU, but that can be split into two 128 bit parts. So no, multiplying two floating point numbers in two threads is performed immediately and simultaneously, the cores do not wait at all. I measured this on a previous generation Opteron 6234, the performance loss caused by running two threads on two cores of the same module vs two cores in different modules was barely measurable, 3%.
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.
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.