Print

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

[profit]

Yeah I would like to see a FUSION and CUDA compatible API myself, where the code would work if you have an ATI or a Nvidia, or use the CPU's remaining cores if you had neither.  Would really help for physics and water sims...

Kinda beyond the scope of DF though and into the realm of "if wishes were fishes"

[arkraven]

I wish there was a way to have all your core act as one core rather than edit the game...

[SSBR]

There is a way, sort of. Implicit parallelism is possible, but not really in the way you describe, and while it may be possible with C++ it'll almost certainly be difficult-- C++ allows you to break the necessary assumptions. The area of research where you can ignore the existence of multiple cores without losing their benefits is with other programming languages, in particular Haskell, but also other functional languages like Scheme, ML, OCaml. And even then, at the present time you can't really ignore it totally.

[Googolplexed]

I don't see why you bring up C/C++. The language MIGHT have something to do with multi-threading IF you had the source code, and for a functional and interpreted language it MAY be possible without it.

But for something compiled, the language does not matter, its all just binary/machine language in the end. If someone did find a way to make pure machine code multi-threaded without much effort, then they would win a medal or something.

I'm not sure why you brought C into this, we don't have the source, so it isn't C for us.

@arkraven
It would be great, but for the moment and for the foreseable future it seams impossible.

[SSBR]

I don't see why you bring up C/C++. The language MIGHT have something to do with multi-threading IF you had the source code, and for a functional and interpreted language it MAY be possible without it.

Because this is the Dwarf Fortress suggestions board, and Dwarf Fortress is written in C++. Given, that's not the only applicable language, as the statement was broader, but I figured I'd get the important bit out of the way first. DF isn't going to get rewritten in Haskell. :p

But for something compiled, the language does not matter, its all just binary/machine language in the end. If someone did find a way to make pure machine code multi-threaded without much effort, then they would win a medal or something.

Well, no. Compilation is the process of translation, that's pretty much it. Compilation can be multi-step-- for example, you might compile an unthreaded non-multi-process single-core ExampleLang file into a multicore C file and then to a multicore native program. Compiled languages can in fact get this magical multi-core thing, the main requirement is just that data dependencies be limited, as with functional languages. For example, GHC, a Haskell compiler (to native code), has an alpha implementation of this implicit parallel execution via DPH. There are also paradigms other than functional that can do this-- in particular, logical programming can, but I don't know if anybody's trying. Haskell gets a lot of attention.

I'm not sure why you brought C into this, we don't have the source, so it isn't C for us.

I brought in C++, and we won't get to implement anything. Is this thread going to become a lamentation about multicore programming in general? I honestly only said it because I assumed we were still talking about the difficulties involved in improving DF to be multicore. C++ is relevant in that context.

[Googolplexed]

Ah, slight misunderstanding then

I though you were replying to arkrevan, and suggesting that without the source code we could make DF multi-threaded. Of-course if that was the case then we would be working with assembly, hence my point about C++ not being relevant

If you were talking about toady, then C++ is defiantly relevant

[sproingie]

DF isn't going to get rewritten in Haskell. :p

Not by Toady anyway, but I am starting up a project to write a "sim roguelike" in Haskell.  I'm calling it Goblin Horde.  No way is it as ambitious as DF, but true to the "horde" theme, I hope to introduce interesting crowd behaviors.

The problem with Haskell isn't so much speed, but memory consumption.  Lazy evaluation is a kick in the ass as far as memory footprint goes.  Multithreading is ridiculously easy, and threads are lighter than even Erlang's, but as I found out with some attempts at cellular automata, data parallelism using Control.Parallel may be easy but getting it to actually result in performance improvement is another matter entirely.

[blue sam3]

Just to prove that DF isn't unplayable, I've just loaded up my current fort (a 40-dwarf megaproject fort, with half of the map designated for digging, massive numbers of stones lying around, two rivers, an ongoing catsplosion, the whole nine yards, on the worst computer that was available, a 2 year old Dell, with a Intel Core2 Duo T8100 @ 2.1GHz, with 3gig of ram, running 32bit windows vista. Even without any init changes besides removing the FPS cap, and running several other applications at the same time, I managed to get far more FPS than I would ever need. It generally averaged around 400 FPS. I took a screenshot, but the FPS spiked somewhat when I took it, so it displays 716 FPS.

Spoiler (click to show/hide)

If this computer can do it, then DF is by no means unplayable, even on relatively old systems.

Once my system to reroute one of the rivers for use as a farming balcony flooding system is finished, I'll try it again, to see what I can get then.

[Googolplexed]

Look, this is now the FORTH time I've had to show this picture.

Spoiler (click to show/hide)

That image is zoomed out, it took 3 days real-time to finish flooding apparently

Yeah, its excessive, but it seams to be what alot of people here are complaining about frame-rate wise. I don't have framerate issues, and neither do most people who limit themselves, but download a succession fort, and you will see the framerate issues.

BTW before you say that a C2D is old, some of us are on much worse computers.

Currently on a 2.6ghz P4 here. (Not my main though, its halfway across the world)

[sproingie]

That's certainly a big project, but there's a few things about it to your favor:

1. Pathfinding isn't terribly complex --the actual fort parts look exceptionally well organized.

2. You've used up the raw materials.  There's apparently some performance bug where having tens of thousands of stone kills performance, but that many walls or floors does not.

3. I can't tell how many z-levels your fully-paved map covers.  Pathfinding is horribly optimized when it comes to z-levels.

Things that kill FPS are well-known -- what isn't known is the layout of the forts for those who are complaining.  Going to be pretty hard to ever get performance bugs nailed down from anecdotes alone.

[Gertack]

Things that kill FPS are well-known -- what isn't known is the layout of the forts for those who are complaining.  Going to be pretty hard to ever get performance bugs nailed down from anecdotes alone.

http://www.bay12games.com/forum/index.php?topic=44482.msg854409#msg854409

That's one of my fortresses having the problem, although not the worst of the two.

And I continue asserting that algorithms, not multi-threading, are the bigger benefit and easier payoff as Dwarf Fortress stands right now.