Blog

So today I was called grumpy, which was inconsiderate and uncalled-for, so I did what every stable adult man would do. I complained to the one person who’s required by God and Country to always be supportive: my wife. “Who the hell does she think she is calling me grumpy?” I asked. And my wife went “well, you totally are,” which was an inconsiderate and uncalled-for answer. “Hey! You’re my wife! You’re supposed to love me!” and she was “I do love you! And that’s why I need to be honest.”

Crap.

It’s not that I could not live with the idea of being grumpy. It’s just that I don’t see myself like that. Or rather I didn’t. Now I kind of do.

There are a couple of young kids who are all high on the whole GNU Fucking Slash Linux. Not unusual. When we’re young, the world does seem a lot more black and white. That’s fine. Kids will rebel and Linux… Ops, sorry! GNU Slash Linux provides an outlet from which all the rebellion that a young nerd can muster. I mean, it’s not like these kids get invited to the parties where popular kids do their rebelling, right? Again, that’s all fine and dandy. Been there.

But then these kids—high as they are on GNU Slash Kool-aid—forget that they’re the new kids on the block. I mean, seriously people, Linux isn’t new anymore. There is a lot of people who came before you kids came out of daddy’s place. No shit.

Let’s face it, this is part of being young. You feel like you have all the answers and everyone else in the world failed to see The Truth. No problem with that. Except…

Except that shit means I’m now officially old!

Motherfucker.

Today I see a friend commenting about Linux and one of these cocky, know-it-all kids jumped on his case like he was some kind of newbie or something. Hell, that actually got me angry. And then it hit me.

Doesn’t that make me grumpy?

So. Fucking. Be. It. I hereby accept the label of grumpy and shall sport it with pride.

So my friend works with and improves Linux for years and then a kid comes out of nowhere—having never done more than tweeting about Linux—and dares berate the guy? Go suck an egg, son! The guy I’m talking about knows more Linux—and note how I dropped that slash shit and I don’t even care—on his pinky toe than all your friends together. Kid!

Goddammit.

-rst.

P.S.: I’m not really angry. Or am I?

Ever came across someone who wanted to show off how independent and free their own thinking was? I have, many times. Discussing with these people is an amusing and yet wretched event. It’s like goping to a funny dentist. She may be funny, but she’s still going to bore a deep hole in your tooth. And boy, will it hurt! At least one of you will be laughing, right?

I happen to know a couple of people who have got such strong conviction of their own uniqueness in being free from delusion that they cannot avoid being delusional themselves. Both are on this righteous crusade to extricate people from their self-foisted enslavement in the hands of evil Apple. Wait, what? Yes, that’s right. From Apple! Apparently to some people, the operating system or the phone we use is the wrong one and we are pulling the wools over our own eyes into thinking otherwise. Fortunately for all of us, there are these cavaliers in shiny armor who will rescue us from ourselves. Dude, seriously? How much more fucked-up delusional can one get?!

I don’t know if those guys did too much role-playing in their lives (and I don’t mean in bed) or it’s just too much World of Warcraft. I don’t really know. But if there is one thing I do know, it’s that it’s delusional. Why is this so? It’s really a synthesis of a couple of things —

• Belief that one is right about something. Being fair, we are all like this. If you ponder about it, this is the very definition of having an opinion. Nobody thinks they are wrong about their opinions.

• Self-aggrandizement. Again, to a variable degree, we’re all like that. We all love to think we are more than what we really are. Probably a defense mechanism. Without that, we’d all have killed ourselves by the time we reached puberty. Or maybe not all of us, because I am super awesome.

• Strong illusions.

What exactly is a delusion? A delusion is the belief that an illusion is real. We all have illusions, but a few go farther. They have such strong illusions that they begin believing in them.

These people actually believe that there is a war going on. A struggle between good and evil. A conflict between freedom and slavery. And let’s face it, everyone wants to be one of the good guys. Except supervilains. Supervilains want to be on the wrong side. Always.

Once you are set on the idea that (a) there is something like black-and-white good and evil, and that (b) the fucking clash is on, there’s really no stopping you. You need to fight to Good Fight. But since there really isn’t a war going on, the only way to fight it is by making up stuff as you go. So you pick your villains (say, Microsoft and Apple) and your heroes (say, Google and GNU) and you go out saving us ignorant civilians. From ourselves. And from Apple. Because Apple is, like, super evil. Ah, if everyone was like Google…

Holy. Shit. People. Grow the fuck up!

Let’s all pretend for a moment that there really is a war going on. That Google is out there fighting for our rights to free goodies in exchange for nothing at all. That Microsoft really owns the world’s Secret Cabal and Bill Gates sits down everyday to plan what evil deed needs to be done that day. Let’s say all of this is real. Wouldn’t it be a lot more productive for you to focus on your enemies and leave us civilians alone? Go ahead, wear your fancy penguin costume and take pictures of yourself peeing on the Microsoft logo. A lot of people will love that. And more importantly, you will feel like you’ve finally accomplished something! You won a battle for the good guys! Hooray!

But please leave the rest of us alone.

-rst.

P.S.: a friend just sent me this picture, which says a lot. I think the message is: Dude, don’t be a fag!

I had two versions of a parser. One finished faster, so I declared victory and nearly deleted the slower one. Before doing that, I tried the new perf tools included with recent kernels and discovered that my explanation for the improvement was wrong.

The kernel’s performance-counter infrastructure provides a common way to measure hardware and software events. The perf tool can count events for a command, sample execution and report where those samples landed. Instead of beginning with a profiler tied to one processor model, I can ask through one kernel interface and use the events available on this machine.

perf stat is a useful first question. It reports elapsed time along with counts such as cycles, instructions, context switches and page faults. Ratios matter more than isolated totals. Instructions per cycle can suggest whether the processor is retiring useful work efficiently, while cache-related events may explain why an apparently smaller algorithm still stalls.

My faster parser did not execute dramatically fewer instructions. It incurred fewer cache misses because its data was laid out more compactly. I had credited a clever branch change that happened nearby. The benchmark result was real; my story about it was fan fiction.

Sampling answers a different question. perf record periodically captures the current instruction pointer, and perf report aggregates samples by symbol. With suitable symbols, hot functions become visible without instrumenting every call. Sampling has overhead and statistical uncertainty, but it is often much less disruptive than logging entry and exit around a hot path.

Counters are constrained resources. The processor can measure only a limited number simultaneously, so events may be multiplexed. Some events are model-specific, and virtualized or restricted environments may expose less. A cache-miss count without knowing which cache or how the event is defined is an attractive number with an uncertain biography.

I also avoid optimizing from one profile. Workload, input size, compiler options and machine state all matter. I run repeated measurements, preserve the input and compare complete behavior. A ten-percent gain in a microbenchmark is not useful if the changed layout doubles memory for the real service.

I strongly prefer starting performance work with perf stat, then sampling when the totals suggest a question. ftrace remains better for many scheduling and kernel-flow investigations; perf is especially convenient for connecting program hotspots to processor and kernel counters. Neither tool replaces understanding, but both are considerably more reliable than staring at source until one loop begins to look guilty.

Google announced a new language called Go last week, and I spent an evening rewriting a small concurrent program in it. This is not a review. Go is new and experimental, its tools are young, and its APIs are changing. Anything written today may become an historical document by next month.

The appealing part is its systems-shaped simplicity. It has compiled code, pointers and familiar control structures, but also garbage collection, interfaces, goroutines and channels. Starting concurrent work is cheap in syntax, while channels provide a way to pass values instead of sharing every structure behind a lock.

My first version translated threads directly into goroutines and retained all the old shared state. Unsurprisingly, new spelling did not improve the design. The better version gave one goroutine ownership of the state and sent it requests through channels. The useful idea was ownership, not the keyword.

There are rough edges, incomplete libraries and unanswered questions about performance and deployment. I would not build an important product around today’s interfaces. I would use it for experiments, particularly network services where its concurrency model can be exercised honestly.

I strongly like the direction, with emphasis on direction. Go is not yet a settled platform, and confidence would be silly after one week. Still, it has made me think differently about a program I already understood, which is a fine result for an evening and cheaper than another programming book.

My event-driven server stayed responsive under load, but its memory use climbed steadily. I had removed blocking and accidentally built an extremely efficient machine for accepting work it could not finish.

Each connection had an output buffer. Producers appended responses faster than the network drained them, so those buffers became an unbounded queue distributed across clients. Nothing was technically stuck. The server was merely saving enough unfinished work to become stuck later.

Backpressure means carrying limited downstream capacity toward the producer. When a connection’s output crosses a high-water mark, I stop reading more requests from it or stop scheduling new work. Once buffered output falls below a lower mark, reading resumes. Separate thresholds avoid switching state on every small write.

The same rule applies between the event loop and worker pool. A bounded job queue makes overload visible. If it is full, the loop must defer input, reject work or shed a connection according to policy. Adding another unbounded queue does not increase capacity; it increases the delay before admitting there is none.

I prefer bounded queues and explicit overload behavior, even when rejection feels impolite. The exact limits require measurement, and short bursts deserve some room. But a service that says “not now” can recover. One that accepts everything may respond to nobody, which is very accommodating in principle and less so in practice.