Print

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

[Darkweave]

Quantum computer cancels run dwarf fortress: schrodingers cat adopts heisenberg

Haha, very good.

[xmakina]

As discussed in the island topic, one option is to edit your worldgen parameters and severely restrict the amount of caverns and how far down they are. You could also try turning off Temperature, Weather and Invaders as well as use some of the DFHack tools to remove unnecessary items/filth etc.

As for code optimisations, unless Toady really low-balled the quality of the code as it is, I'd be surprised if there's any more that can be done to improve things. There have been several discussions on the subject but the end result is that DF is a massive game, ultra-optimising even whole sections (path finding, temperature handling, items, foreign movements etc. etc.) will do very little to improve overall performance because there's just so much stuff happening.

[Girlinhat]

a quantum computer takes advantage of a shrodingers cat situation, where things can be in multiple states at once and all that. I'll skip the lengthy explanation, but let me say, if and when we get quantum computing, one of those will be powerful enough to break military encryption in a heartbeat, a feat that cant be accomplished by every computer in the world put together (well it can, just takes a lifetime or two )

so, then you'll get your 108x108 embarks with no lag

A quantum computer (in theory, of course) operates by communicating with itself at micro time intervals.  This means that it communicates through time, accessing a computer that's a half second in time ahead of it, thus taking up the space and power of one computer, but having the ability of two.  Except, it does this thousands of time across microseconds.  So it might access 1,000 copies of itself from 0 to .1 milliseconds in the past, and another thousand of itself from 0 to .1 milliseconds in the future.

This does, in fact, make it HORRIBLE at running DF.  A quantum computer is basically a 2,000 core processor, and DF will only utilize one core at a time.  DF will run on a quantum computer as well as it will on your mother's desktop.  So while a quantum computer may access the secrets of the universe and unlock FTL travel, it will still succumb to a catsplosion or magma pumpstack.

DF is exempt from the normal rules.

[randyshipp]

Is there a technical reason it could not become multi-threaded at some point?

[JmzLost]

The reason DF won't be multicore anytime soon is that we only have one core programmer.  Toady does the primary coding himself, which means he'd have to stop adding features and bugfixes to rewrite DF for multithreading.  Baughn has coded the graphics to run in a separate thread, so any version that uses the SDL graphics is technically multicore.  But flows, path finding, item counts, etc are all single core.  And since it's all compiled as 32-bit, there's a limit to the amount of RAM the game can use.

Short answer, we don't need a quantum computer, we need a quantum Toady.

JMZ

[randyshipp]

And, forgive me for not having been following things for long enough to have heard this discussion before...but is there a reason he hasn't brought in additional resources, i.e. farmed out a bit of the work to experiment with some of those kinds of changes?

[Dwarf]

The reason DF won't be multicore anytime soon is that we only have one core programmer.  Toady does the primary coding himself, which means he'd have to stop adding features and bugfixes to rewrite DF for multithreading.  Baughn has coded the graphics to run in a separate thread, so any version that uses the SDL graphics is technically multicore.  But flows, path finding, item counts, etc are all single core.  And since it's all compiled as 32-bit, there's a limit to the amount of RAM the game can use.

Short answer, we don't need a quantum computer, we need a quantum Toady.

JMZ

Long answer, it seems DF, due to its sequential nature, is limited to one core, two if rendering is offloaded onto a second core.

It's as if you told someone to write, say, a long, long string of varied characters on a narrow band of paper. It just can't really be done by more than one person simultaneously.

[JmzLost]

And, forgive me for not having been following things for long enough to have heard this discussion before...but is there a reason he hasn't brought in additional resources, i.e. farmed out a bit of the work to experiment with some of those kinds of changes?

Let's see if I can get this right.

1) Money - programmers aren't cheap, and DF (and Toady) is 100% donation funded.
2) Closed Source - Toady doesn't want some or all of the DF code used to create a competing game.  Eventually DF 1.0 is planned as a game people will actually buy.

I think those are the main reasons, there may be more.  I can't remember which DFTalk had an explanation, but it was certainly one of the earlier ones.

JMZ

[randyshipp]

Point #2 is interesting in several ways.  I doubt it'd be productive to discuss it beyond saying that. :-)  Instead, I'm going to go back to play DF, which I'm very thankful for!

[Girlinhat]

What it comes right down to, is that Toady could, in theory, hire coders for him.  Sure, he could get some servers to run tests on, coders to hash out bugs, and synergists to, y'know, synergize or whatever.  But he doesn't want to.  DF is Toady's lovechild, and it's his project to do with as he pleases.  He enjoys working on it himself, and that's understandable because it's quite the impressive project and there's a lot of pride to know that you've done something yourself.  People seem to be under the misunderstanding that DF needs to be made better.  The truth is that we're just an audience.  Toady is in no way required to do anything, and is under no obligation to hire anyone or buy any equipment.  This is his project, and I'm fairly sure that it would be the same if he did this privately, and that's really what it comes down to.  This is his private project, and we're allowed to view it like an artist posting his unfinished sketches on an imageboard.

On-topic, I don't know much about the actual workings of a computer, even though I can program, but it's clear that multi-threading is a complicated change.  It's easy enough to start, but once a program has been made single, then swapping it to multi basically means going through the whole program and shifting numbers, and DF is likely in the tens of thousands of lines of code, likely much more.  It would take considerable effort to make the shift.

[JmzLost]

Yes, in theory, if Toady had the money he could hire coders.  He could also keep creative control, with said coders doing the implementation.  Practically, the money isn't there.  The next-to-last question in this interview was basically "why not go open source?" and the answer was basically "it's not financially sound".  I agree DF is Toady and Threetoe's labor of love, where they make the game based on what they want it to be rather than what will be most popular.  It's all their decision on who helps, and how much.  Fortunately they let us at the raws so we can mod to our hearts content.

On Topic:  Yes, adding multithreading is possible.  Yes, it would take a lot of effort.  Yes, it would take a very long time.  Right now, the focus is on adding more content.  Eventually, multithreading and 64-bit support will be added, just not soon.

JMZ

[Ganondwarf]

Okay, I know quantum computers fell off topic a few posts ago, but...what about optical computers? They use lasers instead of electricity, and of course light is faster. It's not quantum, but it's faster than what we have now. I think it will also boast faster cores, not just more of them.

And as to the "Can DF Be Multi-Threaded?", I think the answer is yes.
Many things operate independently of one another, ie pathfinding, temperature, weather, etc.
In fact, every single "process" (for the layman's definition) can be threaded, if allowed to operate on 1-frame old data. What I mean is, say right now dwarves pathfind according to what units are in their way, so they need to know where everyone else is going. But if we instead let them pathfind based on where everything WAS 1 frame ago, they can operate independently, hence, they can be threaded.

That's just what I think, but it does sound very convincing doesn't it?

[Girlinhat]

An optical computer is a regular computer that uses lasers instead of circuits.  They're theoretically identical, with the same wiring layout except no actual wires.  An improvement, yes, but I'm not sure if an actual processor can be optical, or if it's just the motherboard and other parts.  But, I haven't researched them much at all, so I have no idea.

[Number7]

Quantum computer cancels run dwarf fortress: schrodingers cat adopts heisenberg

i lol'd


EDIT: also, GLaDOS from portal actually did the shrodingers cat test, dozens of times

The bad news is reality doesnt exist, the good news is they now have a cat graveyard

Very dwarfy

Did you get that from my thread, or is it a coincidence?

the very dwafy addition is, but i read that bridging comic ages ago, and the middle line is almost an exact quote from GLaDOS, so yeah. i brought it up because of the shrodingers cat stuff

[Niseg]

Multi-core discussion again  . I don't think it should be considered unless you do a GPU offloading (300+cores). And if you want a fast CPU a Ga-As processor can reach about 50GHz and a Si-Ge processor was made recently which ran at 350GHz on air and 500GHz on liquid nitrogen.

If path finding is the problem that causes the degradation of  FPS  my room system (the no cache button) can fix it easily. Theoretically you can run a 16X16 embark with same FPS as 1X1 with a room based pathfinding but... there are other things like flows and temperatures - I don't know how they work...

The best way to improve performance is to improve algorithms but because we aren't in control of that just get the fastest cpu (single core performance) and overclock it. (2500k/2600k are the winners today).