Print

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

[TheFlame52]

Tell him every single 8-bit smiley has its own functioning circulatory, muscular-skeletal, and nervous systems. Show him the amount of data in each dwarf's profile. Tell him that it's all tracked and effects the gameplay. Also do the stuff other people said.

[Foxite]

The best way to demonstrate it to him is take a save of 40 year old fortress with 150 dwarves in it on a good sized embark with a volcano that just breached the circus and install it on his gaming rig and watch it bring his rig to its knees.

Sigging this

[Tarsis]

Every time 64-bit and multithreading come up I learn things. Thanks for the polite discourse guys!

[NW_Kohaku]

Actually, you could probably just tell him that many people "burn test" their rigs by downloading a program from NASA that basically outsources some of the math they need to calculate all the data they get from various telescopes and satellites.  This basically involves using 100% of your computer's processors for as long as you leave it running doing nothing but pure math problems as fast as your GPU can solve them, which is more resource-intensive (and therefore will overheat your computer more) than any graphics ever could.

[Saiko Kila]

I don't believe that changing to 64-bit will actually speed something up. Occasionally I compare 64-bit versions of programs with their 32-bit versions, and usually the 32-bit version is faster (if there's a difference), and always it takes less memory (which is expected, and which may explain why it is faster). I suppose only the bigger forts will be affected positively, and they are already crippled by other things.

But making multithreading should add more. Especially if made smartly, like adding pathfinding to another thread (which is often used in PC games) or doing that with some environmental updates. Still, it is much, much harder to do.

[TheBiggerFish]

Post to watch people beat an ‼XXMangled Horse CorpseXX‼.

[xana55]

Just tell him if he's convinced it's so trivial to put it on his PC and see how long it lasts. I'm willing to bet it'll surprise him.

[Pvt. Pirate]

copy it over on USB and create a large world on his computer.
while his computer bends, open the DF wiki and explain to him WHAT the game has to calculate and keep track of while time passes.
and that all the events that are being calculated will affect your game when you chose to embark.
also tell him that in every single frame, it also keeps calculating the rest of the world with all its politics, economics, tragedies, wars, marriages, childbirths, animals, animals copulating, animals dying, animal corpses being processed into items or rotting away, trees growing and dying, simlultanous to your fortress growing or going to ruin.

[Dozebôm Lolumzalìs]

HAVE HIM BREACH HELL AND THEN SEAL IT OFF

HE WILL KNOW DESPAIR

AND THE STARING AT THE TASK MANAGER ANGRILY

[Lummox JR]

Converting a single-threaded program to multi-threaded is hideously difficult. Hideous. I could tell you horror stories.

DF might be uniquely suited to some forays into multi-threading, however, by virtue of the fact that some tasks like pathfinding could be considered inherently parallel. The temperature loop could probably be split off and also broken down into subsets, as could (to some degree) flows. The trick would be for all these things to never make a change on their own that might affect the main thread or each other, but rather to message the main thread.

[PatrikLundell]

I would expect converting a single threaded program into a multi threaded one usually to be easier to do by reimplementing it from scratch, making use of the knowledge of the overall design of the original, its algorithms, and some select pieces of code than to massage it by shifting load bearing structures around. In the case of DF, that would probably generate too much of a years long development hole. Also, the whole DF development is one of building a shack, expanding it into a cottage, then a house,...

I agree the results of what results side threads have come up with usually have to be introduced into the main memory structures through a main thread integration effort at the end of each tick, where you'll also have to resolve any conflicts (e.g. a fluid flow calculation may have to be modified or partially redone if an affecting drawbridge has been opened or closed).

[Psieye]

So to summarise the ‼XXMangled Horse CorpseXX‼, a proper multi-threading re-write looks prohibitively time-expensive. But extremely localised areas of code might (would need to be measured) see an improvement with a 'contained' implementation of parallel processing. For example, with pathfinding something like:
- "This is the list of all the units who need a path calculated"
- Pause the main thread
- "N worker threads, divide up this list and crunch through them. Your answers will be aggregated." where N is a fixed, small number
- Resume the main thread after all units have their paths assigned

[Orange Wizard]

Incidentally, Toady has said there are better ways to implement pathfinding than what he's done so far, and it could stand to be improved.
Probably involving chucking it onto a separate thread, really, but it's not like the algorithm itself is as efficient as can be.

[PatrikLundell]

So to summarise the ‼XXMangled Horse CorpseXX‼, a proper multi-threading re-write looks prohibitively time-expensive. But extremely localised areas of code might (would need to be measured) see an improvement with a 'contained' implementation of parallel processing. For example, with pathfinding something like:
- "This is the list of all the units who need a path calculated"
- Pause the main thread
- "N worker threads, divide up this list and crunch through them. Your answers will be aggregated." where N is a fixed, small number
- Resume the main thread after all units have their paths assigned

You could do it that way, or you could just have one path finding thread, one distant world event thread, one... and send these off to do their thing while the main thread continues on, reach the collation phase of the main thread, verify the paths selected and recalculate if failed apply and continue. That approach requires any changes to the fortress used by other threads to be thread safe, though (the change resulting from channeling away a wall should cause the pathing thread to either make use of the tile as blocked by a wall or removed to create a path, not mid way through the changing of the state, possibly resulting in a program termination). From this perspective, the "divide-and-conquer while I wait" approach is easier and safer (the path finding threads are all reading a frozen common state, but not changing anything), but requires you to either use a rather conservative value for N, or determine a suitable number on DF program start based on the computer it's run on. It also hinges on the number of paths to calculate each tick is usually at least 2 and frequently N for a fairly large fortress e.g. during a siege.

Incidentally, Toady has said there are better ways to implement pathfinding than what he's done so far, and it could stand to be improved.
Probably involving chucking it onto a separate thread, really, but it's not like the algorithm itself is as efficient as can be.

This is a rather important point. Before optimizing the code to be as efficient as possible, you should optimize the algorithm, as the gains there usually are much greater than anything code optimization can ever provide. Algorithm implementation also matters (iterating over a matrix column first or row first can matter a lot: if you iterate in the order the data is laid out in memory the next element is usually in the cache and quickly available, and on a cache miss several elements are usually fetched, while iterating with swapped indices can cause every read to be a cache miss if the data structure is large enough).

[Psieye]

... That approach requires any changes to the fortress used by other threads to be thread safe ... From this perspective, the "divide-and-conquer while I wait" approach is easier and safer ... but ...

Aye, I proposed the "just wait until the threads are all done" approach with safety and ease in mind - Toady doesn't have experience with multi-threaded coding/debugging and whatever time he spends getting to grips with it will be time he can't chip away at his long To-Implement list. Though ongoing world gen probably should be on its own thread anyway as most of the time the main thread won't care what's happening outside your own fortress.