Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[martinuzz]

Perhaps a dumb question, but how can I force dwarf fortress on one core, and make other processes stay off it on win7?

Beware that on most modern CPUs, this will *decrease* performance, unless you have a crazy over the top cooling rig.  The adaptive clocking routines, to over-simplify things, depend on being able to "overclock" a key core, let it heat up, and then shift the hot core's task to a different idle one when it gets close to being a problem.  This allows single-core tasks to run at a significantly higher clock rate than the chip could average over the whole surface simultaneously.  Locking a task (such as DF) to a single core defeats this, and will result in lower net performance. 

Good info, didn't know that!

[GenJeFT]

Unfortunately moving from single-threaded to multi-threaded processing is a far from trivial thing.
If you are REALLY lucky you can slice off some tasks and move them into separate threads (Maybe some stuff like pathing or temperature changes could be pre-calculated and then cached, making operations that use/implement that faster - only some idle guessing here)

It is entirely possible to slice off some tasks to separate threads. The guys over at http://www.seedofandromeda.com/ are doing that for their game. They actually split off the planet generation from the CPU and shoved it over to the GPU recently. So there are a lot of things that can be done.

[BoredVirulence]

Unfortunately moving from single-threaded to multi-threaded processing is a far from trivial thing.
If you are REALLY lucky you can slice off some tasks and move them into separate threads (Maybe some stuff like pathing or temperature changes could be pre-calculated and then cached, making operations that use/implement that faster - only some idle guessing here)

It is entirely possible to slice off some tasks to separate threads. The guys over at http://www.seedofandromeda.com/ are doing that for their game. They actually split off the planet generation from the CPU and shoved it over to the GPU recently. So there are a lot of things that can be done.

It depends on the nature of the task. Tasks that are independent can be split into different threads if the design isn't convoluted. Also, Toady has no interest in doing early optimization, which is understandable considering the state DF is in. Optimization to early can often lead to a lot of work rendered useless later, because the process changes. It can also help to identify problems early, and minimize their impact before your design becomes based on a flawed technique.

However, from a glance at functions that occur in DF, there are certain tasks that could definitely benefit from multi-threading. There are also a lot of tasks that could be offloaded to the GPU for optimization. But I totally understand why Toady wants to do the fun work before optimization. I'd really hate to write a lot of code to perform map functions (some pathing, temperature, pressure, etc.) on the GPU, only to find later I have to redesign how the map stores information, rendering that optimization useless.

This is the kind of thing we could argue on for ages and never find the right answer, because frankly I think the answer depends on the situation. However, back on topic, I find that multi-tasking works better when you start out thinking about it, rather than force an old code base into different threads.

[Deboche]

I think our best bet is for tech-savy users to spot stuff like this:

Stopped some CPU-intensive temperature wobble (ag)

easily fixable stuff that's not hardcore optimization

[Lemunde]

One suggestion I keep hearing is to set gen a world with a shorter history by setting the end year to something low. I would suggest as an alternative to lower the site cap. In my experience lowering the site cap to around 200 (from over 1000 on a medium world) makes world gen go by super fast and still leaving plenty of sites to explore. I think this mainly affects how many farms and such get generated around settlements as time goes on. As these tend to clog up the map anyway I don't have a problem with having less of them.

Also consider lowering your population cap in d_init. After the last update this feature is now actually working properly. You really don't need more than 50 dwarves to have an effective fortress. My last fortress had a population cap of 35 and somehow I ended up with a king around year 2, although this might have been a bug or a rare occurrence.

Lowering the number of cavern layers also significantly improves performance and is ideal if you want to make a larger embark.

[Panando]

Unfortunately moving from single-threaded to multi-threaded processing is a far from trivial thing.
If you are REALLY lucky you can slice off some tasks and move them into separate threads (Maybe some stuff like pathing or temperature changes could be pre-calculated and then cached, making operations that use/implement that faster - only some idle guessing here)

Multi-threading is certainly far from trivial, for a game like DF the clear winner would seem to be some kind of concurrency model like goroutines (coroutines, microthreads, it goes by various names). That is, rather than trying to break up the processing into 2 or 3 tasks which can be run on different cores, you break it up into thousands of separate tasks, that can be distributed over the number of available cores. This would tend to be easier because in a game like DF, there might be 200 creatures, each of which has to make some decisions each tick, often which will involve pathfinding (very expensive), so you assemble all the jobs which need to be done, have them executed on the available cores, then bring the results together (in proper order) and have all the units make their moves in order -  so you aren't losing determinism.
This is potentially an extremely powerful model for concurrent execution, but of course the code needs to be written for this model (and ends up dependent on a concurrency library or even programming language).