compiler

Grumpy Old Men, Opacity, and Optimizers

Today I’m channeling my inner grumpy old man. And these guys are helping. (I am not old enough to pull off such a face by myself, although life is rapidly helping me get there. ;-)

Grumpy old men.

The reason I’m feeling grumpy is that I’ve had another in a long, long line of conversations about how to write faster code.

It’s not that optimization experts are dumb. Far from it. They are invariably smart, and in general, they are better informed than I am about how pipeline burst cache and GPUs and RAM prefetch algorithms work. I generally learn a lot when I talk to guys like this.

I applaud their passion, even if I think they sometimes get carried away.

No. What’s making me grumpy is that after decades of hard work, we still have compilers that encourage a culture of black magic and superstition around this topic. I thought I signed up for computer science, not voodoo.

To show you what I mean, let’s talk about the humble inline keyword in C and C++. The amount of FUD and nonsense around it is really unfortunate. How many of the following have you heard?
Continue reading →

In Which Warnings Evolve Wings

Ignoring warnings is a bad idea. At some level, we all know this. If we see a sign that says “Warning: Dangerous Undertow” at the beach, we pause (I hope!) and think twice before we get in the water.

Ignore warnings at your peril. :-) Image credit: xkcd.com

Yet we sometimes get cavalier about warnings in software. Specifially, I have heard programmers describe compiler warnings as being less severe than errors–as if worrying about them is optional.

This is simply not true.
Continue reading →

Lacunas Everywhere

I’m told that in Czech, the word “prozvonit” means “to call a mobile phone and let it ring once so that the other person will call back, saving the first caller money.”

Image credit: AstridWestvang (Flickr)

How would you translate this word to someone in New Guinea who has never experienced electricity, let alone a telephone or a bill from Verizon? You wouldn’t. This is an example of a “lacuna“–a translation problem caused by semantic gaps in a target language. Lacunas occur in programming languages. You might know a few; maybe you wish C++ had python-style generators–or that Java had Haskell’s notion of pure functions–or that C supported PHP-style string interpolation. But what if I told you that semantic misalignment between any pair of programming languages is just minor details? What if I claimed that all programming languages I’ve used have numerous, pernicious, and expensive semantic gaps? That we don’t see these gaps for the same reasons that a stone-age hunter-gatherer fails to notice his inability to discuss patterns of cell phone usage? Would you think I’m crazy? Continue reading →

Why you should be proficient in a tool like vim or emacs

In my last post, I pointed out two little-discussed reasons why I think most engineers should spend most of their time in an IDE.

I knew I was venturing into the realm of religious wars to make such a claim. When I shared the post, the first comment I got was, “Do you have a death wish?” :-) I had to laugh.

Religious wars aren't pretty. "The Second Crusaders Encounter the Remains of the First Crusaders", by Gustav Dore (wikipaintings.org)

Religious wars: not so pretty. “The Second Crusaders Encounter the Remains of the First Crusaders”, by Gustav Dore (wikipaintings.org)

It turns out that my experience with the ensuing comments has been quite positive. Plenty of people disagreed with me, which is fine. I’ve heard good arguments from many different perspectives, which is part of the reason why I blog and post on social media in the first place; I need to be pushed. I hope my assertions about teamwork and gestalt were at least interesting.

Now, I promised that I’d write a follow-up post about the flip side of my advice. This isn’t because I can’t make up my mind; it’s because I see these two toolings as complements with some overlap rather than symmetrical alternatives.

So today, I’m going to try to convince all the IDE zealots in the world that they’re doing themselves and their teammates a disservice if they don’t take the time to become proficient in a powerful text editor.

Death wish part 2. :-) Continue reading →

How to make a const-correct codebase in 4300 easy steps

One of the codebases that I work on is theoretically C++, but if you peer under the hood, it looks more like 1990-vintage C. It’s 500 KLOC of almost purely procedural code, with lots of structs and few true objects. More dusty and brittle than I’d like.

Image credit: Tim Gillin (Flickr)

I am not a C++ bigot; I first began to do serious, professional coding in C, not long after this codebase got its start. I understand the C-isms pretty well. And although I think Linus got carried away in his rant about the ugliness of C++, I can appreciate the ways that lean C sometimes makes its descendant look ugly and inefficient. (Though C++11 and 14 are making this less true…)

This means that I don’t consider the C-like style of this particular codebase a fatal flaw, in and of itself.

However, since my early coding adventures I’ve been converted to the advantages of OOP for complex projects and large teams, and I’ve also accumulated a lot of battlescars around multithreading. Our codebase needs OOP to solve some encapsulation antipatterns, and it needs RAII and C++11-style mutexing in the worst way. Its old, single-threaded mindset makes far too many things far too slow and error-prone.

A few months ago, we decided to make an investment to solve these problems.

To do it right, I had the team add a story to our scrum backlog about making the codebase const-correct. And therein lies a tale worth recounting…

Continue reading →