And you are here why?

Here’s a quick one —  Do you know how many code-bases DB/2 has? The obvious answer, of course, is — or should be! —  ONE , right? Well, it turns out that the actual answer is   FOUR , one for each of their (major) product lines, viz, the   AS/400 ,   MVS , and   R/6000   (as well as one for   VM , but more on that in a bit). As to “ Why? For gods sake, WHY SO MANY CODEBASES? ”, it really comes down to  Mechanical Sympathy . Each of IBM’s hardware lines has dramatically different hardware/OS models. For example, the AS/400 line uses a seriously flat memory model, where memory and disk addresses are indistinguishable, and objects move transparently between them. What’s more, the  whole system is capability based  (pointers to an object in memory/disk include the security permissions necessary to get at them). The R/6000 line, OTOH, very much does  not  have this  . And that takes us directly to the  tradeoff betw...

Intel’s MKL , for those of you who’ve never actually had to worry about math performance, is basically a library of hand-optimized code for  serious math, including Linear Algebra  (BLAS ,  LAPACK , etc.),  FFTs , vector math, and whatnot. And yeah, it’s specific to Intel’s processors (hence “Intel’s MKL ”)  with  effectively free licensing . If you’re doing any kind of heavy lifting in science / math / fintech / etc, you’re probably already using this somewhere in your stack! MKL-DNN  is a library built on MKL which adds in optimizations specific to  Deep Neural Networks  (hence the “DNN” part 😀). It’s been out  since late 2016 , but there are fairly frequent updates as new models and techniques become popular (and boy howdy, is the pace of change rapid in this field!). At heart though, it takes a decent chunk of Neural Network primitive — things like  convolution ,  normalization ,  tensor manipulation , etc. — a...

/via https://xkcd.com/385/ It turns out that just thinking about stereotypes can impair your performance —  especially if it’s a stereotype about you .  The emphasis here is critical to understanding how and why so much bulls**t has spread around “ women suck at programming ”, “ men are logical, women are emotional ” and so forth. Roll the tape back to 1995 when  a  huge  NIH study  (•) showed that there were sex-based differences in spatial abilities, with men outperforming women by over one standard-deviation. The result was a plethora of follow-up studies trying to figure out whether this was due to  testosterone ,  brain wiring , and whatnot. Well, guess what —  it turned out that this was all based on flawed research . A  subtle  flaw, mind you, based on expectations, but a flaw nevertheless. In 2008 (why did it take so long?) folks at the University of Berlin did  a follow-on study  (••) where they “primed” the subj...

  Is your system scalable? As in, “ does it get faster the more CPUs/Nodes you throw at it? ” (no quibbling yet about “faster” please).  The issue here is that when we think “scalable”, we immediately fall into the world of parallelization, concurrency, NUMA, etc. — in short, we tend to believe that our theory is solid, our code is excellent, and we’ve, at the very least, waved our hands in the direction of mechanical sympathy. Is this actually true though? I don’t know about you, but in quite a few of the places I’ve been in, the theory is   mostly solid, the code is   far   from excellent, and mechanical sympathy is, well, something to be dealt with later. The sad truth is that when we say “ scalability ” we usually assume “ efficient use of resources ”. Beck is correct in putting “Fast” last, but (and   this   is where quibbling is important) “Fast” is another overloaded term. Do we mean throughput? Latency? Concurrent requests? Time to proc...

So, Meltwater decided to run   their own ES setup   (on AWS, but still, their own instances). Why? In their own words — “ AWS Elasticsearch Service   allows us too little control, and   Elastic Cloud would cost us 2–3 times more than running directly on EC2 ” Go read   the entire post  — it is well worth it (especially the bit about sharding!), but the following performance tips are worth calling out 1. Limit searches to relevant data . Obvious, but lords, it’s amazing how much this one gets ignored. 2. Invest in Observability . Do you know where your resources are going? GC stats, io-wait, memory hogs, CPU usage, etc. etc. In particular, get really close and intimate with JVM performance tuning 3. Memory, not GC . Unless you’re really good, or have a real edge case, odds are that you’re not going to do much with the GC sub-system. Instead, focus on reducing memory allocation. 4. Azul Zin g for Memory . Basically, outsourcing your JVM management ...

“Hard-Disks” — remember them? Yeah, old school, and all that, but so much (!) of what we take for granted in Database architectures derives from the limitations of hard-disks. The big,   huge , one, of course, is the difference in sequential and random access. Writing data sequentially is easy — the disk head moves to the appropriate location, and just starts writing block after block. Random writes, however, incur the additional — and huge! — latency associated with moving the disk head to the appropriate location. Extend this to your favorite database, and consider what this means for a transaction. Back in the hard-disk days, it was much,   much   simpler to write all the transaction’s changes into a single set of sequential writes (in a separate “log”. Hence “write-ahead logging”, or WAL) instead of a whole bunch of random writes at different locations. Enter the world of nonvolatile memory (NVM), which is pretty close to RAM speeds,   definitely , doesn’...

Great articled on Sealed Abstract on this . Go read the whole thing - its long (10K words!), but completely absolutely worth it. The conclusion is fairly straightforward (and depressing) So here’s what you should remember: Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).   It’s slower than native code by about 5 It’s comparable to IE8 It’s slower than x86 C/C++ by about 50 It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there The most viable path for it to get faster is by pushing the hardware to desktop-level performance.  This might be viable long-term, but it’s looking like a pretty long wait. The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code Garbage collection is exponentially bad in a ...