Print

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

[BionicMeatloaf]

Gonna be getting a new pc this year and I've always wanted to have a consistently good frame rate for dorf fort once I got to the 150+ dorf population range. What should I look for most?

[deathpunch578]

GPU does nothing.
a good CPU is important
RAM is very important, (have a lot of RAM, when I run DF it uses at least 45% at most it uses 57%)

[BionicMeatloaf]

RAM Hun? I kinda thought so. I was thinking of getting 64 gigs of DDR4 RAM to see how that would work

[jecowa]

CPU and RAM are important. Lots of dwarves require lots of pathfinding. Pathfinding can be a bit CPU-intensive.

People smarter than me have determined that cache misses are the biggest bottleneck of Dwarf Fortress, though. Dwarf Fortress has to run calculations on lots of data, and the CPU waiting for data is causing lag. You want fast RAM that can get the data to the CPU as-fast-as-possible. You want enough RAM so that you aren't having to use virtual memory (swap files). 64 GB is more than plenty.

Having a CPU with lots of cache is also helpful in getting the data to your CPU faster. Cache acts as a super-fast RAM. 

[warwizard]

  For any given memory size/CPU speed combo there is a fort that will crush it to it's knees, more RAM lets you have larger embarks, (like a 16X16 embark) More Dwarves 300 or more, and more items.  Faster CPU allows you to make more pathing decisions per second, which allows you to use larger rooms in your fort.
  I have typically used a 8X8 embark with 16 GB of RAM, but managed to run out of RAM with a 16X16 embark.
  My FPS is usually at the speed cap, and I'm running a 12 core 4.2 GHz i7 which was bleeding edge 6 years ago.
 As far as I know, DF is still single threaded, so set affinity for the DF program for the second core and everything else on the rest of the cores so DF is not competing with other programs for execution time on it's one thread.

  So match your memory/CPU mix to your usual play style and budget, laptops may have problems with heat when running a large fort, and will throttle down the CPU speed to match the heat load to the radiator capacity. (clean the dust bunnies out of your laptop's cooling fan radiator once in a while)

[Devast]

  For any given memory size/CPU speed combo there is a fort that will crush it to it's knees, more RAM lets you have larger embarks, (like a 16X16 embark) More Dwarves 300 or more, and more items.  Faster CPU allows you to make more pathing decisions per second, which allows you to use larger rooms in your fort.
  I have typically used a 8X8 embark with 16 GB of RAM, but managed to run out of RAM with a 16X16 embark.
  My FPS is usually at the speed cap, and I'm running a 12 core 4.2 GHz i7 which was bleeding edge 6 years ago.
 As far as I know, DF is still single threaded, so set affinity for the DF program for the second core and everything else on the rest of the cores so DF is not competing with other programs for execution time on it's one thread.

  So match your memory/CPU mix to your usual play style and budget, laptops may have problems with heat when running a large fort, and will throttle down the CPU speed to match the heat load to the radiator capacity. (clean the dust bunnies out of your laptop's cooling fan radiator once in a while)

Can you provide more details?
I've got ...
Intel Core i7 6700K
Corsair Vengeance 16GB (2x8GB) 3000MHz DDR4 in white, 15-17-17-35,
and DF is actually on a Samsung 950 Pro 256GB M.2 SSD

and I still am not game enough to try an embark larger than 6x6 with 200 dwarfs.

I would love to go super huge 16x16 - 300 dwarfs but I doubt that will be possible unless hardware stats starts increasing by good %

[Seolferwulf]

The trend for CPUs is the processing power for individual cores goes down, since the latest CPUs rely on multi-threading.
An older single-core might actually work better for DF.

[Putnam]

The trend for CPUs is the processing power for individual cores goes down, since the latest CPUs rely on multi-threading.
An older single-core might actually work better for DF.

Incredible. Every single word of that is wrong.

Here's a basic example: https://www.cpubenchmark.net/compare.php?cmp[]=1081&cmp[]=1955

A previous generation 1.7 GHz i7 (which indeed focuses on multithreading over single core performance just as you say, compared to the i5) compared to a 3.8 GHz Pentium IV. The Core i7, despite having less than half the clock speed, is still twice as good on a per thread basis, and it's not even the latest model.

Even if you compare to an AMD CPU, which absolutely focus on multi-core performance over single-core, such as the CPU on my computer, you'll still find that single core performance is better:

https://www.cpubenchmark.net/compare.php?cmp[]=1081&cmp[]=1782

Single-core performance has absolutely been improving over the years.

[Devast]

The trend for CPUs is the processing power for individual cores goes down, since the latest CPUs rely on multi-threading.
An older single-core might actually work better for DF.

Incredible. Every single word of that is wrong.

Single-core performance has absolutely been improving over the years.

The single core difference between a 2600k and a 8700k according to
http://cpu.userbenchmark.com/Compare/Intel-Core-i7-2700K-vs-Intel-Core-i7-8700K/1985vs3937

is 39% or 6.5% a year.

[Putnam]

There is no doubt that there is a downward trend in the speed CPUs are getting faster over time; the difference between 2007 and 2017 is not nearly the difference between 1997 and 2007, absolutely. However, to say that "The trend for CPUs is the processing power for individual cores goes down" is wrong, and to say "An older single-core might actually work better for DF." is absolutely wrong.

[warwizard]

  Well I doubt you can get a single core proc these days in new hardware, what I was advising was to optimize the core affinity for dwarf fortress to be the only thread allowed to use that core, all the other overhead is put off on other cores. That is different from saying single core is better. The average operating system has dozens of services and applications running along with whichever program/s you are running, by setting the processor core affinity in the task manager (in windows O/S) you can force all those other processes to use any core except the one you have selected for DF. Look at the performance tab after you have set it up, you should see activity on every core except for the one for DF, until you start running DF, then that core should go to 100% usage.  Toady may have started the first steps towards multi threading, so test that by assigning DF to a couple of cores and see if the performance improves.
Here is my system info from 2012:
◦CPU_Name: Intel(R) Core(TM) i7-3960X CPU @ 3.30GHz 4.2 GHz factory overclock  (aprox 60 FPS in the benchmark shown https://www.anandtech.com/show/5091/intel-core-i7-3960x-sandy-bridge-e-review-keeping-the-high-end-alive/8    https://www.anandtech.com/bench/product/1260?vs=443 This 2nd is comparison with your proc, however my proc is at 4.2 GHz instead of 3.3 GHz as shown here, so you can see that I indeed have still very good performance, comparable to the latest processors.)
◦CPU_Manufacturer: GenuineIntel
◦CPU_Caption: Intel64 Family 6 Model 45 Stepping 7
◦CPU_Version:
◦CPU_ProcessorId: BFEBFBFF000206D7
◦CPU_CurrentClockSpeed: 1188MHz
◦CPU_AddressWidth: 64Bits

•Video_Caption: AMD Radeon HD 7900 Series
O/S is stored on SSD. Games are stored on SATA. DF runs from RAM with generally no swapping of modules into and out of memory unless you are running out of RAM, and then the dreaded page file starts getting used, so the SSD used for DF only affects the load time and store time, not the game's performance. The page file is another ball of worms, SSD's are 10X the speed of the SATA but also with only 1/10 the number of lifetime reads and writes. You should try to never use the page file if you can help it, rather than try to speed up the page file, the SSD is still 100X slower than RAM, and using SSD for heavy page file use is asking for an early death of the SSD.

[Putnam]

  Well I doubt you can get a single core proc these days in new hardware, what I was advising was to optimize the core affinity for dwarf fortress to be the only thread allowed to use that core, all the other overhead is put off on other cores.

Already advised not doing that earlier; modern-day OSes are hilariously good at scheduling stuff in that regard, the overhead from doing so is negligible compared to any other performance issues, performance may be negatively impacted due to the fact that you're using 1 core at 100% instead of 4 cores at 25%, 8 cores at 12.5%, 18 cores at 5.555...% etc.

[warwizard]

That works as advertised with a multithreaded application, I am discussing gaining some performance by not hopping the thread, the single thread of DF, from one core to another, there IS overhead for that.  Technical details to back that statement up available if demanded.  Toady has been making statements where in he is beginning to take the first steps towards making DF multithreaded. Once he does that, then the more cores the better, just as you are saying.

[Bumber]

That works as advertised with a multithreaded application, I am discussing gaining some performance by not hopping the thread, the single thread of DF, from one core to another, there IS overhead for that.

I don't think it would be significant, since the cloned thread is probably already up and running before the hop occurs.

[warwizard]

  OK. A little discussion of what is meant by single threaded appears to be needed here.

  A modern core runs two threads, when the core is dedicated to a single thread it pre-fetches both branches of any decision one in each thread, in other words it runs the same code in both sides of the core, the 'left' one takes the "yes" result and pre-fetches the next instruction as if the yes was the result of the test, the 'right' one takes the "no" result and pre-fetches the next instruction as if no was the result of the test. The branch that failed it's test is then loaded up with the next instruction that the branch that passed it's test takes. The end result is that it generally takes a few less clock cycles to process each decision than if the 2nd thread in that core was running a different program. The deeper you go in predicting decision points the more clock cycles you save. running the same program twice lets you go deeper into the future with your prefetching instructions into the pipeline.

  In order to swap the thread to another core the thread state is loaded to the new core. The thread state is as of the last instruction that the thread executed on the previous core, and includes the address of the instruction in physical memory and pointers to the register set the code is using. There is no keep on executing while the next core is loaded. Execution comes to a full stop and the state is saved, then some time later the thread state is loaded into a core to continue the execution. This may be the same core or another core, it does not matter.

  Multi threaded applications have many such threads all being progressed at different rates, as such it is not deterministic as to when the answer a thread is expecting from a second thread will be ready, hence the difficulty in coding for multi threaded operation is coordinating between the various threads, and is the reason Toady has not made DF multi threaded. There are serious redesigning of the entire program from the ground up required to make it multi threaded.