The Fastest Mutexes

Post by almostgotcaught » Thu, Oct 03, 2024, 2:01 AM UTC

cycomanic wrote: post #227

almostgotcaught wrote: post #213

Earlier quoted context omitted.

> So why did Apple build this ability if nobody wants it? did you miss the part where they transitioned from x86 to arm64 in 2020?

I don't get your point. People were arguing that one doesn't need fat binaries because cross compiling and having different binaries is fine. Apple clearly thought differently when they transitioned from x86 to arm (not their first architecture transition either). So now you're saying because apple finished the transition fat binaries are useless again? What about other platforms?

Post by pizlonator » Thu, Oct 03, 2024, 2:07 AM UTC

wbl wrote: post #217

pizlonator wrote: post #106

Earlier quoted context omitted.

Totally! Pro tip: if you really do know that contention is unlikely, and uncontended acquisition is super important, then it's theoretically impossible to do better than a spinlock. Reason: locks that have the ability to put the thread to sleep on a queue must do compare-and-swap (or at least an atomic RMW) on `unlock`. But spinlocks can get away with just doing a store-release (or just a store with a compiler fence…

Atomic RMW is all you need. Imagine 3 state futex lock of taken, sleeping, and unlocked. Waking thread just needs to see old value but writes unlocked unconditionally. I don't think this is more expensive than release certainly not because of the line where the write goes in most cache coherency protocols. Granted this lock does wake up too many people but you did say usually uncontended.

Post by wmf » Thu, Oct 03, 2024, 2:10 AM UTC

jkachmar wrote: post #102

Uehreka wrote: post #68

So on the one hand, all this Cosmo/ape/redbean stuff sounds incredible, and the comments on these articles are usually pretty positive and don’t generally debunk the concepts. But on the other hand, I never hear mention of anyone else using these things (I get that not everyone shares what they’re doing in a big way, but after so many years I’d expect to have seen a couple project writeups talk about them). Every men…

reposting my comment from another time this discussion came up: "Cosmopolitan has basically always felt like the interesting sort of technical loophole that makes for a fun blog post which is almost guaranteed to make it to the front page of HN (or similar) purely based in ingenuity & dedication to the bit. as a piece of foundational technology, in the way that `libc` necessarily is, it seems primarily useful for fun…

Post by [deleted] » Thu, Oct 03, 2024, 2:16 AM UTC

int_19h wrote: post #197

0x1ceb00da wrote: post #89

Earlier quoted context omitted.

Wasn't elf format modified by upstream to accomodate for cosmo? That makes it kinda official. Still hard to see a use case for it. If you want everyone to be able to run your program, just write a web app, a win32 program, or a java applet. 20 years old java applets still run on modern JVMs.

A web app is, well, a web app. Many things don't fit this format, e.g. command line tools. A Win32 program will not run out of the box on either Linux or macOS. Neither will a Java app. The nice thing about Cosmopolitan is that it "just works" as far as end user is concerned. But without firm support from the OSes involved, it is inevitably a hack with questionable long-term stability prospects. What we really need i…

Post by forrestthewoods » Thu, Oct 03, 2024, 2:29 AM UTC

cogman10 wrote: post #177

forrestthewoods wrote: post #134

Earlier quoted context omitted.

If you’re trying to mutate a dictionary many times from many threads you’re going to have a bad time. The fix isn’t a faster mutex, it’s don’t do that.

Depends on the dictionary implementation. There's a number of thread safe dictionaries in the wild with varying degrees of parallelism performance. Pretty much all of them benefit from faster mutexes. For example, some thread safe dictionaries will segment their underlying key/value pairs which allows them to have concurrent reads and writes for a given segment which significantly improves performance.