Print

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

[jei]

Suggestion: Please give players more control over issues that eat lots of CPU and cause the game to lag and slow down a lot. Current system can easily lead to "impossible to play" due to game being too slow.

[G-Flex]

The game already does this as much as is feasible, as far as I can tell. You can turn off weather and temperature, for instance.

[thijser]

Have you tried to go into the init files both the normal and the d_init?

[Medicine Man]

What we need is DF to run on multiple cores. So multi trolls kind Bay12 users such as myself can run it better.

[jei]

Have you tried to go into the init files both the normal and the d_init?

Yes, both weather and temperature are turned off in my case. I've done all I can, afaik. Now all I can do is buy a faster computer.

Multithreading would be a real improvement. I'm sure some tasks could be offloaded to another cpu.

[nuker w]

Yea, lags a huge bummer for me to. To get the best I can, I set GPS to 25, FPS cap to 0, temp and weather off, no graphics and turn it to real time (THE LAST ONE IS A HORROR FOR ALL THINGS BUT DF). Makes it hit 150 on 7 people? Good times.

[jei]

The game already does this as much as is feasible, as far as I can tell.

And as far as I can tell, it could and should do a lot more.

It is no longer a question of whether I like to play or not, but whether I really can play it or not at steady 1 FPS.

Maybe Toady has a supercomputer and he's suffering from typical developer syndrome of "everyone has this much cpu power"
resulting typically in slow code and even slower solutions used, than would be, if the developer had a shitty and slow computer to develop with.

In any case, I guess this is it for laptop playing.

[Dwarf]

He hasn't got a supercomputer. He's running the game in his mind with ~600 FPS and writing code on his netbook as it comes.

[nuker w]

NOTE: I got 150, as stated before, on a laptop with 1.86 GHz, 1526 RAM and is a Vista. So its not impossible. Just don't ever expect to get a King before going mad.

[jei]

NOTE: I got 150, as stated before, on a laptop with 1.86 GHz, 1526 RAM and is a Vista. So its not impossible. Just don't ever expect to get a King before going mad.

I would like to see you play and take on HFS and win with that FPS number too. I got as far as getting a king on a similar computer setup (not FPS), but hitting 0-1 FPS no matter what I do kinda eats my will to continue.

[zilpin]

He hasn't got a supercomputer. He's running the game in his mind with ~600 FPS and writing code on his netbook as it comes.

lmfao.  Toady's brain is a Cray.

DF is written in C.

Toady has done and is doing what he can to improve performance.  Particularly in the path finding optimizations.
But his time has to be split between bug fixes, new features, and speed improvement.  Of those three, one is critical but not fun, one is fun but not critical, and the last is neither fun nor critical.
He balances them d@mn fine, considering he's a 1 man band, here.

Yes, multithreading would vastly improve performance, and there is enormous potential for it in DF.  Most importantly, the UI needs to be in a separate thread.  Sure, putting pathing for water & lava in their own thread would have a huge performance bonus.
Have you ever written multitasking in C?  It is bloated and messy, bug-prone, and quite challenging.  It is difficult to implement correctly for a project designed from the start to use it, but it is downright hazardous to implement on top of an existing giant codebase.  He's not going to do it.  It is unreasonable to expect it.  Maybe, maybe, the UI will get it's own thread.  Maybe.

<technical jargon>
I've never seen the source code, but based on the data structures I've seen in dfhack and StoneSense, there is one area which could improve speed at the cost of ram.  Map tiles do not contain their own material information.  Instead, they have a lookup index into the global Geology array, which in turn contains vein information and lookup indicies into the global Materials array.  Caching the most important property information directly into the tile could have a noticeable performance increase, because every single pointer redirection requires the CPU to perform another fetch across the bus.  No CPU cache can be used when you hop around memory like that, and the code within the tight loop will effectively run at your bus speed instead of your full CPU speed (e.g. for most 2ghz processors today, the FSB is typically around 800Mhz).  Caching the values in the structure permits the CPU to pull the entire structure into its internal cache in one or two fetches, and Intel processors are impressively intelligent about this.  There are probably some other things that could be done to the tile structure to improve pathing speed, while that was done.  Since neither the material properties nor the geology data ever change during the course of the game, referential integrity is moot.  Additionally, since the values are merely being cached, the save game file format would not be changed.
</technical jargon>

But that would probably take a few weeks to implement, and introduce some quirks.  And its no fun to code.
I'll volunteer right now to do it.... but no source code == no work.


It all comes down to the four way split of Toady's time: Fixes, features, optimization, eat/drink/sleep/bathe/read forums.

He already sacrifices eat/drink/sleep/bathe a lot.
So which do you want to trade, Fixes or Features?

[G-Flex]

DF is written in C.

Nope, C++.

Toady has done and is doing what he can to improve performance.  Particularly in the path finding optimizations.

I honestly don't remember this; where'd he say that?

Yes, multithreading would vastly improve performance, and there is enormous potential for it in DF.  Most importantly, the UI needs to be in a separate thread.

Erm, the UI? Seriously? Why? If you mean graphics in general, they already are (in the SDL versions), but aside from that, the user interface probably isn't a big contender.

Have you ever written multitasking in C?  It is bloated and messy, bug-prone, and quite challenging.

Again, not using C, he's using C++. That said, a lot of the same still applies.

<stuff about data structures>

Yeah, it's my (very limited) understanding that DF does not store or access data in a very scalably-efficient manner at all. We could probably see major improvements there.

[orbcontrolled]

Yes, multithreading would vastly improve performance, and there is enormous potential for it in DF.

Toady already mentioned in the last DF talk that it's never going to happen in any significant way.

[zilpin]

Nope, C++.

Yes, apologies, I was speaking more generally, C/C++ family.  But keep in mind that DF was originally written in C with C++ classes later being added.  The legacy is still there, particularly in data structures and likely in coding style being used.

I honestly don't remember this; where'd he say that?

Teleporting water, comes to mind.  Everything used to use the same path finding algorithm, but now different simplified cases are used in the interest of speed.  Chained creatures, animals in general use a shorter distance for pathing.  All those add up, and any time Toady notices a chance for improvement, he takes it.

Erm, the UI? Seriously? Why? If you mean graphics in general, they already are (in the SDL versions), but aside from that, the user interface probably isn't a big contender.

Please reference Separation of Concerns.
By UI I don't just mean the rendering, I mean all user commands and interaction.  Menus, Dwarf information screen, etc.  Even in the SDL version, when the game lags every screen lags.
This is the most important not for actual performance, but for perceived performance and user expectation of response.  When a user wants to pause, or exit, or quit, it is important to execute post haste.
Responsiveness is key for user experience.

Again, not using C, he's using C++. That said, a lot of the same still applies.

Agreed.

Yeah, it's my (very limited) understanding that DF does not store or access data in a very scalably-efficient manner at all. We could probably see major improvements there.

Although I want to be clear that I am not poo-pooing Toady's implementation.
There are complex relationships between the data for a reason.
But there are data structure tricks that are key in performance and efficiency in C/C++.

[zilpin]

Yeah, it's my (very limited) understanding that DF does not store or access data in a very scalably-efficient manner at all. We could probably see major improvements there.

Some elaboration on data structure tricks in C/C++.

Example is how the data is packed.  Every compiler packs structures and objects differently.  My understanding of DF is that it uses C structures for most data instead of C++ objects, but without source code I can't know.  I would recommend keeping it that way.
If you have a structure which is defined like this:

Code: [Select]

struct ExampleStruct {
    unsigned char    TypeID;
    unsigned long    GeologyIndex;
}

The actual expected size of the structure is 5 bytes.  If the compiler packs the structure for memory efficiency, it will be 5 bytes long, but every access to the GeologyIndex will have a small time overhead, because modern computers work on either 32bit or 64bit boundaries.  So on a 32bit machine, accessing the 32bit long GeologyIndex requires grabbing two distinct 32bit blocks of memory, performing a bitshift and combining them.  It is a small overhead, done inside the processor, but it adds up inside of a tight loop, when processing 400 z-levels by 256 tiles by 256 tiles.

If the compiler packs the structure for speed on a 32bit machine, the structure suddenly takes up 8 bytes, because 3 extra bytes are 'padding' around the TypeID to ensure that variables are on 32bit boundaries.  If packing for a 64bit machine, it goes up further.  Notably, packing for 64bit will give the same performance benefit on a 32bit machine, because 32bit boundaries are always at 64bit boundaries.


End story:
Depending on how Toady's structures are defined and packed, by intelligently and carefully re-arranging them, we may be able to add new variables, and noticeably increase speed, without increasing the size of the structure or decreasing the size of any of its existing fields.
No multi-threading, no save game breaking, no gameplay changes.  Just speed and efficiency.
Been there, done that, willing to do it again.