Spark SQL: Another 16x Faster After Tungsten: Spark Summit East talk by Brad Carlile
9 likes3,993 views
The document discusses the performance advantages of Oracle's SPARC processors, particularly in relation to Apache Spark and big data analytics. It emphasizes the efficiency of SPARC's architecture compared to x86 processors, highlighting significant improvements in core performance and in-memory query speeds. Additionally, it outlines various software optimizations and innovations that enhance data processing capabilities within Oracle's ecosystem.
Spark SQL: Another 16x Faster After Tungsten: Spark Summit East talk by Brad Carlile
- 3. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Spark is ExciKng – Lots of so=ware innova$on Spark’s Whole Ecosystem totally appeals to the performance expert in me • Great Ecosystem for AnalyKcs – Spark forms a conKnuum with other technologies (Ka`a, Solr, …) – Lots of Oracle’s customer using Spark • Spark is fast & scalable because of clean design – Spark’s in-memory focus • Spark speaks SQL & DataFrames – Perfect marriage for Data ScienKsts & Hardware AcceleraKon – …but what is the status of processor performance? 3
- 4. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Modern AnalyKcs is about Your Data & External Data • AnalyKcs is now your data PLUS external data – Oracle Database In-Memory Fastest on SPARC – ConKnuously analyzing same data in different ways – Fastest if store data in-memory • Big Data can be used to describe external data – Social networks, public data: senKments, weather, traffic, events, raKngs, trends, IoT sensors, behaviors,… – Lots of ETL/filtering needed to find useful data – Big Data SQL ConfidenKal – Oracle Internal/Restricted/Highly Restricted 4 BeBer informa1on when you can analyze all relevant data Weather Tweets External Data Order Customer Your Data Sensors Social
- 5. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 0.8x 1.0x 1.2x 1.4x 1.6x 1.8x 2.0x 2012 2013 2014 2015 2016 Core Performance vs. x86 E5 v2 Why NOT Up HERE? Is it really latency? X86 per core performance flat for 4 genera1ons IS THERE COMPUTE BOTTLENECK? REALLY? MIT Tech Review, “Chip maker Intel has signaled a slowing of Moore’s Law, … which played a role in just about every major advance in engineering and technology for decades.” 5 x86 Innova1ons in Per Core Performance has Stalled "per core = (server performance)/(server core count)" E5 E5 v2 E5 v3 E5 v4
- 6. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 0.8x 1.0x 1.2x 1.4x 1.6x 1.8x 2.0x 2012 2013 2014 2015 2016 Core Performance vs. x86 E5 v2 x86: flat for four genera1ons SPARC’s InnovaKons are ConKnually Increasing Core Performance • SPARC has faster cores for Database, Java, Apps, ... • SPARC has more cores per chip which also drives efficiency 6 Innova1ve HW Design gets around “x86 boBleneck” SPARC M7 S7 SPARC S7 SPARC: DB & Java/JVM S7 "per core = (server performance)/(server core count)"
- 7. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 0.8x 1.0x 1.2x 1.4x 1.6x 1.8x 2.0x 2012 2013 2014 2015 2016 Core Performance vs. x86 E5 v2 Java-JVM OLTP DB Meory Bandwidth GB/s SPARC S7 is 1.6x to 2.1x faster than x86 It’s more important how you use transistors, than the number transistors you make (Moore’s Law) 7 Innova1ve HW Design gets around “x86 boBleneck”, x86 per core perf stalled x86 in dashed lines SPARC in solid lines E5 E5 v2 E5 v3 E5 v4 SPARC T5 SPARC M7 S7 SPARC S7 "per core = (server performance)/(server core count)" "per core = (server performance)/(server core count)"
- 8. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPECjbb2015 MulKJVM SPARC S7 • InnovaKons in SPARC processor innovaKons improve Java and JVM performance – x86 performance is flat generaKon-to-generaKon • Trade off between tuning for Max jOps or Crit jOps on x86 8 SPARC S7 core 1.5x to 1.9x faster than x86 E5 v4 core on Max jOps/core 0 1,000 2,000 3,000 4,000 5,000 6,000 S7-2 Huawei HP HP Cisco Huawei Lenovo Crit jOps/core Max jOps/core x86 E5 v4 x86 E5 v3 "per core = (server performance)/(server core count)” See disclosure slide Processor chip, core Max jOPS Crit jOPS SPARC S7-2 4.27GHz SPARC S7 2,16 65,790 35,812 Huawei RH2288Hv3 2.2GHz E5 v4 22c 2,44 121,381 38,595 Cisco C220 2.2GHz E5 v4 22c 2,44 94,667 71,951 Huawei RH2288Hv3 2.3GHz E5 v3 18c 2,36 98,673 28,824 Lenovo x240 M5 2.3GHz E5 v3 18c 2,36 80,889 43,654
- 9. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Java(JVM) is the Language of the Cloud & FOSS JVM = Java Virtual Machine - Run$me ORACLE CONFIDENTIAL - Highly Restricted Java & the underlying JVM is the design target for SPARC Big Data & DevOps Descrip1on WriBen to Oracle Fusion Enterprise Apps Java Apache Spark In-memory Analtyics JVM Apache Cassandra NoSQL database Java Apache Hadoop Disk to disk Map Reduce Java Apache HDFS filesystem Java Apache Lucene Doc text Indexing Java Apache Solr text/doc/web search Java Jersey/Grizzly (REST) REST Interface Java Apache Hive SQL on HDFS Java Neo4j Graph Java Scala Language JVM Big Data & DevOps Descrip1on WriBen to Akka (REST) REST for Big Data JVM Apache Accumulo key/value store Java Apache Flink Batch &Stream Processing Java(JVM) Apache Ka`a Streaming Message Broker JVM Apache log4j Log event manager Java Apache Samza Stream processing JVM Apache Storm Stream processing Java & Clojure Apache Yarn Cluster job manager Java Apache Zookeeper Config & group services Java H20.ai ML Apps libraries Java, Python,R Apache Hbase NoSQL database Java
- 10. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Cassandra NoSQL 2.2.6 (Yahoo Cloud Serving Benchmark) SPARC core is 2.0x faster than E5 v3 core • SPARC S7 2.0x faster per core than E5 v3 Haswell • SPARC’s Java/JVM advantages benefit Cassandra performance – YCSB – Yahoo Cloud Serving Benchmark – 300M • Mixed Load Workload A (50% Read/50% Update) • More info at: hXp://blogs.oracle.com/bestperf 10 Cassandra Chip, core Processor Ave Ops/s K Ops/s per core SPARC per core Advantage SPARC S7-2 2,16 4.27 SPARC S7 69,858 4.4K 2.0x E5 v3 Haswell 2,36 2.3 E5 v3 90,184 2.5K 1.0x
- 11. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Oracle Database also OpKmized for AnalyKc Queries Apache Spark needs to implement these op$miza$ons! • Column Store is opKmal for AnalyKcs – AnalyKcs Looks across transacKons at specific columns – Database columns are Machine Learning features • Columns far more efficient when analyzing features (efficient bandwidth & CPU needs) • Can exploit data characterisKcs >20x benefit • Storage opKmizaKons – data repeatedly analyzed – Vector processing of DicKonary-encoded compares needs to be added to in Spark persisKng DataFrames in memory – layered compression means 10’s TB of data fit into TB’s of memory • Processing opKmizaKons – Bloom Filter join processing, operator pushdown, metadata opKmize 11 SQL op1mized for analy1c queries Big Feature RevoluIon # features collected is Exploding 10’s to 100’s Order F1 F2 … F150 Customer F1 F2 … F78 … F100
- 12. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Oracle DB Oracle Database In-Memory At Scale & SPARC DAX • OLTP uses proven row format • AnalyKcs use in-memory Column • 10x faster analyKcs due to soFware • Columnar compression means huge databases can now fit in-memory • Oracle database stores BOTH row and column formats • Simultaneously acKve and transacKonally consistent • 10x to 20x Faster SPARC DAX (Data Accelerator) HW innovaKon 12 Row Format Column Format Cached OLTP TransacKons Whole DB In Memory Compressed Whole DB In Memory Compressed 10-100’s TBytes Row store
- 13. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPARC DramaKcally Faster In-Memory SQL AnalyKcs in DB • SPARC S7 9.4x faster per core than x86 E5 v4 – SPARC S7-2 422 query/m vs 2-chip x86 56 query/m • S7-2 (18-cores total), 2-chip x86 E5 v4 (20-cores total) – x86 per core performance flat for 4 generaKons • DAX offloads In-Memory Scans – DAX offload allows cores to increase throughput • 160GB in memory represents 1TB DB on disk • 6.2x compression with Oracle 12.2 In-memory 13 SPARC is mul1genera1onal lead in performance: 14 Billion-row/sec per core In-Memory SQL Analy1cs 9.4x faster SPARC core advantage E5v4 x86 SPARC Offload DAX frees Cores for other processing 6x Compression 6x IM capacity
- 14. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPARC’s MulK-generaKonal Leapfrog in Performance • Integrated Offload – Data AnalyKcs AcceleraKon (DAX) – EncrypKon & Security • It’s more important how you use transistors, than Moore’s Law (the number transistors you make) Radical Innova1on: Integrated Offload offers 10x faster performance! Other vendors focused on Detached GPUs • Detached GPUs are poorly designed for SQL • Slow GPU interconnec$on robs performance Memory Half BW Memory X86 IBM Power 100% U1lized NO OFFLOAD ! NO OPEN Cores ! Band- Width SPARC S7 DAX OFFLOAD OFFLOAD DAX 14
- 15. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Graphic Processing Units (GPUs) GPUs Only Help Very Compute Intensive Algorithms Complex ML/StaIsIcs oRen not fast on GPUs… “Can only compute as fast as move data” • Detached GPUs have limited bandwidth – GPUs fit for lots of simple graphics • Graphics have Kny data movement: Coords & textures in, video frame out – Big Data ML much more demanding: GPUs have limited applicaKons • ML Learning & Scoring – Some ML Learning can be compute intensive, but only done iniKally to create Model • Nvidia Math Libraries only have BLAS3 rouKnes – BLAS2 and BLAS1 do NOT have compute intensity therefore are not in library – Complicated ML has mix of BLAS1, BLAS2, BLAS3 Bandwidth lines to scale GPU compute oRen stalled by lack of bandwidth Memory Chip Local 169 GB/s Local 57 GB/s E5 v4 22core Local 57 GB/s E5 v4 22core GPU GPU Current PCIe Future NVlink SPARC M7 32core
- 16. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SQL & the Many Flavors of DSL – All potenKals for DAX • SQL: – SELECT count(*) from person WHERE ci$zen.age > 18 • Apache Spark SQL (DSL) – val voters : Int = ci$zen.filter($”ci$zen.age” > 18).count() • Java Streams – int voters = arrayList.parallelStream().filter(ciKzen-> ciKzen.olderThan(18)).count(); • Apache Eclipse (Goldman Sachs CollecKons) – int voters = fastList.count(ciKzen-> ciKzen.olderThan(18)); ORACLE CONFIDENTIAL- Highly Restricted SQL can be wriBen in Domain Specific Languages (aka Language Integrated Queries) Apache Spark feeds both formats into SQL opImizer Joins can be wrinen & op$mized
- 17. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPARC DAX Integrated with Java JDK8 Streams • Java Streams provide SQL-style code in Java – Java Streams is a perfect fit for DAX acceleraKon • DAX & Java Streams – Integer Stream filter, allMatch, anyMatch, noneMatch, map(ternary operator), toArray & count funcKons – Simple code changes to use DAX • import com.Oracle.Stream instead of import java.uKl.Stream • DaxIntStream instead of IntStream • Public access: hXp://SWiSdev.oracle.com/DAX ORACLE CONFIDENTIAL - Highly Restricted DAX accelerates Java Streams: 3.6x to 21.8x faster 3.6x 4.0x 4.1x 10.7x 21.8x Outlier %Kle Top-N Filter allMatch Speedup with DAX 10 Million Rows Java Stream API: filter2_data.parallelStream().filter(w->w.temp<100).count()
- 20. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | By EvaluaKng Delivered Bandwidth, We can see we are sKll Not Yet Efficient • EvaluaKon performance on Full Table Scan of 600M rows – Time to Scan = 0.16 sec Impressive: 104.2 Million Rows/sec per core • Going back to 1st principles: Scanning is about data movement – What is bandwidth of 2.1 in-memory Scan? 14 GB/s (Spark 2.0.1) – What is the system memory bandwidth? 114 GB/s (Stream Triad) – 7.6x more bandwidth available! • Other Queries deliver less: “SELECT count(*) FROM lineorder WHERE lo_quanKty BETWEEN 10 and 20” – 19x more bandwidth available! -- BUT only delivering 6GB/s on the system 20 2-chip x86 E5 v3(Haswell), total 36 cores, 72 threads/VCPU
- 21. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | AFer Spark 2.1: Another 10x in Performance SKll Possible Select count(*) from store_sales where ss_item_sk > 100 and ss_item_sk < 1000 1. Volcano Iterator model: plan interpretaKon – Open; Next data element; perform predicate; Close 2. “College Freshman” Java : Whole-Stage CodeGen pipelined code – for (ss_item_sk in store_sales) {if (ss_item_sk > 100 and ss_item_sk < 1000 ) { count += 1}} 3. Tuned true vectorizaKon library: highly-tuned code operates on conKguous column – vectorRangeFilter (n, VECTOR_OP_GT, 1000,VECTOR_OP_LT, 1000, store_sales, result, result_cnt) 4. Hardware Accelera1on further accelerates scanning – vectorRangeFilter (n, VECTOR_OP_GT, 1000,VECTOR_OP_LT, 1000, store_sales, result, result_cnt) • x86 AVX2 (Graphics InstrucKon) – deliver 70 GB/s per chip • Oracle’s SPARC M7 processor – deliver 140 GB/s per chip 21 Project Tungsten SPARC DAX
- 22. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPARC DAX AcceleraKng Apache Spark 2.1.0 • Proof-of-Concept Prototype on SPARC S7: Apache Spark 2.1 POC: DAX & in-memory columnar – 2-chip SPARC S7 DAX: 9.8 Billion rows/sec on 2-predicate scan • SPARC S7-2(16 total cores) 0.061 sec • 2-chip x86 (20 total cores) 0.760 sec latest genera$on E5 v4 Broadwell – These advantages are over and above Tungsten’s improvements • SPARC DAX offloads criKcal funcKons – SQL: filtering, dicKonary encoding, 1 & 2 predicate, join processing, addiKonal compression, etc. • Libdax open API: hXp://SWiSdev.oracle.com/DAX 22 Spark SQL on SPARC S7-2 DAX over 15.6x faster per core than x86 x86 SPARC DAX 15.6x faster per core than x86 Spark On SPARC S7
- 23. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | In-Memory Columnar Two-level Compression: Oracle DB Same technique needs to be added to Apache Spark • Efficient In Memory Columnar Table • DicKonary encoding huge compression – 50 US only need 6 bits (<1 byte) vs. “South Dakota” needs 12 characters or 192 unicode bits = 32x smaller – Ozip/RLE compression is then applied on top of dicKonary encoding • Innova1ons that Apache Spark s1ll needs – Directly scan dic$onary encoded data ! – Range scans (2-predicate) in one step – Ozip decompression without wri$ng to memory – Save Min & Max for scan eliminaKon – Can use dicKonary for “featurizaKon” of data for ML 23 0 1 3 2 0 2 3 Column Min: South Dakota Max: Utah DicIonary Dict encode Column value list South Dakota Tennessee Utah Texas South Dakota Texas Utah DicIonary VALUE ID South Dakota 0 Tennessee 1 Texas 2 Utah 3 OZip + RLE) Capa- city Low (Ozip) Verizon re-invented this as well (Spark Summit 2017 Boston): RealKme AnalyKcal Query Processing &PredicKve Model Debasish Das (Verizon)
- 26. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | The Basic AnalyKcs Flow • Data can come from many sources – Databases, NoSQL, csv, feeds… • We need to prepare it – Data Munging of all sorts! • Analyze the data – Find the “right way” to analyze it • ML, Graph, SQL… ConfidenKal – Oracle Internal/Restricted/Highly Restricted 26 A lot of 1me spent in Data Munging Data Munging RESULTS Analy1cs NoSQL, Search. … Streaming Kaza, Storm… Databases
- 27. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | ConKnuous AnalyKcs Cycle Results OFen Enrich TransacKons Analy1cs is more than one pipeline stream • ConKnuous iteraKons around the data analyKcs wheel – Save, catalog, and re-use all things: data, SQL, code, and analyKcs • In-memory advantages at each stage – SPARC’s DAX & leading bandwidth is key • Many sources of data – Internal proprietary, public data, external streaming, archives Oracle ConfidenKal – Highly Restricted 27 Streaming Kaza, Storm, … Enhance TransacIons Reports NoSQL ETL (SQL) ETL (SQL) In-Memory: Reuse data & analysis ML & Graph (FP) Results (SQL) Feature Extract, Generate & Transform (SQL) Databases
- 28. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | ComputaKonal Graph Algorithms: PageRank & Single-Source Shortest Path (SSSP) • Graph computaKons accelerated by SPARC’s memory bandwidth – Bellman-Ford/SSSP (single-source shortest path) – opKmal route or connecKon – PageRank - measuring website importance Graph: SPARC M7 up to 1.5x faster per core than x86 Graph Algorithm Workload Size 4-chip X86 E5 v3 4-chip SPARC T7-4 SPARC per chip Advantage SPARC per core Advantage SSSP Bellman-Ford 448M verKces, 17.2B edges 39.2s 14.7s 2.7x 1.5x 233M verKces, 8.6B edges 21.3s 8.5s 2.5x 1.4x PageRank 448M verKces, 17.2B edges 136.7s 62.6s 2.2x 1.2x 233M verKces, 8.6B edges 72.1s 27.6s 2.6x 1.5x 28 "per core = (server performance)/(server core count)"
- 29. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Oracle Database Advanced AnalyKcs OpKon Machine Learning on SPARC • Oracle Advanced AnalyKcs in Oracle Database 12.2 – SPARC M7 faster per core on training 64-bit floaKng point intensive – In-memory 640 million records, Airline On-Kme dataset ML training SPARC M7 up to 2.0x faster per core than x86 SGD (StochasKc Gradient Descent) IPM (Interior Point Method) Training: CreaIng Model from data ABri- butes X5-4 4-chip T7-4 4-chip SPARC per chip Advantage SPARC per core Advantage Supervised SVM IPM Solver 900 1442s 404s 3.6x 2.0x GLM ClassificaKon 900 331s 154s 2.1x 1.2x SVM SGD Solver 9000 157s 84s 1.9x 1.1x GLM Regression 900 78s 55s 1.4x 0.8x Cluster Model ExpectaKon MaximizaKon 9000 763s 455s 1.7x 0.9x K-Means 9000 232s 161s 1.4x 0.8x 29 "per core = (server performance)/(server core count)" Predict Train
- 30. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Oracle Database Advanced AnalyKcs OpKon Machine Learning on SPARC • Oracle Advanced AnalyKcs in Oracle Database 12.2 – SPARC M7 much faster per core on scoring bandwidth-intensive – In-memory 1 Billion records, Airline On-Kme dataset ML predic1on SPARC 3.0x - 4.8x faster per core than x86 SGD (StochasKc Gradient Descent) IPM (Interior Point Method) Predic1on Using model on 1B records ABri- butes X5-4 4-chip T7-4 4-chip SPARC per chip Advantage SPARC per core Advantage Supervised SVM IPM Solver 900 206s 24s 8.6x 4.8x GLM Regression 900 166s 25s 6.6x 3.7x GLM ClassificaKon 900 156s 25s 6.2x 3.5x SVM SGD Solver 9000 132s 24s 5.5x 3.1x Cluster Model K-Means 9000 222s 35s 6.3x 3.6x ExpectaKon MaximizaKon 9000 243s 40s 6.1x 3.4x 30 "per core = (server performance)/(server core count)" Predict Train
- 31. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Spark ML DataFrame Algorithms use BLAS1 & some BLAS2 • ALS(AlternaKng Least Squares matrix factorizaKon – BLAS2: _SPR, _TPSV – BLAS1: _AXPY, _DOT, _SCAL, _NRM2 • LogisKc regression classificaKon – BLAS2: _GEMV – BLAS1: _DOT, _SCAL • Generalized linear regression – BLAS1: _DOT • Gradient-boosted tree regression – BLAS1: _DOT • GraphX SVD++ • BLAS1: _AXPY, _DOT,_SCAL • Neural Net MulK-layer Perceptron • BLAS3: _GEMM • BLAS2: _GEMV 31 Lower compute intensity of 0.66 to 2.0, BLAS1/BLAS2 limits ML performance, BLAS3 faster Sparse Linear Algebra has Even lower compute intensity “One can only compute as fast as one can move data” Max Flops = Compute-intensity * (Memory-BW/bytes-element) Compute-Intensity = Flops/element Single FP = 4bytes/element Double FP = 8bytes/element HINT: Spark Developers need to write sub-block matrix implementa$ons to get more BLAS3 usage in Spark ML …Why? BLAS3 are more efficiently, because they use less memory bandwidth and reduce number of method calls Fastest LAPACK solvers use BLAS3
- 32. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | GPUs Only Accelerate Some Compute Kernels Detached GPU memory bandwidth is boBleneck for most computa1ons Rou1ne Level Opera1on Flops Mem Compute Intensity Tesla K80 peak Max Possible Gflops @12GB/s block=100 PCIe GPU % peak Max Possible Gflops @80GB/s block=100 Nvlink (future) GPU % peak BLAS1 (vector) y = ax + y 2n 3n 2/3 935 Gflops 1 Gflops 0.1% 7 Gflops 0.7% BLAS2 (matrix-vector) y = Ax + y 2n^2 + 2n n^2 2 935 Gflops 3 Gflops 0.3% 20 Gflops 2.1% BLAS3 (matrix-matrix) C = AB + C 2n^3 4 n^2 n / 2 935 Gflops 75 Gflops 8.0% 500 Gflops 53.5% FFT C = FFT(A) n log(n) 2n Log(n)/2 935 Gflops 239 Gflops 1M 1D-FFT 25% 935 Gflops 1M 1D-FFT Near peak Oracle ConfidenKal – Highly Restricted 32 Only 6 BLAS3 rouKne types in Nvidia Library: gemm, syrk, syr2k, trsm, trmm, symm Can write codes using BLAS2/1 in GPUs but resulKng compute intensity must be large to accelerate
- 33. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPARC Advantages on AnalyKcs Across the Spectrum Key underlying technologies provide drama1c performance advantages SPARC’s Java & JVM advantages SQL DAX Offload SPARC DAX offload acceleration Oracle Developer Perflib math libraries NoSQL Machine Learning Graph & Spatial • Oracle Database • Big Data with DAX • Cassandra NoSQL • Oracle NoSQL • Spark MLlib • Advanced Analytics • Spark GraphX • Oracle Spatial&Graph up to 10x faster per core up to 5x faster per core up to 1.5x faster per core up to 1.9x faster per core 33
- 34. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Required Benchmark Disclosure Statement • AddiKonal Info: hXp://blogs.oracle.com/bestperf • Copyright 2016, Oracle &/or its affiliates.All rights reserved. Oracle&Java are registered trademarks of Oracle &/or its affiliates.Other names may be trademarks of their respecKve owners • SPEC and the benchmark name SPECjEnterprise are registered trademarks of the Standard Performance EvaluaKon CorporaKon. Results from www.spec.org as of 7/6/2016. SPARC S7-2, 14,400.78 SPECjEnterprise2010 EjOPS (unsecure); SPARC S7-2, 14,121.47 SPECjEnterprise2010 EjOPS (secure) Oracle Server X6-2, 27,803.39 SPECjEnterprise2010 EjOPS (unsecure); IBM Power S824, 22,543.34 SPECjEnterprise2010 EjOPS (unsecure); IBM x3650 M5, 19,282.14 SPECjEnterprise2010 EjOPS (unsecure). • SPEC and the benchmark name SPECjbb are registered trademarks of Standard Performance EvaluaKon CorporaKon (SPEC). Results from hXp://www.spec.org as of 6/29/2016. SPARC S7-2 (16-core) 65,790 SPECjbb2015-MulKJVM max-jOPS, 35,812 SPECjbb2015-MulKJVM criKcal-jOPS; IBM Power S812LC (10-core) 44,883 SPECjbb2015-MulKJVM max-jOPS, 13,032 SPECjbb2015-MulKJVM criKcal-jOPS; SPARC T7-1 (32-core) 120,603 SPECjbb2015-MulKJVM max-jOPS, 60,280 SPECjbb2015-MulKJVM criKcal-jOPS; Huawei RH2288H v3 (44- core) 121,381 SPECjbb2015-MulKJVM max-jOPS, 38,595 SPECjbb2015-MulKJVM criKcal-jOPSHP ProLiant DL360 Gen9 (44-core) 120,674 SPECjbb2015-MulKJVM max-jOPS, 29,013 SPECjbb2015-MulKJVM criKcal-jOPS; HP ProLiant DL380 Gen9 (44-core) 105,690 SPECjbb2015-MulKJVM max-jOPS, 52,952 SPECjbb2015-MulKJVM criKcal-jOPS;; Cisco UCS C220 M4 (44-core) 94,667 SPECjbb2015-MulKJVM max-jOPS, 71,951 SPECjbb2015-MulKJVM criKcal-jOPS; Huawei RH2288H V3(36-core) 98,673 SPECjbb2015-MulKJVM max-jOPS, 28,824 SPECjbb2015-MulKJVM criKcal-jOPs; Lenovo x240 M5 (36-core) 80,889 SPECjbb2015-MulKJVM max-jOPS,43,654 SPECjbb2015-MulKJVM criKcal-jOPS; SPARC T5-2 (32-core) 80,889 SPECjbb2015-MulKJVM max-jOPS, 37,422 SPECjbb2015-MulKJVM criKcal-jOPS; SPARC S7-2 (16-core) 66,612 SPECjbb2015-Distributed max-jOPS, 36,922 SPECjbb2015-Distributed criKcal-jOPS; HP ProLiant DL380 Gen9 (44-core) 120,674 SPECjbb2015-Distributed max-jOPS, 39,615 SPECjbb2015-Distributed criKcal-jOPS; HP ProLiant DL360 Gen9 (44-core) 106,337 SPECjbb2015-Distributed max-jOPS, 55,858 SPECjbb2015-Distributed criKcal-jOPS; HP ProLiant DL580 Gen9 (96-core) 219,406 SPECjbb2015-Distributed max-jOPS, 72,271 SPECjbb2015-Distributed criKcal-jOPS; Lenovo Flex System x3850 X6 (96-core) 194,068 SPECjbb2015-Distributed max-jOPS, 132,111 SPECjbb2015-Distributed criKcal-jOPS. • SPEC and the benchmark names SPECfp and SPECint are registered trademarks of the Standard Performance EvaluaKon CorporaKon. Results as of October 25, 2015 from www.spec.org and this report. 1 chip resultsSPARC T7-1: 1200 SPECint_rate2006, 1120 SPECint_rate_base2006, 832 SPECfp_rate2006, 801 SPECfp_rate_base2006; SPARC T5-1B: 489 SPECint_rate2006, 440 SPECint_rate_base2006, 369 SPECfp_rate2006, 350 SPECfp_rate_base2006; Fujitsu SPARC M10-4S: 546 SPECint_rate2006, 479 SPECint_rate_base2006, 462 SPECfp_rate2006, 418 SPECfp_rate_base2006. IBM Power 710 Express: 289 SPECint_rate2006, 255 SPECint_rate_base2006, 248 SPECfp_rate2006, 229 SPECfp_rate_base2006; Fujitsu CELSIUS C740: 715 SPECint_rate2006, 693 SPECint_rate_base2006; NEC Express5800/R120f-1M: 474 SPECfp_rate2006, 460 SPECfp_rate_base2006. • Two-Ker SAP Sales and DistribuKon (SD) standard applicaKon benchmarks, SAP Enhancement Package 5 for SAP ERP 6.0 as of 5/16/16:SPARC M7-8, 8 processors / 256 cores / 2048 threads,SPARC M7, 4.133 GHz, 130000 SD Users, 713480 SAPS, Solaris 11, Oracle 12cSAP, CerKficaKon Number: 2016020, SPARC T7-2 (2 processors, 64 cores, 512 threads) 30,800 SAP SD users, 2 x 4.13 GHz SPARC M7, 1 TB memory, Oracle Database 12c, Oracle Solaris 11, Cert# 2015050. HPE Integrity Superdome X (16 processors, 288 cores, 576 threads) 100,000 SAP SD users, 16 x 2.5 GHz Intel Xeon Processor E7-8890 v3 4096 GB memory, SQL Server 2014, Windows Server 2012 R2 Datacenter EdiKon, Cert# 2016002 . IBM Power System S824 (4 processors, 24 cores, 192 threads) 21,212 SAP SD users, 4 x 3.52 GHz POWER8, 512 GB memory, DB2 10.5, AIX 7, Cert#201401. Dell PowerEdge R730 (2 processors, 36 cores, 72 threads) 16,500 SAP SD users, 2 x 2.3 GHz Intel Xeon Processor E5-2699 v3 256 GB memory, SAP ASE 16, RHEL 7, Cert#2014033. HP ProLiant DL380 Gen9 (2 processors, 36 cores, 72 threads) 16,101 SAP SD users, 2 x 2.3 GHz Intel Xeon Processor E5-2699 v3 256 GB memory, SAP ASE 16, RHEL 6.5, Cert#2014032. SAP, R/3, reg TM of SAP AG in Germany and other countries. More info www.sap.com/benchmarks. Must be in SPARC S7 & M7 Presenta1ons with Benchmark Results
- 36. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Why Apache Spark is best on SPARC • SPARC’s leadership in fast JVM performance speeds Scala – SPARC design focus on Java & JVM benefits all Apps that use JVM • SPARC’s huge lead in delivered memory bandwidth – SPARC accelerates Spark’s in-memory design – Big data apps needs fast data movement • SPARC DAX to provide huge offload acceleraKon in Apache Spark – ContribuKng code to Apache Spark SQL/DataFrames to use DAX • SPARC’s leading floaKng-point performance for Machine Learning – Designed for fast FloaKng Point (FP) on sparse & advanced algorithm Design innova1ons at every level 36
- 37. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | SPARC Advantages for Every Form of AnalyKcs AnalyIcs In-memory Columnar SW & SoRware in Silicon (SPARC DAX) SPARC’s efficient CPU & memory design Database Analy1cs Analy$c SQL Queries for database ✔ ✔ Java Analy1cs Java Code that probes data SQL-like code ✔ ✔ Machine Learning (ML) Automa$cally finding hidden panerns & correla$ons ✔ ✔ Graph Automa$cally find panerns in Social networks, etc. ✔ NoSQL Fast access to semi-structured & unstructured data ✔ Spa1al Fast throughput on geometric data ✔ 37 SPARC is 1.3x to over 10x faster per core on Analy1cs than x86 Feature genera$on & Selec$on for ML is o=en SQL
- 38. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 0.0 50.0 100.0 150.0 200.0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Billions Rows/sec Bits to encode data: log2(cardinality) Range Scan Used in SQL “Between” S7-1 DAX 8-core S7-2 DAX 16-core E5 v3 AVX2 18-core SPARC DAX Scan Performance versus x86 E5 v3 (AVX2) DAX offload scans: SPARC S7 only uses 25% cores and x86 uses 50% cores 38 18-core x86 E5 v3 8-core SPARC S7 Oracle has open API for DAX: hXps://swisdev.oracle.com/ 16-cores SPARC S7-2
- 40. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Machine Learning (ML): Scoring/PredicKon versus Training/Learning CharacterisKcs Predic1on/Scoring operates on huge amounts of data with low compute intensity ML Score/ Predic1on ML Learn/ Train % of acKvity Most Data *IniKal ComputaKon O(n^2) Matrix-vector O(n^3) Matrix-matrix Data O(n^2) O(n^2) Compute Intensity (Compute/Data) Low constant O(n) SPARC Advantage Due to Memory Bandwidth & design 3x to 6x per core Up to 1.3x per core Oracle ConfidenKal – Highly Restricted 40 Training Set Scoring/PredicKon Results Can train on one server then move model to predic$on server (ex: StubHub) Models live 1 week! Training/ Learning Data to Evaluate *Ini$al and then occasionally update models data samples Model Every 4 weeks