Welcome Guest Search | Active Topics | Log In | Register

Multi core serialization
#1 Posted : Thursday, July 27, 2017 3:14:46 PM(UTC)
Rank: Member

Groups: Registered
Joined: 4/24/2012(UTC)
Posts: 25
Location: Netherlands

Thanks: 3 times
Was thanked: 0 time(s) in 0 post(s)
Hi all!

For a long time I'm trying to speed up the serialization process of the entire VM of our game. Currently it basically iterates through the roottable and serializes every object that is in it. Because our game needs to be persistent we need an exact snapshot of the VM, the moment a player enters a checkpoint. Depending on the number of entities and objects in a level, this serialization time is pretty long. The player notices a significant framedrop; depending on the speed of a CPU core.

Question: since it is a read-only process, is it in any way possible to share the workload over multiple cores? I know that the language itself is not multithread safe; so starting multiple serialization threads on the same VM is a bad idea. But in theory multiple VMs should have no interference with each other.

Would it be possible to setup multiple VMs (each with their own stack) at the start of the serialization process, each VM running at a separate core, and then share the iteration process over those cores? This way I can theoretically speed up the serialization process significantly. Only question is, is it possible to quickly setup multiple VMs that each use the same roottable? And would it be safe to do read-only operations on those?

Or if someone has another idea on how to speed this up, let me know!




Users browsing this topic
Guest (2)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.107 seconds.