5 ms·
That's not shifting goalposts, that's the goal from the start. You seem to be throwing a lot of technical terms. Could you elaborate on where exactly do you se
by deprave 10y ago
That's not shifting goalposts, that's the goal from the start.
You seem to be throwing a lot of technical terms. Could you elaborate on where exactly do you see overhead coming from in a multiprocess vs. multithread architecture? And which data structures can be shared between threads but not between processes?
Scheduling overhead is identical and pure OS memory overhead is slightly higher for processes (they need more "accounting" data), but everything else can be optimized at the application level. Furthermore, shared memory lets you share data structures between processes just fine (heck, some data can be shared between processes and the kernel!), and since I assume the content processes will be dynamically linked, you're not even going to load shared libraries multiple times.
- the8472 10y ago> shared memory lets you share data structures between processes In theory maybe. In practice data structures contain pointers, which you can't just shove into cross-process shared memory. Which in turn results in copying things and serialization/deserialization overhead when doing IPC. With multi-threading you can just share regular data structures (think std::map) and put them under locks or copy-on-write logic if they need to be modified. Of course you can share some large blobs, like pixel data or loaded files. But the major data churn consisting of many small, nested data structures involves copying and (de)serializing.