Live data from Hacker News

Peredvizhnikov Engine: Lock-free game engine written in C++20

github.com

111–120 of 183 posts

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#111
post #103

Earlier quoted context omitted.

It's a requirement for any game that needs a reliable frame rate. Unpredictable delays during frame rendering cause jank. (This is not to say the OP has any such issues in its context.)

"Unpredictable delays during frame rendering cause jank" This is usually not serious inflicted and the presentation threads will be higher priority than the simulation in order to minimize visual 'jank' Lockfree game code ain't fixing jank from the OS.

[deleted]

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#112

I 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…

Thank you for sharing this.

Could you tell me if your 10 million figure includes batching or are they a loop that tries to enqueue as many items as possible?

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#115

Actors is one of the worst programming models possible. It's hard to observe actor-based systems and debug them. The protocol complexity (and complete protocol informality) usually brings much more trouble than any kind of locking/synchronization.

I’ve had good success with actor based models. When you say “protocol complexity”, I don’t understand what you mean.

Observation requires good logging, but this isn’t out of line for any complex system. Debugging (as in actual breakpoints in an IDE or post-mortem analysis) can be facilitated with stack tracking (this same problem occurs with async await patterns and is solved in a similar way).

The advantages and disadvantages exist, but I think it’s an extremely effective programming model for many use cases. Formal state-machine programming, that’s the worst model, unless you need it.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#116
post #105

Earlier quoted context omitted.

July console sales: PS5: 1.2m Switch: 950k Xbox: 370k Xbox accounts for just 17% of total console sales in July Both Switch and PS5 are FreeBSD based If we count the whole period of the current gen of each vendors, it only accounts for 13%, it's not big https://www.vgchartz.com/

Actually its only the PS5 that's FreeBSD based. Switch runs a completely proprietary Nintendo OS that borrows a lot from Android.

A mix of the two

"partially Unix-like via certain components which are based on FreeBSD and Android"

https://en.wikipedia.org/wiki/Nintendo_Switch_system_softwar...

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#117
post #80

I 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…

Aren't lock free data structures more about reducing the impact of contention than throughput under low contention?

Depends what you mean by “the impact of contention”. It is possible, if you build a lock-free system, to end up with threads that keep churning and never make forward progress.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#118
post #64

It says that it's actor-based, and sending messages to an actor is equivalent to running the actor function under a mutex, and thus reduces parallelism (in other words, you have N threads sending messages, but only 1 thread running the actor code, so it's just as serialized as a mutex), so while it may technically be "fully lock-free", using actors means that there is no parallelization improvement.

> sending messages to an actor is equivalent to running the actor function under a mutex Where does it say that? In my understanding actor model means message-passing with asynchronous execution. So quite the contrary, actor model allows N threads executing in parallel given N actors.

Whenever I read any press about actors or goroutines, they say the same thing about preventing races (and the need for explicit locking) through share-nothing concurrency.

It's easy to scatter the computations, but they never go on to explain how to gather them back up.

You're going to render one frame to the screen. Did multiple actors have a write-handle into the frame buffer? What about collisions, does each entity collide with itself, without sharing position information with other actors?

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#119

Earlier quoted context omitted.

bullshit, consoles/mobile are bigger markets than PC/Windows PC is just less than 1/3 of the whole picture https://www.data.ai/en/insights/mobile-gaming/2022-gaming-sp...

He's probably referring to the Desktop/laptop market. In which case windows controls like 90%.

Title is: "Peredvizhnikov Engine is a fully lock-free game engine written in C++20 "

A Game Engine targets various platforms

A "video-game" is not something exclusive to desktop/laptop windows market

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#120
post #80

I 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…

Aren't lock free data structures more about reducing the impact of contention than throughput under low contention?

Lock free is kind of an overloaded term that can mean a variety of things depending on what the user is thinking. Usually the goal is being able to make forward progress even if one thread is context switched out by the OS scheduler, which might be called wait-free or non-blocking. Using mutexes (unless you can prevent OS scheduling, interrupts, etc) makes this property impossible to achieve. In general, MPSC queues are super fast and there's no real reason to prefer a locked queue.
Post reply on HN