dr2chase

Linked-list freeing need not all happen in one go. There can be a queue of free-but-not-zeroed, push RC=0 stuff there instead of recurring on referents, anyone doing memory allocation work can pop a few items off that queue and decrement the counts of their referents, etc.

That loses timeliness, adds problem of queue management.

A weird trick I stumbled across years ago is to not strictly pop from the head of the stack/queue -- instead choose randomly from the last N elements of push end of the stack. This seemed to blunt the sort of growth that you get from "visiting wrong". I never did figure out the theory of why this worked.

s/platforms/functions and types, noticed that too late to edit.

All the methods tagged as "zero-cost" compile to movd or less. The earlier version of archsimd (1.26, for amd64) supported these as direct "AsFooNxM" methods, and there were a lot of them. I am not 100% satisfied with either approach, but don't have a better idea and we must settle on something.

Two of the "conversion" methods between int and uint vectors compiled to movd or less (but the convert from int to float32 vector does not) and are actually identical to corresponding zero-cost reshapes.

Conversion between int vectors and masks may be zero-cost; it depends on the platform (zero cost on Wasm, NEON, AVX, AVX2; change in representation on AVX512 and SVE).

There's also pattern-based optimization going on in the backend of the compiler, so if (on AVX512 or SVE) you do some operation followed by an IfElse, odds are pretty good the two "methods" will compile down to a single instruction. We did this API factoring so that we could support (many) fewer methods, and it also increases the similarity between different platforms.

Binary size only scales for the simd-touching platforms, with scaling depending on platform. Each platform gets emulation+number-of-variants. Emulation is there as an option, primarily for testing (do you trust us? I don't trust us). So wasm is 2x, amd64 is 4x, arm64 is currently 2x but should be 4x in the near future. ppc64 ought to be 2x, maybe 3x, don't know their variants story. Loong64 will be 3x. But only the SIMD-touching stuff is replicated, and N-1 copies of the replicated code are never executed by a given program execution.

SVE and RVV, because they are "scalable", may end up with a larger amount of replication.

Go uses fixed-size stack frames, so spill space is fixed size, etc. We could "just" fix this limitation, or we could generate multiple sizes for what actually exists in the wild, with a masked implementation for longer. So, SVE would end up with 0 (emulation), 128, 256, and 512-masked, plus (as arm64) would also have NEON and NEON-noclmul (Raspberry Pi). I'm not sure what sizes exist for RVV.

Depends how you define "equal". One approach is simply to scale the charge by income -- effectively, convert time to money, and charge you a congestion tax of some amount of money-earning time. "6 minutes" is 1/10000 of your annual income -- $2 for someone earning $20,000 per year, $20 for someone earning $200,000 per year.

But does a vehicle with several people in it pay for the max, min, median, average, or the driver's time? I suspect "driver" is easiest, it seems like it might work but I'll bet there are some screwy ways to game that rule, too.

author here, you are right, I missed that. In my pathetic defense, the normal argument around here (Cambridge, MA) is about literal lane widening and narrowing, and not adding and subtracting.

Hi, author of the article. I'm assuming urban traffic speeds, which is what I observe all the time myself, but you can look at the video of those kids, and count, and look at the seconds. 125 bikes in 45 seconds, between 0:02 and 0:47. Understanding it is another issue, but it's a fact. (This is one of those things that I do myself and would not claim that I exactly understand the details, I just do it.)

There have been more academic studies. e.g. https://nacto.org/wp-content/uploads/5_Zhou-Xu-Wang-and-Shen... estimates 2512 bicycles per hour per meter of road width, or 7536 bikes per hour on a 3-meter (10 feet) wide lane. That's only 4.2x car throughput, versus those kids who managed 5.5x.

You are right about the trailers, but at least where I ride, they are not common-case for carrying things, lots more cargo bikes instead, and those are "better" than trailers -- it's possible to ride two cargo bikes side-by-side even in a US protected lane (specifically on Garden Street in Cambridge, MA), though this of course assumes competent riders.

The way to view it is "unless there is syntactic sharing, it is a for loop, same as before". The compiler uses a syntactic test (with little knowledge of control flow or value use) to exclude loops from the change. This excludes most loops.

After the change, escape analysis figures out if the changed iteration variable actually needs heap allocation; in an internal sample of code that was actually buggy (i.e., biased, guaranteed to have at least one loop like this) for 5/6 of the loops escape analysis decided that heap allocation wasn't needed.

The reason this optimization isn't part of the language change proposal is that escape analysis is "behind the curtain"; ignoring performance, a program should behave the same with or without it, and it is removing heap allocations all over the place already. Escape analysis is also extremely difficult to explain exactly, so you would not want it in the spec, and "make escape analysis better" (that is, change it) is one of the prominent items in the bag of things to do for Go.

How do you get mm-wave radiation to an aquatic plant? Skin depth at that frequency is tiny. Are they doing studies on duckweed? (Look up the plant, indeed, they are.) And I can see how pine needles might be more affected, what with size and pointy tips.

Speaking both pedantically and based on my experience riding a bicycle, when traffic speed is reduced all the way to zero, it is in fact safer, at least for me. I am of course, not counting the risk of drivers stroking out from frustration-induced high blood pressure, but that's what we on bikes call a lifestyle choice.

I think it's a three-part problem. One, it is a flow problem, and by removing congestion at one bottleneck you mostly deliver traffic more efficiently to the next bottleneck. Actually increasing traffic flow is much more expensive than the cost of any single project. Second, over time, you end up with induced demand -- if you actually do get rid of all the congestion, longer commutes will become more practical, and traffic will increase until the marginal-next-commuter is discouraged from adding his car to the scrum.

Third, economic arguments are a little dicey for driving because driving is filled with externalized costs, subsidies, overoptimistic assumptions, and dependent utility. Driving creates noise and pollution (and it appears that the pollution is more deadly than crashes) but drivers don't pay that cost. There's personal crash risk, but people tend to assume that they are careful drivers and hence less likely to crash than the norm. The cost of the roads themselves is currently subsidized from the general fund; it's not a huge external cost, but it's a cost. Driving also creates (perceived) danger to people biking and walking; that tends to encourage them to also drive for their own (perceived) safety, even when they otherwise would not, and the congestion costs of driving also delay bus transit, making it less useful (it's already slower because of all the stops; traffic jams make it slower yet).

As someone else pointed out, reducing peak speeds does not necessarily increase travel time. See this report on the Prospect Park West redesign: http://jonathansoma.com/ppw/

I commute-by-bike on a road with bike lanes in Somerville and Cambridge. At rush hour, no matter what the speed limit, the fastest way from point A to point B is a bicycle (unless A and B are stops on the red line), almost never exceeding 20mph. The reason cars are slow is that they take up too much space and have to wait in line, again and again and again.