Re:The C++20 Naughty and Nice List for Game Devs
by jzwinck on Monday December 25, 2023 @10:14AM
(#38763247)
Instead of literally loading the plugin into the same address space as the host process, you could launch it as a separate process and use sockets or shared memory to communicate. With a slight shift in API design this might actually be better than traditional dynamically loaded plugins. It will tend to level the performance playing field across languages (e.g. no JNI penalty for plugins written in a JVM language). And it will prevent plugins crashing the host.
[ Parent
| on HN ]
Re:The C++20 Naughty and Nice List for Game Devs
by anarazel on Monday December 25, 2023 @10:24AM
(#38763338)
And the dispatch overhead will be a few orders of magnitude higher.
Re:The C++20 Naughty and Nice List for Game Devs
by jzwinck on Monday December 25, 2023 @11:30AM
(#38763865)
Passing a message via a shared memory queue (twice) is not 1000x slower than a non-inlineable function call.
Re:The C++20 Naughty and Nice List for Game Devs
by anarazel on Monday December 25, 2023 @11:46AM
(#38763997)
With the associated context switch it's bigger, if anything. Busy looping to wait if some memory changes isn't really viable for many scenarios.
Re:The C++20 Naughty and Nice List for Game Devs
by gpderetta on Monday December 25, 2023 @11:42AM
(#38763959)
That actually seems about the right order of magnitude.
Re:The C++20 Naughty and Nice List for Game Devs
by kllrnohj on Monday December 25, 2023 @12:29PM
(#38764375)
You're right, but that's also not the entire workload. You have to also wake up the remote process in some way and, depending on the expected duration, probably wake up for the response. On pretty much all major platforms that work is measured in 10s of microseconds, which puts you easily into the 1000x slower than a non-inlineable function call category.