mbitsnbites

Same with BuildCache, except you also get a fast local cache so you effectively have an L1 and an L2 cache.

In fact, since you also have super fast "direct mode" caching that bypasses the preprocessor (like ccache but unlike sccache), BuildCache really has three logical levels of cache: direct, preprocessor and remote (S3, redis, ...).

Though I'm not actively working with Firefox so can't speak for their use cases, one important use case for clobber builds is CI.

I'm the author of BuildCache, and where I work we make thousands of clobber builds every day in our CI. Caching helps tremendously for keeping build times short.

There are a few use cases for local development too. For instance if you switch between git branches you may have to make near full rebuilds (e.g. in C++ if some header file is touched that gets included by many files).

Another advantage as a local dev is that you can tap into the central CI cache and when you pull the latest trunk and build it, chances are that the CI system has already built that version (e.g. as part of a merge gate) so you will get cache hits.

For what it's worth, browser uptake is largely dictated by the browser being default shipped with some major OS. Very few users make an active choice (statistically speaking).

Safari is popular because it ships with iOS and macOS.

Edge (previously IE) is popular because it ships with Windows.

Chrome, however, is popular for several reasons. One reason is that it ships with Android and ChromeOS, but before that Google had a very aggressive multi-channel campaign where they pushed it with large banners on Google search (everyone used Google) and they made deals with Windows AV vendors so that when a user installed anti-virus on their computer Chrome was automatically installed and made the default browser. Another reason is that Google has consistently develeoped Chrome together with their web services, so things like search, maps, gmail, docs etc tend to work best in Chrome.

The only default channels that Firefox has, that I'm aware of, are verious Linux distros, and they have a pretty thin market slice.

And a local cache (kind of level 1 and level 2 caches)

Just a note for the posterity: The continuation of the project is called Bitfrost CC and lives here: https://codeberg.org/mbitsnbites/bitfrostcc

Thanks for the references! After writing the blog I was looking for such references.

Thanks for the feedback, and the interesting ideas. It's good to know that I was on to something and not completely off :-)

I'm mostly doing this for learning purposes, but a hidden agenda is to create a low-latency codec that can be used in conjunction with other codecs that deal primarily with luma information. AV1 and friends are usually too heavy in those settings, so I try to keep things simple.

I truly get that. That's also one of the reasons why I started from scratch once I got the idea, rather than researching all the available papers and implementations etc (because the latter is quite overwhelming, while the former took me about a week of spare time hacks).

My scope is also a bit unusual, I think, because one of the applications I'm thinking about is to "augment" luma-only codecs with chroma. One such codec is https://gitlab.com/llic/llic

But most of all, I wanted to learn.

The model is based on Qwen2.5-Coder-7b it seems. I currently run some quantized variant of Qwen2.5-Coder-7b locally with llama.cpp and it fits nicely in the 8GB VRAM of my Radeon 7600 (with excellent performance BTW), so it looks like it should be perfectly possible.

I would also only use Zeta locally.

When measuring the errors I exhaustively iterate over all possible floats in the range [1, 2), by enumerating all IEEE 754 single precision representations in that range. That's "only" 2^23 numbers, so perfectly doable.

My selection criteria was abit complex, but something like this:

1. Maximize number of accurate bits in the approximation.

2. Same in NR step 1, then NR step 2 etc.

3. Minimize the max error in the approximation, and then the avg ertor in the approximation.

4. Same for NR step 1, 2, ...

Given my search criteria, the optimal magic number turns out to be: 0x7ef311c2

  Initial approximation:
    Good bits min: 4
    Good bits avg: 5.242649912834
    Error max: 0.0505102872849 (4.30728 bits)
    Error avg: 0.0327344845327 (4.93304 bits)

  1 NR step:
    Good bits min: 8
    Good bits avg: 10.642581939697
    Error max: 0.00255139507338 (8.61450 bits)
    Error avg: 0.00132373889641 (9.56117 bits)

  2 NR steps:
    Good bits min: 17
    Good bits avg: 19.922843217850
    Error max: 6.62494557693e-06 (17.20366 bits)
    Error avg: 2.62858584054e-06 (18.53728 bits)

  3 NR steps:
    Good bits min: 23
    Good bits avg: 23.674004554749
    Error max: 1.19249960972e-07 (22.99951 bits)
    Error avg: 3.44158509521e-08 (24.79235 bits)

Here, "good bits" is 24 minus the number of trailing non-zero-bits in the integer difference between the approximation and the correct value, looking at the IEEE 754 binary representation (if that makes sense).

Also, for the NR steps I used double precision for the inner (2.0 - x * y) part, then rounded to single precision, to simulate FMA, but single precision for the outer multiplication.

The big cores do. They essentially pump division through something like an FMA (fused multiply-add) unit, possibly the same unit that is used for multiplication and addition. That's for the Newton-Raphson steps, or Goldschmidt steps.

In hardware it's much easier to do a LUT-based approximation for the initial estimate rather than the subtraction trick, though.

It's common for CPUs to give 6-8 accurate bits in the approximation. x86 gives 13 accurate bits. Back in 1975, the Cray 1 gave 30 (!) accurate bits in the first approximation, and it didn't even have a division instruction (everything about that machine was big and fast).

We have memcpy behind a C++ template function that mimics the interface of std::bit_cast.

Your suggestion got me intrigued. I have a program that does an exhaustive check for maximum and average error, so I'll give your numbers a spin.

If you're not constrained to software solutions you have a whole world of opportunities. E.g. if it's a graphics or neural net pipeline you can pour tricks like this (or better) onto it. If it's a CPU then you can add special instructions that do exponent manipulation and the likes.

Excellent! Will have a look.

There is also the case with machines that lack FP support, like some ARM Cortex M variants.

The proper solution is to use std::bit_cast in modern C++ or otherwise use memcpy, and of course know what you're doing.

Some things that could mess with you:

* Floating-point endianity is not the same as integer endianity.

* Floating-point alignment requirements differ from integer alignment requirements.

* The compuler is configured to use something else than 32-bit binary32 IEEE 754 for the type "float".

* The computer does not use two's complement arithmetic for integers.

In practice, these are not real problems.

Yep. Along the same lines. This one is even simpler, though, as it requires only a single integer CPU instruction (and the simplest of all instructions too).

If you want full precision, you need to do three Newton-Raphson iterations after the initial approximation. One iteration is:

    y = y * (2.0F - x * y);

I'd argue that x86 and IBM z/Arch are the ones that stick out among contemporary ISAs in that they need fairly complex fron-end translation into an internal instruction format.

ARM implementations that support both ARMv7 (both ARM mode and THUMB mode) and ARMv8 also need some kind of translation in the front-end, but recent ARMs (like Apple's implementations) don't support 32-bit mode and are simpler in that way.

Most other ISAs are much closer to the metal, although many implementations still do some level of translation in the front-end (mostly fusing/splitting certain instruction combinations for better efficiency). Examples: ARMv8+, RISC-V, MIPS, Loongson, TI 6x & 7x DSP, and of course most GPUs (and my own MRISC32 ISA).

People are ignorant. Companies are greedy. That's why we need regulation.

Children don't need social media, just as they don't need tobacco or alcohol. As long as all your friends are off social media, you'll be fine. It's when there's a choice that you get the FOMO situation that makes it more or less impossible for parents to dissuade their children from using social media.

Yup. Everything pre-RISC was CPI (Cray doesn't count - it was effectively RISC, and way too expensive anyway).

> government doing a parent's job

The problem here is that it's pretty much out of the hands of the parents. If your kids' friends have social media, your kids will absolutely need it too in order to not be left out. I've witnessed the pressure, and it's not pretty. Add to that the expectation from society that children shall have access to social media.

Regulation is pretty much the only way to send the right signals to parents, schools, media companies (e.g. Swedish public service TV has a kids app that until recently was called "Bolibompa Baby", but it's now renamed to "Bolibompa Mini"), app designers, and so on.

> I'd like to see more science proving that social media is bad for kids

Smoking tobacco was allowed for children for hundreds of years before it was regulated. Today we can hardly fathom how stupid it would be to allow children to smoke. Social media is much more accessible than cigarettes, far more addictive, and rather than messing with your lungs it messes with your brain and personality.

There are many problems with "waiting for the science". One is that it takes many, many decades to get reliable longitudinal studies on things like addiction and how the brain is affected.

There are so many indications that social media is bad for children (including scientific studies), in many different ways. It really should not be controversial to limit use for children. It's not like it is something that they need.

This book, "Smartphone brain: how a brain out of sync with the times can make us stressed, depressed and anxious" by Swedish MD psychiatrist Anders Hansen, brings up one of the aspects (unfortunately I don't know of an English translation): https://www.amazon.se/Sk%C3%A4rmhj%C3%A4rnan-hj%C3%A4rna-str...

Here's a short video with Anders Hansen: https://youtu.be/DwAx2kRwCRI?t=112

Then there's is of course the question of how to limit the use. But that's another issue.