Sun

SPARC M7

Oracle announced their next-generation SPARC processor - M7 - a few weeks ago, and it's fascinating! Here's the rundown.

  • It has 32 cores, running at a clock speed higher than 3.6GHz. These are a minor tweak to the existing S3 core; i don't really expect it to be super-competitive just on core performance, as it's still dual-issue and therefore can only issue from two threads in a given cycle.
  • It has a new cache hierarchy, involving shared L2 among blocks of cores. The 256KB L2I is shared among groups of four cores, while the 256KB L2D is shared among pairs. This can mean an effective 50% capacity increase and additional flexibility over the existing 128KB unified L2 per core.
  • It has a 64MB partitioned L3, up from 48MB in M6. Based on the quoted transistor count of approximately ten billion transistors, i believe this is SRAM rather than eDRAM.
  • It has 8-channel DDR4, for 160GB/s peak memory bandwidth. This is good.
  • It includes metadata (which can be used for data integrity) in unused bits of virtual addresses.
  • Finally, the cool part - it includes accelerators for SQL as core blocks on the processor itself, with a coherent address space with the SPARC cores themselves.

It looks like a really good chip - if it can be priced competitively. We're seeing what looks like a smaller emphasis on trying to keep up on core performance, and a larger focus on workload specialization for databases; i look forward to seeing benchmarks once it ships.
How do you anticipate it matches up with an x64 chip for the same application?
SGI:
:A3502L: Dual Itanium [email protected] 4GB Marisa
:Octane2: Dual [email protected] 2GB V12 Sakuya
Non-SGI:
HP C8000
HP EliteBook 8560p [email protected] 16GB Youmu FreeBSD 10.1/Windows 8.1
IBM IntelliStation 265 Dual [email protected] Jigoku-Karasu ( Hell Raven )

Incoming/On bench for repair/not in service:
2x :O3x0: Origin 300

For Sale: O2 DIMMS, Octane and O2 caddies.
Depends on the application. For core compute performance, i anticipate Broadwell-EP and possibly Haswell-EX will attain comparable or higher SPEC numbers at a vastly lower price. On the other hand, the wildcard here is the database acceleration engines. Oracle only provided us one comparison point in the presentation: one of thirty-two database query pipelines is approximately an order of magnitude faster than a T5 core running a single thread that decompresses the bit-packed internal format of the Oracle database.

This is a flawed comparison in a number of ways. First off, the S3 core used in the T5 (and, in a slightly modified form, the M7) is inherently weak at single-thread performance. The whole idea is to get high utilization of a relatively weak (in peak instructions per cycle) core. Running a single thread as a comparison point doesn't tell us much. Second, we don't know the characteristics of the actual workload - the slide is ambiguous on whether it's comparing the decompression alone, or the WHERE-clause predicate evaluation, which the query engines are also capable of doing. There's also no word on latency of setup and transfer to a query engine.

Overall i would say that there's a lot of cool stuff here but it's hard to anticipate how much it will actually affect a normal transaction-processing workload running Oracle. Oracle will no doubt publish SAP SD-2 and TPC-H results for M7 when it's released; we'll get a clearer picture then of what the new features do for Oracle databases. i would not be at all surprised if M7 is significantly faster than contemporary Xeon on a per-socket basis for Oracle workloads - but it also needs to be priced competitively.
Kira wrote: Depends on the application.

Any benchmarks on Palantir ?
he said a girl named Patches was found ...
hamei wrote:
Kira wrote: Depends on the application.

Any benchmarks on Palantir ?


We're going to have to sit back for a bit and wait for some benchmarks. All of what I saw was just promotional stuffing with no meat.
"Apollo was astonished, Dionysus thought me mad."
That never happens in enterprise computing. :P
smit happens.

:Fuel: bigred , 800MHz R16K, 4GB RAM, V12, 6.5.30
:Indy: indy , 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP: purplehaze , R10000, Solid IMPACT
probably posted from Image bruce , Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * HP C8000 * BeBox * Solbourne S3000 * Commodore 128 * many more...
So in a nutshell it has specialised instructions and a core for database usage, and if these can be utilised, it will do better at the limited market of running OracleDB software? I know that's a gross oversimplification but I'm not an electrical engineer so I can't say I really am well acquainted with the industry terminology.
SGI:
:A3502L: Dual Itanium [email protected] 4GB Marisa
:Octane2: Dual [email protected] 2GB V12 Sakuya
Non-SGI:
HP C8000
HP EliteBook 8560p [email protected] 16GB Youmu FreeBSD 10.1/Windows 8.1
IBM IntelliStation 265 Dual [email protected] Jigoku-Karasu ( Hell Raven )

Incoming/On bench for repair/not in service:
2x :O3x0: Origin 300

For Sale: O2 DIMMS, Octane and O2 caddies.
Keep in mind that the (actually only) reason Oracle bought Sun was to have a proprietary platform to run OracleDB on and lock customers in.
smit happens.

:Fuel: bigred , 800MHz R16K, 4GB RAM, V12, 6.5.30
:Indy: indy , 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP: purplehaze , R10000, Solid IMPACT
probably posted from Image bruce , Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * HP C8000 * BeBox * Solbourne S3000 * Commodore 128 * many more...
TeamBlackFox wrote: So in a nutshell it has specialised instructions and a core for database usage, and if these can be utilised, it will do better at the limited market of running OracleDB software? I know that's a gross oversimplification but I'm not an electrical engineer so I can't say I really am well acquainted with the industry terminology.


That's roughly accurate, yes.
TeamBlackFox wrote: So in a nutshell it has specialised instructions and a core for database usage, and if these can be utilised, it will do better at the limited market of running OracleDB software? I know that's a gross oversimplification but I'm not an electrical engineer so I can't say I really am well acquainted with the industry terminology.


Should be a lot better at running OracleDB software - think of it like running OpenGL on CPU vs GPU - the GPU is has the specialized instructions for OpenGL and runs it many orders of magnitude faster then the CPU. Oracle is trying to create the "Ultimate OracleDB Platform"
"Apollo was astonished, Dionysus thought me mad."