a quick writedown of an idea of mine to enable parallel processing (in special for LT)


in LT every object has its own data area in the general ram base.
to enable changing of this data one needs to "lock" the data area,
reserve it to a single thread to prevent write collisions.

this processing sheme removes the need for locks (or at least minimizes it)


at first we create an independent thread for every object we want to process

the threads only read the data out of the shared memory, to prevent locks.

the write orders the threads process needs to make get collected into a pool of messages,
specific to the objects
for example a message can contain "20 damage on ship #a3f5c0"

this individual message pools get summarized by another group of threads, one for every object
this threads make from
"20 dmg to ship #a3f5c0"
"15 dmg to ship #a3f5c0"
"25 dmg to ship #a3f5c0"
"20 dmg to ship #a3f5c0"
a single change request of
"80 dmg to ship #a3f5c0"

this summarized up change request messages get handled by a last, single thread
which gets started after all the change requests are summed up

this last thread can lock the memory for a single, large batch of changes to the memory
removing the need for locks specific to single threads.

while the last thread has to process all of the change requests, every request is a quick change which does not need
much processing time.

as the important processing was already handled by the first group of threads




i dont know if this is feasible

especially creating large swathes of threads could clog the cache,
but this is a matter of balancing nr of threads vs nr of objects per thread

just had to get this away

*graphics will be added tomorrow when i get back to my computer

There's also a difference between multi-threading, multiple handles, and multiple processes when it comes to the coding level.

Multi-threading is relatively easy, as can be outlined here. Yeah, there's some overhead that is added by creating locks and checking to see if locks are in place before trying to access data. That's easy.

However, the problem arises with the way cores handle such code. That may be multi-threaded, but it still ends up running on the same core. In order to truly take advantage of multiple cores, you need to be able to do multiple processes. This becomes much more difficult because at the hardware level, it enforces apps to run on a per-core basis rather than splitting across multiple cores.

If it were as easy as just checking locks and all that, you'd be finding much more programming taking advantage of using multiple cores. But when the hardware level requires things to run in their own memory space, you get these issues.

Realistically, in order to efficiently be able to utilize multiple cores/CPUs, you would want a holy grail of a compiler that is able to take the code and compile it to a multi-process binary. Anything else and you're just adding unnecessary work to be able to run multiple handles on the same core.

well, there are libraries for doing that, like Cilk Plus where you just have to implement a sheme like i outlined, and the library takes care of the rest (of course you have to mark the regions you want to split).

but as the title said, its just rambling what i wrote ^^


edit Cilk seems to be easily implementable afterwards too...

it may be usable without mayor code-ripping, while also providing potential massive speed ups