Tales from the Chipset
February 20, 2014 1 Comment
Bill Cole – Competitive Sales Specialist,Information Management, IBM
My history in computing is littered with different roles. Everything from operator to programmer to architect as well as (forgive me) manager and director. A few lives back, I worked for a company that built the first computer on a single chip. It was a beast to make it productive outside the lab. In fact, it was so difficult that I was the first one to make it work in the field. The funny thing was that the whole configuration process was carried out using (this is absolutely true) staples. That’s right, staples! I keep a copy of that chip in my memento cabinet, too. By now the whole adventure seems a bit surreal. It was fun, though, and I learned a lot.
That was my first adventure with chipsets. But not my last. Later, when I managed a database development team for that company, I had a further education into just how software and hardware work together to build a system that delivers the performance customers need to address business problems and opportunities.
That’s what makes a system special, I think. It’s not a matter of simply slapping together some software or building a chip and hoping customers will show up. Sure, you can build vanilla software that works on a chipset but there’s no synergy in that. Synergy where the system is better than the parts. That’s what DB2 on Intel is all about. The IBM and Intel team consists of engineers and developers from both companies work together to optimize the chip and the DB2 engine so that our mutual customers get the fastest return on investment.
So, you ask, how is that different from any other database? It’s not just different, it’s unique. Doesn’t a certain red database run on the same hardware? Yes. And they use the same code line for Intel platforms that they do for any other bit of hardware. The code doesn’t know where it’s running and can’t make use of those features that would give their customers the sort of performance that DB2 delivers on the same chipset.
But SQL Server also runs on the chipset. Ah, yes, that’s true but it, too, is a prisoner of a code line. It’s not optimized for the chipset; it’s optimized for the operating system.
So what chipset do most Linux installations run on? I think we all know the answer to that one. Intel, of course. SQL Server is out of the picture. That red database is still running the same code line that runs on Windows and every other environment. Still no optimization.
I know, whine, whine, whine. What does this mean to me and my organization? Simple. Better performance. Better return on investment through improved, sustainable and predictable performance.
Talk, talk, talk. Show me, you say. Let’s take the easy one first. Vector instructions. I’ve written about these in an earlier post and I’ll amplify that now. These instructions push multiple data streams through the registers with a single instruction that uses a single processor cycle. This means we’re multiplying MIPS because we don’t have to wait on multiple cycles to process the same data stream. Said in another way, it’s sort of like doing homework for all your courses simultaneously. Wouldn’t that have been nice!
Then there’s register width. DB2 is built to manage compression based on the width of the registers. Filling a register means more efficient use of the fastest resource in the processor. That’s exactly what DB2 does. We know the width of the registers on Intel chips – and Power chips, too – so we make sure we’re filling those registers to get the most out of the instructions. Again, this is not only efficient and saves disk space, it makes the overall system faster since we don’t have to use as many instructions to compress and de-compress the data. Easy.
So the vector instructions and registers make DB2 fast and efficient. What else is there? Balance, my friends. I’ve been involved with building and tuning systems for too long to think that the processor is all there is to system performance. Indeed, it’s processor, memory and I/O that combine to give us the performance we get. Again, this is where knowing the chipset comes in very handy. DB2 is written to take advantage of the various caches on the x86 chipset, including the I/O caches.
And we have worked with Intel to understand where the sweet spot is for the combination of processor, memory and I/O. Standard configurations are pre-tuned to fit within the guidelines we know will give you the best performance.
And then there’s the tools that help us make the most of the chipset. You may not realize that the release of a chipset includes tools for compiling, profiling and optimizing the software that runs on those chips. DB2 on Intel has gone through the process of being optimized specifically for Intel on any of the operating systems for which we have distributions. (I know that was awkward but my old English teachers would haunt me for weeks if I ended a sentence with a preposition!) Gotta like that. Seems a great arrangement to me.
Finally, my wife loves IKEA, where all the furniture comes in kits. We’ve built lots of furniture out of those kits. And they always include tools that work with that kit. Taking advantage of a chipset is much the same way. Use the tools to get most from the hardware. There’s no sense in buying too much hardware just because your database is blind, eh?
Being the program manager for databases as I mentioned above gave me the opportunity to sit in front of many customers to listen to them tell me about their experiences with my hardware and software, both good and bad. I carry those conversations with me today. Your story is the one I want to hear. Let me know what DB2 is doing for you.
Follow Bill Cole on Twitter : @billcole_ibm
Watch this video on the collaboration between Intel and DB2 with BLU Acceleration!