lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

61
active users

#mutex

0 posts0 participants0 posts today
Felix Palmen :freebsd: :c64:<p>More interesting progress trying to make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> suitable for very busy sites!</p><p>I realized that <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (both with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> and <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> queue as opposed to one protected by a <a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a>. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 😆</p><p>So I read some scientific papers 🙈 ... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 🤩 Maybe it could do even more, didn't try yet.</p><p>Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...</p><p>(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dl.acm.org/doi/10.1145/248052.</span><span class="invisible">248106</span></a></p>
Felix Palmen :freebsd: :c64:<p>Nice, <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>threadpool</span></a> overhaul done. Removed two locks (<a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a>) and two condition variables, replaced by a single lock and a single <a href="https://mastodon.bsd.cafe/tags/semaphore" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>semaphore</span></a>. 😎 Simplifies the overall structure a lot, and it's probably safe to assume slightly better performance in contended situations as well. And so far, <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>valgrind</span></a>'s helgrind tool doesn't find anything to complain about. 🙃</p><p>Looking at the screenshot, I should probably make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> default to *two* threads per CPU and expose the setting in the configuration file. When some thread jobs are expected to block, having more threads than CPUs is probably better.</p><p><a href="https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/Zirias/poser/commit</span><span class="invisible">/995c27352615a65723fbd1833b2d36781cbeff4d</span></a></p>
you╭👺+300╭🐈x5╭⁂+3╭(Ⓐ+a<p><a href="https://mastodon.social/tags/tui" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tui</span></a> <a href="https://mastodon.social/tags/daw" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>daw</span></a> for <a href="https://mastodon.social/tags/jack" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>jack</span></a> in <a href="https://mastodon.social/tags/rustlang" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>rustlang</span></a> </p><p>Rewrote the UI of the <a href="https://mastodon.social/tags/midi" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>midi</span></a> sequencer with <a href="https://mastodon.social/tags/ratatui" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ratatui</span></a> for double buffering.</p><p>We're polyphonic now! Multithreaded, too - I put a <a href="https://mastodon.social/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a> between input/render/audio threads instead of message passing.</p><p>Doesn't even properly support Note Off events yet, but it does play a mean cheerful dirge. Playback cursor position still off, though.</p><p>Hooking this up to the VST host every time I restart either is bit of a faff. Gotta teach it to auto-connect the MIDI/audio ports...</p>