Print

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

[assimilateur]

There are only 2 init file changes that seem to make any differences at all.

Removing Heat tracking.

And technically population cap... but it is an indirect change.

Well, some people have reported different print modes improving their performance, but for me that didn't do anything.

Everyone's definition of unplayable is different.

You've hit the nail on the head.

I always thought that DF was already legendary because of its features, allowing you to do things unheard of in other games. It is also notorious for its abysmal performance.

How the dev can, in that situation, continue to focus on adding more features instead of on streamlining performance is beyond me. How the community can then still largely support his efforts, and voices like ours, questioning the dev's priorities, are in the vast minority (and liable to be met with hostility), is even more unfathomable.

[profit]

A lot of people do not know what kind of gains they are looking at if multithreading is done right either.. some believe it will only double their speed because they have a dual core processor.. *and in fact if that was all that's done it would be true.

But... it just so happens that I have a video of parallization at its height.

Here are 16,384 creatures using 800 pipelines at 1 Ghz, of a video card to simultaneously jobfind, pathfind, animate, and still have enough power left to render, shade, and so all those video card things.
*And they are hauling stone... I honestly take it as a sign for dwarf fortress.

http://download-developer.amd.com/GPU/videos/Froblins.H.264.HD.136MB.mov

"16,384 characters calculate the shortest path to their goal, while avoiding each other, obstacles and congestion.

Character color corresponds to the goal type (Blue - sleep, Green - Mine gold, Red - Pick mushrooms, Beige - Drop off treasure at pagodas).

Characters form lanes, avoid collisions and move smoothly past each other.

Characters react to dynamically placed obstacles/hazards and alter their global path

Froblins dynamically update their paths to take into account newly available goals. "

Wow.. sounds like a cure for every single fricking annoying dwarf trick at once....

No getting near creatures, no running into closed areas because they already pathfound there, no being stupid, and it happens at well north of 60 FPS for 16,384 of them.

And here we are getting frustratingly low FPS with 50 dwarves.



I renamed mine from .mov to .flv so I could play it in gom player. I would recommend you do the same since quicktime sucks!

* the demo uses 3,000 froblins for most of it so they are less crowded when showing off rendering features, to see 16,384 frobllins skip ahead to 6:40ish

[Shades]

Edit: just realised I'm not sure if your implying you'll get more than double or less. (unable to watch video at work)

[profit]

Edit: just realised I'm not sure if your implying you'll get more than double or less. (unable to watch video at work)

Honestly if all that is done is simple multithreading, if you have a dual core proccessor you will get less than double the speed... Maybe only slightly less but less... Doubling the speed is nothing to sneeze at, but it is only a starting point.

I was using the video to illustrate what happens when you go MASSIVE number of pipelines not just 2 or 4.. (maybe 8 or 16 if you were rich) like you would be limited to with a CPU but 800 that is in a video card.

Even though each pipeline is slow, when they put all their power together they can do the incredible.

And since the number of cores in CPU's seems to be going up but the Speed seems relatively unchanged since about 2000ish I have to imagine that waiting for a faster single core processor is going to become like a railroad in 1910 waiting for steam engines to make a comeback.

So... I was trying to illustrate potential, even though the real world usefulness of it could be kinda iffy to many of us *I would borrow my brothers phenom computer but for right now I only have a dual core*

But in the future, there will be cores, so many cores, and to leave them unused will be like asking for 1$ an hour when the boss offers to pay you 800$ an hour.

[assimilateur]

And since the number of cores in CPU's seems to be going up but the Speed seems relatively unchanged since about 2000ish I have to imagine that waiting for a faster single core processor is going to become like a railroad in 1910 waiting for steam engines to make a comeback.

Also, without a performance-minded overhaul, Toady can expect the community to shrink substantially if all the coming updates are going to bring is more features and even worse performance. I'm pretty sure I won't be playing the next version longer than a couple of days if it turns out even slower than 40d#, and I don't think I'm the only one.

[profit]

I do not echo your sentiments but I feel your pain...

May I recommend you put it into a window, and you can easily play another game like the Sims 3 or something while you have dwarf fortress running as well...

That's what I do... It has become more like a game of chess.... and I basically am waiting for the computer to make its move.

(Don't worry, if anything important happens it auto pauses.... OH! and turn off children in the init... it gets annoying to have it pause on every child birth)

* yes I do realize it's sad to play a second game cause the first is so slow it doesn't need me for at least another 30 mins.

[assimilateur]

The ability of doing something other while playing this game, like reading or listening to an audiobook, is probably what keeps me going. It doesn't say much for the game though, because then it just boils down to giving some orders and waiting, when what I should be doing is enjoying my dwarves do the work I ordered.

I mean, what point is there to doing anything in the game if its performance makes it aggravating to watch?

[profit]

I agree..

But it does say something for the game that you are putting up with it... in other words this game has massive potential, just it is held back by it's performance...

One other thing, I have been hesitant to offer because it will dramaticly change gameplay..Setting your dwarves speed to 0 inside the raws... While you will once again lose FPS, your dwarves will zip around like a gnat on meth.

While this will make the game playable at sub 10 FPS.... it will break the game and remove a massive amount of difficulty.

Use at your own discretion.

[assimilateur]

Right, I've read about that speed hack but I have yet to use it. Well, the game as I play it isn't very difficult in the first place, so if this means they'll be able to get shit done even at 20 fps, then I'm all for it. That said, first I'm trying to reduce my number of dwarves to around 40-50 and implement a layout that's supposed to streamline pathing. If that doesn't help me much, then I guess I'll increase my dwarves' speed.

[Draco18s]

video card

The problem is that each video card is different and what works for one card might not work for another, especially if that other card is from a different manufacturer (ATI vs. nVidia).

[profit]

video card

The problem is that each video card is different and what works for one card might not work for another, especially if that other card is from a different manufacturer (ATI vs. nVidia).

Very true, that's why I never said "Implement FUSION, or CUDA." I was only using it to show potential.

[eerr]

multi-thread what?
In-game lag comes from a few actions that all depend on the same information.

This includes Pathfinding, temprature, water-mechanics, map modifications and screen drawing(or so I've heard).

Unfortunately, the lag is always with just one of these processes at a time.
Only  with screen-drawing vs everything else could you afford multi-threading.
Anything else is a minimal gain, where you have one massive processor hog and another process which is 2% of it's size.

I know measurements of multithreading power are underconstruction by people more experienced than I, but multithreading 100%  of the game into  a 100% process and a 2% process is hardly any progress at all.
and that is ignoring the problem of syncronizing pathfinding with map-edits!

[profit]

multi-thread what?
In-game lag comes from a few actions that all depend on the same information.

This includes Pathfinding, temprature, water-mechanics, map modifications and screen drawing(or so I've heard).

Unfortunately, the lag is always with just one of these processes at a time.
Only  with screen-drawing vs everything else could you afford multi-threading.
Anything else is a minimal gain, where you have one massive processor hog and another process which is 2% of it's size.

I know measurements of multithreading power are underconstruction by people more experienced than I, but multithreading 100%  of the game into  a 100% process and a 2% process is hardly any progress at all.
and that is ignoring the problem of syncronizing pathfinding with map-edits!

Well.. Since it is all done inside of a frame anyhow... You could break the temprature subroutine off into 100 threads or so...  They dont have to modify anything until the end of the frame.

The fluid simulation could also be broken off into discrete threads, probably one for every tile with a fluid simulation flag on it.

Every pathfinding job could each have its own thread...

At the end of the frame when it is time for an update, they all sequentially add their data to the relevant parts of memory.

It would not be easy, but just because they all depend on the same information does not mean they are all changing it at the same time. 

It is possible to do it... and if you had bothered to look at the video and read the messages stated earlier in this thread you would know IT HAS ALREADY BEEN DONE by someone else. 

Therefore.... Your statement is completely incorrect with no redeeming and useful information.   It has been done. It is possible. It did not just give 2% it gave at least a several Thousand percent increase.

[sproingie]

One problem with breaking pathfinding into threads: it's widely believed (but Toady doesn't give details) that pathfinding is implemented by writing into bits directly in the map data.  This is global shared state, which is inimical to being broken into independent threads (you can, but the locking would end up only allowing one thread at a time anyway).

Fluid simulations might get a big boost from vectorized algorithms, but if they're writing to map data then they have the same problems with shared state.

Copying out the map data for pathfinding would allow for independent threads, but you're talking about chewing up even more memory than DF uses now.  You drive it into swap and you can kiss every performance gain goodbye.

It's all possible, but one thing you can't call it is easy or straightforward.

[profit]

One problem with breaking pathfinding into threads: it's widely believed (but Toady doesn't give details) that pathfinding is implemented by writing into bits directly in the map data.  This is global shared state, which is inimical to being broken into independent threads (you can, but the locking would end up only allowing one thread at a time anyway).

Fluid simulations might get a big boost from vectorized algorithms, but if they're writing to map data then they have the same problems with shared state.

Copying out the map data for pathfinding would allow for independent threads, but you're talking about chewing up even more memory than DF uses now.  You drive it into swap and you can kiss every performance gain goodbye.

It's all possible, but one thing you can't call it is easy or straightforward.

Memory usage should remain about the same.

Yeah, I would never call it easy and I believe I even stated it probably was not easy, but you do not need a copy of the map, you just need to delay the writes till after the threads are done with their work on it.  I think it would be incredibly silly to make a bunch of copies of map data when it does not need to change until the frame generates anyhow.

I thought I stated that as well.

*for those who do not understand here is the basic ways things like this would likely work in a game like dwarf fortress or similar game *

1. Determine what needs to be done and how many threads are needed to do it.
2. Start Threads (There may be 1 thread there may be several thousand, the more there are the less likely they are to have one last significantly longer than the rest)
3. Wait For them to finish
4. Write Data that is returned from threads into memory *This is usually done by a single thread in order to catch collisions and the like*
5. Generate Frame

then the process starts all over for the next frame..
It looks like a lot of work and it is, but with complex simulations the speed gain can be worth all the effort.