All those people who complain about project names squatting on existing words have finally been heard :-D
[flagged]
Otherwise known as "cd p."
Peredvizhnikov Engine: Lock-free game engine written in C++20
21–30 of 183 posts
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#22I don't have time to read through the impl, but the readme makes it sound like a classic distributed system between game threads, where patterns like retry-backoff will be common.
The paper goes into more detail without forcing you to go into the impl but it does seem to be a decent bit more advanced than that.
https://github.com/eduard-permyakov/peredvizhnikov-engine/bl...
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#23Does anyone have experience debugging/profiling highly contended critical sections of STM vs a more traditional mutex implementation? At the end of the day something has to mediate concurrent access to shared memory, there’s no free lunches, and mutexes are so well optimized, profiled, and understood. I’m unclear if the same applies to STM where a transaction may need to be retried an unbounded(?!) number of times.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#24[flagged]
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#25[flagged]
Forgive me if it’s common knowledge, but what’s wrong with SDL2 in this case? Broadly speaking, I feel as though there is largely positive sentiment around the SDL project, no?
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#26Does anyone have experience debugging/profiling highly contended critical sections of STM vs a more traditional mutex implementation? At the end of the day something has to mediate concurrent access to shared memory, there’s no free lunches, and mutexes are so well optimized, profiled, and understood. I’m unclear if the same applies to STM where a transaction may need to be retried an unbounded(?!) number of times.
Yes. The mediator in this case is the scheduler. The one that actually calls the asynchronous block. Potentially retrying it if it fails. In the OP’s code, there’s atomic blocks, sequential execution of blocks, stateful blocks, etc for ensuring singular access at a time.
The meat here is scheduler.cpp. It uses std::coroutines.
This is like async/await in other languages. The scheduler has a queue of work(coroutines) and a pool of threads(N>0) to execute those on.
In this case, messages are passed between work that contains the data. No locks are required at the expense of memory footprint.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#27I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…
With a post like this, however interesting, you really should link the code. Not only will it prove your claim, but others like me will find the idea intriguing and immediately want to see how it's done.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#28[flagged]
Forgive me if it’s common knowledge, but what’s wrong with SDL2 in this case? Broadly speaking, I feel as though there is largely positive sentiment around the SDL project, no?
I have nothing against the SDL project. I have everything against the DirectMedia style api of 1997. I get that people are actively developing with it and that roadmap towards 3.0 is getting close but my experience is it’s designed for legacy games, legacy rendering styles, legacy ABI’s. No one is shipping games for Dreamcast or PS2.
2/3rds of the library is dead code when working with Vulkan.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#29I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…
how do you deal with msvc's `std::deque`? (or maybe you're not using literal std::dequeue)
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#30I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…
My benchmarks show that the price is acceptable
Well, except to people who have a hard requirement that there never be this unpredictable, infrequent longer delay you mention.