11,488 karma · joined April 14, 2013
The last thing you want is all of the threads failing to cmpxchg (spuriously or otherwise ) spinning on a shared cacheline
Real world alternatives show atomic xchg only solutions scale to hundreds of threads.
Property that isn't registered can remain unregistered but must be registered before it is sold.
https://en.wikipedia.org/wiki/City_of_London_Cemetery_and_Cr...
I have very vivid memories as a child of walking through Brookwood Cemetary in south east England seeing a big machine crunching up headstones. Vast swathes of the place was flattened. The cheat code here seems to be "topple testing" for health and safety reasons.
It's the UKs largest cemetery and in a shocking state:
There's plenty of evidence the rear gardens were used for growing food and drying laundry back then
Children would also play there where they could be seen from the kitchen (which was always in the rear), rather than playing in the road (as much)
Rear gardens also served as a space where you would converse with your neighbour. Typically fences between neighbours were low and wire (tall 6ft wooden fences came later)
The other thing is the only toilet in a 4 bedroom property would also be out there, as an outdoor WC, accessible from outside
I doubt much read space was reserved for lawn back then
You can't have a bounded queue that is always non-blocking because slow consumers can block producers.
You can't have a global FIFO order + multiple producers without slow producers blocking consumers.
You can't have a global FIFO order + have have non-atomic reserve and commit without a interrupted/de-scheduled producer thread being able to block the consumer
If you want atomic commit then you lose separate reserve which means either unbounded memory or atomic fixed-size data with sentinel values, ABA problems etc.
There are trade-offs everywhere, and it's best to pick the data structure that fits your needs just like any other problem.
There are simple node based algorithms that achieves a similar guarantee:
https://web.archive.org/web/20240928080729/https://www.1024c...
There is also a MPMC algorithm on this site very similar to the article
https://web.archive.org/web/20220524214823/https://www.1024c...
"Suuuuure. Kidnap the humans, DESTROY THE MACHINE."
Both should use multipass ahead of time compression with a rate control algorithm, and both should have enough slack streaming bandwidth to handle complex scenes with buffering
The code will be prefetched in to local (executing) CPU cache just the same. No invalidations will take place across NUMA zones.
Modern DLLs on e.g. Linux use PIC and not mutable relocations.
Adjusting for purchasing power parity, GDP per capita in Poland isn't far behind the UK.
If I have access to your digital ID I shouldn't be able to impersonate you anymore than I should be able to fly using your passport.
Your passport is useful not just because it's difficult to forge, but because border control is a thing.
You still need to send a digital image from the id, signed by an authority, saying "this person is 18"
You then still need a trusted ID service or algorithm to capture an image of the user _at the time of use_ to compare that to.
Just having access to your digital ID credentials proves nothing
The zero knowledge proof only helps prevent tracking between the ID service and the website you're logging into. This is valuable but requires standardisation and client side support, which doesn't exist.
All the time the client side is implemented by JavaScript served from the server side you're just trusting these parties to behave and not snoop
In person that falls to a human being, and it's an easy and intuitive task that takes seconds.
On the internet this involves some kind of video recording being sent to some agency somewhere being paid a fee, who may later be asked to prove the efficacy of their service. This agency needs a digital copy of the photo from your ID for matching purposes. They'll be tempted to store this for auditing purposes... they'll also be tempted to store correlation IDs etc if the architecture allows.
The issue is trust. You just can't trust these first and third parties not to collaborate for commercial gain or at government demand or request.
And ultimately you're still exchanging verification at registration for a shareable credentials: I could use my ID to sign up to pornhub premium and then sell the username and password to a 16 year old if I wished, just like those buying alcohol can go and give it to the underage. A black market for digital credentials is even easier to establish than material goods
I've worked at several HFTs and 2 had independently settled on 64bit signed fixed point with a implied 10^9 scaling factor between internal systems.
However in-process one just used 'double' for all FX conversions, scaling etc. With 15 digits of precision and careful rounding choices it's fine.
Dealing with the outside world you'd obviously just convert as cheaply as possible - and there are some crazy fast algorithms doing fast binary float -> correctly rounded decimal conversions these days