coroactors
Medo
coroactors | Medo | |
---|---|---|
1 | 12 | |
10 | 143 | |
- | - | |
8.8 | 4.5 | |
about 2 months ago | 9 months ago | |
C++ | C++ | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
coroactors
-
Peredvizhnikov Engine is a fully lock-free game engine written in C++20
When you protect an std::deque with a mutex you would need at least two atomic operations: to lock the queue before pushing, and to unlock the queue after pushing. Because you're using an std::deque it may need to allocate memory during a push, which would happen under the lock, which makes it more likely for a thread to suspend with the lock taken. While the queue is locked other threads will have to wait, possibly even suspend on a futex, and then the unlocking thread would have to wake another thread up.
The most expensive part of any mutex/futex is not locking, it's waking other threads up when the lock is contended. I'm actually surprised you only get 10 million messages per second, is that for a contended or an uncontended case? I would expect more, but it probably depends on the hardware a lot, these numbers are hard to compare.
My actor framework currently uses a lockfree intrusive mailbox [1]_, which consists of exactly two atomic exchange operations, so pushing a node is probably cheaper than with a mutex. But the nicest part about it is how I found a way to make it "edge triggered". A currently unowned (empty) queue is locked by the first push (almost for free, compared to a classic intrusive mpsc queue [2]_ the second part of push uses an exchange instead of a store), which may start dequeueing nodes or schedule it to an executor. The mailbox will stay locked until it is drained completely, after which it is guaranteed that a concurrent (or some future) push will lock it. This enables very efficient wakeups (or even eliding them completely when performing symmetric transfer between actors).
I actually get ~10 million requests/s in a single-threaded uncontended case (that's at least one allocation per request and two actor context switches: a push into the target mailbox, and a push into the requester mailbox on the way back, plus a couple of steady_clock::now() calls when measuring latency of each request and checking for soft preemption during context switches). Even when heavily contended (thousands of actors call the same actor from multiple threads) I still get ~3 million requests/s. These numbers may vary depending on hardware though, so like I said it's hard to compare.
In conclusion it very much depends on how lockfree queues are actually used, and how they are implemented, they can be faster and more scalable than a mutex (mutex is a lockfree data structure underneath anyway).
I'd agree with you in that mutexes are better when protecting complex logic or data structures however, because using lockfree interactions to make it "scalable" often makes the base performance so low, that you'd maybe need thousands of cores to justify the resulting overhead.
.. [1] https://github.com/snaury/coroactors/blob/a599cc061d754eefea...
Medo
- Peredvizhnikov Engine is a fully lock-free game engine written in C++20
-
De-Bloated Windows 11 Build Runs on 2GB of RAM
To me the most impressive recent example is a video editor developed for Haiku OS [0]. It fits on a 1.44MB floppy disk.
[0] https://github.com/smallstepforman/Medo
-
LosslessCut: The Swiss Army Knife of Lossless Video/Audio Editing
> does anybody know of an editor capable of cutting between inter frames?
https://github.com/smallstepforman/Medo
- A C++17 thread pool for high-performance scientific computing
-
Ask HN: How were video games from the 90s so efficient?
I’ve created a 4k UHD video editor for Haiku OS (https://github.com/smallstepforman/Medo), it’s a C++17 native app, with over 30 OpenGL GLSL effect plugins and addons, multi threaded Actor model, over 10 user languages, and the entire package file fits on a 1.44Mb floppy disk with space to spare. If I was really concerned about space, I could probably replace all .png resources with WebP and save another 200kb.
How is it so small? No external dependancies (uses stock Haiku packages), uses the standard C++ system API, and written by a developer that learned their trade on restrained systems from the 80’s. Look at the old Amiga stuff from that era.
-
HaikuOS running on real RISC-V hardware
At its core, Linux offers variety, while Haiku strives to be a unified system. There is only one official UI, one sound API, one filesystem, one preference system, etc. making Haiku easier to administer. The system kits are designed to work together.
For instance, I created a from scratch video editor for Haiku which does 4K UHD videos with OpenGL based plugins, with over 30 effects, and 10 languages. The installer package with no dependancies is 1.3Mb (fits on a floppy disk). https://github.com/smallstepforman/Medo Under Linux, I would require many more dependancies since I have so no guarantee what libraries or API the users have installed.
-
What GUI Library do you use?
My favourite - BeOS/Haiku Interface Kit (Link to my project with screenshot https://github.com/smallstepforman/Medo).
-
How to Use CMake Without the Agonizing Pain - Part 1
You can always use both ... example from my project: https://github.com/smallstepforman/Medo
-
Linux, macOS, and Windows running simultaneously on a first gen Core i5
Wait until you try Haiku on the same hardware. I’ve got a 4K video editor with no HW acceleration yet is smoother to edit videos than both OSX and Win10.
https://github.com/smallstepforman/Medo/raw/main/Docs/Medo.j...
-
Announcement: Haiku Media Editor - R1.0.0, Beta 1
https://github.com/smallstepforman/Medo It is for a opensource Media Operating System called Haiku Os, and it is less than 1.44 Mb open source very lightweight:
What are some alternatives?
peredvizhnikov-engine - A fully lock-free game engine written in C++20
xhyve - xhyve, a lightweight OS X virtualization solution
cmake-init - The missing CMake project initializer
thread-pool - BS::thread_pool: a fast, lightweight, and easy-to-use C++17 thread pool library
VoxelSpace - Terrain rendering algorithm in less than 20 lines of code
macOS-Simple-KVM - Tools to set up a quick macOS VM in QEMU, accelerated by KVM.
cmake-init-vcpkg-example - cmake-init generated executable project with vcpkg integration
OSX-KVM - Run macOS on QEMU/KVM. With OpenCore + Monterey + Ventura + Sonoma support now! Only commercial (paid) support is available now to avoid spammy issues. No Mac system is required.
Descent-2 - The Descent 2 source code.
micro-editor - A modern and intuitive terminal-based text editor
CMake - Mirror of CMake upstream repository
FTXUI - Features: - Functional style. Inspired by [1] and React - Simple and elegant syntax (in my opinion). - Support for UTF8 and fullwidth chars (→ 测试). - No dependencies. - Cross platform. Linux/mac (main target), Windows (experimental thanks to contributors), - WebAssembly. - Keyboard & mouse navigation. Operating systems: - linux emscripten - linux gcc - linux clang - windows msvc - mac clang