Print

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

[motorbitch]

somehow me thinks writing within a programming or coding releated tread is like writing of being in 0-gravity for me: i read about it, but i dont realy get it.anyhow, ill do it:

istīnt this whole multicore theme a little bit pointless at the given point? i mean: with optimization, i think df culd be much much faster on a single core. its just not optimisated for performance today.
then when optimization will take place, im verry sure toady will think about multicore, as hardware definitive goes this way.
so, no need to suggest to use multicores, its clearly that this will be a good way to speed up df once attemps are made to speed up df.
i mean... its just pointless to suggest :speed up df! toady wont have a 5 - 8 ghz c2d to run a 200 dwarfs fort on his own. he surely knows that a better performance wuld be nice. its just not on the agenda today.

[dreiche2]

true true, but by discussing how difficult or easy it might be, and possible even coding examples to try out, we might be able to influence for when it comes onto the agenda 

[Core Xii]

then when optimization will take place, im verry sure toady will think about multicore, as hardware definitive goes this way.

Though, it's easier to implement multi-threading from the beginning, rather than at the end. In my personal opinion, every single game and app should be designed with multi-threading in mind from the very start.

Then again, I'm in the minority of people who have quad cores, and just looking for reasons to justify my purchase.

[Draco18s]

then when optimization will take place, im verry sure toady will think about multicore, as hardware definitive goes this way.

Though, it's easier to implement multi-threading from the beginning, rather than at the end. In my personal opinion, every single game and app should be designed with multi-threading in mind from the very start.

Toady started this project before dual cores became common, and he's stated at least once he doesn't understand the code necessary.

[Tormy]

then when optimization will take place, im verry sure toady will think about multicore, as hardware definitive goes this way.

Though, it's easier to implement multi-threading from the beginning, rather than at the end. In my personal opinion, every single game and app should be designed with multi-threading in mind from the very start.

Toady started this project before dual cores became common, and he's stated at least once he doesn't understand the code necessary.

Yes true, however one day Toady should consider to give multi core support for DF. Just image later on in the game, once more features will be added, the CPU will be used much more compared to what we have now. Armies will be formed/moving all over the map with loads of items, the game world will "live" and everything will happen in real time. Basically all living creatures in the generated world will be linked to your CPU virtually, the game will have to track/monitor everything in real time...you got the picture I guess.

[Veroule]

Multi-threading does not imply the usage of multiple cores.  Thinking that a multi-threaded app will automatically use multiple cores is the first mistake everyone makes.  Generally all threads of a given process are run in a single core.

There are additional API's with Linux and Windows to create a form of thread that runs in a different core, but they are very complex to work with.  It is usually easier to preform inter-process communications and use multiple processes to utilize multiple cores.

Yes, the Windows API for thread synchronization is horribly bulky and cumbersome.  After I played around with it for some basic sectioning I decided it was much better to just write my own assembly that does exactly what I needed and has no overhead.

The next thing to consider when examining the concept of multi-threading is what is actually worth having in seperate threads.  The answer to this is always anything that can occur asynchronously.

User input is the first thing that comes to my mind everytime I look at threading an app, as there is no way within an app to predict what the user will do next.  If an app uses the OS's message queue system for receiving user inputs then I have to look at how often different parts of the program check the queue and holdup what they were doing to run the message processing code.

Toady doesn't actually use the message queue for user input.  If he hasn't changed much from last time I looked through the KQ code he does a check of the keyboard state with each game frame.  This could be done in a seperate thread as a relatively safe place for him to learn threading.  The immediate benefit of threading that particular section is that even when the game view or graphic redraw are horribly slow, keyboard response will still be within 25ms on most systems.  However threading that potion still has the problem of making everything else thread aware.  This is because a user input might invalidate a calculation occurring in the main game thread.

So if Toady were to actually try to start threading DF.  I would suggest starting with something that is already cleanly seperated.  That is the game play function, and graphic display function.  The only thing that needs to be protected with sectioning between them is the display data table.  By moving the graphics display into a seperate thread it can be set to sleep for a period of time equal to make the desired G_FPS, and does not require further checking for when it should be called.  Almost anyone with a basic understanding of threading should be able to handle that change as a demonstration for Toady.  Anyone with a reasonable understanding of threading will realize immediately that there is little to no speed gain from this change.

[Jay]

Delete this please.

Nothing (except for spambots/their messages) gets deleted in the Bay 12 forums.  Nothing.

[Exponent]

Multi-threading does not imply the usage of multiple cores.  Thinking that a multi-threaded app will automatically use multiple cores is the first mistake everyone makes.  Generally all threads of a given process are run in a single core.

That hasn't been my experience on my new computer.  I've thrown together a few quick-n-dirty computationally heavy programs this summer that used .Net's ThreadPool class, and I was able to cut my computation time nearly in half when compared to a single-threaded version.  Both cores were running at near 100% as well, according to the task manager.  Now it is possible that the ThreadPool class is doing some extra stuff above and beyond just managing basic Win32 threads in a convenient manner, but I never got the impression that it was.  I haven't actually tested with plain Win32 threads since I got my new computer, but I might if I get an opportunity.

You could be right, but I'd be curious to see some official information regarding this claim if you know of any, as it doesn't really square with my personal experiences.

[chewd]

what about water flows? Isnt that something which is cpu-intensive and could be ported to a separate process without causing too many synchronous headaches?

Afterall, it is easy for the program to predict where the water will eventually flow, the only reason water flows at the speed it does is because it is artificially slowed down for the sake of realism in gameplay. Its already a-synchronous from the main game engine.

Besides that, if the water-flow process is slightly out of synch on a bit of water here & there, it shouldnt have any major effects on gameplay... or would it? At least not as catastrophic as pathfinding 3 dwarfs to pickup the same rock would be....

Or maybe it would be... WTH do i know?

Are water-flow slowdowns the result of water pathfinding hogging the cpu? or is more of an issue with the display & repositioning of the bits of water units onto the map?

[Draco18s]

Are water-flow slowdowns the result of water pathfinding hogging the cpu? or is more of an issue with the display & repositioning of the bits of water units onto the map?

1 part pathfinding, one part....something else.

[Felix the Cat]

Multi-threading does not imply the usage of multiple cores.  Thinking that a multi-threaded app will automatically use multiple cores is the first mistake everyone makes.  Generally all threads of a given process are run in a single core.

Multi-threading implies that the OS may choose to run different threads on different cores, combined with how the compiler chooses to optimize (2 threads which heavily share data will probably run on the same core so that data may be stored in the cache).

In any case, single-threading DOES imply that the app will NOT use multiple cores. Which is a pretty significant handicap with the current trend of parallel processing in hardware design. Three years from now, when top-end mainstream computers have 8 core processors and the latest and greatest have 16 cores, a single-threaded app will be at a significant performance disadvantage, barring some technical breakthrough that allows the OS to dynamically multi-thread a single-threaded application. (Which isn't happening as it would risk seriously breaking important things.)

[Draco18s]

Three years from now, when top-end mainstream computers have 8 core processors and the latest and greatest have 16 cores

Two things:
1) I already know a commercially available DESKTOP machine with 32 cores (it's a $30,000 desktop rendering machine for small 3D animation companies, but it still fits the bill).
2) Someone has already found that Windows thinks that DF has about 7 "threads" on occasion.  I've never witnessed it though (notably I don't give a damn as I have a single core machine).

Threads and processes differ from one operating system to another but, in general, a thread is contained inside a process and different threads in the same process share some resources while different processes do not.

I.E. a multi-threaded single process application can't run on two cores.  The distinction is subtle, I think, but yes, before an application can run on multiple cores it needs multiple processes.

[Felix the Cat]

I was thinking consumer PCs :-p

[dreiche2]

Threads and processes differ from one operating system to another but, in general, a thread is contained inside a process and different threads in the same process share some resources while different processes do not.

I.E. a multi-threaded single process application can't run on two cores.  The distinction is subtle, I think, but yes, before an application can run on multiple cores it needs multiple threads.

Uh... did you mean "it needs multiple processes"? Because I think otherwise your statement contradicts itself...

Also, if your statement is "multi-threaded single process application can't run on two cores" then I think you're wrong.  What you quoted just says that threads share some resources, but that does not mean they cannot run on two cores.

I also looked up wikipedia (link btw), and the distinction in between threads and processes seems to be somewhat blurry, but I think it just comes down to processes are more like independent programs, whereas threads are more part of the same program, i.e. share more resources directly. It's not a clear cut because processes can communicate with each other, too.

So for DF for example, you could from th DF process create multiple threads, which share resources in that they access the same memory (e.g., to do independent path finding from a shared map data structure).

If that doesn't convince, here another quote from the same article:

Multithreading [...]. However, perhaps the most interesting application of the technology is when it is applied to a single process to enable parallel execution on a multiprocessor system.

[eerr]

what about all the stuff on the map thats not displayed? such as wars between goblins and elves
those seem the best target for not causing serious syncronization/access/whatever problems since its uncommon that something leaves or enters the map.