tubs

I see what you mean here, sorry.

I guess I'd argue if you have 20 items whose full hash collides then something is pretty seriously wrong with the hashing algorithm - raise an error/exception/panic/(whatever is appropriate for the situation) and surface it.

They go to the same bucket because their hash *mod the size of the top array* collides.

They resize the top level array and rehash items into their new buckets.

Meh. Even with h3 I still see more gains from reducing network requests than most other attempts I try. (One day s3 will support multiple ranges per request, if I wish hard enough).

The gain is in power efficiency.

Arm64 provides `dc zva` for this.

Any way this can work on arm64 without dwarf info at runtime? Would be very interested.

M chips has some matrix multipliers in hardware as well.

To expand on azornathogron's answer, when you are working with 2d data (it generalises to 3d too!) you often want to filter pixels in a rectangular area. This is commonly for bilinear filtering or some kind of convolution kernel.

If you don't interleave the bits and have large textures (think 4096 pixels wide) where each pixel is 4bytes big, that means there is a distance of 16kb between a pixel and the pixel below it.

This is super bad for caches (really important for the TLB in the MMU which is usually way smaller than data caches).

In GPU literature you'll see this called "tiling" (again like azornathogron said it's not always pure morton order), Intel document their tiling layout, here's an older layout doc:

https://docs.mesa3d.org/isl/tiling.html

This doesn't work efficiently for non-square arrays.

E.g. if you have a 128x32 then you don't want to interleave the y bits once they are exhausted (only need 5 bits of y, but 7 bits of x to fully address this).

The posted implementation would produce

    y6,x6,y5,x5,y4,x4,y3,x3,y2,x2,y1,x1,y0,x0

but really we want:

    x6,x5,y4,x4,y3,x3,y2,x2,y1,x1,y0,x0

Hehe, I also worked on a delivery robot with exactly the same problem. We ended up licencing phantom auto. Expensive and ... Not particularly amazing.

Still works on link farms, yep. And works pretty well!

The ram is not on the cpu on a mac. It's in the same can but it's still regular ddr dimms.

Copilot seems to handle this fine.

sched-ext is meta, Google have something else but less open i believe.

https://github.com/sched-ext/scx/blob/main/OVERVIEW.md

The website (perhaps innocently) animates the cookie popup on ios such that attempting to reject presses on accept. Please fix.

The navigation and path planning in godot are pretty primitive.

Having worked for a few of those lazy vendors, the aot usually just ends up being bitcode which is fully jitted later.

All of these are jit by the driver in the end though?

Of that blog post the float formatting is a tiny fraction (excuse the pun) of the perf win.

It is used to say that there isn't really a relationship between them.

I love a homebrewed gui system (having made more than a couple myself)! This looks pretty far along, kudos.

The only slight nitpick I have is the unity gui system is also called ugui so search conflicts might be annoying.

In my experience if you're doing perf critical stuff with string formatting you won't be using anything like fmt or printf, and for everything else the runtime difference is almost entirely unimportant.

For me the compile time increases are a killer, even if the api is considerably nicer.

The memory is not on the die. It's in the package just like pretty much every other big boy mobile ap out there.

Consider it in terms of error.

The difference is 0.4 to 0.035

An order of magnitude more light reflected.

It's not packaged materially differently from the other chips it's compared against. Which is what I said originally.

It's a board space and cost saving measure but it does not change performance. The tooling is also expensive and Intel have their own internal mature packaging processes.

The drams on an apple chip are still bog standard lpddr. Most benchmarks find the actual memory middle of the road at best.

Critically they aren't magically on the die or any more inside the package than most other high end mobile chips.

The memory is not inside the package any more than on any other flip chip or pop soc, ie every mobile ap soc made in the past 5 years. Please stop propagating this myth.

One of Apple's actual secret sauces is they can make their big caches fast. Typically latency increases with cache size so it's a tradeoff. Apple trades off less here. And it's not some "only fast because tsmc" it's just really solid engineering at both the architectural and physical design level.

Agreed no one uses those defunct tools like awk or roff, let's re-use them!

Who cares if every build script in the world breaks, progress waits for no one.

Have you got any links to how they continue the threads after the gc has run? I was looking for something similar but couldn't find much.