"A lot of code can be pessimized by golfing instruction counts"

Can you explain what this phrase means?

An old approach to micro-optimization is to look at the generated assembly, and trying to achieve the same thing with fewer instructions. However, modern CPUs are able to execute multiple instructions in parallel (out-of-order execution), and this mechanism relies on detecting data dependencies between instructions.

It means that the shorter sequence of instructions is not necessarily faster, and can in fact make the CPU stall unnecessarily.

The fastest sequence of instructions is the one that makes the best use of the CPU’s resources.

I’ve done this: I had a hot loop and I discovered that I could reduce instruction counts by adding a branch inside the loop. Definitely slower, which I expected, but it’s worth measuring.

Sounds nice! I could see where that could be simultaneously rewarding and frustrating. Best of luck to you.

This was the first thought that occurred to me too when I saw this post.

I would be more inclined to use it if it didn't have punctuation within the name.

I've been using it as my daily driver for ~3 years now.

The punctuation hasn't bothered me once in that time.

I've enjoyed a much more stable Linux desktop experience than I had on other distros in the past when I tried though.

That only works for really small holes.

I've been holding off on Zig because it hasn't reached 1.0 milestone, but I'm starting to think that it might be time to start digging in. Is Ziglings kept up with language changes being made in Zig? It would be very frustrating to find that Ziglings is out of sync with the newer version of Zig that you might be using at the time.

It uses the development version so it keeps in sync. I don't think we'll see many changes in the language itself before 1.0, they are no longer accepting changes to it. Most changes from now on will be in the Standard Library.

"Ceph is fundamentally already RADOS at its core (fully compatible with S3 API.)"

Yes, Ceph is RADOS at its core. However, RADOS != S3. Ceph provides an S3 compatible backend with the RADOS Gateway (RGW).

My point was even 45drives virtualization of Ceph host roles to squeeze the entire setup into a single box was not a "hobby" grade project.

I don't understand yet exactly what MinIO would add on top of that to make it relevant at any scale. I'll peruse the manual on the weekend, because their main site was not helpful. Thanks for trying though ¯\_(ツ)_/¯

What I tried to say (perhaps not successfully) was that core Ceph knows nothing about S3. One gets S3 endpoint capability from the radosgw which is not a required component in a ceph cluster.

The risk with mixing different subjects per thread. Cheers =3

https://docs.ceph.com/en/latest/radosgw/s3/

Ceph has multiple daemons that would need to be running: monitor, manager, OSD (1 per storage device), and RADOS Gateway (RGW). If you only had a single storage device it would still be 4 daemons.

Ceph is awesome for software defined storage where you have multiple storage nodes and multiple storage devices on each. It's way too heavy and resource intensive for a single machine with loopback devices.

I've done some preliminary testing with garage and I was pleasantly surprised. It worked as expected and didn't run into any gotchas.

Garage is really good for core S3, the only thing I ran into was it didn't support object tagging. It could be considered maybe a more esoteric corner of the S3 api, but minio does support it. Especially if you're just mapping for a test api, object tagging is most likely an unneeded feature anyway.

It's a "Misc" endpoint in the Garage docs here: https://garagehq.deuxfleurs.fr/documentation/reference-manua...

"didn't support object tagging"

Thanks for pointing that out.