3 ms·
Yeah people don’t realize the IO bandwidth (off the central CPUs mostly) is the differentiator. And writing SQL for DB2 is easier than writing efficient spark j
by lanstin 7y ago
Yeah people don’t realize the IO bandwidth (off the central CPUs mostly) is the differentiator. And writing SQL for DB2 is easier than writing efficient spark jobs (with minimal shuffles across those cheap small machines).
- rbanffy 7y agoPeople often forget how much computer science and engineering is in those machines that allow them to fully saturate two and a half full height racks of high performance IO while running COBOL programs that are blissfully unaware of all that goes behind their ABI and just see a ridiculously fast computer.
- bogomipz 7y agoHow is that level of IO bandwidth achieved exactly? Or how is it different from the x86 architecture?
- altatyper 7y agoThere is a ton of technical info out there, but in a nutshell, the hardware is extremely optimized for I/O bandwidth, cache's are able to be accessed by more cores at a time (I think the L3 cache is 32-way accessible for example). The goal is to have nearly everything in at least RAM (up to 40TB of it) or better yet in a cache closer to a CPU so there is no latency. And when it comes to reaching things outside of the mainframe itself, generally anything you can do to make accessing the data wider is better... Why use a single 16GB/sec HBA when you can interleave 8 or more FCAL paths to the same disk. Why use FCAL when you can use Infniband, etc etc.. They have a LOT of PCIe lanes available, and enough chips to keep most of them busy most of the time. TL;DR if it's expensive and offers more paths between things, it's probably an option for a mainframe.