Counting Fast in Erlang with:counters and:atomics
https://andrealeopardi.com/posts/erlang-counters-and-atomics/
#HackerNews #Erlang #FastCounting #counters #atomics #programming
Counting Fast in Erlang with:counters and:atomics
https://andrealeopardi.com/posts/erlang-counters-and-atomics/
#HackerNews #Erlang #FastCounting #counters #atomics #programming
Counting Fast in Erlang with:counters and:atomics
Erlang의 :atomics와 :counters 모듈은 BEAM VM 내에서 고성능 동시성 카운팅을 지원하는 새로운 공유 메모리 데이터 구조입니다. :atomics는 CPU 수준의 원자적 연산과 순차적 일관성을 제공해 동기화에 적합하며, Broadway의 레이트 리미팅 기능에 활용됩니다. :counters는 각 스케줄러별로 분산된 카운터를 유지해 쓰기 성능을 극대화하며, 읽기 작업이 적은 상황에 적합합니다. ETS 대비 높은 동시성 처리량과 명확한 의미론적 차별점을 갖고 있어, Erlang/Elixir 동시성 프로그래밍에서 적절한 도구 선택에 도움을 줍니다.
https://andrealeopardi.com/posts/erlang-counters-and-atomics/
Деконструкция GO: CPU, RAM и что там происходит. Reordering, atomics, locks, fences. Часть 1.3
С постановкой проблем в прошлой статье мы почти закончили и вывели самое важное – природу состояния гонки и состязания за кэш. В этой статье мы также разберем оптимизацию, порождающую часть проблем синхронизации – instructions reordering , а также механизмы решения вышеуказанных проблем. В этот раз снова будет Go Assembler, а также снова будут примеры на Go. В прошлый раз это было необходимое зло во имя соответствия реальности Напоминаю, что эта статья – часть большого цикла разбора языка программирования Golang End 2 End. Но если вы уверены, что понимаете природу многозадачности, многопоточности, проблемы оных, а также то, как выполняются инструкции и пришли разбираться в самых примитивных механизмах синхронизации, то велком Instructions reordering Обычно мы считаем, что CPU добросовестно выполняет свои инструкции последовательно. Ровно так, как мы ему сказали. Но это не всегда верно! Допустим есть код
https://habr.com/ru/articles/1025292/
#go #assembly #cpu #atomics #memory #memorybarrier #reordering #data_race #cache_contention
C++Now 2026 SESSION ANNOUNCEMENT: Thinking in Nanoseconds - A Mental Model for Ultra Low Latency C++ by Namrata Priyadarshani
https://schedule.cppnow.org/session/2026/thinking-in-nanoseconds/
Register now at https://cppnow.org/registration/
Edit: solved, thanks Paul!
Any bored #RustLang atomics enthusiast around? I'm trying to write a kind of global unique id allocator using fetch_add and compare_exchange but now I'm not even sure if it's possible with the right orderings or if I should just do the simple thing and wrap it in a mutex ...
C++Now 2026 SESSION ANNOUNCEMENT: When Atomics Lose - Architecture Dependent Performance of C++ Synchronization by Sampad Acharya
https://schedule.cppnow.org/session/2026/when-atomics-lose/
Register now at https://cppnow.org/registration/
Please help me spread the link to #swad 😎
https://github.com/Zirias/swad
I really need some users by now, for those two reasons:
* I'm at a point where I fully covered my own needs (the reasons I started coding this), and getting some users is the only way to learn about what other people might need
* The complexity "exploded" after supporting so many OS-specific APIs (like #kqueue, #epoll, #eventfd, #signalfd, #timerfd, #eventports) and several #lockfree implementations based on #atomics while still providing fallbacks for everything that *should* work on any #POSIX systems ... I'm definitely unable at this point to think of every possible edge case and test it. If there are #bugs left (which is somewhat likely), I really need people reporting these to me
Thanks! 🙃
Next #swad release will still be a while. 😞
I *thought* I had the version with multiple #reactor #eventloop threads and quite some #lockfree stuff using #atomics finally crash free. I found that, while #valgrind doesn't help much, #clang's #thread #sanitizer is a very helpful debugging tool.
But I tested without #TLS (to be able to handle "massive load" which seemed necessary to trigger some of the more obscure data races). Also without the credential checkers that use child processes. Now I deployed the current state to my prod environment ... and saw a crash there (only after running a load test).
So, back to debugging. I hope the difference is not #TLS. This just doesn't work (for whatever reason) when enabling the address sanitizer, but I didn't check the thread sanitizer yet...