Print

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

[sproingie]

Am I the only one for whom that picture comes out corrupted?  Oddly enough the title bar looks fine. [edit: ahhh, it's zoomed out.  wow.]

I've seen DF run succession game megaprojects with waterfalls and flowing lava on 5x5 embarks and getting 15FPS.  Not great, but playable.

Thank you for calling of tech support, am happy we could do the needful for you.  Having a nice day!

[Gertack]

Posting from my phone, otherwise i'd link you to the images... if you search recent embark posts you'l find it.

In a few benchmarks I tested several 2x2 forts that ranged in 1500 fps to 4800 fps (depending on location features) without optimizing init on an overclocked i7.

Another poster got 2400 fps on a core2quad with no tweaks.

Technology is advancing. i7 and phenomIIs offer greater performance even if clockspeeds aren't faster. It's completely different architecture than pentiums.

So DF is definitely playable, and if it's really bad an upgrade may be in order.

My Intel Core i7 920 gets 0 FPS in one of my forts, 3 FPS in another of my forts.

Fast hardware can't compensate for slow software.

[Googolplexed]

Yeah, but even if DF was fully optimized it would still run slowly.
as I said earlier, a 4x speed boost isn't much help if your fort is running at frames per minute.

[profit]

Yeah, but even if DF was fully optimized it would still run slowly.
as I said earlier, a 4x speed boost isn't much help if your fort is running at frames per minute.

I do have to agree with that =/  Still would like to see 4x but yes I know it would still be unplayable.. *but on the plus side when it is just normal moments without me doing anything in my forts 4x would give me close to 40FPS.

[G-Flex]

Yeah, but even if DF was fully optimized it would still run slowly.
as I said earlier, a 4x speed boost isn't much help if your fort is running at frames per minute.

Frames per minute? I have an 80-dwarf fortress with a ton of animals and a complicated moat system, running on a system with really crappy hardware and an old Pentium 4 (single-core). If my FPS in that fortress quadrupled, it would be at least 50 or 60, which is very far from unplayable. It's not perfect, but this is on worse hardware than almost anyone is likely to have a year or two from now.

Plus, there are two types of optimizations we can consider: The possibility of the program becoming multi-threaded, and other optimizations which do not require that. If you know anything about computational complexity, you know how drastic such improvements can be: An algorithm's CPU time increasing quadratically is significantly and qualitatively worse than it increasing linearly or logarithmically.

[Googolplexed]

I have to show this picture yet again

Spoiler (click to show/hide)

Third time in three pages I brought it up

Also I was mentioning 4x as a completely optimistic, impossible in real life scenario. We've been over most of the stuff about multi-threading now and I think the general conclusion for the last few pages has been to optimize the rest of the game first

I don't doubt your frame-rate, mine is fine aswell but looking at the image I do not believe that even if DF was fully optimized it would run at a decent speed.

In summery that post was more for profit then anyone else. A 4x speed boost would be brilliant if we could get it, but as you pointed out, it wouldn't happen

[profit]

LOL I didn't know my tree farm would attract so much attention..

The real odd thing is after it was created my FPS fell by half.. from about 30 to 15 FPS.   That was when it was just a big empty room, without any water in it yet...

It took 3 days of processor time in order for it to flood and dry out( about 2 seasons).

It now produces about 60 ish tree's a season, with a loss of FPS at about 13-17FPS from the overall game speed.... Even after all the stone from the room was destroyed... I don't know why but apparently DF does not like big empty spaces.

[Googolplexed]

Yeah, probably yet another thing that needs optimizing.
I know that DF doesn't store information about non-discovered areas in ram, or at least not much about it. That wouldn't explain a massive speed drop though.

And I think the tree-farm is getting attention mostly from me, but admittedly I don't think many people here attempt water projects of that scale, Even less would expect it to run at a decent speed.

If DF had massive speed issues then no-one would play it. As it stands most people just try to avoid stuff that causes that much of a speed drop

[profit]

I know some of people here start forts, play them for a little bit then start a new one when the speed gets too bad.

Still others they play with only their starting dwarves and disable children in order to keep their speed up.

One other person joked that the atmospheric simulation would mirror his current forts where goblins come in, he could melt their iron down and use the smoke to kill more goblins until his processor melted... Which he informed us was basically what already happened...

I don't know ALL the causes for slow games.. but I do know that many of the causes are directly in the way of things which I consider fun. 
 
I know it can be "handled" but it really makes playing the game like taking a shower in a raincoat...  Yeah you "played" it, but you missed a lot of the experience.

Honestly though.. if the fluid simulations could be pushed off into a physics processor, it could in theory run at a decent speed...  I AM NOT ENDORSING that as the path that should be taken... Just... it could happen and probably be a real time flow that could keep up with the simulation "thread"...

Here is one using 500K blocks of fluid in a simulation using some nvidia card as the physics sub processor -> http://www.youtube.com/watch?v=RuZQpWo9Qhs  ... http://www.youtube.com/watch?v=o07KjfBx8GE


So it COULD be done.. But I don't know if it could be done in a reasonable time frame so I do not endorse such a thing at the moment.

and it still doesn't do a thing for the slowdowns that happen when there are no fluid simulations.

[Rorax]

Dwarf fortress needs massive amounts of optimization as far as I can tell. But forgive me if I am remembering something that has never happened. but I remember toady mentioning somewhere he would like to get a couple more stages of the project done before he sat down and optimized his code.

I'm unsure of how long toady has been using the current architecture.

But I know that with any of my coding projects I hammer out the program, tear it all down again because it was terribly written, rewrite it, tear it down, rewrite, tear down, rewrite, polish, done.(on average)

And I have no idea of how many revisions toady has done but if this has been running off his first pass this whole time because he favors getting his creativity onto the table. Then no wonder it has so many speed issues.

I feel as though, once toady actually settles into overhauling the efficiency of the code he has written HUGE speed increases will follow.
Hell I am confident enough in that fact that I am will to stake my first born on it efficency of code is everything.
I'm actully interested in what the overall Big O is of toadies path-finding and liquid sim

[SSBR]

And I have no idea of how many revisions toady has done but if this has been running off his first pass this whole time because he favors getting his creativity onto the table. Then no wonder it has so many speed issues.

"revisions" don't necessarily have to involve tearing it down and rebuilding it. That'd be silly. He just needs to move a bunch of stuff around, and maybe rewrite a few things.

efficency of code is everything.

I think that Toady doesn't have it as his highest priority should be a major hint that not everyone agrees. Most people value functionality over speed, and many other also value maintainability/etc. over speed. At least, to a degree-- FPS:0 throughout anything and everything may be a speed issue, but it also makes the code effectively nonfunctional, and it's not just the extreme end of performance that gets this problem.

I'm actully interested in what the overall Big O is of toadies path-finding and liquid sim

That probably won't be very interesting. It'd be bad if worst-case O(2ⁿ) was a tight upper bound on worst-case input, otherwise it's some polynomial that's probably about as good as it gets. The big O, though, that's basically a solved problem if you want optimal pathfinding, and if you're okay with nonoptimal it's not all that interesting either (also not sufficient for an analysis). From what I understand, and from my own experience trying to get pathfinding to work well, the search space is the most interesting. That is, it's not the O(), but the n. You can change it all sorts of ways, some of which change the optimality and reduce the upper bound, others which work nicely but more on the margins, others which are just plain better because the old representation sucked.

[Rorax]

I'd like to clarify that "Efficency is everything" is my personal opinion, not what I think everyone should code by.

and as for tearing it down everytime. I should also be more clear about what I mean. I don't entirely start again, but personally I tend to gut the thing and keep only the very best of my work on that iteration.

the liquid sim is what I am more concerned about, but then liquid is bloody hard anyway and he is obviously a damn site better than I am at physics simulation, hah

But I stick to my guns that, when toady gets to optimizing, when ever that may be, that we will all see a massive increase in performance.

[Googolplexed]

Efficiency is important, I think everyone can agree to that, and DF is also quite unoptimized.

I agree, that when toady gets around to optimizations it will speed up alot. The question now is when. You don't spend large amounts of time optimizing if you are going to add new features in, that might conflict with the optimizations.

Remember what happened last time toady had an unworkable code base.

Also the CUDA water sims are pretty neat, but ATM the only compatible API between both ATI and NVIDA is not fully supported yet.

Anyway, it would be good, but I don't think we want to spend months whilst toady learns,implements and debugs GPGPU code. Optimization, then multi-threading, then MAYBE GPGPU, depending on how much the platform has matured.

Anyway if all we focus on is the water sims, then this will be the result.
Slaves to Physics:God of Water:Dwarf Bath.

[profit]

Yeah but since magma is one of the most important parts of the game the fluid sim needs to work flawlessly!! =p
 
JK.

There was a reason I specifically said I did not endorse anything, and I just want speed in general.   I only used the many video that I have shown to show it CAN be done because piles of people say it CAN NOT be... not that it SHOULD be.

[Googolplexed]

I'm not 100% sure the video directly applies to what DF need in terms of a water sim.
That being said, CUDA could speed up DF.
But yeah, I don't think GPGPU should be used in DF, at least not for a few years,