Print

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

[runningoutofcreativenames]

I wasted tons of money on a computer with the following:
4 cores running at 2.9 Ghz
6 Gigabytes of memory
A graphics card with a 650Mhz engine speed and a 900Mhz memory clock speed, with a gigabyte of memory on the card

The graphics card works great. I have no graphical lag because OpenGL is the best state machine ever and utilizes my graphics card perfectally.

The game does not work great. I have tons of lag because Dwarf Fortress is 32 bit only, and can only use one out of four processor cores and two gigabytes out of six gigabytes of memory.

I have never grown to love multithreading so much in my life. Without 64 bit multithreading i can only use one fourth of my processing power and a third of my memory if i am stuck in 32 bit single threaded processing.

tldr; please rewrite all the OS code to work with 64 bit and multithreading so DF doesnt run slow as shit on my expensive ass computer 

edit: oh this has been suggested before i should have learned to use the search option, if toady doesnt have any plans to support multithreading how can he plan to support contemporary modestly priced PCs? all PCs you buy new have multiple cores now, besides maybe crapbooks er netbooks but they arent meant to play games anyways they are for browsing the internet with microsoft internet exploder or AOL's Nutscrape

[Frajic]

It has been suggested ~1000 times, and Toady just can't be bothered reworking all the code to support multiple cores. At the very least not yet.

[runningoutofcreativenames]

It has been suggested ~1000 times, and Toady just can't be bothered reworking all the code to support multiple cores. At the very least not yet.

Its not just that, for him, it is learning how multithreading works, and them implementing it properly. That would take FOREVER, his dissertation was in mathematics not CS

[Draco18s]

Please use the search and post in an older thread

[kaenneth]

Just run 4 copies of DF at once, one for each core 

Anyway, making DF multithreading at the end... won't work (very well) multithreading has to be in the core design, otherwise it's like converting a 2 wheel motorcycle into a 4 wheel car... yeah, you could add some wheels, and it might keep it from tipping over... but it's not the same.

[tolkafox]

I double(ish) this suggestion.

I also suggest a community project for DF lovers to unite and recode DF to be multithreaded.

First and foremost, we need a new pathing algorithm.

And people with time. Oh wait, we have those here >.>

[Girlinhat]

I would like to invite all of you to the 9,001th Suggestion Division!  Only the elite are chosen for this special task force!  To gain entry, you must start a new forum thread suggesting mutli-threading, improved pathfinding, multiplayer, and/or open source code.  I warn you though, the ranks of the 9,001th are already very full...

[sockless]

So you upgraded your computer to play DF better?

The RAM cap doesn't matter, it doesn't use that much RAM.

Once again, use search function.

Also, the general consensus is that improving things such as pathfinding, fluids and temperature will have a greater performance gain rather than multithreading. Recently, Toady made DF run a whole lot faster by using coding magic. Also making the game multi-threaded doesn't fix the game's problem, it just hides the symptoms for the time being.

The biggest argument is probably implementation, there isn't very good cross-platform threading support, mainly because Windows isn't POSIX complaint.

[Niseg]

Anyway, making DF multithreading at the end... won't work (very well) multithreading has to be in the core design

After writing code in a multi-threading  environment for a long time I can generally say  your statement is  not true. What's true is that you should know what you are doing and what you are trying to achieve . Without going into details you can generally convert any for loop that process independent data  into a work queue scheduler . 

To gain entry, you must start a new forum thread suggesting mutli-threading, improved pathfinding, multiplayer, and/or open source code.

I suggest that people that open a suggestion without giving a clear methodology should donate 10$ to Toady to  figure it out.

The pathfinding suggestions are all in one thread .There is a lot  progress in the in the clear methodology area  . I implemented a demo of 2 of the suggestions . I know  room pathing is half done  but it simplify the problem by a factor of 10 and no path penalty runs at best case time instead of worst case every time.

Toady made DF run a whole lot faster by using coding magic. Also making the game multi-threaded doesn't fix the game's problem, it just hides the symptoms for the time being.

 I haven't noticed much of a performance difference (maybe because my 25% overclock stopped being stable - I blame my cats) . We are totally in the dark in the benchmarking field because it's hard to points out the performance killer because there are more than one. I think it got to do with how data is organized .

[runningoutofcreativenames]

I double(ish) this suggestion.

I also suggest a community project for DF lovers to unite and recode DF to be multithreaded.

First and foremost, we need a new pathing algorithm.

And people with time. Oh wait, we have those here >.>

it would be awesome if DF was open sauce i would commit code on the weekly

[Not a Cylon]

Anyway, making DF multithreading at the end... won't work (very well) multithreading has to be in the core design

After writing code in a multi-threading  environment for a long time I can generally say  your statement is  not true. What's true is that you should know what you are doing and what you are trying to achieve . Without going into details you can generally convert any for loop that process independent data  into a work queue scheduler . 

Sure, but that's sorta the point. If the code is written already in such a way that it has lots of independent tasks, and modifications to shared data are rare and well-controlled, then sure. Refactor, and you've got a multithreaded program. But in a large, complex code base like Dwarf Fortress that wasn't designed with threading in mind, how likely is it that everything is already independent? No processing steps are modifying data structures in place as they're traversed, for instance? The hard part, I imagine, of reworking DF for multithreading wouldn't be converting for loops to work queues; the problem would be finding every little niggling synchronization point and either acquiring a lock (which could erase performance gains if contested locks are common, and would introduce extra randomness (dunno if that matters)) or delaying and batching the writes somehow (which could be a lot of work in itself).

In short, I tend to agree with the suspicion that the low-hanging fruit has got to be in the pathfinding algorithms, and getting those right could improve performance just as much, if not more, as multithreading, and with way less work and way fewer irreproducible crasher bugs …

[Chilton]

Why dont you just SetAffinity or imgcfg it into submission?

[Draco18s]

Why dont you just SetAffinity or imgcfg it into submission?

...meaning...?

[Dutchling]

Why dont you just SetAffinity or imgcfg it into submission?

...meaning...?

I hope it means that everyone who suggest this again will burn for a very long time ^^

[Darkweave]

If anyone uses the term "multi-threading" in a post they should receive an automated message instructing them to use the search function and be sent a male and female cat.