12 ms·
Oracle Cranks Up The Cores To 32 With Sparc M7 Chip
- slambam 12y agoOne of the better write ups, since the Hot Chips presentation.
- Quequau 12y agoIt's a shame we've got to wait so long until the publish the videos of the presentations.
- matdrewin 12y agoI wonder how much it would cost in licensing to run an Oracle DB on that kind of hardware.
- rodgerd 12y agoOracle are increasingly moving to hugely punative licensing schemes for running their DB on non-Oracle platforms, up and down the stack; run a single vCPU guest on a VMware farm? Fuck you, license all your hypervisors. Unless you want to buy SPARC, the you can do sub-capacity licensing. Time will tell whether customers will prefer to get reamed for Oracle hardware to avoid some Oracle software costs, or simply switch to DBs with less tied pricing models.
- needusername 12y agoSwitch to what? We send a seven figure number every year to Oracle but we currently see no alternative. SQLServer only runs Windows, their licensing model gets more and more Oracle like every year (for us currently "buying" SQLServer from internal IT isn't much cheaper than Oracle anymore). And you have to maintain you own JDBC driver. DB2 is just the same thing as Oracle. PostgreS does not compare. Then there's the migration itself. Firstly your application will be "tuned for Oracle" over several years. So you'll use every proprietary Oracle feature that gives you additional performance (subpartitions, parallel query execution, optimizer hints, manual column statistics, connect by, listagg, …). Which makes porting fun. You can't assess the performance of your application on the new database until you're done porting. Likely the most performance critical parts will have the most Oracle dependencies. You won't have any experience performance tuning the new database. And you won't have any experience operating the new database (monitoring, trouble shooting, backups, HA, failover, maintenance, …). Take all this together and we're pretty much locked into Oracle. So I see us go with Oracle hardware rather than switch to some other database. Which has the additional benefit of getting rid of the "engineered" SAN by the internal IT which is slower than a single SSD.
- rodgerd 12y ago> DB2 is just the same thing as Oracle. DB2 supports sub-capacity licensing on a wide variety of virtualisation platforms, unlike Oracle. This may or may not matter to you. It does to me under a variety of circumstances. DB2 also has much more granularity in licensing before you have to ramp up to ASE, which, again, may make a big difference to you (many equivalent features are available a significantly lower price points). > So you'll use every proprietary Oracle feature that gives you additional performance (subpartitions, parallel query execution, optimizer hints, manual column statistics, connect by, listagg, …). More than a few of these are trivial conversions to other DBs. CONNECT BY is hardly magic, neither's parallel query execution or listagg. Operational concerns are probably the biggest one. > Take all this together and we're pretty much locked into Oracle. If you're in a business where running your company on whatever schedule Oracle chooses to offer you, that won't be a problem.
- cafard 12y agoTuning is one thing. What if you have a lot of business logic in a few ten or hundred thousands of lines of PL/SQL. What will it cost you to rewrite that in Pg/SQL or T-SQL?
- cafard 12y agoI must say that my first reaction on reading the headline was, Gee, 32 cores * .75 * $40,000, and you're looking at most of a million in licensing per CPU up front, well over $100 thousand per year support. Oracle give away the machines and do very nicely on this one. (Calculations not guaranteed.)
- nsxwolf 12y agoI'd love to see the SPARCStation make a comeback with that thing.
- thrownaway2424 12y agoWhat would you need it for that couldn't be done better on an iMac?
- nsxwolf 12y agoApparently it does Java better? Mostly it would be nostalgia. I was assigned to a Sparc at at my first real developer job. It gave me an appreciation for exotic workstations. Plus, I love the Sun style keyboards (I use an HHKB 2 Pro today)
- deleted 12y ago[deleted]
- userbinator 12y agoI like how they're adding hardware specifically to speed up databases, to a CPU based on a RISC core; it looks like there is a trend toward more CISC-like hardware, because designers have figured that operations that would've been done in software can be done faster with dedicated hardware. My experience with using older SPARC servers for testing various things is that they're rather disappointing, both in terms of value and performance - "more cores" seems to be their guiding principle, and while this makes for impressive benchmark results and aggregate numbers, the speed of a single thread is pretty horrible; it's only in specific multithreaded applications that all the resources on the chip can be fully saturated. Meanwhile x86 servers cost far less and can handle different workloads better because per-clock, each core is several times faster.
- kourt 12y agotrend toward more CISC-like hardware, because designers have figured that operations that would've been done in software can be done faster with dedicated hardware. And since clock speeds stagnated a decade and a half ago, but Moore's Law still allows more transistors to be packed onto a chip, adding dedicated hardware for specialized operations is about all designers can do.
- wtallis 12y agoIt's not like we reached any sort of limitation on individual transistor switching speed, though. The problem is that you can't evolve a product line by removing features. You've always got some feature or instruction that is the limiting factor for clock speed; some longest chain of gates that need to settle on the output value before the next cycle. You might be able to shorten that chain by breaking up an operation into several instructions or by reducing the number of registers or addressing modes, but that breaks compatibility. On the other hand, anything that can be added without lengthening the critical path and can be powered down when not in use is fair game.
- sliverstorm 12y agoIndividual transistors are getting faster, but wires are not. Wire performance has not been keeping up with the transistors since something like 90nm (2004), hence the "telescopic metal stack" Clock speeds are in part chosen based on optimal path length (measured in gate count). The longer the path, the less is wasted on flop overhead. The shorter the path, the faster your clock and the more flop overhead. Features or instructions are not important to this equation, because you can break a feature into multiple stages divided by flops. So the fact that frequency has stayed about the same should tell you that path length (gates per cycle) has stayed about the same, which in turn means gates have probably stayed about the same speed for many years! Next, let's not forget about the power/heat envelope. Modern transistors are mind-numbingly fast if you juice them with 5V, but 1kW CPUs are generally frowned upon these days. We continually squeak down the supply voltage to save power and meet the heat envelope. Now, you might be thinking about all the extra transistors that are added to newer designs. "Forget about path length," you might say. "If we cut crap features and got rid of those extra transistors, we could afford the power cost of turning up the supply voltage, and get faster!" Alright, now you're thinking smart! But 90% of modern CPU area is spent on graphics and cache, not x87, MMX, and AVX512. I could go on, but I cannot properly cover all the aspects in one comment...
- curiousDog 12y agoStill don't understand why businesses buy this instead of scaling-out. Cost? Complexity?
- SDGT 12y agoThe third and most important reason: They have someone to blame when shit goes tits up. Response time may still be abysmal, but "dammit we payed a million dollars for this!"
- th3iedkid 12y agoand one more thing with large volume transaction processing is scaling out on I/O and ETL jobs.Oracle (and other DB vendors) offer a lot of utilities that scale out perfectly with least of development time. For e.g. it would rather be a difficult deal to work with parsers to parse a Gigabit-data file with code we have to own up , than to use features these DBs directly offer to parallel-load into a ready to use table within minutes.
- elliptic 12y agoI'm not saying that Oracle hardware or software is the solution, but "scaling-out" is incredibly difficult in transaction processing. I worked at a mid-size tech company with what I imagine was a fairly typical workload, and we spent a ton of money on database hardware because it would have been either incredibly complicated or slow to maintain data integrity across multiple machines. I imagine that situation is fairly common.
- AlisdairO 12y agoBoth, I suspect. When you consider the cost of engineer time needed to create high performance scale-out systems in a problem domain that requires consistency, scale-up can start to look fairly attractive.
- CHY872 12y agoGenerally it's just that it's really difficult to do it right. Sometime's it's impossible. It's often loads more work (which can be hard to debug). Furthermore, it's frequently not even an advantage. Have a read of https://research.microsoft.com/pubs/163083/hotcbp12%20final.pdf https://research.microsoft.com/pubs/163083/hotcbp12%20final.... Remember corporate workloads frequently have very different requirements than consumer.
- jwr 12y agoDoes anybody know what the pipeline depth is? At 4GHz, it can't be short, and the cost of mispredicted branches could significantly worsen real-world results.
- wmf 12y agoThe S3 core has a 16-stage pipeline and it sounds like S4 is roughly the same. All the threads can cover a lot of stalls.
- jwr 12y agoFairly large, then. Hyperthreading is only useful if you can make use of it and if you are batch processing — if you're running a single computation that needs to finish within a certain time, it won't help you.
- capkutay 12y agoI would think that Oracle would be investing more in something like flash storage in their hardware rather than optimizations to processor speed. More threads don't make the disc spin faster and a lot of DB workloads are bound by going to persistent storage.
- rodgerd 12y agoIf you've spent any time with Oracle sales staff you'll know their pitch these days is that their on-chip acceleration is the only way to break IO barriers, and that you'll get a shit experience with Oracle DBs unless you deploy on Oracle hardware. It's an old-school full stack play straight from the mainframe era. SSD, by way of contrast, is relatively commodity stuff that Oracle can't get a lock-in with.
- trhway 12y agobasically vaporware. In the sense that almost nobody will see/touch it. Huge chip - 10B transistors - using new process node - 3D 16nm - will have such low yield that its obviously high price will be even higher. Thus only a handful of systems will be delivered. Thus practical non-existence equivalence. SPARC CPU division brought down Sun, and i see it still puts a good fight inside Oracle despite Rock cancelation :) Edit: even if the CPU become realistically (in the High Enterprise sense) available just imagine what [ram-to-cpu] bus should the CPU to sit on for it to be able to feed the beast, especially considering that it will be DB application, not HPC for example
- xooyoozoo 12y ago>using new process node - 3D 16nm The Hotchips slides explicitly mentioned 20nm. Based on a bad assumption, the author for this story decided to freely reinterpret '20nm' as 16FF. (There's a connection between the two, but that's mostly for pedants on internet forums)
- willvarfar 12y agoVaporware means it won't exist. You mean it will be exclusive. This is not the same thing.
- ris 12y agoBeyond this I wouldn't trust anything about a platform whose sole future & trajectory is governed by Oracle. Not a good boat to be in.
- sgt 12y ago“Decompression can be driven at memory bandwidth rates, so there is now downside to using compression,” says Fowler. The on-chip compression leaves the S4 cores leftover capacity to do useful work. I assume he meant to say that there is "no downside to using compression" ?
- illumen 12y agoThis is a big thing that GPUs have been doing for decades. I'm honestly surprised this has not been done until now. Scientific, and many other data processing workloads use compression because memory bandwidth is the slow part. Mostly once you have the data in memory, doing some extra instructions on it is almost free, considering how slow a memory load is in comparison these days. But if all you are doing is compressing the data, then I guess it's a definite win. It'll be interesting to see what sort of speedups this gives when you're also processing the data.
- willvarfar 12y agoYeah, he surely means no disadvantage. This has been true for fast LZ e.g. LZO on normal CPUs for ages, and the only reason hardware doesn't try and transparently compress RAM is the RA in RAM.