Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fastest Mutexes

justine.lol

Post reply on HN
Print view View original

151–160 of 360 posts

Re: The Fastest Mutexes

#151

Post by bmacho »

0x1ceb00da wrote: post #89
amiga386 wrote: post #82

Earlier quoted context omitted.

APE works through cunning trickery that might get patched out any day now (and in OpenBSD, it has been). Most people producing cross-platform software don't want a single executable that runs on every platform, they want a single codebase that works correctly on each platform they support. With that in mind that respect, languages like go letting you cross compile for all your targets (provided you avoid CGO) is deli…

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.

Justine has similar claims about POSIX allowing binary in shell scripts now

> This is an idea whose time has come; POSIX even changed their rules about binary in shell scripts specifically to let us do it.

https://justine.lol/cosmo3/

> Jilles Tjoelker from the FreeBSD project played an instrumental role in helping me to get the POSIX rules changed to allow binary in shell scripts, which is what made this project possible.

https://justine.lol/ape.html

but that's not true, as recently discussed here: https://news.ycombinator.com/item?id=41636569

Re: The Fastest Mutexes

#152

Post by favorited »

betimsl wrote: post #144

And here I thought musl was better than libc sigh

musl is a libc, and while it is superior in some ways, it is inferior in others. If you want a statically linked libc, or a permissively licensed libc, musl is a fantastic choice. If you want a libc with the fastest malloc implementation, you'll probably want to look elsewhere.

Re: The Fastest Mutexes

#153

Post by jcranmer »

hinkley wrote: post #62
zozbot234 wrote: post #35

Earlier quoted context omitted.

The "volatile" keyword should never be used for C/C++ multithreaded code. It's specifically intended for access to device-mapped addresses and does not account for any specific memory model, so using it for multithreading will lead to breakage. Please use the C/C++ memory model facilities instead. (As a contrast, note that in Java the "volatile" keyword can be used for multithreading, but again this does not apply to…

I’m surprised that’s true. C borrowed very heavily from Java when fixing the NUMA situations that were creeping into modern processors.

The C/C++ memory model is directly derived from the Java 5 memory model. However, the decision was made that volatile in C/C++ specifically referred to memory-mapped I/O stuff, and the extra machinery needed to effect the sequential consistency guarantees was undesirable. As a result, what is volatile in Java is _Atomic in C and std::atomic in C++.

C/C++ also went further and adopted a few different notions of atomic variables, so you can choose between a sequentially-consistent atomic variable, a release/acquire atomic variable, a release/consume atomic variable (which ended up going unimplemented for reasons), and a fully relaxed atomic variable (whose specification turned out to be unexpectedly tortuous).

Re: The Fastest Mutexes

#154

Post by 0xDEADFED5 »

ngoldbaum wrote: post #112
pizlonator wrote: post #23

Always cool to see new mutex implementations and shootouts between them, but I don’t like how this one is benchmarked. Looks like a microbenchmark. Most of us who ship fast locks use very large multithreaded programs as our primary way of testing performance. The things that make a mutex fast or slow seem to be different for complex workloads with varied critical section length, varied numbers of threads contending,…

This style of mutex will also power PyMutex in Python 3.13. I have real-world benchmarks showing how much faster PyMutex is than the old PyThread_type_lock that was available before 3.13.

Can I use PyMutex from my own Python code?

Re: The Fastest Mutexes

#155

Post by dundarious »

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…

Mozilla llamafile uses it. Bundles model weights and an executable into a single file, that can be run from any cosmo/ape platform, and spawns a redbean http server for you to interact with the LLM. Can also run it without the integrated weights, and read weights from the filesystem. It's the easiest "get up and go" for local LLMs you could possibly create.

Re: The Fastest Mutexes

#156

Post by akira2501 »

Production isn't about speed, efficiency, or obviously "clever hacks."

If I have to sacrifice 50% of my efficiency to ensure that I never get called on Sunday at 3am to fix a broken system, no kidding, I'll make that trade every time.

Production is about _reliability_. And writing reliable code is 10x harder than writing "fast" code.

Re: The Fastest Mutexes

#157

Post by jart »

jonathrg wrote: post #104
fefe23 wrote: post #92

Earlier quoted context omitted.

Have you considered that you may have a different kind of humor than Justine? Why would you even post this here? Who do you think this is helping?

It doesn't clearly come across as a joke.

It's a splash of dry humor on a personal blog in an information dense article.

Re: The Fastest Mutexes

#158

Post by kgeist »

>Contention is where mutex implementations show their inequality. Mark was so impressed by Microsoft's SRWLOCK that he went on to recommend Linux and FreeBSD users consider targeting Windows if mutex contention is an issue.

Interesting, I remember reading a detailed article where they found that there's a lot of severe contention in the Windows kernel, compared to Linux. I think it was when they were trying to parallelize Chrome builds?

Re: The Fastest Mutexes

#159

Post by cyberax »

jrockway wrote: post #149
cyberax wrote: post #141

Earlier quoted context omitted.

> With that in mind that respect, languages like go letting you cross compile for all your targets (provided you avoid CGO) Even that is not a big deal in most of cases, if you use zig to wrap CC: https://dev.to/kristoff/zig-makes-go-cross-compilation-just-...

Does this still work? The article is from 2021 but when I last tried it this year, Go appeared to (newly) depend on headers that Zig doesn't need and thus it doesn't work. The Github issue was something like "yeah, we don't need those, so I guess Go doesn't work anymore". Without the actual error message I can't find the issue, however, so maybe I imagined this.

Yes, I use it in my PKCS#11 client glue code.

Re: The Fastest Mutexes

#160

Post by [deleted] »

bjourne wrote: post #138
hyperion2010 wrote: post #107

Earlier quoted context omitted.

> Most people We'll I'm used to not being most people, but I'd much rather be able to produce a single identical binary for my users that works everywhere than the platform specific nonsense I have to go through right now. Having to maintain different special build processes for different platforms is a stupid waste of time. Frankly this is how it always should have worked except for the monopolistic behavior of vari…

The binary is only one part of the puzzle (and largely solved by WSL). Installation/uninstallation and desktop integration is just as much of a hassle.

[deleted]
Post reply on HN