The overblown frequency vs cost efficiency trade-off

I've often read arguments that computing circuitry running at a high frequency is inefficient, power-wise or silicon area-wise or both. So roughly, 100 MHz is more efficient, in that you get more work done per unit of energy or area spent. And CPUs go for 1 GHz or 3 GHz because serial performance sells regardless of efficiency. But accelerators like GPUs or embedded DSPs or ISPs or codecs implemented in hardware etc. etc. – these don't need to run at a high frequency.

And I think this argument is less common now when say GPUs have caught up, and an embedded GPU might run at the same frequency as an embedded CPU. But still, I've just seen someone peddling a "neuromorphic chip" or some such, and there it was – "you need to run conventional machines at 1 GHz and it's terribly inefficient."

AFAIK the real story here is pretty simple, namely:

  1. As you increase frequency, you GAIN efficiency up to point;
  2. From that point on, you do start LOSING efficiency;
  3. That inflection point, for well-designed circuits, is much higher than people think (close to a CPU's frequency in the given manufacturing process, certainly not 10x less as people often claim);
  4. …and what fueled the myth is, accelerator makers used to be much worse at designing for high frequency than CPU makers. So marketeers together with "underdog sympathizers" have overblown the frequency vs efficiency trade-off completely out of proportions.

And below I'll detail these points; if you notice oversimplifications, please correct me (there are many conflicting goals in circuit implementation, and these goals are different across markets, so my experience might be too narrow.)

Frequency improves efficiency up to a point

What's the cost of a circuit, and how is it affected by frequency? (This section shows the happy part of the answer – the sad part is in the next section.)

  1. Silicon area. The higher the clock frequency, the more things the same circuit occupying this area does per unit of time – so you win!
  2. Leakage power – just powering up the circuit and doing nothing, not even toggling the clock signal, costs you a certain amount of energy per unit of time. Here again, the higher the frequency, the more work gets done in exchange for the same leakage power – again you win!
  3. Switching power – every time the clock signal changes its value from 0 to 1 and back, this triggers a bunch of changes to the values of other signals as dictated by the interconnection of the logic gates, flip-flops – everything making up the circuit. All this switching from 0 to 1 and back costs energy (and NOT switching does not; measure the power dissipated by a loop multiplying zeros vs a loop multiplying random data, and you'll see what I mean. This has implications for the role of software in conserving energy, but this is outside our scope here.) What's the impact of frequency on cost here? It turns out that frequency is neutral - the cost in energy is directly proportionate to the clock frequency, but so is the amount of work done.

Overall, higher frequency means spending less area and power per unit of work – the opposite of the peanut gallery's conventional wisdom.

Frequency degrades efficiency from some point

At some point, however, higher frequency does start to increase the cost of the circuit per unit of work. The reasons boil down to having to build your circuit out of physically larger elements that leak more power. Even further down the frequency-chasing path come other problems, such as having to break down your work to many more pipeline stages, spending area and power on storage for the intermediate results of these stages; and needing expensive cooling solutions for heat dissipation. So actually there are several points along the road, with the cost of extra MHz growing at each point – until you reach the physically impossible frequency for a given manufacturing process.

How do you find the point where an extra MHz isn't worth it? For synthesizable design (one created in a high-level language like Verilog and VHDL), you can synthesize it for different frequencies and you can measure the cost in area and power, and plot the results. My confidence of where I think the inflection point should be comes from looking at these plots. Of course the plot will depend on the design, bringing us to the next point.

Better-designed circuits' optimal frequency is higher

One hard part of circuit design is, you're basically making a hugely parallel system, where many parts do different things. Each part doing the same thing would be easy – they all take the same time, duh, so no bottleneck. Conversely, each part doing something else makes it really easy to create a bottleneck – and really hard to balance the parts (it's hard to tell exactly how much time a piece of work takes without trying, and there are a lot of options you could try, each breaking the work into different parts.)

You need to break the harder things into smaller pipeline stages (yes, a cost in itself as we've just said – but usually a small cost unless you target really high frequencies and so have to break everything into umpteen stages.) Pipelining is hard to get right when the pipeline stages are not truly independent, and people often recoil from it (a hardware bug is on average more likely to be catastrophically costly than somewhat crummier performance.) Simpler designs also shorten schedules, which may be better than reaching a higher frequency later.

So CPUs competing for a huge market on serial performance and (stupidly) advertised frequency, implementing a comparatively stable instruction set, justified the effort to overcome these obstacles. (Sometimes to the detriment of consumers, arguably, as say with Pentium 4 – namely, high frequency, low serial performance due to too much pipelining.)

Accelerators are different. You can to some extent compensate for poor serial performance by throwing money at the problem - add more cores. Sometimes you don't care about extra performance – if you can decode video at the peak required rate and resolution, extra performance might not win more business. Between frequency improvements and architecture improvements/implementing a huge new standard, the latter might be more worthwhile. And then the budgets are generally smaller, so you tend to design more conservatively.

So AFAIK this is why so many embedded accelerators had crummy frequencies when they started out (and they also had apologists explaining why it was a good thing). And that's why some of the accelerators caught up – basically it was never a technical limitation but an economic problem of where to spend effort, and changing circumstances caused effort to be invested into improving frequency. And that's why if you're making an accelerator core which is 3 times slower than the CPU in the same chip, my first guess is your design isn't stellar at this stage, though it might improve – if it ever has to.

P.S. I'll say it again – my perspective can be skewed; someone with different experience might point out some oversimplifications. Different process nodes and different implementation constraints mean that what's decisive in one's experience is of marginal importance in another's experience. So please do correct me if I'm wrong in your experience.

P.P.S. Theoretically, a design running at 1 GHz might be doing the exact same amount of work as a 2 GHz design – if the pipeline is 2x shorter and each stage in the 1 GHz thing does the work of 2 stages in the 2 GHz thing. In practice, the 1 GHz design will have stages doing less work, so they complete in less than 1 nanosecond (1/1GHz) and are idle during much of the cycle. And this is why you want to invest some effort to up the frequency in that design – to not have mostly-idle circuitry leaking power and using up area. But the theoretically possible perfectly balanced 1 GHz design is a valid counter-argument to all of the above, I just don't think that's what most crummy frequencies hide behind them.

Update: here's an interesting complication – Norman Yarvin's comment points to an article about near-threshold voltage research by Intel, from which it turns out that a Pentium implementation designed to operate at near-threshold voltage (at a near-2x cost in area) achieves its best energy efficiency at 100 MHz – 10x slower than its peak frequency but spending 47x less energy. The trouble is, if you want that 10x performance back, you'd need 10 such cores for an overall area increase of 20x, in return for overall energy savings of 4.7x. Other points on the graph will be less extreme (less area spent, less energy saved.)

So this makes sense when silicon area is tremendously cheaper than energy, or when there's a hard limit on how much energy you can spend but a much laxer limit on area. This is not the case most of the time, AFAIK (silicon costs a lot and then it simply takes physical space, which also costs), but it can be the case some of the time. NTV can also make sense if voltage is adjusted dynamically based on workload, and you don't need high performance most of the time, and you don't care that your peak performance is achieved at a 2x area cost as much as you're happy to be able to conserve energy tremendously when not needing the performance.

Anyway, it goes to show that it's more complicated than I stated, even if I'm right for the average design made under today's typical constraints.

People can read their manager's mind

The fish rots from the head down.

– A beaten saying

People generally don't do what they're told, but what they expect to be rewarded for. Managers often say they'll reward something – perhaps they even believe it. But then they proceed to reward different things.

I think people are fairly good at predicting this discrepancy. The more productive they are, the better they tend to be at predicting it. Consequently, management's stated goals will tend to go unfulfilled whenever deep down, management doesn't value the sort of work that goes into achieving these goals.

So not only is paying lip service to these goals worthless, but so is lying to oneself and genuinely convincing oneself. When time comes to reward people, it is the gut feeling of whose work is truly remarkable that matters. And what you usually convince yourself of is that the goal is important – but not that achieving it is remarkable. In fact, often someone pursuing what you think are unimportant goals in a way that you admire will impress you more than someone doing "important grunt work" (in your eyes.)

You then live happily with this compartmentalization – an important goal to be achieved by unremarkable people. However, nobody is fooled except you. The people whose compensation depends on your opinion have ample time to remember and analyze your past words and decisions – more time than you, in fact, and a stronger incentive. And so their mental model of you is often much better than your own. So they ignore your requests and become valued, instead of following them and sinking into obscurity.

Examples:

  • A manager truly appreciates original mathematical ideas. The manager requests to rid the code of crash-causing bugs, because customers resent crashes. The most confident people ignore him and spend time coming up with original math. The less confident people spend time chasing bugs, are upset by the lack of recognition, and eventually leave for greener pastures. At any given moment, the code base is ridden by crash-causing bugs.
  • A manager enjoys "software architecture", design patterns, and language lawyer type of knowledge. The manager requests to cooperate better with neighboring teams who are upset by missing functionality in the beautifully architected software. People will tend to keep designing more patterns into the program.
  • A highly influential figure enjoys hacking on their machine. The influential figure points out the importance of solid, highly-available infrastructure to support development. The department responsible for said infrastructure will guarantee that he gets as much bandwidth, RAM, screen pixels and other goodies as they can supply, knowing that the infrastructure he really cares about is that which enables the happy hacking on his machine. The rest of the org might well remain stuck with a turd of an infrastructure.
  • A manager loathes spending money. The manager requires to build highly-available infrastructure to support development. People responsible for infrastructure will build a piece of shit out of yesteryear's scraps purchased at nearby failing companies for peanuts, knowing that they'll be rewarded.
  • A manager is all about timely delivery, and he did very little code maintenance in his life. The manager nominally realizes that a lot of code is used in multiple shipping products; that it takes some time to make a change compatible with all the client code; and that branching the entire code base is a quick way to do the work for this delivery, but you'll pay for the shortcut many times over in each of your future deliveries. People will fork the code base for every shipping product. (I've seen it and heard about it more times than the luckier readers would believe.)

And so it goes. If something is rotten in an org, the root cause is a manager who doesn't value the work needed to fix it. They might value it being fixed, but of course no sane employee gives a shit about that. A sane employee cares whether they are valued. Three corollaries follow:

Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, hard earned doing things management truly values, on doing work they don't truly value – such a person can keep fighting for a long time. Some people manage to make a career out of it by persisting until management truly changes their mind and rewards them. Whatever the odds of that, the average person cannot comprehend the motivation of someone attempting such a feat.

Corollary 2. When does the fish un-rot from the top? When a manager is taught by experience that (1) neglecting this thing is harmful and (2) it's actually hard to get it right (that is, the manager himself, or someone he considers smart, tried and failed.) But that takes managers admitting mistakes and learning from them. Such managers exist; to be called one of them would exceed my dreams.

Corollary 3. Managers who can't make themselves value all important work should at least realize this: their goals do not automatically become their employees' goals. On the contrary, much or most of a manager's job is to align these goals – and if it were that easy, perhaps they wouldn't pay managers that much, now would they? I find it a blessing to be able to tell a manager, "you don't really value this work so it won't get done." In fact, it's a blessing even if they ignore me. That they can hear this sort of thing without exploding means they can be reasoned with. To be considered such a manger is the apex of my ambitions.

Finally, don't expect people to enlighten you and tell you what your blind spots are. Becoming a manager means losing the privilege of being told what's what. It's a trap to think of oneself as just the same reasonable guy and why wouldn't they want to talk to me. The right question is, why would they? Is the risk worth it for them? Only if they take your org's problem very personally, which most people quite sensibly don't. Someone telling me what's what is a thing to thank for, but not to count on.

The safe assumption is, they read your mind like an open book, and perhaps they read it out loud to each other – but not to you. The only way to deal with the problems I cause is an honest journey into the depths of my own rotten mind.

P.S. As it often happens, I wanted to write this for years (the working title was "people know their true KPIs"), but I didn't. I was prompted to finally write it by reading Dan Luu's excellent "How Completely Messed Up Practices Become Normal", where he says, among other things, "It’s sort of funny that this ends up being a problem about incentives. As an industry, we spend a lot of time thinking about how to incentivize consumers into doing what we want. But then we set up incentive systems that are generally agreed upon as incentivizing us to do the wrong things…" I guess this is my take on the incentives issue – real incentives vs stated incentives; I believe people often break rules put in place to achieve a stated goal in order to do the kind of work that is truly valued (even regardless of whether that work's goal is valued.) It's funny how I effectively comment on Dan's blog two times in a row, his blog having become easily my favorite "tech blog", while my own is kinda fading away as I spend my free time learning to animate.

 

Stock options: a balanced approach

…or at least an attempt at a balanced approach.

Do your own math

Dan Luu has recently published a great piece arguing that working for a big company will on average net you more money than working for a startup. If his math makes sense for you, so does his conclusion.

For me personally the math is different. I live in Israel, where a programmer's salary is very unlikely to surpass $150K/year, and $100K/year is pretty good. On top of that, taxes are higher, while prices aren't much lower overall, AFAIK. Based on Dan's numbers, a senior engineer working for Google at their Mountain View site might be able to save $3M in 10-12 years. His colleague at the Tel Aviv site might take 30 years to save that amount. And while a startup might pay less than Google, the difference will be much less than 2x, and nothing near the 3x-5x multiples mentioned in Dan's post.

Beyond math

Did I land at a startup because I figured the stock options were valuable? No, definitely not. In fact, while I was granted some laughable amount of stock options, I had no idea how it all worked – strike price, vesting, I didn't even know those words. How did I end up with the job then? I'll tell you how.

At the time nobody, and I mean nobody, would hire me. In hindsight, the reason was as obvious as it was misguided. They wouldn't hire me because I projected a large degree of mental imbalance. They were misguided because in terms of performance/price, I was solid gold. I'd work as hard as you can imagine for peanuts, and, nuttiness of youth aside, I knew my shit. I often wonder if today's me would hire then's me. I know I should, but I'm not sure I would.

6 months passed, and not a single job offer. To cheer myself up, I'd send SMSes to friends which supposedly parodied my missives to potential employers, along the lines of "Hi, my name is Shitface McArsefuck. Do you happen to be in need of a programmer?" And so it went from bad to worse, until EB called.

EB was among the tiny number of people I "networked" with in the university. I originally contacted him to get advice on building a 3D scanner from a commodity camera and clever software that reconstructs 3D geometry from images. (He immediately explained why it wouldn't work. Then I somehow convinced him to spend the next 3 months on a failed attempt to do this.)

And now he recommended me to this startup which he just joined. And I passed the interview, nuttiness and all, no doubt because of that recommendation.

My point being, maybe you just happened to land at a startup because it so transpired. Maybe you didn't pass the interviews at the big companies for some transient reason, maybe you'd pass them a year later but right now you didn't. Maybe the startup is right near your home and your friends work there. Whatever the reason, right now you're there.

The question now is, should you ignore the equity part of your compensation? And the answer, of course, is…

Do your own math

Here are some points to consider:

  • A lot of the problems with equity are solved by getting more equity. It doesn't help if the stock ends up completely worthless. But dilution, a long time spent waiting for the IPO, a high strike price, and, in some scenarios, liquidation preferences – all of these problems are helped a lot by having more equity.
  • They call stock options a lottery ticket. I call it insurance. It sucks to have worked at a startup which did make it big and to not have made anything off it. Incidentally, I know quite a lot of people who either forfeited their stock options or sold them very cheaply, on the theory that equity is worthless. Trust me, if you're working for a startup, this is the one accident you want to be insured against.
  • Who has invested in this company at the latest round? VCs often lose their entire investment. On the other hand, investment banks like Goldman Sachs tend to make money, and so do investment management firms like BlackRock. Sounds obvious – and yet I knew people with more financial literacy than myself who'd say "how much more can this stock go up?" after GS or BlackRock invested in the company. The right answer is that now it will most definitely go up, albeit perhaps by a smaller percentage than in previous rounds. Which brings us to the next point:
  • Percentages are not absolute amounts, and you care about the latter. If the stock goes from $1 to $10 (a "large" 900% increase), you get $9 when you exercise the option. If it goes from $50 to $70 (a "small" 40% increase), you get $20. Sounds obvious – and yet I knew people who're way better at math than me, who preferred tiny cash raises to sizable stock options grants, right after an investment round involving firms which rarely lose money, on the theory that "the stock is too expensive already."
  • These days it takes companies a lot of time to go public. As an employee, it largely works to your advantage. It gives you time to become valuable and to then ask for more equity. To a private company, even one with serious late-stage investors, equity is still pretty cheap, and there are few enough employees for some to have gained significant bargaining power. So it might be sensible to initially ignore equity and mainly ask for cash raises – the company is too likely to tank at this stage, while your bargaining position isn't good enough to get enough equity for it to matter anyway. Later on, when your salary gets closer to the ceiling, and the stock becomes more valuable, and you will have become more valuable to the company, ask for equity. (The downside of asking later, of course, is that they give increasingly less of their increasingly more valuable stock over time. But the difference in bargaining position might be larger than this unfortunate effect.)
  • To actually negotiate more equity, to a first approximation, you must be ready to leave over this point. Leaving might mean losing whatever stock options you already have. This is where the advice of people who tell you to ignore equity paradoxically comes in handy! (I do know people who managed to find an outside investor who helped them buy their stock options; whether you can legally do this in your particular case is a question to a lawyer.)
  • The variance in options-based compensation is vastly larger than the variance in salary. One reason is that stock options are very cheap for private companies, and it's therefore their preferred way to motivate their favorite employees. I suspect that another reason is, you getting 10x my salary tends to piss me off much more than you getting 10x the stock options. Right now you can't spend the stock options, so there will be no changes to your lifestyle signaling to me that you're better off than me, and then even if I knew, I might not care as much about stock options, which might, after all, be worthless. The upshot is, if you want to increase inequality in the world by getting an outsized compensation for your supposedly outsized contribution, stock options are your #1 route.

One point on equity negotiations

All the usual advice on negotiation, of which I'm hardly a good source, applies here. But on top of that there's one specific point when it comes to equity and it's this.

Suppose the party line is, this company will be worth $50B, but you think it'll be worth $20B (right now it's valued at $10B.) And let's say you want to ask for enough stock options to net you $1M.

The wrong thing to do is argue that the company will be worth $20B, and ask for an amount netting you $1M on that theory. They'll tell you that you're wrong, that it'll be worth $50B, and here's 1/4th of what you ask for, and it'll net you your $1M.

The right thing to do is tell them you want to end up with $4M (or better yet, $8M) and ask for an amount netting you that, according to their $50B theory – in the hope of getting half of what you asked for, and then 1/4th the capital gain they predict, overall $1M.

Why? Because it's much, much easier to argue that your contribution is worth $8M and that you can make it elsewhere than it is to argue that the company isn't worth what they tell everyone it's worth. Of course your common sense cries foul at this: "but you can't make $8M elsewhere! And the company might end up worthless, for all we know! Surely arguing that it's not worth $50B is more sensible than arguing that you are worth $8M, because it isn't, and you aren't!"

Well, common sense is wrong, because common sense is not a salesman (in fact, it's a salesman's worst enemy.) "We're both unusually valuable" simply sells better than "neither of us is". So do go for the former.

Expiration dates

Stock options have expiration dates. With the time it takes companies to file an IPO these days, yours might expire earlier. Don't miss that moment, and make sure they extend the date (a private company can easily do it.) Make sure to ask for the extension as early as possible – you never know what things will look like at a later date. While all is well, it's a trivial request. But not all is well at all times.

From competent programmers to terrible investors

It might well be that, having worked your ass off, and having negotiated a nice chunk of equity, you'll sell it at some early liquidity event for a fraction of the IPO price or some such. With this shit, trading skills/luck might dwarf the rest of your skills. A bit depressing, that. But don't get depressed. Here, I'll cheer you up. My name is Shitface McArsefuck. Do you happen to be in need of a programmer?

There are many schools of thought with respect to trading strategy. I recommend the following method:

  • When you can, sell enough to get a sum of money that buys you something important. Something so important that, if you won't buy it now, and you won't get another chance, you will have a hard time forgiving yourself. That something can be a house, or enough money for some crazy trip you dream about, or enough money for "financial independence" according to your definition, whatever.
  • If you're left with stock and selling it does not buy you something important, keep it, or sell in little bits, so that you spread out the selling of the whole amount over a long period of time.
  • Try to not be fully vested at all times (your employer should be willing to help you with it), so that these rules don't result in the selling of everything at what in hindsight is a low price.

The point of this approach is to think hard about what you really want, and not miss a chance to get it. I expect it to net worse results on average than a strategy aiming at maximizing the mean profit, because it does not try to maximize the mean profit. What it does attempt to do is minimize regrets, and unlike maximizing strategies, it takes your personal priorities into account.

(Incidentally, the differences in personal priorities might make the best strategy for me a terrible strategy for you. The question isn't where the price will go – and BTW nobody can answer that, anyway – but what you need the money for. I wish I understood that before giving people what in hindsight was bad trading advice.)

I strongly recommend to refrain from selling everything upon the first opportunity under the assumption that diversified risk is always better than concentrated risk. People who understand the "rationality" of this argument should also understand that it's somewhat rational to spread the selling over some period of time, because stock prices tend to be volatile and you're rather likely to have sold at a bad moment.

More importantly, people underestimate their own irrationality. Yes, it's crazy to put a large amount of money in a single stock, but it does not follow that it's equally crazy to hold that stock. Stock analysts understand this, which is why they have a Hold rating – don't buy this stock, but if you already have it, don't sell it. Holding a position that you wouldn't buy makes perfect sense for a human, because a human tends to get very upset if they sell it and then the price goes way up. I say, unless selling it all right now is your way to buy something that you absolutely must buy, don't.

Are stock options worth it for employers?

Absolutely. It does nothing to motivate most but it does wonders to motivate some, and then it's really cheap for the employer.

Conclusion

Overall, if you're at a startup and there's no compelling reason to leave (as there might be if you can make $3M in 10 years at a big company, or start your own business, whatever), make sure to maximize your equity. From a regret minimization perspective, it's not a lottery ticket, but an insurance policy. If the company makes it, you will not be the one who came out with nothing. If it doesn't make it, at least you took a shot.

A manager's pitfall: striving to "add value"

There's this guy I work with who has a head the size of a small planet. In that head, dozens of design decisions big and small are made every day. Hundreds of options clash in his mind: which gives us the best trade-off between 3 different desirable things? Or 5 things, or 12, as the case may be?

And the thing about this guy is, he'll always make the decision, because you must, because deadlines. So not the kind of guy who just gets stuck in the multitude of possibilities, nope, not him. BUT he's normally unhappy with the decision, because you see, there wasn't time to REALLY evaluate it PROPERLY.

So we've been working with this guy, and he'd often ask me to help decide something at his end.

At first I'd ask about the details, and I'd propose solutions. And he didn't seem very happy with that, and eventually he got seriously pissed off. That was when I asked for a really big new feature, and he said it wasn't doable, "forget it."

So I said, "let's see though, what makes this so hard? Because I'm willing to throw a lot of it out and do just the most bare-bones version. Maybe then it'd be doable." So I was helping him, I was willing to ask for less, right? So I sure didn't expect the outcome, which was, he rather forcefully said he couldn't work like that any longer, with no stable specs and no real schedule and it's just him doing this after all AND…

At this point I sorta gathered from the form and substance of his speech that I should back off, RIGHT NOW. I said, "look, if you add this, all I can say is, the whole thing will be much better. But if it can't be done, fine, we can live without it. It's entirely your call and I have nothing to add."

And then he did it. Not some bare-bones, half-assed version, mind you, he did a pretty impressive full-blown thing. Then he redid it to make it better still.

So clever me thinks to myself, aha! I see, so what annoyed him wasn't how I asked for this huge feature in itself. What annoyed him was me demanding him to tell why it was hard, so I could break it up into parts, and tweak it, and basically solve this myself. He didn't really mind solving it if he did it, provided that

  • It was a request and not a "requirement" – because someone like me who doesn't really understand what goes into it has no right to just require it. You're not entitled to things you can't even comprehend, asshole!
  • …and I wouldn't try to "help" him by attempting to remedy my ignorance at his expense, questioning him on the details and then hastily "making it easier" for him, without thinking deeply enough whether making it easier was even NEEDED, and so  tricking him into making some pale no-good version of it! And then HE, because of ME, because of my impatient superficial "help", will have done a bad job! No, he doesn't want it easy, he wants it done right, so take a hike and give him time to decide what the right trade-off is, where to work harder and get more done and where to do less.

OK, so that's how it's gonna work from now on, I thought. From then on, if he wanted me to help him decide something, I'd just ask him what options he had in mind, regardless of what I could come up with myself. And I'd say this one sounds good.

This sort of worked, but he still didn't seem quite happy. And at one point he got pissed off and demanded explanations why I thought his option A was better than his option B. And I gave my explanations, and he thought they were shit. And I said, you know, A and B are both alright. Pick whichever you like better. "What?! So why did you just say that A was better?" "I dunno, I was wrong, you convinced me, it's a tough call."

Now I finally got it! So the way it works is, he thinks something through, for hours and days. If it's still a close call, he comes to me, whom he genuinely respects, and who's got the nominally higher seniority. What he comes to me for is superior wisdom. What he doesn't realize, out of excessive humility, is that there's no way I'll be better at deciding it than him, because he's better at it than me, and he's been thinking about it for so much longer.

And he only comes to me with what to him are the hardest things, guaranteeing that I won't be able to help, not really. So trying will just piss him off because I'll necessarily be suggesting some pretty dumb and superficial decision procedure, which is like helping Michelangelo with a sculpture by lending him a sledgehammer to just remove all that big chunk of stone over there.

So from then on I'd listen to his doubts, and agree that it's hard because of this thing we can't measure and that other thing we can't know, and say optimistically that either way I think it'll come out alright but it's his call, really. And he appeared very happy with my careful supervision of his work.

Bottom line for me was, I did very little hard thinking and a pretty cool project got done, I think, and the guy was happy, at least as much as he can be in this imperfect world. What's not to like?

The thing many of us managers don't like in such cases is, we seem to have added no value. Where's my chunk of value?

"He who does not work doesn't get to eat", they taught me in the USSR. "To capture value, add value" would be the translation of this slogan into MBA-speak. "By the sweat of your brow you will eat your food", says the Holy Bible. None of this prepares you for a managerial role, where not doing shit is usually better than trying too hard.

A manager on a mission to add value usually thinks that it's his job to have all the good and important ideas. Corollary: someone else having many of the good and important ideas means you, the manager, are bad at your job. Will you accept this and suffer silently, or will you convince yourself that the report's ideas aren't that good? You don't want to find out. I say, don't put yourself in this situation in the first place, don't try hard to have the good ideas, look at your ability to not do shit in return for a nice compensation as both your new virtue and your immense luck, and relax.

If you're really addicted to making tangible contributions, I suggest to do what I've been doing in managerial roles – do some of the work yourself. Now, this is, without doubt, terribly irresponsible, because it makes me unavailable at unpredictable moments. When shit hits the fan and I must attend to it in my contributor's role, it prevents me from attending to the never-ending fan-hitting shit that the people I manage deal with.

There's also an advantage, and that is that I know how much things really suck in the trenches. And that's good, and anyone overseeing less than 50-100 people should stay current that way, I think. But don't "stay current" by working on urgent mission-critical shit (as I often do, because I suck.) Pick something unimportant instead.

Anyway, working myself is immensely better than trying to have the good ideas myself, I believe. This can result in not being there when they need me, but it never results in being there when they don't, which is worse.

If it's not the deep thinking, then what do managers do, except for sitting on their asses? I started putting it down, and it didn't come out very well, and the reason ought to be that, well, I don't really get it at this point. I'm a middling manager, whose main skill is attracting strong people and then taking credit for their work. And this one managerial skill compensates for the underdevelopment of the rest so well that they, unfortunately, remain underdeveloped.

So until my understanding of the managerial role improves, the one thing I will say here is, many people actually don't do shit most of the time and it's fine – say, lifeguards. Why do you need them? Just in case. So that's one way I think about myself - I'm like a lifeguard, except for the physique. Maybe I should use the time freed up by not having to do deep thinking to work on my pectoral muscles, so that one day I could star in "Programmer Watch", a "Baywatch" rip-off about R&D management. But I keep my hopes low on that one.

I say, quit "adding value", fellow managers. Just sit back and take credit for others' work. They'll thank you for it.

P.S. angry hamster – this one's for you.

The C++ FQA is on GitHub

I have become burned out in my role as guardian of the vitriol, chief hate-monger… and most exalted screaming maniac.

– Alan Bowden, then the moderator of the UNIX-HATERS mailing list

The C++ FQA's "source code" (that is, the ad-hoc markup together with the ugly code converting it to HTML) is now on GitHub.

I decided to write the FQA around 2006. I felt that I should hurry, because I'd soon stop caring enough to spend time on it, or even to keep enough of it all in my head to keep the writing technically correct.

And indeed, over the years I did mostly stop caring. Especially since I managed to greatly reduce my exposure to C++. The downside, if you can call it that, is that, in all likelihood, I'll forever know much less about C++11 than I knew about C++98. I mean, I can use auto and those crazy lambdas and stuff, but I don't feel that understand all this horror well enough to write about it.

So I invite better informed people to do it. I was looking for a single person to take over it for a while. The trouble is, most people disliking C++ choose to spend less time on it, just like me. And since writing about C++'s flaws is one way of spending time on it, people who want to do it, almost by definition, don't really want to do it. Bummer!

However, doing a little bit of editing here and there might be fun, it wouldn't take too much of your time, and you'd be creating a valuable and scarce public good in an environment where naive people are flooded with bullshit claims of C++11 being "as fast as C and as readable as Python" or some such.

I don't think my original tone has to be preserved. My model at the time was the UNIX-HATERS style, and in hindsight, I think maybe it'd actually turn out more engaging and colorful if I didn't write everything in the same "I hate it with the fire of a thousand suns" tone.

Also, and I think this too was needlessly aped from UNIX-HATERS – I keep insisting on this good-for-nothing language being literally good for nothing, and while I don't outright lie to make that point, I'm "editorializing", a.k.a being a weasel, and why do that? I mean, it's a perfectly sensible choice for many programmers to learn C++, and it's equally sensible to use it for new projects for a variety of reasons. Do I want to see the day where say Rust scrubs C++ out of the niches it currently occupies most comfortably? Sure. But being a weasel won't help us get there, and for whomever C++ is the best choice right now, persuading them that it isn't on general grounds can be a disservice. So the "good for nothing" attitude might be best scrapped as well, perhaps.

On the other hand, there was one good thing that I failed to copy from UNIX-HATERS - how it was a collaboration of like-minded haters of this ultimately obscure technical thing, where human warmth got intermixed with the heat of shared hatred. Maybe it works out more like that this time around.

Anyway, my silly markup syntax is documented in the readme file, I hope it's not too ugly, and I'm open to suggestions regarding this thing, we could make it more civilized if it helps. In terms of priorities, I think the first thing to do right now is to update the existing answers to C++11/14, and update the generated HTML to the new FAQ structure at isocpp.org; then we could write new entries.

You can talk to me on GitHub or email Yossi.Kreinin@gmail.com

 

 

Fun with UB in C: returning uninitialized floats

The average C/C++ programmer's intuition says that uninitialized variables are fine as long as you don't depend on their values.

A more experienced programmer probably suspects that uninitialized variables are fine as long as you don't access them. That is, computing c=a+b where b is uninitialized is not harmless even if you never use c. That's because the compiler could, say, optimize away the entire block of code surrounding c=a+b under the assumption that c=a+b, where b is proven to be always uninitialized, is always undefined behavior (UB). And if it's UB, the only way for the program to be correct is for this code to be unreachable anyway. And if it's unreachable, why waste instructions translating any of it?

However, the following code looks like it could potentially be OK, doesn't it?

float get(obj* v, bool* ok) {
  float c;
  if(v->valid) {
    *ok = true;
    c = v->a + v->b;
  }
  else {
   *ok = false; //not ok, so don't expect anything from c
  }
  return c;
}

Here you return an uninitialized c, which the caller shouldn't touch because *ok is false. As long as the caller doesn't, all is well, right?

Well, it turns out that even if the caller does nothing at all with the return value – ever, regardless of *ok – the program might bomb. That's because c could be initialized to a singaling NaN, and then say on x86, when the fstp instruction is used to basically just get rid of the return value, you get an exception. In release mode but not in debug mode, some of the time but not all the time. This gives you this warm, fuzzy WTF feeling when you stare at the disassembled code. "Why is there even a float here in the first place?!"

How much uninitialized data is shuffled around by real-world C programs? A lot, I wager – likely closer to 95% than to 5% of programs do this. Otherwise Valgrind would not go to all the trouble to not barf on uninitialized data until the last possible moment (that moment being when a branch is taken based on uninitialized data, or when it's passed to a system call; to not barf then would require some sort of a multiverse simulation approach for which there are not enough computing resources.)

Needless to say, most programs enjoying ("enjoying"?) Valgrind's (or rather memcheck's) conservative approach to error reporting were written neither in assembly which few use, nor in, I dunno, Java, which won't let you do this. They were written in C and C++, and most likely they invoke UB.

(Can you touch uninitialized data in C without triggering UB? I seriously don't know, I'm not a language lawyer. Being able to do this is actually occasionally useful for optimization. Integral types for instance don't have anything like signaling NaNs so at the assembly language level you should be fine. But at the C level the compiler might get needlessly clever if it manages to prove that the data is uninitialized. My own intuition is it can never prove squat about data passed by pointer because of aliasing and so I kinda assume that if I get a buffer pointing to some data and some of it is uninitialized I can do everything to it that I could in assembly. But I'm not sure.)

What a way to make a living.

 

 

Accidentally quadratic: rm -rf??

This is a REALLY bad time. Please please PLEASE tell me I'm not fucked…

I've accidentally created about a million files in a directory. Now ls takes forever, Python's os.listdir is faster but still dog-slow – but! but! there's hope – a C loop program using opendir/readdir is reasonably fast.

Now I want to modify said program so that it removes those files which have a certain substring in their name. (I want the files in that directory and its subdirectories, just not the junk I created due to a typo in my code.)

HOW THE FUCK DO I DO THAT IN O(N)??

O(N^2) is easy enough. The unlink function takes a filename, which means that under the hood it reads ALL THE BLOODY FILE NAMES IN THAT DIRECTORY until it finds the right one and THEN it deletes that file. Repeated a million times, that's a trillion operations – a bit less because shit gets divided by 2 in there, but you get the idea.

Now, readdir gives me the fucking inode number. How the FUCK do I pass it back to this piece of shit operating system from hell, WITHOUT having it search through the whole damned directory AGAIN to find  what it just gave me?

I would have thought that rm -rf for instance would be able to deal with this kind of job efficiently. I'm not sure it can. The excise function in the guts of coreutils for instance seems to be using unlinkat which gets a pathname. All attempts to google for this shit came up with advice to use find -inode -exec rm or some shit like that, which means find converts inode to name, rm gets the name, Unix converts the name back to inode…

So am I correct in that:

  • Neither Unix nor the commercial network filers nor nobody BOTHERS to use a hash table somewhere in their guts to get the inode in O(1) from the name (NOT A VERY HARD TASK DAMMIT), and
  • Unix does not provide a way to remove files given inode numbers, but
  • Unix does unfortunately makes it easy enough (O(1)) to CREATE a new file in a directory which is already full of files, so that a loop creating those bloody files in the first place is NOT quadratic?? So that you can REALLY shoot yourself in the foot, big time?

Please tell me I'm wrong about the first 2 points, especially the second… Please please please… I kinda need those files in there…

(And I mean NOTHING, nothing at all works in such a directory at a reasonable speed because every time you need to touch a file the entire directory is traversed underneath… FUUUUUCK… I guess I could traverse it in linear time and copy aside somehow though… maybe that's what I'd do…)

Anyway, a great entry for the Accidentally Quadratic blog I guess…

Update: gitk fires up really damn quickly in that repository, showing all the changes. Hooray! Not the new files though. git citool is kinda… sluggish. I hope there were no new files there…

Updates:

  • `find fucked-dir -maxdepth 1 -name "fuckers-name*" -delete` nuked the bastards; I didn't measure the time it took, but I ran it in the evening, didn't see it finish in the half an hour I had to watch it, and then the files were gone in the morning. Better than I feared it would be.
  • As several commenters pointed out, many modern filesystems do provide O(1) or O(log(N)) access to files given a name, so they asked what my file system was. Answer: fucked if I know, it's an NFS server by a big-name vendor.
  • Commenters also pointed out how deleting a file given an inode is hard because you'd need a back-link to all the directories with a hard link to the file. I guess it makes sense in some sort of a warped way. (What happens to a file when you delete it by name and there are multiple hard links to it from other directories?.. I never bothered to learn the semantics under the assumption that hard links are, um, not a very sensible feature.)

"Information asymmetry" cuts both ways

They pretend to pay us, and we pretend to work.

 – A Soviet-era political joke according to Wikipedia, though I've only seen it in an English text describing the C++ object model

Having been born in the USSR, #talkpay – people disclosing their compensation on May 1 - put a series of smiles on my face, expressing emotions that I myself don't quite understand.

The numbers certainly left me pleased with the state of the oppressed proletariat (web designers, computer programmers, etc.) in the rotting capitalist society. I do hope that the $125K/year proletarian will not feel resentment towards the $128K/year guy in the next cubicle. I hope as well that the second guy's manager won't deny him a promotion so as to avoid further offending the first guy.

"Hope", yes; "count on" – no, which is why I won't be tweeting about my compensation. Because my numbers are almost certainly either lower or higher than yours, and why needlessly strain our excellent relationship – am I right, dear reader? (The other reason is having no Twitter account.)

So, yeah, a series of smiles and a range of emotions. But today I want to focus on one particular bit – the one mentioned by Patrick McKenzie:

Compensation negotiations are presently like a stock exchange where only your counterparty can see the ticker and order book. You’d never send an order to that exchange — it would be an invitation to be fleeced. “I happen to have a share of Google and want to sell it. What’s it go for?” “Oh, $200 or so.” “Really? That feels low.” “Alright, $205 then, but don’t be greedy.”

The spot price of Google when I write this is $535. Someone offering $205 for GOOG would shock the conscience. …folks have received and accepted employment offers much worse than that, relative to reasonably achievable market rates.

All very true, except that with a share of Google, they're all the same and you arguably know what you're buying, and with an employee's services, they aren't and you don't.

There seems to have been a string of Nobel Prize-winning economists who founded "X economics" – such as "behavioral economics" or "information economics." The common thing between "X economists" is, they all (correctly) tell me that I'm irrational and misinformed. But then they conclude that it's them and not me who should manage my money. I believe the latter does not follow from the former. But I'll save that discussion for another day.

In particular, Stiglitz, the information economics guy, opened his Nobel Prize lecture with an explanation of his superiority over other economists. This state of things arose, according to him, due to having grown up in a small town in Indiana, where things didn't work as predicted by standard economic models. Specifically, the proletariat got shafted, prompting Stiglitz to come up with formulas predicting how badly one can be swindled due to his ignorance of the market conditions.

Which is probably very true and relevant, but it cuts both ways. A guy paying me to work on a conveyor belt could measure my productivity perfectly, and probably knew the market for my labor better than I did – clearly he had an advantage. A guy paying me to program, however, might know more about wages than I do. But he certainly doesn't have the foggiest idea what I'm doing in return for his money, even if he's a better programmer than I am.

Basically the "knowledge worker's" contract is something like this:

We'll give you a precisely defined salary and a benefits package. In return, we request that you handle some problems that we're told we're having. We hope that you'll solve them well enough to prevent us from having to know what they were in the first place. Please help us maintain the feeling that we own an asset similar to land or gold or something. Please keep the realization that we're more like the operator of a flying circus than a landowner from disturbing us. And certainly, never, ever ask us what to do with any of the moving pieces of this flying circus, because we seriously have no idea.

Of course, most people have a direct manager overseeing their work in the flying circus who knows more about it than the owner. But, ya know… "…then for the next 45 minutes I just space out", as the quote from Office Space goes. Seriously, it's bloody hard to tell if you're only working at half your ability – the only guy who knows is you. And this information asymmetry seems to me kind of symmetrical with that other asymmetry – employers being better at tracking the labor market, negotiating, etc. So, see the "Soviet" joke at the top of the page…

(Of course it's much better with an actual market for labor – I'm just saying that it's still far from perfect, and it'll get increasingly farther from "perfect" as the knowledge becomes more widely dispersed and you basically just have to trust experts at every step. An economy of dishonest experts – now that's a bloody nightmare. And by the way I actually think we now have enough newfangled technology together with ages-old fallibility to get there. AAA-rated MBSs is just the beginning.)

For a closing remark, I think it's fitting to mention all those bozos saying how "higher compensation does not increase motivation." (A management consultant saying something else might not get his management consulting gig, so I understand where they're coming from.)

To that I say: for me, at least, higher compensation leads to higher awareness of "spacing out" and such – call it "guilt" if you like. Pay me enough and I will think things like, "I'd really like to ignore this here shit, and it's SO ugly, and nobody will ever know. But, sheesh, they paid me all this money, just like they promised. And I sorta promised that I'll take care of the flying circus in return. And so it's seriously not OK to leave this here shit unattended. I better tell someone, and what's more, this here patch is definitely mine to clean, so here goes."

One danger in underpaying someone is it might prevent those thoughts from entering their minds. So, employers – caveat emptor. 'Cause goodness knows that the easiest way to raise one's compensation in the knowledge economy is to simply space out more while getting paid the same.

#talkpay…

A "WTF is that sound" widget

A core function of an OS is dividing resources between apps: multiple windows per screen, files per disk, sockets per Internet connection, etc.

The machine's goddamned SPEAKER is one of those resources.

Now let's say you're working at your desktop. Your boss walks in for a chat. And now, midway through the conversation, your computer's goddamned speaker emits something like: "Major breakthrough reached at the G-20 meeting!", or "I came in like a wrecking ball!", or "Aaaah… ah! yeah, right there… AAAGH!!"

Your computer might have said it because you're watching news, or that other stuff, instead of working. Alternatively, perhaps some uninvited pop-up popped up an hour earlier - and then decided to self-activate at the worst possible moment.

Either way, it'd be nice to be able to shut the thing off quickly – say, right after "Hi, I'm Wendy" and before it gets to "yeah, right there." And not only that, but you might want to kill the app without giving focus to its window, because who knows what Wendy's up to in that window.

Now, closing a window or deleting a file is easy, because you have a visible handle to click on. Not so with sound, unfor-tu-nate-ly. Big mistake on behalf of OS designers, says I… BIG MISTAKE.

And that, folks, is the perfect use case for a "WTF is that sound" widget. I haven't figured it out down to an actual mockup or anything, but, ya know, it'd be a list of who the FUCK is using the GODDAMNED SPEAKER. "Who the fuck" might be a list of window titles – or maybe not, because you might not want a title like "Erm erm Wendy erm ahem". So it might be a list of app names without the window titles. Most importantly, if just ONE app is using the goddamned speaker, then there'd be just one red button that you press to KILL the fucking thing.

I'm hereby placing the idea in the public domain. Now go ahead and make {the world a better place, billions, an abandoned GitHub project implementing this dumb idea}.

P.S. I'm fine, thank you, but yes, the inspiration comes from real life, and no, it was neither Miley Cyrus nor Wendy, but a weird tune without words that ended as mysteriously as it commenced, and I still don't know what played it.

Update: no, it's not like a mute button. If we're seriously being serious about it, then pressing a mute button is like turning off the screen. When the boss walks in and there's a noise and you mute everything including the ambient music it's off, just like pressing the screen's off button would be off. More seriously, if you have umpteen apps and tabs and shit and something starts to emit sound and you don't know what that is, then a mute button doesn't help you, not if you want to listen to anything else at the same time which you might want to. So you need a "sound manager" just like you need a window manager. (Imagine having to guess which of the umpteen [x] buttons to close to make a particular window disappear. Sucks, right? Exactly the situation with sound, which, if it doesn't happen to be synced to video playing in some window, comes from fuck knows where – and even if it's synced to video, you must sift through windows to find that video! Why can't the window/tab/whatever at least have an indication of "sound is being emitted by the sucker who opened me"? Seriously, it's just dumb.)

A Sokoban levels design programming contest

I hate puzzles with a passion; I think of them as Gordian knots best untied with a sword, a machine gun or whatever else you can bring to bear on the problem.

The world of computer programmers, however – the world which I entered with the sole purpose of working for the highest bidder – is a world full of people who sincerely love puzzles. And if you visit this blog, perhaps you're one of these people.

If so, you might be pleased to learn about the recently launched Sokoban levels design contest, operated by gild – a great hacker, my long-time co-worker, an IOCCC winner, and a participant in Al Zimmerman's programming contests which he cites as inspiration for his own new contest.

The rules are precisely defined here; the general idea is to design Sokoban levels falling into different problem classes. Submitted levels are scored based on the length of the shortest solution (longer is better), and normalized s.t. the level taking the most steps to solve right now gets the score of 1. With 50 problem classes, the maximal overall score is 50. But with all the other cunning contestants submitting their own levels, your levels' score might be dropping every day or hour!

And I really mean every day or hour – even now at the very beginning there are several submissions per day. Judging by the rankings page, people spread around the globe are busy improving their Sokoban level-designing software and resubmitting better solutions. (Or they might be doing it in their heads; you don't need to submit any code, just the levels. I hear that occasionally a contestant using no software at all gets a rather good result in an Al Zimmerman's contest… What happens inside the heads of such people I don't know.)

There's also a discussion group, and if you're among the cunningest, most tenacious puzzle lovers who'll get to the top, you'll get – guess what? – a puzzle! Specifically, a gift card which you can use to buy, say, this Rubik's cube – or rather a Rubik's fuck-knows-what. I guess cubes are for sissies:

I personally think it's a bloody cool community/subculture to be in; a pity that I don't quite have the brains for it. (Could I hold my own if I really liked it? Or maybe I would really like it if I could hold my own? These are the types of questions it all brings to my mind.)

Anyway – if you're that sort of guy, it looks like a great thing for your brain to chew on. Good luck!