Print

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

[numerobis]

I feel like OpenMP grew out of HPF (high performance fortran).  So that would be why olemars finds it so familiar.

Loop parallel algorithms are nice, but sadly, that's not usually what we end up with (when was the last time you wrote a loop that iterated over a few thousand things, all of them independent).  The likeliest things to fit the framework would be flows, temperature, and weather.

[olemars]

I feel like OpenMP grew out of HPF (high performance fortran).  So that would be why olemars finds it so familiar.

Loop parallel algorithms are nice, but sadly, that's not usually what we end up with (when was the last time you wrote a loop that iterated over a few thousand things, all of them independent).  The likeliest things to fit the framework would be flows, temperature, and weather.

It indeed works well on lattice models of fluid flows used for scientific simulations. But then again, how accurate do the flows need to be in a game like this? I would think there is some simpler way to fake something flowlike in a tile-based world.

[numerobis]

Toady is essentially using a very simple finite difference method for the flows.  He follows standard practice and calls it a cellular automaton; the language and the way of thinking differ, but the math is basically identical.

Basically, every tile computes "how much water will I have next by pushing water to/from my neighbours."  That's trivial to parallelize.  Of course there's no point computing this on tiles that won't change, so you have to only run "every tile" on those that may change.  There are some other complications, which all make it less trivial to parallelize, but I'd still expect you could openMP this stuff.  I'm not clear whether Amdahl's Law suggests this is a good idea or a red herring, and I can't be clear since I can't profile Toady's code.

[isitanos]

Wow Dreiche, that's a very well researched and presented thread. One thing that you didn't mention is that instead of creating threads you can create separate processes, which can communicate through pipes or other means. I'm currently learning to use the fork() command in Unix/Linux programming: it's pretty interesting since after the fork() instruction your code is actually executed by two separate processes, and you can put checks in the code to identify the father or son process and act accordingly.

Processes seem easier to work with, and less error-prone if they communicate through standard input/output, but it's slower and more memory-intensive than threads.

[isitanos]

It might help Toady if someone spent the time applying these changes to Battle Champions or Kobold Quest, so he could see it in action.

I really enjoy the interplay between the community's programmers and The Programmer himself. I think his idea to release a portion of DF code in the form of Battle Champions was a great idea. Thanks for posting all this!

Battle Champions? Never heard about that, and a forum and google search yield nothing. Is it sitting in some very obscure corner of the Bay 12 Website?

[korora]

It's "Battle Champs", and it lives in the Announcement thread for 40c.

[Maggarg - Eater of chicke]

Oh no, coding!
I was never good at languages.