Don't Panic

Why I leave my webcam off

Mon, 05 Jan 2026 05:12:48 -0700

Whenever possible, I leave my webcam off during internet meetings. It is almost always possible.

There are a few reasons. In decreasing importance:

Attention

Screens are attention-destroyers.

There are so many things to look at and to do. I was probably deep into a task when the meeting started. So tempting to just nudge it along. Or I might stare at myself on camera.

If I turn the webcam off, I can stand up and move around.

The impact of this on my attention is dramatic.

People sometimes think that I’ve turned off my camera so that I can tune out. This has it exactly backwards. If my camera is on, I’m probably not paying much attention.

As a bonus, I get fresh air, exercise, a tidier house, or fewer weeds in my garden.

Fatigue

Being on-camera is tiring; it’s well-documented. I have yet to see benefits from video that outweigh that cost.

Connection quality

Except for the very best of internet connections, audio-only just works better.

Fluid conversation consists of continuous negotiation about turn-taking. Every negotiation is a round trip; high latency destroys easy communication.

Humans also handle audio hiccups better than video artifacts, perhaps because we’re accustomed to acoustic interference in the real world. Wind happens, but a frozen, pixelated face is unnerving.

Formality

I don’t FaceTime my family or close friends. We talk on the phone. It’s relaxing and pleasant. Video calls feel formal and stiff.

And in fact, the main scenario in which I find it socially difficult to turn off my video camera is in formal calls, usually with people I don’t know.

Increasingly, though, I establish from the moment that the call is scheduled that my camera will be off. Any awkwardness from that has faded by the time the call occurs. And I’m happier for it.

How to make NYT Connections better

Mon, 27 Oct 2025 07:12:48 -0700

I’ve played nearly every NYT Connections.

The core game is rock solid, but category colors sap some of the joy. To maximize your score, you’re supposed to submit categories from purple to yellow. But:

After spotting an easy category, I waste mental energy filtering it out.
When I’ve solved the whole thing in my head, I must still guess which category is which color.
I use grayscale devices.

Here are some proposals to fix these frustrations.

Let me select more than four tiles

Right now, when you reach four selected tiles, the Submit button is enabled and no further tiles may be selected.

Instead, continue allowing tiles to be selected above four, but disable the Submit button whenever there aren’t exactly four tiles selected.

Then I could select all of the tiles that I have categorized, and easily focus on what remains.

Add Gather

The Gather button gathers exactly four selected tiles to the top row, just like the Submit button, except that it doesn’t check for correctness and doesn’t Submit.

Then I could Gather my categories one at a time as I find them.

Add Submit All

Once there is a Gather button, or drag-and-drop, or any other non-Submit way to organize tiles, add a Submit All button. This succeeds only if every row is a category; otherwise it fails outright. It is available only when no categories have been Submitted yet.

This removes any guesswork, and by being all-or-nothing, raises the stakes.

Add non-color affordances

Even small visual clues would make a big difference.

Security through intentional redundancy

Mon, 15 Sep 2025 07:12:48 -0700

When writing a service, it’s very easy to accidentally forget to check permissions or ownership of an object.

This code has a gaping security hole in it:

func (s *Server) deletePhoto(w http.ResponseWriter, r *http.Request) {
    id := r.URL.Query().Get("id")
	s.db.DeletePhoto(id)
}

Anyone who gets ahold of a photo ID can delete that photo.

Developers often address this through middleware, but such middleware tends to get complicated and thus error prone.

The problem is that DeletePhoto API has an insecure design: The caller must actively remember to check permissions before calling it. It fails open.

One approach to fixing this is to add redundant arguments.

Let’s change:

func (db *DB) DeletePhoto(id string) error

to this:

func (db *DB) DeletePhoto(id string, owner *User) error

The owner parameter is, strictly speaking, redundant. The photo ID already uniquely identifies its owner.

But now, the caller needs a *User to use the API. They’ll probably reach for the most convenient one.

func (s *Server) deletePhoto(w http.ResponseWriter, r *http.Request) {
    id := r.URL.Query().Get("id")
    // grab user set by middleware
    user, _ := r.Context().Value("user").(*User)
    s.db.DeletePhoto(id, user)
}

This is the path of lowest resistance to calling DeletePhoto. A developer (or an LLM) might write this code without thinking about security at all…and yet, it’s pretty solid, because DeletePhoto can enforce that the photo must be owned by the provided user. Only one person (the author of DeletePhoto) had to think about security. Everyone else gets it for free. This API fails closed.

This approach works across many programming languages, and at many different API levels.

My favorite is SQL, usually via sqlc. For example, change the query from:

DELETE FROM photos WHERE id = ?;

to:

DELETE FROM photos WHERE id = ? and owner_id = ?;

The main challenge I’ve encountered with this in the past is that people will want to refactor the code to remove the clutter. It can take some convincing.

This trick isn’t a panacea (nothing is), but it definitely helps. And in an era in which serious amounts of code is being written by LLMs, with only local information, secure-by-default APIs look increasingly appealing.

Simpler backoff

Fri, 30 May 2025 07:12:48 -0700

Exponential backoff with jitter is de rigeur for making service calls. This code, or something like it, probably looks really familiar:

func do(ctx context.Context) error {
	const (
		maxAttempts = 10
		baseDelay   = 1 * time.Second
		maxDelay    = 60 * time.Second
	)

	delay := baseDelay
	for attempt := range maxAttempts {
		err := request(ctx)
		if err == nil {
			return nil
		}

		delay *= 2
		delay = min(delay, maxDelay)

		jitter := multiplyDuration(delay, rand.Float64()*0.5-0.25) // ±25%
		sleepTime := delay + jitter

		select {
		case <-ctx.Done():
			return ctx.Err()
		case <-time.After(sleepTime):
		}
	}

	return fmt.Errorf("failed after %d attempts", maxAttempts)
}

func multiplyDuration(d time.Duration, mul float64) time.Duration {
	return time.Duration(float64(d) * mul)
}

But we can make this much nicer with a simple lookup table.

func do(ctx context.Context) error {
	delays := []time.Duration{
		1 * time.Second, 2 * time.Second,
		4 * time.Second, 8 * time.Second,
		16 * time.Second, 32 * time.Second,
		60 * time.Second, 60 * time.Second,
		60 * time.Second, 60 * time.Second,
	}

	for _, delay := range delays {
		err := request(ctx)
		if err == nil {
			return nil
		}

		delay = multiplyDuration(delay, 0.75 + rand.Float64()*0.5) // ±25%
		select {
		case <-ctx.Done():
			return ctx.Err()
		case <-time.After(delay):
		}
	}

	return fmt.Errorf("failed after %d attempts", len(delays))
}

This is much simpler. There are fewer variables, with smaller scope. There’s no need to reasoning about behavior across loops, and if there’s a bug in the calculations, it won’t affect subsequent iterations.

It is more readable. It is obvious how it will behave. It is also more editable. Changing the backoff schedule and number of attempts now feels safe and trivial.

Don’t write code that generates a small, fixed set of values. Use a lookup table instead.

Blog schism

Fri, 23 May 2025 05:12:48 -0700

Lots of people don’t want to read about AI.

I respect that.

But I’m currently steeped in the world of AI, for better or for worse, and I want to blog about it. So I’ve split this blog in half.

The normal blog, which you are reading, is now AI-free.

There’s another, at /ai that contains only AI posts. It has its own RSS feed.

Podcast ho!

Fri, 12 Jan 2024 15:12:48 -0700

I have started a podcast, Significant Bits.

The goal is to have substantive technical discussions about software engineering, very broadly defined.

You can listen at https://sigpod.dev/

Sometimes Software is Done, or Why Hugo Why

Tue, 09 Jan 2024 09:12:48 -0700

I didn’t sit down this morning planning to write a grouchy blog post about Hugo.

When I first used Hugo I loved it. It was fast. It was simple. It just worked, as much as any software does, and it solved a real problem.

It was done.

But people kept working on it.

I’m sure that it has been improved in countless ways. But along the way it has gotten bigger and more complicated, and has broken backwards compatibility repeatedly.

I am only inspired to write a blog post every few months. It takes a lot of self control to forgo the glittering pile of side projects and use my precious free time to write some words instead of code.

I commit to myself: Today is the day! I will finally tackle one of the items from my blog post idea list!

And then…

I run hugo…

And it scribbles all over my files, a slew of unimportant changes, unfortunately occasionally interspersed with a few that matter…

And it warns me of new deprecations, often with unusable upgrade instructions…

And things flat out break.

(Often, they were deprecated and then broken entirely between two subsequent blog posts, so I never ever saw the deprecation.)

Instead of writing a blog post, I spend hours fixing build failures.

Build failures of my static site, which has maybe a few dozen posts.

I don’t care about Hugo’s internals. I have never cared. I just want a blog that works.

Enough complaining. Hugo is officially on the chopping block. Suggestions for alternatives welcome.

And in the meantime, I’ll just compile Hugo myself from source, never update it, and live in the ever receding past.

Backwards compatibility matters. And sometimes, software is done.

Type Specialization in Go

Mon, 03 Apr 2023 08:12:48 -0700

This post was originally tweets but then things happened, and it needed a new linkable home. Btw, I’m now @commaok@inuh.net on Mastodon.

This post is about manual type specialization, which can make a big difference in some hot code.

Consider this:


type Gopher interface {
  Goph()
}

func f(x Gopher) {
  // ...
  if t, ok := x.(*T); ok {
    t.Goph()
  } else {
    x.Goph()
  }
  // ...
}

It’s weird. The type assertion to (*T) is semantically irrelevant. We call .Goph on each branch!

But that pointless type assertion is also really cheap. And on the success branch, the compiler can do improved escape analysis (alloc less) and inline the method body (faster).

This is one form of type specialization, a common optimization done by JIT compilers.

This technique can help if you have (1) very hot code that (2) is called via an interface but (3) has only one or two primary implementations.

It hurts readability. Use only when it counts, and document it.

Why doesn’t the compiler do this for you? It doesn’t know what types would be good to try. JIT would help. IPO/WHO/LTO might help.

And PGO probably will help, in some future Go release! As of Go 1.20, cmd/compile has some profile-guided optimization around inlining. More is planned, including register allocation and type specialization, which might end up covering this use case.

Nicer struct literals in Go templates

Fri, 24 Jun 2022 08:12:48 -0700

Go templates (text/template, html/template) accept a single argument to render. That’s generally enough when you’re executing them from Go code. But when invoking a template from another template, you often want to pass multiple things to it.

For example, we might have a template that renders a nav bar item. It requires a title, a url, and an “enabled” bool. We want to invoke it from another template.

How do you do that?

In this post I’ll review the existing options and then discuss a new one I’m working on.

Existing options

dict

You can combine multiple key/value pairs into a map. Define a “dict” function in your FuncMap and call it from your template.

This might look like:

{{ template "navbar" dict "title" "Home" "url" (urlNamed "home") "enabled" true }}

This is flexible and gets the job done. But it is a bit of a blob and has no type safety.

Do it all in Go code

Define a nav bar item struct:

type NavBarItem struct {
    Title string
    URL string
    Enabled bool
}

Construct the nav bar item in your Go code using a struct literal. Pass it into your template, and then pass it along to the nested template.

This works, but it splits your content into two places. And it can be annoying to thread everything through. It is not so much a solution to the problem as it is giving up on solving the problem.

tmplfunc

tmplfunc converts templates to functions. If you define the navbar template using {{ define "navbar title url enabled" }}, then tmplfunc arranges for it to be callable:

{{ navbar "Home" (urlNamed "home") true }}

This adds a bit of type safety, but not much. As the list of parameters grows, it loses readability. It only works with template execution; you can’t use it to define a local variable. And it requires that you replace the template parsing pipeline with tmplfunc.

A new approach

The new approach I’m experimenting with is to define a Go struct for the template input (as above) and then autogenerate corresponding FuncMap entries. This provides a template syntax for writing struct literals.

My initial attempt at this is package tstruct.

First, we hook the NavBarItem struct up to the FuncMap:

m := template.FuncMap{ /* your func map here */ }
err := tstruct.AddFuncMap[NavBarItem](m)
// handle err

We can now call the template like this:

{{ template "navbar" NavBarItem (Title "Home") (URL (urlNamed "home")) (Enabled true) }}

This is a bit more verbose, but I find it far more readable. It is pretty type safe, and it is flexible; you can reorder and omit any of the field arguments.

Package tstruct also supports map and slice fields. For example, given this struct type:

type Example struct {
    Map map[string]int
    Slice []int
}

After calling tstruct.AddFuncMap[Example](m), you can write:

{{ $x := Example (Map "a" 1 "b" 2) (Slice 5 6 7) }}

x now contains the value:

Example{
    Map: map[string]int{"a": 1, "b": 2},
    Slice: []int{5, 6, 7},
}

If it helps with clarity, you can also build maps and slices incrementally. This yields identical results:

{{ $x := Example
    (Map "a" 1)
    (Map "b" 2)
    (Slice 5)
    (Slice 6)
    (Slice 7)
}}

You can also define custom setters for struct fields with named types; look for TStructSet in the tstruct readme.

FuncMap name collisions

FuncMaps are global, so if you already have an entry called NavBar, then package tstruct can’t (or rather, won’t) add one to construct NavBar structs. Similarly, tstruct can’t add two structs with the same name, or a struct with the same name as a struct field.

As a special case, however, tstruct supports using the same struct field name across different structs, even if they have different types. (This is possible because the “field setter” FuncMap entry is only fully evaluated by tstruct itself in the context of a specific struct type.)

Fortunately, most FuncMap functions start with a lower case letter, and tstruct only works with exported struct fields, so there’s some amount of convention-based namespacing.

Caveats

As of June 2022, this is fairly novel, both the idea (I think) and the implementation (definitely).

I expect the API and details to evolve as I use this more and (hopefully) hear from others using it. Please file issues with feedback, bugs, and ideas. If it ends up being popular, I’ll try to push towards a stable v1.

Performance and files full of code

Sat, 30 Apr 2022 08:12:48 -0700

Linus’s Famous Law: “Given enough eyeballs, all bugs are shallow.”

Linus’s Less Famous Law: “Files grow.”

One of the hardest things programmers do is keep code readable. Splitting code up into separate files is a basic tool for that.

And yet, crazy as it sounds when you say it out loud, our tools pressure us not to.

PHP

My first software job was for a company called AdMob. We used PHP. I know.

I needed to optimize some very hot code. I was a philosophy Ph.D. dropout, so I had very little idea what I was doing. The internet’s advice for optimizing and scaling PHP was “use memcached!”, but we were way beyond that.

I eventually figured out that if I combined all of our code into a single file, I could get double-digit speed-ups. It turns out that the overhead of statting, opening, and parsing a new file was substantial. I wrote a simple preprocessor, everyone groaned unhappily, and we moved forward.

JavaScript

Today I was looking into a bit of JavaScript that runs as part of our build process. (I care a lot about build time. For many years I was the de facto watchdog of the Go toolchain’s speed and have spent countless hours working on it.) Poking around a bit, I found that a substantive chunk of time was spent opening and parsing JavaScript files containing a bunch of data.

“No way,” I thought. So I ran an experiment.

I created two sets of files, containing the same data, an NxM map. One was all the code in a single JavaScript file, like this:

module.exports={"k0":{"j0":0},"k1":{"j0":0}};

The other was split across N JavaScript files:

module.exports={"k0":require("./sub/k0"),"k1":require("./sub/k1")};

where, e.g., sub/k0 is:

module.exports={"j0":0};

Then instead of N=2 and M=1, I set N=1000 and M=100, and executed the two.

On my M1 mac, with all files in the page cache, going from many files to one was considerably faster:

name  old time/op         new time/op         delta
Exec          111ms ± 1%           59ms ± 1%  -46.53%  (p=0.000 n=9+8)

name  old user-time/op    new user-time/op    delta
Exec          113ms ± 1%           51ms ± 1%  -54.62%  (p=0.000 n=10+9)

name  old sys-time/op     new sys-time/op     delta
Exec         17.5ms ± 2%          5.8ms ± 3%  -66.67%  (p=0.000 n=9+8)

Since the data files I was looking at today are autogenerated anyway, it would make sense to generate one big file instead of lots of little ones, even though it’s a bit less nice that way.

Some facts don’t change: An interpreted language must still stat, open, and parse each file, and that has overhead.

And it’s not just opening the file! /usr/bin/time -l on a mac now prints an “instructions retired” count, which is awesome. Spreading the data across many files causes over twice as many instructions to be executed. It also increases the peak memory footprint by 15%.

C++

It’s not just interpreted languages! Compiled languages are also sensitive to the apparently unimportant detail of how your code is organized into files.

At my first startup, card.io, I was doing computer vision and machine learning on underpowered mobile devices. The heavy computational work was in a bunch of C++ files. On a (somewhat educated) lark, I preprocessed all the files into a single giant input file. Lo! The code got a lot faster.

The compilation unit (what a single invocation of the compiler works on) of C/C++ is a file. By placing all the code in a single compilation unit, the compiler could see more of the code at one time and thus optimize it much more. I didn’t even bother grumbling. I just added the preprocessor to our build system and moved on.

Link-time optimization has improved the situation some since then, because it provides the opportunity to optimize across compilation units. But that comes at a steep cost. The results of compilation can be cached, but linking must be done every time, so LTO slows down builds.

Go

Go mostly gets this right.

The compilation unit of Go is a package, which can contain multiple files. Moving code around between those files has no impact on performance.

What about moving code around between packages, though? Perhaps surprisingly, there are very few cases in which this matters.

When compiling a package, the Go compiler emits information about optimizations (mostly inlining and escape analysis) that will be useful when compiling code that imports that package. So moving code around between packages typically has no impact at all.

As far as I know, this has never been written down as a formal design decision for the language, but it comes up occasionally in discussion.

One hard problem in compiler design is phase ordering. Here’s an example. Should it do inlining before or after dead code elimination?

Obviously, compilers should inline before dead code elimination, because inlining will often cause code to be provably dead. (Imagine code like if debug() { ... } and func debug() bool { return false }.)

Obviously, compilers should do dead code elimination before inlining, because dead code elimination will provide a clearer picture of the true complexity and size of a function, which is important for making good inlining decisions.

Hmmm. Obviously, compilers should apply optimizations in a loop until they reach a fixed point. What could go wrong?

The Go compiler does inlining early. But the part where it emits information for subsequent compilations occurs very late. We could have the best of both worlds: We could inline early intra-package, but make better inter-package inlining decisions by using information that wasn’t available earlier.

However, this could incentivize programmers to warp the structure of their code to get different optimization results. And that is a showstopper, at least for Go.

Go’s definitely not perfect. For example, its lackluster inlining heuristic (and lack of an pressure release valve) causes programmers to mangle their code. But that’s considered a bug. And it’s slightly off-topic for this post.

Moral

The moral of this story is not that Go is superior, although I am obviously fond of it; there are complex trade-offs here.

People like to say things like “tools don’t matter” and “tools are just a way to get the job done”. I disagree.

Our tools generate incentives that end up warping how we do our jobs, in ways subtle (code organization, dependency culture) and not-so-subtle (formatting flame wars, hallway sword fights).

Programmers should pick their tools carefully. And tool authors should think hard about the incentives they create.

How to test a Go beta or RC

Sun, 13 Jun 2021 08:12:48 -0700

Around this time in the Go release cycle, the Go team asks people to test Go betas and release candidates.

Please help! It is easy, fast, and important.

This post is about how, what, and why to test.

Installation

Pre-releases can be downloaded using go get. For example:

$ go install golang.org/dl/go1.17beta1@latest
$ go1.17beta1 download
$ go1.17beta1 test your/favorite/package

A complete list of pre-releases is available at https://pkg.go.dev/golang.org/dl.

Betas

Betas are early looks at a new release. They sometimes have known bugs. Critical bugs are uncommon but not unheard of. New APIs may still change in response to feedback. You should not use a beta release in production.

Here’s what you should do with a Go beta release, ordered from easy and fast to pretty involved. Even if you only do the first item or two, it is helpful!

Run your tests locally. Investigate and report any new failures.
Read the draft release notes. (You may have to edit this link appropriately for newer releases.) If you see anything concerning, file an issue to discuss.
Run your benchmarks locally. Investigate and report performance regressions.
If you have a staging server, CI, or anywhere you can run more involved tests, use the pre-release version there, and file any issues you encounter.
Look over the API diffs. (Again, adjust link as appropriate.) If you see anything concerning, file an issue to discuss.

Release candidiates

Release candidates are generally free of known serious bugs. (Google tests release candidates on their live servers.) APIs should be stable.

The list of things to do with a Go RC is the same as with betas, except that, if you have the bandwidth and means, you may want to try running it in production, on a small subset of servers.

I don’t have that much time

It is not atypical to have one or two betas and one or two RCs. That’s a lot of testing. What if you only have a small amount of time to contribute to helping Go have bug-free releases?

If you can only do one thing, run your tests locally using the first beta. It takes just a few minutes. The earlier bugs get caught, the more likely it is they can be fixed, and fixed well.

If you can do a little bit more, please read the release notes early. You’d probably read them when the release came out anyway. By reading it early, there’s still a chance of fixing any problems you see.

Why test betas and RCs?

Programming languages, and their tooling and communities, are complex creatures. People use them in marvelous and unusual ways. And programming languages are software too, and you know what that means. Despite the Go contributors’ best efforts, the Go issue tracker has its fair share of frustrated programmers who have discovered too late that a new release doesn’t work for them: a subtle behavior change, a rare performance regression, an API design that is not quite right.

Once a release is out, fixing these problems becomes harder and sometimes even impossible. Security problems get prompt fixes, but anything short of that, even a critical bug, won’t see a fix for a month, at the next point release. Non-critical bugs won’t be fixed until the next full Go release, six months out, at the earliest. And in many cases, thanks to the Go 1 Compatibility Promise, we may simply be stuck forever with whatever the problem is.

Betas and RCs are our only chance as a community to catch many issues while there’s still time to really fix them.

Bonus

Consider adding the “tip” version of Go to your CI. This is especially helpful in catching problems very early, but it does add a fair bit of work: Before filing issues, you need to check the build dashboard and investigate a bit to determine whether any failure is worth reporting.

Make your lookup table do more

Thu, 03 Jun 2021 10:00:00 -0700

Lookup tables are powerful micro-optimization tools, because they implement arbitrary transformations in cheap constant time.

And yet we often do not use them to their full potential. This post is the story of one example.

A good starting point

In a recent blog post, Daniel Lemire rediscovered a technique for calculating the base ten length of a uint32. Start by calculating integer log2(x), do an approximate integer division to translate log2(x) to log10(x), and then fix up the result as needed.

His code, with some annotations:

static uint32_t table[] = {
	9, 99, 999, 9999, 99999, 999999,
	9999999, 99999999, 999999999,
};
int y = (9 * int_log2(x)) >> 5; // log10(2) ~= 0.301, 9/32 ~= 0.281
y += x > table[y]; // use lookup table to discover off-by-one due to using integer math
return y + 1;

The initial calculation gets us close to the right answer. The lookup table steps in to handles numbers like 9 and 10. log2(9) is equal to log2(10), so we need some way to distinguish them. 9 * log2(x) >> 5 yields 0 for both 9 and 10. Comparing x to table[0] tells us to increment the result for 10, but not for 9. Then we increment again, yielding the correct result: 1 for 9, 2 for 10.

But lookup tables let us do arbitrary transformations, and we’re getting only a single bit out of it: Increment or not. For example, maybe we could work that increment at the end of the function into the lookup table somehow. (Yes, that increment is free on amd64 architectures with a good enough compiler by using the ADC instruction.)

Some groundwork

If we used a lookup table to modify the original input, then we would be in a better place to absorb some of the later work. For any given power of two range (e.g. 8–15), there is at most one transition from an n digit number to an n+1 digit number. For the range 8–15, that transition is from 9 to 10. For the range 16–31, there isn’t one.

My first attempt at using this observation was to use a lookup table to translate base 2 transitions (7 to 8) to line up with base 10 transitions (9 to 10).

My code:

static uint32_t table[] = {
	0, 0, 0, (1<<4) - 10,
	0, 0, (1<<7) - 100,
	0, 0, (1<<10) - 1000,
	0, 0, 0, (1<<14) - 10000,
	0, 0, (1<<17) - 100000,
	0, 0, (1<<20) - 1000000,
	0, 0, 0, (1<<24) - 10000000,
	0, 0, (1<<27) - 100000000,
	0, 0, (1<<30) - 1000000000,
	0, 0,
};
x += table[int_log2(x)]; // adjust input to align base 2 and base 10 transitions
int ans = (77*int_log2(x)) >> 8; // log10(2) ~= 0.301, 77x/256 ~= 0.301
return ans + 1;

Consider the inputs 9 and 10. We start with integer log2, which yields 3 in both cases. Then we add table[3], which is 6. This transforms 9 and 10 into 15 and 16. Now if we take the integer log2 again we get 3 and 4. Integer division and an increment yields the correct result (1 and 2).

This doesn’t actually reduce any of the other post-lookup-table work, but it sets us up to do so.

Note that the table has grown from 9 uint32s to 32 uint32s. This is probably acceptable.

A small step

The next iteration looks like this:

static uint64_t table[] = {
	16, 14, 12, 246, 240, 224, 3996, 3968, 3840,
	64536, 64512, 63488, 61440, 1038576, 1032192,
	1015808, 16677216, 16646144, 16515072, 267435456,
	267386880, 266338304, 264241152, 4284967296,
	4278190080, 4261412864, 68619476736, 68585259008,
	68451041280, 1098511627776, 1098437885952,
	1097364144128,
};
uint64_t n = (uint64_t)(x) + table[int_log2(x)];
return int_log2(n) >> 2;

The non-lookup calculations here have gotten simpler. The table is a lot more complex, but that’s OK. That complexity is computationally free! The table has also grown again, from 32 uint32s to 32 uint64s. If speed matters, this is probably acceptable. (And if it doesn’t matter, go implement something obvious instead.)

The basic idea is the same as before. Add an offset to each base 2 range to translate base 2 transitions onto base 10 transitions. But now we also tack on extra amounts to make our post-lookup calculations computationally cheaper: a single shift, instead of a multiply, a shift, and an increment. Adding table[3] to 9 and 10 make them 255 and 256. log2(255) / 4 is 1 and log2(256) / 4 is 2, as desired.

A great leap

That’s where I left it. Then Kendall Willets stepped in and made a marvelous leap. The code below is from Daniel Lemire’s follow-up blog post laying out Kendall’s approach:

static uint64_t table[] = {
      4294967296,  8589934582,  8589934582,
	  8589934582,  12884901788, 12884901788,
	  12884901788, 17179868184, 17179868184,
	  17179868184, 21474826480, 21474826480,
	  21474826480, 21474826480, 25769703776,
      25769703776, 25769703776, 30063771072,
	  30063771072, 30063771072, 34349738368,
	  34349738368, 34349738368, 34349738368,
	  38554705664, 38554705664, 38554705664,
	  41949672960, 41949672960, 41949672960,
      42949672960, 42949672960,
};
return (x + table[int_log2(x)]) >> 32;

Lookup tables can implement arbitrary functions! Kendall embeds two pieces of information in a uint64: the integer log10 for that base 2 range in the top 32 bits and the transition translation (if any) in the bottom 32 bits. The table is eye-watering, but your CPU doesn’t care.

Consider 9 and 10 again. table[3] is 8589934582, which is (2<<32) - 10. Adding 9 and 10 to that yields (2<<32) - 1 and 2<<32. If we now shift right 32 bits, this yields 1 and 2 respectively. Voilà!

We now require only an integer log2, a table lookup, an addition, and a shift. Not bad.

My three takeaways:

Lookup tables implement arbitrary transformations at a constant cost. If you have one in your code, it’s worth asking whether it can do more work for you.
Open collaboration can be delightful, with thoughtful people. Three people’s combined insights and refinements broke new ground (I believe) on an old question. I’m not sure any of us would have gotten there alone.
This is an existence proof that there are websites on the internet where it’s worth reading the comments.

What happens when you load into x0 on RISC-V?

Wed, 17 Feb 2021 10:00:00 -0700

A small thing of which I am irrationally proud: I was the proximate cause for the addition of a sentence to the RISC-V ISA spec.

Here’s the sentence:

Loads with a destination of x0 must still raise any exceptions and cause any other side effects even though the load value is discarded.

It’s OK if you have no idea what that means. You will soon.

Here’s the story.

Background

In the summer of 2016, I wrote most of the initial RISC-V Go compiler implementation. (Michael Pratt and Benjamin Barenblat worked on the assembler, linker, and runtime, and other people jumped in and ultimately completed the port.)

I was writing the first version of the RISC-V SSA lowering rules. Those rules turn a generic, architecture-independent description of Go code into a RISC-V-specific set of operations that ultimately get lowered into RISC-V instructions.

One of those lowering rules specified how to lower a nil check.

Nil checks in the Go compiler

Consider this code:

type T struct {
    a [5000]byte // we'll explain this later
    b bool
}

func f(t *T) {
    _ = t.b
}

f does almost nothing. But not nothing. f evaluates t.b for side-effects. If t is nil, f panics.

In the Go compiler, this is (unsurprisingly) called a nil check. The compiler arranges to execute an instruction that will fault if t is nil.

On amd64, f compiles to three instructions:

MOVQ	"".t+8(SP), AX

Get the value of t off of the stack and put it in the AX register.

TESTB	AL, (AX)

Load the value pointed to by AX and do something with it. The parens around AX mean dereference the pointer in the AX register. It doesn’t matter here what the TESTB instruction does; it was chosen because it is short to encode. It’s the deferencing that matters. If the load faults, the runtime will receive a signal and turn that into a panic.

RET

Return from the function. We only reach this instruction if we don’t panic first.

Implicit nil checks

Why does type T above contain a [5000]byte field?

There are lots of nil checks in a typical Go program. As an optimization, the runtime allocates a guard page at address 0, typically with size 4096 bytes. Any loads from an address < 4096 will fault.

As a result, if you’re dereferencing a struct field with a small offset, we can directly attempt to load from the calculated address of that struct field. If the pointer is zero, then the calculated address will be < 4096, and it’ll fault. There’s no need for a separate, explicit nil check.

For example, if I had used [20]byte above, then *t.b requires loading from t plus 20. If t is nil (0), then that address is 20, which is located in the guard page.

Since we have a [5000]byte field above, the guard page isn’t enough, so we need an explicit nil check.

This makes it sounds like explicit nil checks are exceedingly rare. They’re not; they show up in other ways too.

Back to RISC-V

I had to decide how RISC-V should lower explicit nil checks.

RISC-V has a dedicated zero register, x0. It always holds the value zero, and writes to it are discarded. It’s like /dev/null and /dev/zero rolled into one.

It sounds like just the thing for a nil check: We can derefence the pointer and load the value into x0.

Here’s f, compiled for RISC-V:

LD	"".t+8(SP), X3
LB	(X3), X0
JALR	X0, X1

It is almost identical to the amd64 version. The first instruction loads the pointer from the stack. The second instruction dereferences it into x0. The final instruction returns.

There was only one problem: Would it work?

An ambiguity in the spec

If you’re loading a value in order to discard it, do you really need to load it at all? if you’re writing to x0, maybe you can just skip it.

There is an analog from amd64. The CMOV instruction does a conditional move. If a flag is set, then it loads or moves a value, and not otherwise. It shows up when compiling code like this:

func g(x int) int {
	y := 1
	if x == 0 {
		y = 3
	}
	return y
}

The core of this function compiled for amd64 is:

TESTQ	AX, AX
MOVL	$1, AX
MOVL	$3, CX
CMOVQEQ	CX, AX

TESTQ sets the EQ flag if x is 0. The next two instructions put 1 in AX and 3 in CX. Last, if the EQ flag is set, we move CX into AX. AX now holds the correct value of y to return.

If a CMOV instruction includes a load from memory, that load is done unconditionally, even though the write of that value into the destination register is conditional.

I knew (and know) approximately nothing about hardware, but I can guess why this is a good decision. If you’re doing out of order execution, you might not know yet what the flags are going to be when you reach that CMOV instruction. But memory loads are slow. We want to start that memory load early for maximum benefit. So it is useful to be able to do the load unconditionally, even if it is inconvenient for compiler developers.

But the same consideration doesn’t really apply to RISC-V. There’s no uncertainty about whether the instruction writes to x0. Skipping the load would be easy and cheap.

Denouement

I asked my co-conspirators, and one of them asked Andrew Waterman.

He replied:

We debated this hole in the spec at length, but neglected to write down the conclusion.

The main reason we went with this definition is cleaner semantics for memory-mapped I/O loads that trigger side effects. The opposite choice is also defensible (it gives you a non-binding prefetch instruction for free).

Light-years ahead of me, unsurprisingly. But convenient for Go’s nil checks. And me having asked did help tie up one little loose end.

git rebase --fork-point considered harmful (by me)

Mon, 02 Nov 2020 09:12:48 -0700

This is the first blog post I’ve written that isn’t about Go, and it’s pretty weedy. Feel free to stop reading now.

This is a git experience report based on something that bit me hard today, despite being quite experienced with git. Play along!

Prologue

Initialize a repo. Create two commits.

$ git init .
Initialized empty Git repository in <redacted>

$ touch readme
$ git add readme
$ git commit -a -m "initial commit"
[main (root-commit) ac2d8e7] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 readme

$ touch readme.2
$ git add readme.2
$ git commit -a -m "another commit"
[main fb0f7fe] another commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 readme.2

So far, pretty mundane. Here’s what the repo looks like:

$ git log --all --decorate --oneline --graph
* fb0f7fe (HEAD -> main) another commit
* ac2d8e7 initial commit

Oops

I meant to create readme.2 on a branch. No problem. Let’s create that branch now.

$ git checkout -b branch
Branch 'branch' set up to track local branch 'main' by rebasing.
Switched to a new branch 'branch'

Oh, and better put main back where it belongs.

$ git checkout main
Switched to branch 'main'
$ git reset --hard HEAD~1
HEAD is now at ac2d8e7 initial commit

Now the repo looks like this:

$ git log --all --decorate --oneline --graph
* 95cc2c0 (branch) another commit
* 20a231b (HEAD -> main) initial commit

Bug fix

Let’s fix a bug on main.

$ echo "nothing to see here" > readme
$ git commit -a -m "fill out the readme"
[main eebece5] fill out the readme
 1 file changed, 1 insertion(+)

Now main and branch have diverged a bit.

$ git log --all --decorate --oneline --graph
* eebece5 (HEAD -> main) fill out the readme
| * fb0f7fe (branch) another commit
|/  
* ac2d8e7 initial commit

Time to rebase

Let’s get branch rebased onto main.

$ git checkout branch
Switched to branch 'branch'
Your branch and 'main' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

Before reading any further, stop. Summon your git fu. What will happen when we run git rebase?

If you’re like me, you expect something like this:

* 7a8805e (HEAD -> branch) another commit
* eebece5 (main) fill out the readme
* ac2d8e7 initial commit

Three commits. branch has been rebased on top of main, so it is one commit ahead of it.

OK, let’s find out what really happens.

$ git rebase
Successfully rebased and updated refs/heads/branch.

Moment of truth.

$ git log --all --decorate --oneline --graph
* eebece5 (HEAD -> branch, main) fill out the readme
* ac2d8e7 initial commit

There are only two commits. branch and main are on the same commit.

What happened to the third commit? It’s gone.

Denouement

What happened was --fork-point.

The first step to a rebase (and many other operations) is to find a merge base. This is some shared commit in history, common ground from which to trace divergent paths.

The most obvious way to find a merge base is by looking at the graph for the most recent commit reachable by everyone.

But inspecting the graph doesn’t always get you the ideal result. What if you intentionally abandoned some commits on main? Looking just at the graph to find the merge base might accidentally resuscitate them. There’s a fully worked example in the git docs.

The --fork-point flag is a clever attempt to work around this. git rebase describes it thus:

Use reflog to find a better common ancestor between upstream and branch when calculating which commits have been introduced by branch.

The git reflog is a log of changes made to git refs. (If you don’t know what a “ref” is, substitute the word “branch”.) It’s meta version control. It tracks what you did with your version control over time.

The reflog is quite useful if you make a horrible mistake. You can poke through the reflog to find a lost commit.

--fork-point looks through the temporal history of your git repo to pick a merge base, “allowing you to replay only the commits on your topic, excluding the commits the other side later discarded.” In this context, “later” really means later in time, not “descendent of” in abstract git graph world.

And here we have the explanation for what happened. I discovered I had committed on main by accident, and reset main to the previous commit. From --fork-point’s perspective, the main branch had discarded the commit on branch. Therefore it was not included when we selected a merge base to rebase branch onto main.

What’s wrong here?

To my mind, two things went wrong here.

--fork-point assumes that discarded commits were discarded because they were unwanted. But that is not always true. In my case, they were discarded because they were unwanted at that moment. Adding more clever heuristics might help some here, but I suspect it’s impossible to infer intent, which is what is required.

The bigger issue is that the behavior of git rebase now depends on (almost) invisible, inscrutable state. The ability to mentally model what a command will do is critical to being able to use any tool. It’s pretty easy to view a git graph; it is the default view for most git UIs. And it’s not too hard as a human to pick out the topological merge base from there. The reflog is all but invisible. And it is definitely not easy for a human to process.

The fix

The solution is obviously more flags. My git config’s [alias] section now includes r = rebase --no-fork-point.

Generating safer Go code

Wed, 28 Oct 2020 09:12:48 -0700

It’s easy to forget to call go generate when you need to. Failure to regenerate can mean nasty bugs.

Venerable gopher Rog Peppe found an excellent technique for guarding against this class of bugs. Like many good ideas, it is obvious in retrospect.

Generate code that will not compile if needs to be regenerated.

I’ll illustrate this with two examples.

stringer

The first example comes directly from Rog, in the stringer command. stringer generates a String() string method for integer types that have defined constants.

type T int

const (
    One T = 1
    Two T = 2
)

stringer will generate a method that returns "One" for 1, "Two" for 2, and "T(3)" for 3.

What if you now change the value of One to be 3 and forget to re-generate?

Well, stringer also generated this function:

func _() {
	var x [1]struct{}
	_ = x[One-1]
	_ = x[Two-2]
}

The function is named _, which means it is impossible to call it. The compiler won’t even bother generating code for it. It will, however, typecheck it. And typechecking is where the magic happens.

When the value of One is 1, x[One-1] evaluates to x[0]. Since x has length 1, that’s OK.

When the value of One is 3, x[One-1] evaluates to x[2]. But x only has length 1! Attempts to compile this generate a compiler error: invalid array index One - 1 (out of bounds for 1-element array).

The function recorded the values of the constants when stringer was run and fails to compile if those values change.

cloner

Now that we know the trick, we can apply it elsewhere.

Tailscale has a little bespoke tool to generate Clone methods for structs.

The output of cloner depends on the input struct fields. How can we trigger a compilation failure if we forget to re-run the tool after changing an input struct?

The trick is to duplicate the original struct in the generated code and then attempt to convert from the original struct to the current struct.

We start with this input code:

type T struct {
	X int
}

After generating a Clone method for T, cloner also generates:

var _ = T(struct {
	X int
}{})

Here we’ve written out the exact form of T when we generated the code, and assigned it to _, which the compiler can discard. However, it still must be typechecked.

Suppose we now change the type T. Let’s add a new field.

type T struct {
	X int
	Y string
}

The conversion now fails: It’s not possible to convert a struct { X int } to a struct { X int; Y string }.

Similar to stringer, cloner recorded the types when cloner was run and now fails to compile if those types change.

Compile-time assertion taxonomy

We’ve seen two forms of assertions that can trigger during typechecking: x == y and a struct’s fields are unchanged.

There are others. For example, you can use conversions to assert that a type implements an interface. You can use conversion to uint to assert that one untyped constant is greater than or equal to than another. (You can’t convert a negative constant to uint.)

There are some obscure ones, of questionable utility. For example, you could assert that two concrete types are distinct by putting them both as cases in a type switch, which disallows duplicate types.

I don’t know of any attempt to exhaustively list compile-time assertions (aside from the spec) and how they can be used, with examples. Someone please make one!

Matthew Dempsky has proposed that Go add explicit compile time assertions for boolean expressions. (That doesn’t cover relationships between types, although maybe generics would break some new ground here.) And I’ve written about a quirky way that you can write link-time assertions in Go.

Call to action

If you maintain a code generator, please check whether you can use this technique to protect your users from bugs. One obvious category is generated serialization/deserialization routines. There are almost certainly others.

Discovering alloc size classes in Go

Tue, 01 Sep 2020 09:12:48 -0700

As of Go 1.15, the Go runtime’s memory allocator doesn’t always allocate exactly the number of bytes required for an object. Instead, it rounds up to the nearest size class.

type T struct {
    i int64
    b byte
}

Type T has a size of 9 bytes, but allocating a T will use 16 bytes.

If you’re trying to reduce the memory usage of a program that allocates a lot of one particular type of object, it’s good to be aware of the size classes, as the impact of shrinking the object will be a step function.

What are the size classes?

The easiest way to find out the size classes is to read the source.

It’s also possible to discover them at run time!

The trick is to use append. append gets to choose the capacity of the returned slice. And, as you would hope, append is aware of the allocator; it picks a cap that fills as much as possible of the size class it selected.

We are going to start with a nil slice, cap 0. We will then append n bytes to it. append will helpfully round n up to the nearest size class as the new cap.

func sizeup(n int) int {
	b := append([]byte(nil), make([]byte, n)...)
	return cap(b)
}

If you run this in a loop, you get a nice size class list. In the unlikely event that you were going to do this in a real program, you’d probably calculate the size classes at startup and cache them.

This technique relies on an implementation detail, but hey, the mere existence of size classes is also an implementation detail.

Who cares?

In particularly performance sensitive code, it sometimes makes sense to overallocate a slice, to avoid allocation in subsequent appends, such as in math/big. When deciding how much to overallocate, you might want to be size-class aware, so as not to waste capacity that is effectively free. See #24204 for interesting related discussion.

And there’s an interesting generics connection. People are fond of pointing out that generics would obviate the need for append. You could implement it yourself. But if you want your custom append to be as optimized as the runtime’s, you need to be aware of the size classes.

Why not hard-code the size classes?

They change.

Hard-coding the size classes, per-release, behind build tags, is a fine idea. But they’re also pretty easy to calculate.

Life without line numbers

Thu, 30 Apr 2020 08:12:48 -0700

If you are desperate for 6% smaller Go binaries, this blog post is for you. (I did this experiment to help out Tailscale. Disclosure: I’m an investor.) If binary size doesn’t worry you, well, maybe you’ll find it entertaining.

In order to get example numbers for this post, I grabbed a random item from my GOPATH. All the hard numbers in this blog post are for github.com/mvdan/sh/cmd/shfmt. From a bit of experimenting, they seem fairly representative.

I am using commit 9d812cfa5c of the Go toolchain as my base commit. This is the master branch as of April 29, 2020; it will probably be similar to the Go 1.15beta1 release. I’m using it rather than Go 1.14 because it contains several binary size reductions, including one in particular that you’ll definitely want if you’re concerned about binary sizes.

There are lots of ways to shrink a binary. Removing extraneous dependencies is probably the best way. Avoiding global maps through judicious use of sync.Once can help. Keeping separable code separate by indirection can help. You can suppress equality algorithm generation (ick…until you really need it). You can usually save double-digit percentages by stripping debugging information: pass -ldflags=-w to go build.

Let’s assume you’ve done all that. And you still need to shrink more. And that need is so pressing you’re willing to make some sacrifices for it.

Go binaries contain a lot more than just executable code. There are type descriptors that describe the types in a Go program. There are garbage collection data structures. There’s debugger information. And there are mappings from PCs to position information. (And there’s lots more, too.)

We’re going to get rid of the position information.

We can’t just strip out the position information entirely from the binary. That would break lots of stuff.

But we can make all the line numbers the same. That shouldn’t break anything. After all, no one (except gofmt) said we had to put our code on multiple lines.

For example, instead of this:

package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hello, playground")
}

We could write this:

package main

import ( "fmt" ); func main() { fmt.Println("Hello, playground") }

The Go compiler and runtime has to be prepared for lots of stuff to be on one line.

We could write a preprocessor, maybe using -toolexec and //line directives, but it’s easier to just hack the compiler. Fortunately, this is well-factored code, so we only need to touch two little spots.

--- a/src/cmd/compile/internal/syntax/pos.go
+++ b/src/cmd/compile/internal/syntax/pos.go
@@ -23,3 +23,3 @@ type Pos struct {
 // MakePos returns a new Pos for the given PosBase, line and column.
-func MakePos(base *PosBase, line, col uint) Pos { return Pos{base, sat32(line), sat32(col)} }
+func MakePos(base *PosBase, line, col uint) Pos { return Pos{base, 1, 1} }
 
@@ -101,2 +101,3 @@ type PosBase struct {
 func NewFileBase(filename string) *PosBase {
+       filename = "x.go"
        base := &PosBase{MakePos(nil, linebase, colbase), filename, linebase, colbase}

Every file is now named x.go, and every source position has line 1 and column 1. (Columns don’t actually matter for binary size, once you’ve stripped DWARF.)

This isn’t quite enough. There are two other spots in the toolchain that get unhappy if all code lives at x.go:1:1.

The first is in constructing DWARF, for debuggers. We can just remove that check: We are already stripping DWARF, so generating invalid DWARF doesn’t matter.

The second is in cgo. There are some security checks about where certain cgo pragma can be located. We’re going to trust ourselves not to violate them (by ensuring all code keeps building with an unaltered toolchain), and remove that security check.

The full diff is at https://github.com/josharian/go/commit/1a3e66ceed.

Now all code we compile has x.go:1:1 as its position.

Our program, compiled with -ldflags=-w, shrinks from 3,126,800 bytes to 2,938,384 bytes, or about 6%.

Most of this is from shrinking the encoding of position information. A little bit of it comes from a compiler optimization.

These two programs compile slightly differently:

func f(x []byte) {
    _ = x[0]
    _ = x[1]
}

func f(x []byte) {
    _, _ = x[0], x[1]
}

If you run go tool compile -S x.go on each of these files, you’ll see that the first program contains two separate calls to runtime.panicIndex. The second program contains only one such call. The reason is that runtime.panicIndex must display a backtrace containing the line number of the line that panicked. In the first program, we need two separate panics, one for each possible panicking line number. In the second program, we don’t, so the compiler combines them.

Since we are now putting all code on the same line, the compiler can combine more panics than before.

What do we lose by doing this? Anything that needs accurate position information. Panic backtraces will still show you the PC, the function, the arguments, and so on. But all line numbers will be x.go:1. With patience, you could still figure out the line number yourself based on the PC, but it’d take some manual work. Pprof will still be able to analyze performance by function and by instruction, but it’ll think everything happens on the same line, which will make analysis by line number useless.

Let’s play around a bit. What if we ditch only filenames, and keep the true line numbers? It saves only 0.9%. And as you’d then expect, keeping only accurate filenames and making all line number 1 saves 5.1%.

So most of the savings are from the line numbers. What if we keep the original filenames, and truncate all line numbers to the nearest multiple of 16? That is, trim our diff down to:

--- a/src/cmd/compile/internal/syntax/pos.go
+++ b/src/cmd/compile/internal/syntax/pos.go
@@ -23,3 +23,3 @@ type Pos struct {
 // MakePos returns a new Pos for the given PosBase, line and column.
-func MakePos(base *PosBase, line, col uint) Pos { return Pos{base, 1, 1} }
+func MakePos(base *PosBase, line, col uint) Pos { return Pos{base, sat32(line/16*16 + 1), 1} }

This cuts our binaries by 2.2%. Not bad. What if we divide all line numbers by 16 instead? That preserves exactly the same information as truncating, but we have to multiply by hand to get the “nearby” line number.

--- a/src/cmd/compile/internal/syntax/pos.go
+++ b/src/cmd/compile/internal/syntax/pos.go
@@ -23,3 +23,3 @@ type Pos struct {
 // MakePos returns a new Pos for the given PosBase, line and column.
-func MakePos(base *PosBase, line, col uint) Pos { return Pos{base, 1, 1} }
+func MakePos(base *PosBase, line, col uint) Pos { return Pos{base, sat32(line/16 + 1), 1} }

This cuts our binaries by 2.75%! Why does /16 save 0.5% more than /16*16?

Line numbers are stored in the binary using a varint encoding relative to the previous line number. Smaller numbers mean smaller deltas, and can thus be stored more efficiently.

Interning strings in Go

Tue, 17 Dec 2019 08:12:48 -0700

This blog post covers string interning in Go.

What is a string?

In Go, a string is a (possibly empty) immutable sequence of bytes. The critical word here for our purposes is immutable. Because byte slices are mutable, converting between string and []byte generally requires an alloc and copy, which is expensive.

Under the hood, strings in Go are (currently) represented as a length and a pointer to the string data.

What is string interning?

Consider this code:

b := []byte("hello")
s := string(b)
t := string(b)

s and t are strings, so they both have a length and a data pointer. Their lengths are obviously the same. What about their data pointers?

The Go language doesn’t provide us a direct way to find out. But we can sniff around with unsafe:

func pointer(s string) uintptr {
    p := unsafe.Pointer(&s)
    h := *(*reflect.StringHeader)(p)
    return h.Data
}

(This function ought to return an unsafe.Pointer. See Go issue 19367.)

If we fmt.Println(pointer(s), pointer(t)), we get something like 4302664 4302632. The pointers are different; there are two separate copies of the data hello.

(Here’s a playground link if you want to experiment. What happens if you change "hello" to just "h"? Explanation.)

Suppose you wanted instead to re-use a single copy of the data hello? That’s string interning. There are two advantages to interned strings. The obvious one is that you don’t need to allocate and copy the data. The other is that it speeds up string equality checks. If two strings have the same length and same data pointer, they are equal; there is no need to actually examine the bytes.

As of Go 1.14, Go doesn’t intern most strings. Interning, like any form of caching, also has costs: synchronization for concurrency safety, garbage collector complexity, and extra code to execute every time a string is created. And, like caching, there are cases in which it is harmful rather than helpful. If you were processing a list of dictionary words, no word would ever occur twice, so interning strings would be waste both time and memory.

Manual string interning

It is possible to manually intern strings in Go. What we need is a way to look for an existing string to re-use given a byte slice, perhaps using something like a map[[]byte]string. If a lookup succeeds, we use the existing string; if it fails, we convert and then store that string for future use.

There’s only one problem: You can’t use []byte as a map key.

Thanks to a long-standing compiler optimization, we can use a map[string]string instead. The optimization is that map operations whose key is a converted byte slice don’t actually generate a new string to use during the lookup.

m := make(map[string]string)
b := []byte("hello")
s := string(b) // allocates
_ = m[string(b)] // doesn't allocate!

(A similar optimization applies in other scenarios in which the compiler can prove that a converted byte slice doesn’t get modified during use, such as switch string(b) when all switch cases are free of side-effects.)

The entirety of the code required to intern strings is this:

func intern(m map[string]string, b []byte) string {
    // look for an existing string to re-use
    c, ok := m[string(b)]
    if ok {
        // found an existing string
        return c
    }
    // didn't find one, so make one and store it
    s := string(b)
    m[s] = s
    return s
}

Pretty simple.

Complications

Note that this manual interning routine pushes the problems with interning into the calling code. You need to manage concurrent access to the map; you need to decide the lifetime of the map (and thus everything in it); and you need to pay the extra cost of a map lookup every time you need a string.

Pushing these decisions onto the calling code can yield better performance. For example, suppose you were decoding json into a map[string]interface{}. The json decoder is probably not concurrent. The lifetime of the map can be tied to the json decoder. And the keys of this map are likely to be repeated frequently, which is the best case scenario for string interning; it makes the extra cost of the map lookup worth it.

A helper package

If you don’t want to have to think about any of these complications, and are willing to accept the slight concomitant loss of performance, and have code in which string interning may help, there’s a package for that: github.com/josharian/intern.

It works by horribly abusing sync.Pool. It stores interning maps in a sync.Pool, retrieving them as needed. This neatly solves the concurrent access problem, because sync.Pool access is concurrency-safe. It mostly solves the lifetime problem, because the contents in a sync.Pool are usually eventually garbaged collected. (For related reading about managing lifetimes, see Go issue 29696.)

testing.B.ReportMetric

Wed, 03 Jul 2019 18:07:05 -0800

My favorite new API in Go 1.13 is testing.B.ReportMetric. It allows you to report custom metrics from within your benchmarks.

When the API was proposed, the motivating example was package sort. The package sort benchmarks, like all benchmarks, measure elapsed wall time and (optionally) allocations. But wall time measurements can be noisy, and the sort routines don’t allocate much. There is another really useful algorithm-level metric for a sorting routine: How many comparisons does it perform?

Let’s use our new to API find out. Here’s a simple sort benchmark.

package demo

import (
	"sort"
	"testing"
)

func BenchmarkSort(b *testing.B) {
	data := make([]int, 1<<10)
	b.ResetTimer() // ignore big allocation
	for i := 0; i < b.N; i++ {
		for i := range data {
			data[i] = i ^ 0x2cc
		}
		b.StartTimer()
		sort.Slice(data, func(i, j int) bool {
			return data[i] < data[j]
		})
		b.StopTimer()
	}
}

(Aside: Some of the sort benchmarks in the standard library allocate inside the loop. Oops. Carefully fixing this might make a nice first contribution for someone wanting to try their hand at the Go standard library.)

On my machine, executing this looks like:

$ go test -bench=. -count=5
goos: darwin
goarch: amd64
pkg: github.com/commaok/blog/content/post
BenchmarkSort-8   	   19536	     60568 ns/op
BenchmarkSort-8   	   19666	     60592 ns/op
BenchmarkSort-8   	   19569	     60674 ns/op
BenchmarkSort-8   	   19724	     61363 ns/op
BenchmarkSort-8   	   19705	     60792 ns/op
PASS
ok  	github.com/commaok/blog/content/post	11.772s

If the number of iterations looks funny to you, it’s because you are used to seeing round numbers there. That also changed in Go 1.13.

Now let’s use the new testing.B.ReportMetric API to report the number of comparisons. To do this, we need to count the number of comparisons. Then we’ll divide by b.N. The reason we must do the division ourselves is to allow metrics that aren’t naturally represented as per-op counts, such as ratios or percentiles.

Here’s the updated code, with added lines marked:

func BenchmarkSort(b *testing.B) {
	var cmps int64 // <--------
	data := make([]int, 1<<10)
	b.ResetTimer() // remove allocation
	for i := 0; i < b.N; i++ {
		for i := range data {
			data[i] = i ^ 0x2cc
		}
		b.StartTimer()
		sort.Slice(data, func(i, j int) bool {
			cmps++ // <--------
			return data[i] < data[j]
		})
		b.StopTimer()
	}
	b.ReportMetric(float64(cmps)/float64(b.N), "cmps/op") // <--------
}

Running this yields:

$ go test -bench=. -count=5
goos: darwin
goarch: amd64
pkg: github.com/commaok/blog/content/post
BenchmarkSort-8   	   18523	     69874 ns/op	     10091 cmps/op
BenchmarkSort-8   	   18654	     64621 ns/op	     10091 cmps/op
BenchmarkSort-8   	   18657	     64589 ns/op	     10091 cmps/op
BenchmarkSort-8   	   18774	     64367 ns/op	     10091 cmps/op
BenchmarkSort-8   	   18704	     64408 ns/op	     10091 cmps/op
PASS
ok  	github.com/commaok/blog/content/post	12.062s

Note that the number of comparisons is stable. This is a wonderful property when benchmarking. It means you can run your benchmarks a small number of times, without quitting your browser or trying to disable thermal scaling or worrying about how your laptop CPU may be different from your production CPUs.

Now let’s reach into the standard library and tweak something! There’s a function called maxDepth inside package sort:

// maxDepth returns a threshold at which quicksort should switch
// to heapsort. It returns 2*ceil(lg(n+1)).
func maxDepth(n int) int {
	var depth int
	for i := n; i > 0; i >>= 1 {
		depth++
	}
	return depth * 2
}

(Aside: maxDepth should probably use math/bits.Len to calculate ceil(lg(n+1)). This is another candidate for a good first contribution to the Go core.)

Let’s make maxDepth just return 0 instead and re-run our benchmark:

$ go test -bench=. -count=5 -run=NONE
goos: darwin
goarch: amd64
pkg: github.com/commaok/blog/content/post
BenchmarkSort-8   	   12618	     94792 ns/op	     17426 cmps/op
BenchmarkSort-8   	   12668	     94769 ns/op	     17426 cmps/op
BenchmarkSort-8   	   12642	     94645 ns/op	     17426 cmps/op
BenchmarkSort-8   	   12738	     94623 ns/op	     17426 cmps/op
BenchmarkSort-8   	   12654	     94431 ns/op	     17426 cmps/op
PASS
ok  	github.com/commaok/blog/content/post	12.867s

We can see that not only is it slower, but that it is clearly an algorithmic degradation: The number of comparisons has increased markedly.

benchstat supports custom metrics, so we can use it to tell us exactly how much:

$ benchstat a b
name    old time/op   new time/op   delta
Sort-8   64.5µs ± 0%   94.7µs ± 0%  +46.76%  (p=0.016 n=4+5)

name    old cmps/op   new cmps/op  delta
Sort-8    10.1k ± 0%    17.4k ± 0%  +72.69%  (p=0.008 n=5+5)

There’s one more trick worth worth mentioning. testing.B.ReportMetric generally overrides built-in metrics. If you call b.ReportMetric(5, "allocs/op"), then go test will report 5 allocs/op, regardless of how much your benchmark actually allocated. There’s one special case: ns/op. If set to 0, then ns/op won’t be reported at all. This is useful to avoid confusion or distraction if your benchmark’s elapsed time is meaningless. For example, one of the earliest uses of testing.B.ReportAlloc was for a package sync benchmark that reported garbage collector stop-the-world time, in percentiles. It is irrelevant how long it takes that benchmark to run; only the percentiles matter.

On a sad note, there’s currently no good way to get profiling tools to tell you where a particular custom metric increased.

What else could you use testing.B.ReportMetric for? Obvious use cases include cache hit rates, I/O amounts, fast path/slow path heuristics, percentile reporting, and algorithmic improvements. (We measured comparisons during sorting here; how about swaps?) I’m sure there will be non-obvious ones as well.

Compatibility: Not just about code

Wed, 06 Feb 2019 16:05:13 -0800

The Go 1 compatibility promise was designed to ensure “that Go 1 will be a firm foundation for the development of Go and its ecosystem.”

Go 2 is coming.

Ian Lance Taylor has written a masterful, thoroughly researched design document about “how to make incompatible changes from Go 1 to Go 2 while breaking as little as possible”.

Interestingly, both documents are clearly geared towards code and APIs.

A few examples from the Go 1 compatibility promise (emphasis added):

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification.

Compatibility is at the source level.

Of course, for all of these possibilities, should they arise, we would endeavor whenever feasible to update the specification, compilers, or libraries without affecting existing code.

And from the Go 2 transitions proposal (emphasis added):

A key feature of these options is that code compiled at different language/library versions can in general all be linked together and work as expected.

While we can provide tooling to convert pre-1.20 code into working 1.20 code, we can’t force package authors to run those tools.

This can be used to take incremental steps toward new language versions, and to make it easier to share the same code among different language versions.

As we all know, however, there is much more to a language’s ecosystem than the extant body of code. There is culture. There is infrastructure, like conferences and training. There is tooling. There is trust. There is an aesthetic. (Ian Lance Taylor’s takeaway from the history of C++: “A new version may have a very different feel while remaining backward compatible.”)

And then there is a giant, sprawling, chaotic mess of documentation, ranging from official docs to blog posts to Stack Overflow to mailing list archives and beyond.

This organic documentary hodgepodge is invaluable. With the help of search engines, it ensures that most questions will have multiple answers written in different ways, at different levels, by different authors. This is a great boon, particularly to newcomers to a language.

A year ago or so, I needed to write something in Swift. The single biggest pain point by far was that when I searched for examples and discussion, I found answers written for Swift 2, Swift 3, and Swift 4. I ended up having to simultaneously learn three dialects of Swift and how to translate between them. This situation also commonly arises with popular libraries.

My code was brand new, so I didn’t care that the language had changed in incompatible ways. But it sure did break the documentation ecosystem in a deep way. And docs, unlike code, are impossible to go fix.

Of course, docs do go stale even when there is backwards compatibility. For example, strings.Builder made some old performance advice obsolete. But such breakage is relatively localized, easy to repair gradually, and not particularly damaging to people who find it instead of up-to-date docs.

The tentatively accepted Go 2 changes look unlikely to break much documentation, and the discussion so far on the many Go 2 proposals give no particular reason for concern. Nevertheless, as we all ponder Go 2, it’s probably worth explicitly thinking about compatibility in terms much broader than working code.

Benchmarking package initialization

Thu, 31 Jan 2019 13:53:05 -0800

Go program execution doesn’t start at func main. First is a bit of bootstrapping. Then the runtime gets initialized. Then, package by package, the program initializes global variables and runs init functions. Then it’s time for main.

Usually, the startup time for a Go program is negligible, and irrelevant compared to its steady state performance.

For short-lived programs, though, startup performance can matter a lot. This is particularly true if the program is a low level tool that is executed repeatedly by other programs. There has also been recent interest in optimizing the startup impact of the standard library.

So: How do you benchmark and profile program initialization?

If you are interested in memory allocation, Brad Fitzpatrick has a simple solution. This works because memory profiling is on by default.

But what about execution time?

One obvious idea is to copy your global variables and init functions into a regular Go benchmark. This is tedious and (like most tedious things) error-prone. It also fails for a more subtle reason: The compiler generates different (slower) code for variable initialization when it occurs inside a function instead of at the top level. This is because the compiler can make fewer assumptions (although as always there are ways to improve).

Another idea is to hack your code to return immediately from main and then use benchcmd to benchmark and perf to profile. This works on Linux, although it’d be nicer to have an option that uses standard Go tooling. Also, because initialization is generally fast, you need to do a bunch of runs to gather data, and the exec and profiler tool overhead can be considerable. (I tried using macOS’s instruments for profiling the go tool’s startup and found that—in addition to being generally useless—it added 300x overhead per run!)

Instead, let’s void the warranty!

Here’s how the compiler implements package initialization, at least as of Go 1.12. For each package, it generates code like:

var initdone· uint8

func init() {
	if initdone· > 1 {
		return
	}
	if initdone· == 1 {
		throw()
	}
	initdone· = 1
	// for all imported packages {
		pkg.init()
	// }
	init.ializers()
	
	init.<n>() // call user init functions, if any
	initdone· = 2
	return
}

func init.ializers() {                          (0)
	{ <init global variables for this package> }
}

This init takes the place of any init functions in the package; those are renamed init.0, init.1, and so on.

If we could reset initdone· to 0 and then call this init function, then we’d be (re-)executing the exact code that gets executed during package initialization.

We can do that! We’ll use //go:linkname to get access.

Here’s an example, benchmarking net/http package initialization:

package p_test

import (
	_ "net/http" // must import net/http, so that net/http.init actually ends up in the executable
	"testing"
	_ "unsafe" // must import unsafe to use go:linkname
)

//go:linkname _initdone net/http.initdone·
var _initdone uint8

//go:linkname _init net/http.init
func _init()

func BenchmarkNetHTTPInit(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_initdone = 0
		_init()
	}
}

And voila! A regular old Go benchmark that does just what we want.

Mostly. There are a few gotchas, above and beyond merely being a terrible idea.

First, if you do non-idempotent work in one of your init functions, things could get wonky. We did just void the warranty, after all. And I don’t know what might happen if you re-initialize package runtime or testing or something else low level while running a benchmark. Almost certainly something bad.

Second, as written, this only measures the initialization of net/http and not any of its dependencies. This might or might not be want you want. You can work around this by using more //go:linkname to reset initdone· to 0 for all dependencies. Then, as you can see from the compiler pseudocode, a single call to _init will re-initialize those packages as well.

Third, using //go:linkname requires that the symbol we are linkname-ing to must actually be in the executable. The easiest way to do this is to import the package in question. If you are working with an internal package, that means you might need to put this code somewhere with sufficient visibility for that import to work.

Fourth, line number support for autogenerated code isn’t all that fabulous. If you encounter frustrating pprof output while doing this, consider filing bugs.

Now that you can benchmark, what do you do if you find a bottleneck you want to fix? Mostly, lazily initialize things instead, usually using sync.Once, which is fast and hopefully will be faster still in Go 1.13.

Thanks to Daniel Martí for posing this question and for reading an early draft of this blog post.

Daniel has also created a tool based on this blog post, benchinit, so that you can break your programs this way with even less effort.

Logging, interfaces, and allocation

Mon, 06 Feb 2017 10:52:40 -0800

This post is about some new compiler optimizations scheduled for Go 1.9, but I want to start with logging.

A couple of weeks ago, Peter Bourgon started a thread on golang-dev about standardizing logging. Logging is pervasive, so performance came up quickly. The go-kit log package uses structured logging, centered on this interface:

type Logger interface {
    Log(keyvals ...interface{}) error
}

Sample call:

logger.Log("transport", "HTTP", "addr", addr, "msg", "listening")

Note that everything that goes into a logging call gets converted into an interface. This means that it allocates a lot.

Compare with another structured logger, zap. Zap has uglier call sites, specifically to avoid using interfaces, in order to be zero-allocation:

logger.Info("Failed to fetch URL.",
  zap.String("url", url),
  zap.Int("attempt", tryNum),
  zap.Duration("backoff", sleepFor),
)

The arguments to logger.Info have type logger.Field. logger.Field is a kind of union-ish struct that includes a type and a field each for a string, an int, and an interface{}. Thus interfaces are not necessary to pass the most common kinds of values.

Enough about logging. Why does converting a concrete value to an interface sometime allocate?

Interfaces are represented as two words, a type pointer and a value pointer. Russ Cox wrote a lovely explanation of this, which I will not attempt to repeat. Just go read it.

His post is slightly out of date, however. He points out an obvious optimization: When the value is pointer-sized or smaller, we can just put the value directly into the second interface word. However, with the advent of concurrent garbage collection, that optimization got eliminated. Now the second word in the interface is always a pointer.

Consider:

fmt.Println(1)

Before Go 1.4, this code did not allocate, because the value 1 could be put directly into the second interface word.

That is, the compiler treated it something like this:

fmt.Println({int, 1})

where {typ, val} represents the two words in an interface.

As of Go 1.4, this code started allocating, because 1 is not a pointer, and the second word must contain a pointer. So instead the compiler+runtime conspired to turn it into something roughly like:

i := new(int) // allocates!
*i = 1
fmt.Println({int, i})

This was painful, and there was much wringing of hands and gnashing of teeth.

The first significant optimization to remove allocations was added a bit later. It kicked in when the resulting interface did not escape. In that case, the temporary value could be put on the stack instead of the heap. Using our example code above:

i := new(int) // now doesn't allocate, as long as e doesn't escape
*i = 1
var e interface{} = {int, i}
// do things with e that don't make it escape

Unfortunately, many interfaces do escape, including those used in calls to fmt.Println and in our logging examples above.

Happily, Go 1.9 will bring a few more optimizations, in part inspired by the logging conversation. (Unless those optimizations get reverted in the next six months, which is always a possibility.)

The first optimization is to not allocate to convert a constant to an interface. So fmt.Println(1) will no longer allocate. The compiler puts the value 1 in a readonly global, roughly like this:

var i int = 1 // at the top level, marked as readonly

fmt.Println({int, &i})

This is possible because constants are immutable, and will thus be the same every time the interface conversion is reached, including recursively and concurrently.

This was inspired directly by the logging discussion. In structured logging, many of the arguments are constants– almost certainly all the keys, and probably a few of the values. Recall the go-kit example:

logger.Log("transport", "HTTP", "addr", addr, "msg", "listening")

This code drops from 6 allocations to 1, because five of the arguments are constant strings.

The second new optimization is to not allocate to convert bools and bytes to interfaces. This optimization works by adding a global [256]byte array called staticbytes to every binary, where staticbytes[b] = b for all b. When the compiler wants to put a bool or uint8 or other single-byte value into an interface, instead of allocating, it calculates a pointer into this array. That is:

var staticbytes [256]byte = {0, 1, 2, 3, 4, 5, ...}

i := uint8(1)
fmt.Println({uint8, &staticbytes[i]})

There is a third new optimization proposed that is still under review, which is to not allocate to convert common zero values in an interface. It applies to integers, floats, strings, and slices. This optimization works by checking at runtime whether the value is 0 (or "" or nil). If so, it uses a pointer to an existing large chunk of zeroed memory rather than allocating some memory and zeroing it.

If all goes well, Go 1.9 should eliminate a fair number of allocations during interface conversions. But it won’t eliminate all of them, which leaves performance still on the table as the logging discussion continues.

The interplay between implementation decisions and APIs is interesting.

Picking an API requires thinking about the performance consequences. It is not an accident that io.Reader requires/allows callers to bring their own buffer.

Performance is in no small part a consequence of the implementation decisions. We have seen in this post that the implementation details of interfaces can substantially alter what code allocates.

And yet those very implementation decisions depend on what kind of code people write. The compiler and runtime authors want to optimize real, common code. For example, the decision to in Go 1.4 to keep interface values at two words instead of changing them to three, which made fmt.Println(1) allocate, was based on looking at the kind of code people wrote.

Since the kind of code people write is often shaped heavily by the APIs they use, we have the kind of organic feedback loop that is fascinating and sometimes challenging to manage.

Not a terribly deep observation, perhaps, but there is one takeaway: If you’re designing an API and worrying about performance, keep in mind not just what the existing compiler and runtime actually do, but what they could do. Write code for the present, but design APIs for the future.

And if you’re not sure, ask. It worked (a bit) for logging.

Picking up pennies: Disabling memory profiling

Sat, 28 Jan 2017 18:06:36 -0800

If you work on a short-lived, allocation heavy program and care about a tiny (maybe 0.5%) performance improvement, this post is for you.

I was looking at a CPU profile of the Go compiler when I noticed something odd: An entry in mprof.go. mprof.go contains the memory profiling implementation, but I was doing cpu profiling. Was there a bug in compilebench, perhaps?

Nope. The variable runtime.MemProfileRate controls the rate at which the runtime samples allocations. And its default value is not 0 (disabled), but 512 * 1024.

This is a good default. One sample per 500k of allocations is not much overhead. And when something goes wrong on a server, you want to be able to find out why, rather than fussing with profiling settings and then hoping it happens again.

But if you work on a short-lived program, like a compiler, when something goes wrong, you probably don’t have any mechanism for gathering ad hoc profiles. For any given run, you either have profiling enabled or you don’t, and if something goes wrong, you just enable profiling and try again.

And if your program is allocation-heavy, like the Go compiler, there might be enough memory profiling samples collected to absorb some CPU time. (As currently implemented, the first sample is particularly expensive, as it allocates a pretty large data structure.)

And I’m always looking for performance wins in the compiler, even little ones (hoping they add up). So I sent a CL to disable memory profiling entirely when not explicitly requested. The benefits aren’t head-turning, but it’s a very cheap, low risk 0.5% to put in the bank. It’ll get reviewed for Go 1.9.

Doing this in your own program requires nothing more than setting runtime.MemProfileRate = 0 when memory profiling has not been requested. But please, think twice first.

Compile-time assertions in Go

Tue, 24 Jan 2017 09:37:05 -0800

This post is about a little-known way to make compile-time assertions in Go. You probably shouldn’t use it, but it is interesting to know about.

As a warm-up, here’s a fairly well-known form of compile-time assertions in Go: Interface satisfaction checks.

In this code (playground), the var _ = line ensures that type W is a stringWriter, as checked for by io.WriteString.

package main

import "io"

type W struct{}

func (w W) Write(b []byte) (int, error)       { return len(b), nil }
func (w W) WriteString(s string) (int, error) { return len(s), nil }

type stringWriter interface {
	WriteString(string) (int, error)
}

var _ stringWriter = W{}

func main() {
	var w W
	io.WriteString(w, "very long string")
}

If you comment out W’s WriteString method, the code will not compile:

main.go:14: cannot use W literal (type W) as type stringWriter in assignment:
	W does not implement stringWriter (missing WriteString method)

This is useful. For most types that satisfy both io.Writer and stringWriter, if you eliminate the WriteString method, everything will continue to work as it did before, but with worse performance.

Rather than trying to write a fragile test for a performance regression using testing.T.AllocsPerRun, you can simply protect your code with a compile-time assertion.

Here’s a real world example of this technique from package io.

OK, onward to obscurity!

Interface satisfaction checks are great. But what if you wanted to check a plain old boolean expression, like 1+1==2?

Consider this code (playground):

package main

import "crypto/md5"

type Hash [16]byte

func init() {
	if len(Hash{}) < md5.Size {
		panic("Hash is too small")
	}
}

func main() {
	// ...
}

Hash is perhaps some kind of abstracted hash result. The init function ensures that it will work with crypto/md5. If you change Hash to be (say) [8]byte, it’ll panic when the process starts. However, this is a run-time check. What if we wanted it to fail earlier?

Here’s how. (There’s no playground link, because this doesn’t work on the playground.)

package main

import "C"

import "crypto/md5"

type Hash [16]byte

func hashIsTooSmall()

func init() {
	if len(Hash{}) < md5.Size {
		hashIsTooSmall()
	}
}

func main() {
	// ...
}

Now if you change Hash to be [8]byte, it will fail during compilation. (Actually, it fails during linking. Close enough for our purposes.)

$ go build .
# demo
main.hashIsTooSmall: call to external function
main.init.1: relocation target main.hashIsTooSmall not defined
main.init.1: undefined: "main.hashIsTooSmall"

What’s going on here?

hashIsTooSmall is declared without a function body. The compiler assumes that someone else will provide an implementation, perhaps an assembly routine.

When the compiler can prove that len(Hash{}) < md5.Size, it eliminates the code inside the if statement. As a result, no one uses the function hashIsTooSmall, so the linker eliminates it. No harm done. As soon as the assertion fails, the code inside the if statement is preserved. hashIsTooSmall can’t be eliminated. The linker then notices that no one else has provided an implementation for the function and fails with an error, which was the goal.

One last oddity: Why import "C"? The go tool knows that in normal Go code, all functions must have bodies, and instructs the compiler to enforce that. By switching to cgo, we remove that check. (If you run go build -x on the code above, without the import "C" line, you will see that the compiler is invoked with the -complete flag.) An alternative to adding import "C" is to add an empty file called foo.s to the package.

I know of only one use of this technique, in the compiler test suite. There are other imaginable places to apply it, but no one has bothered.

And that’s probably how it should be. :)

new(Blog)

Mon, 23 Jan 2017 15:19:05 -0800

I’m going to try this blogging thing again.

I’ve failed at it a few times before. I’m going to try Julia Evans style this time. Maybe this one will stick?

Don't Panic

Why I leave my webcam off

Attention

Fatigue

Connection quality

Formality

How to make NYT Connections better

Let me select more than four tiles

Add Gather

Add Submit All

Add non-color affordances

Security through intentional redundancy

Simpler backoff

Blog schism

Podcast ho!

Sometimes Software is Done, or Why Hugo Why

Type Specialization in Go

Nicer struct literals in Go templates

Existing options

dict

Do it all in Go code

tmplfunc

A new approach

FuncMap name collisions

Caveats

Performance and files full of code

PHP

JavaScript

C++

Go

Moral

How to test a Go beta or RC

Installation

Betas

Release candidiates

I don’t have that much time

Why test betas and RCs?

Bonus

Make your lookup table do more

A good starting point

Some groundwork

A small step

A great leap

What happens when you load into x0 on RISC-V?

Background

Nil checks in the Go compiler

Implicit nil checks

Back to RISC-V

An ambiguity in the spec

Denouement

git rebase --fork-point considered harmful (by me)

Prologue

Oops

Bug fix

Time to rebase

Denouement

What’s wrong here?

The fix

Generating safer Go code

stringer

cloner

Compile-time assertion taxonomy

Call to action

Discovering alloc size classes in Go

What are the size classes?

Who cares?

Why not hard-code the size classes?

Life without line numbers

Interning strings in Go

What is a string?

What is string interning?

Manual string interning

Complications

A helper package

More reading

testing.B.ReportMetric

Compatibility: Not just about code

Benchmarking package initialization

Logging, interfaces, and allocation

Picking up pennies: Disabling memory profiling