[Hnefi]

> DF's simulation model is deterministic. Most aspects of it depend on prior aspects.

I don't see what that has to do with using parallel programming to improve the performance of DF's simulation. If you are implying that threading implies nondeterministic behaviour in a simulation, you are mistaken. In fact, a system with such a discrete space model as DF would be quite easy to parallelize in a safe and deterministic way, with the proper expertise and forethought.

[eropple]

Sorry, you're right. Nomdetermimistic isn't the right word. "Heavily shared" might be better: it isn't perfect cellular automata, a lot of the game word cheats in a way that would necessitate really weird locking or sweeping changes of the game world. Couple that disruption with Toady not really understanding that sort of architecture and I can't see him ever being okay with other people doing it. He'll learn to do it when he absolutely has to.

[Hnefi]

The lack of perfect cellular automata isn't an obstacle either. One of the simplest and most robust way of doing parallellization of a system like DF avoids all such issues in a very simple way with no almost no synchronization needed.

Basically, when starting the game, spawn X threads and partition the world between them so that only one thread can write to any particular world block. Then, when calculating a new frame, make a read-only copy of the previous world frame. Any reads are done from that copy; any writes obviously occur only in the blocks assigned to a particular thread. Wait for all threads to complete, then render thread. No messaging, locking, event handling or whatever needed. Just care and forethought.

But you are right that Toady likely not possessing that kind of knowledge. That's the very reason why people would like to see others involved for things like optimization and UI design and the main point these people are trying to make; Toady seems either not able or willing to do it himself, and it could improve the state of the game tremendously.