Print

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

[omg_scout]

Fluids are really not a problem in DF. I remember someone of forum making a big research and stating, that most resources are wasted on iterating through objects list, even after destroying them with atom-smasher.

Also, multithreading a rogue-like game is not a small deal, generally, ask yourself a question, why most of modern games are still making most of their logic tasks on single core. And df is 99.9% about logic tasks.

[Telgin]

Huh? CFD is done on GPUs all the time and is much faster, thanks to fluid dynamics being highly parallel in nature.

Perhaps, but that's making the assumption that fluid flows in DF work anything remotely like fluid dynamics in scientific applications.  I've actually worked with parallelizing a fluid dynamics simulator on a GPU, and one of the parts that got the worst performance on the GPU was the code that calculated changing water levels and wetting and drying of nodes.  How much else DF models of fluid dynamics I have no idea.

[Calite]

I have noticed a bit of optimization since the last version I played (which was roughly a year or so ago). I am sitting with 70 dwarves and a whole lot more FPS than I used to.

I'm curious if this is a generally experienced situation, and if anyone knows how well the current game's performance compares to say, 40d.

Personally I can't say I have made any specific observations about performance increase/decrease, but my hardware has changed a lot in the last few years.

[cats]

I started playing df in 2010, have played since on the same hardware and noticed substantial improvements in speed and memory use. I have better fps with the newest version, and can choose a larger embark site.

[Joben]

Fluids are really not a problem in DF. I remember someone of forum making a big research and stating, that most resources are wasted on iterating through objects list, even after destroying them with atom-smasher.

Woah, no wonder FPS death happens then. So does atom smashing not work as a FPS improvement strategy then?

What about items that are removed from play by other means, like eaten, traded, melted or rotted away?

[Telgin]

I thought the findings were that smashing worked but melting didn't (burning away might).  That may be true though, as I've been aggressively smashing crap in this fort and my FPS hasn't changed much.  It has gone up, but not by a lot, could be from other sources.

In any case, I'm pretty confident that traded items are removed from the pool.  FPS goes down when traders show up and goes up when they leave, a lot more so than I'd expect from just a few extra units wandering about.  I'd expect rotted items would be removed completely as well.

[AutomataKittay]

I thought the findings were that smashing worked but melting didn't (burning away might).  That may be true though, as I've been aggressively smashing crap in this fort and my FPS hasn't changed much.  It has gone up, but not by a lot, could be from other sources.

In any case, I'm pretty confident that traded items are removed from the pool.  FPS goes down when traders show up and goes up when they leave, a lot more so than I'd expect from just a few extra units wandering about.  I'd expect rotted items would be removed completely as well.

Yeah, the finding was destroying/smelted things or having it go off-map worked to remove it from list, dropping rock and metal in magma didn't always worked because they forms liquid puddles. And it'd not really noticible unless you have MASSIVE loads being send off, like in range of thousands, and it can take a program restart to notice it. There was also a finding that having a lot of dead things, even without corpse, contribute to FPS hit.

[MrWiggles]

Why is it a generally held belief that ToadyOne doesnt do any optimization as he works?

[omg_scout]

I also noticed general improvement. It might be related to new PC, although I would bet, that DF gained most at reducing mining output by a factor of 4. I guess number of items on map was effectively halved. Also, autoforbidding outside siege leftovers might have made a visible difference in pathfinding, as algorithms need not to path far away items. And far away pathfinding is always pain in the ass. (Yes, I am a game dev).

Oh, and I am not 100% sure about these atom-smashers. I remember an old thread with lots of good fps science, but I cannot find it now.

[AutomataKittay]

I also noticed general improvement. It might be related to new PC, although I would bet, that DF gained most at reducing mining output by a factor of 4. I guess number of items on map was effectively halved. Also, autoforbidding outside siege leftovers might have made a visible difference in pathfinding, as algorithms need not to path far away items. And far away pathfinding is always pain in the ass. (Yes, I am a game dev).

Oh, and I am not 100% sure about these atom-smashers. I remember an old thread with lots of good fps science, but I cannot find it now.

http://www.bay12forums.com/smf/index.php?topic=104643.0 This one? This' where I'm getting the 'melted pool stays' and 'dead things takes up FPS' from. And the restarting program to finalize the smashed/traded/melted set-up.

[ZzarkLinux]

Why is it a generally held belief that ToadyOne doesnt do any optimization as he works?

TVTropes and fanbases might explain
I guess the DF fanbase is getting larger-and-larger if we keep getting "A Toast to Toady" and "A Grumbling to Toady" threads constantly.

But on-topic,

I'm sure that most of the "optimization" and "fancy graphics" are scheduled for the ".99 DF release".
As a developer, you shouldn't add in "optimizations" until the main bulk of code is done.
Otherwise you just waste time optimizing code that may be deleted in a few weeks
(or, if the code stays, you've added another system to maintain).

The way I envision it, Toady will focus much of his time in Adventure mode e.g. tracking-every-mug, tracking-every-tooth, track-every-footprint, etc ...
Then, when the final code is almost ready, then he can add options for Ignore-Mug-History / Ignore Footprint-History / Ignore Deceased-Animal-History options for Fort Mode.

Hell, at my job right now I'm designing an 1D Cut Optimizer, and I'm doing the exact same thing.
When it's done, it'll be slow-as-molasses, and then I'll worry about optimizing.

[Zarat]

Why is it a generally held belief that ToadyOne doesnt do any optimization as he works?

Because, uh, it's slow.

And generally optimization per se isn't something you do as you work anyway.

Careful design and implementing efficient algorithms on the other hand, is. That's what's lacking, or "FPS death" wouldn't be happening except on ungodly old and large forts.

Why is it a generally held belief that ToadyOne doesnt do any optimization as he works?

TVTropes and fanbases might explain
I guess the DF fanbase is getting larger-and-larger if we keep getting "A Toast to Toady" and "A Grumbling to Toady" threads constantly.

But on-topic,

I'm sure that most of the "optimization" and "fancy graphics" are scheduled for the ".99 DF release".
As a developer, you shouldn't add in "optimizations" until the main bulk of code is done.
Otherwise you just waste time optimizing code that may be deleted in a few weeks
(or, if the code stays, you've added another system to maintain).

The way I envision it, Toady will focus much of his time in Adventure mode e.g. tracking-every-mug, tracking-every-tooth, track-every-footprint, etc ...
Then, when the final code is almost ready, then he can add options for Ignore-Mug-History / Ignore Footprint-History / Ignore Deceased-Animal-History options for Fort Mode.

Hell, at my job right now I'm designing an 1D Cut Optimizer, and I'm doing the exact same thing.
When it's done, it'll be slow-as-molasses, and then I'll worry about optimizing.

Yes, premature optimization is something you shouldn't do. In fact, I'd argue that the kind of optimization that most people in this thread seem to be talking about (oh look this O(3n) function is now O(2n)!!!!) should be basically ignored period, unless you're talking about some kind of mission-critical realtime application or you've done everything else and you're really bored and you can write it and document it in such a way that it is equally understandable as the original code.

[omg_scout]

I cannot agree, Zarat. Changing O(n3) to O(n2) is not an "optimization". It is design change. And you'd better changed design sooner then later. I guess it is too late now. Not that I am saying that Toady included some design fails, propably he did not. I am tired of people who mindlessly repeat that "premature optimization is the root of all evil".

[Zarat]

I cannot agree, Zarat. Changing O(n3) to O(n2) is not an "optimization". It is design change. And you'd better changed design sooner then later. I guess it is too late now. Not that I am saying that Toady included some design fails, propably he did not. I am tired of people who mindlessly repeat that "premature optimization is the root of all evil".

I think you might have confused my O(3n) and O(2n) example with O(n^3) and O(n^2) - understandably, since generally, all the constant factors and smaller terms are dropped to simplify things. You could get the former by refactoring your code a little bit. You won't get the latter without changing the design.

[AutomataKittay]

I cannot agree, Zarat. Changing O(n3) to O(n2) is not an "optimization". It is design change. And you'd better changed design sooner then later. I guess it is too late now. Not that I am saying that Toady included some design fails, propably he did not. I am tired of people who mindlessly repeat that "premature optimization is the root of all evil".

How'd you manage to flip the big O types? Premature optimization does leads to less readable program, which with DF being as buggy as it is, is bad idea. Even then, I'm fairly sure Toady's done optimization when he can, otherwise the game'd be unplayable with how much details' been added since 40d. As is, only worldgen's pretty badly impacted, since a lot of details can't be glossed over. At least that's my understanding.