A recent TED talk by Rupert Sheldrake has been causing commotion on both the social media (Reddit, Facebook) as well in most scientific meetings. It’s a discourse on how science has been built into this moral fortress that would have made the perfect inspiration for 1984. A sect of rabid defenders that would crush any questioning about the correctness of science above everything else, religion, humanity and even common sense. It talks about how the scientific community rushed to muffle and hide from public view its failures, settling by the power of the pen as constants metrics that stubbornly did not stop moving around over the years (gravitational constant). Ultimately, how science grew up to adulthood, loosing in the way its thirst for dare and questioning so common in children.
Much has been said about this and I’m not going to expose my word here. This is a too of a charged issue (science vs religion) for a small business owner to expose himself with – not that anyone would care anyway. I’m just going to say that I’ve seen my share of academic savagery and misconduct over the years, reported and not reported, to hold any scientist as a moral bastion. The trust the public puts on the correctness of peer-reviewed publications is beyond the comprehension of someone that has seen this sausage being cooked more than once.
But my main goal in this article is not to bash science. Is to ask if computer science has also fallen to the temptations of turning itself into a religion. There are indeed traces of it.
The Big Firm
Some time ago I visited a big trading firm which I really desired to have as client. They were large enough to guarantee some good projects and at the same time I knew their staff had complementary skills to mine. A perfect fit. I met with many fellows in the technical team. On one meeting the conversation went down to the rabbit hole of “modern c++ idioms”. A show of SFINAE, variadics, lambdas, patterns, sex of angels… wait, did I say sex of angels? The discussion then went finally through something tangible, circular queues, and at that point I was asked what could be done to make the final pointer increment faster:
if ( ++_readpos == _numitems ) _readpos = 0;
I responded that you should use a builtin macro to indicate to the compiler that the test is unlikely to succeed and should be normally ignored (this is for speculative branch prediction purposes). To which the “Modern C++ Guru and Evangelist” responded that this form would be much faster:
_readpos = ++_readpos % _numitems;
The reason this was supposed to be faster is because if eventually the IF test fails and the CPU guesses wrong (false or true) then the pipeline is invalidated and a penalty is imposed. So no IFs is better.
The Slowest CPU Instruction
(Among the common instruction set, that is)
Don’t flinch: it’s the integer division. So much that there are courses and papers exclusively devoted to it. While additions, subtractions, multiplications all take one cycle in most modern CPUs, division easily takes ten cycles or more. Here’s a little background on it: Integer division – slides UTAH.EDU
The percent sign in the code above is a remainder operation and it is calculated using an extremely expensive IDIV instruction as can be seen in this disassembly.
Additions we have the straightforward carry algorithm. For subtraction, two’s complement and addition. For multiplication, there are multiples ways to perform it. Intel even as recently as 2011 patented a new method for cryptographic applications based on the Karatsuba algorithm. For division? It seems that we have been using the same radix-2 algorithm since the Pentium over thirty years ago and the reason is really that there’s not really nothing else we can do. Avoid integer division at all costs, folks.
(A parenthesis is necessary here: if the quotient of an integer division is a constant known at compile time, there is a fast method to compute it using multiplication-and-overflow as described in this paper: Division by Invariant Integers using Multiplication. So when I say ‘integer division’ please understand this is a division of an integer by another whose value is not known at compile time. )
The forgotten mission
Choosing an expensive integer division over a very inexpensive branch (even if missed the prediction) is the type of very basic mistake that leadership level folks in technology/trading firms should not be making in 2016. This overexposure to language patterns in detriment of real hardware/software interaction issues is such a serious and widespread problem that as an example, there are still trading companies in Chicago that need a full 16-core machine to run a single strategy with only 10 symbols trading on one single exchange. As comparison, properly written trading code on good companies will allow a single CPU core to handle all 8,000 US equities symbols on all 7 main exchanges with ease.
So my rant is, computer science forgot that its real task is a mundane one: to transform bits and bytes from one place and/or format to another. The way it is done, meaning the language or subset of language, is as important as wearing a full ninja suit to butcher a pig, as long as it gets done under the requirements. Since C++11 nothing was added to C++ that has contributed to this goal, it’s been a syntax sugar layer over the next. Meanwhile an overwhelming number of the packages under Ubuntu/default, perhaps more than 95% of all, are still written in C for very good reasons, with python taking most of the rest.
Regarding C++, Bruce Eckel, one of the creators of the Go language, has stated:
The complexity of C++ (even more complexity has been added in the new C++), and the resulting impact on productivity, is no longer justified. All the hoops that the C++ programmer had to jump through in order to use a C-compatible language make no sense anymore — they’re just a waste of time and effort. Now, Go makes much more sense for the class of problems that C++ was originally intended to solve.
We computer scientists and CS graduates forgot our mission. Instead of focusing on the real problems we are increasingly more entertained by the problems we ourselves created.