Print

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

[The Architect]

...No. Just...no

This isn't TVtropes, around here were we support our ideas.

Also that was very annoying Blacken. What If I quoted you can and instead of actually responding I just said "No"?

Is this what you were saying? And yes, I would say that Blacken's impatient tone of superiority is irritating. It would be nice to see some reasonable and well-thought, well-supported, well-written responses. I asked for help and information, and got a smart-ass, "I'm tired of dealing with ignorant people" response. About half of what was said didn't even apply to my comments, but seemed more of a generic response to past irritations Blacken has experienced when dealing with irrational and ignorant people who demand the impossible.

[Footkerchief]

So be it, if this is in any way feasible with the source code then let's ask for it. If it's not possible either way then sure I'll forget it. But let's not dismiss it out of hand based on things that may or may not be the case (Toady/Threetoe never agreeing to such a thing).

In a general sense, it's out of the question:

# Will you make Dwarf Fortress open-source so the community can speed development and fix bugs?
No. We don't want to associate with other people at a quasi-professional level, since this would make development less enjoyable. This is not a job for us; it is our personal mission.

# But will you make Dwarf Fortress open-source for forks and tinkering?
No. Heavily diluting Dwarf Fortress adds a strong element of unpredictability to our support, and your donations are our sole source of income. While donations might not be affected at all, it's not a risk we can take at this point if the project is to continue.

Now, if that was a hard-and-fast rule then we wouldn't have 40d#.  But I/O was relatively decoupled from the rest of the program.  The parts of the code that would have to be opened for useful parallelism are probably more... intertwined.

I was actually looking for something to interpret the processes and feed DF information that it would normally need to manually cycle through. Not work the whole program on a multi-thread base. But most likely this would require non-existant output and non-existant input options. Outsourcing just the stocks database, causing DF to feed the info to a separate process and retrieve it from said process would cut the load tremendously, would it not?

DF can sequentially request info from the program rather than calculating it itself as it does now. The "emulator" would just be an interface. I do realize now that it might be the wrong term for such a program, but I dont' know a better one. The emulator would cause DF to believe xy was happening, when in fact z was performing the functions of xy separately. The same could be done with pathing, but that would be insanely problematic and likely to produce a headache just contemplating, but those are the two major drags besides job priority checks. Allowing us to set our own job priorities for dwarves and groups would probably cut lag in large forts by a ton as well. This problem could be circumvented by outsourcing the Jobs menu and feature to a separate program.

I think what you're describing here is essentially an asynchronous API.  We actually have people here working on a DF pathfinding library, although Toady has expressed no support for the project that I know of, and I don't know if they're envisioning it being used asynchronously.  But yeah, that approach is not totally without promise.

This isn't TVtropes, around here were support our ideas.

Also that was very annoying Blacken. What If I quoted you can instead of actually responding I just said "No"?

Sorry, but I had the same reaction to what you said.  Vista failed because clock speeds aren't rising as fast?  Huh?

[Blacken]

Asking a program to look at the compiled program (or even the source code) and do this for you relies on the same lack of understanding as asking someone "Why won't the computer do what I want?" - the computer never does what you want, only what you tell it to. Even the different parts of DF's code that could be run in parallel currently are not and will interface in ways that no program can magically figure out for you.

I think this is an oversimplification, if I'm remembering my Op Sys class correctly, which I'm not at all sure of.

Actually, he's pretty close. It is extremely difficult to figure out programmatically what code is serial (requires the results of previous code) and what code can be safely parallelized. A person can look at it and go "this, right here--this can be parallelized easily", but the heuristics to make a computer do so...not so much. There are techniques to do it, but (there be a pattern here!) they invariably require the source code.

(A pet interest of mine is compiler design, so I've been exposed to an unhealthy amount about this stuff. )

Splitting the processes DF does (if that is even necessary) might require access to code that has not previously been available to players, and we may need Toady's help. If that is so, then let's go there with it.

The point of this is to enable DF to utilize our computers' true potential without the need to rewrite the whole program. A program-specific emulator. Not a universal tool.

It seems obvious to me that I have already stated the possible need for access to the source code. You're right, I don't know a lot about what I am proposing. From what you say, access or at the very least close cooperation would be absolutely necessary. So be it, if this is in any way feasible with the source code then let's ask for it. If it's not possible either way then sure I'll forget it. But let's not dismiss it out of hand based on things that may or may not be the case (Toady/Threetoe never agreeing to such a thing).

I was actually looking for something to interpret the processes and feed DF information that it would normally need to manually cycle through. Not work the whole program on a multi-thread base. But most likely this would require non-existant output and non-existant input options. Outsourcing just the stocks database, causing DF to feed the info to a separate process and retrieve it from said process would cut the load tremendously, would it not?

DF can sequentially request info from the program rather than calculating it itself as it does now. The "emulator" would just be an interface. I do realize now that it might be the wrong term for such a program, but I dont' know a better one. The emulator would cause DF to believe xy was happening, when in fact z was performing the functions of xy separately. The same could be done with pathing, but that would be insanely problematic and likely to produce a headache just contemplating, but those are the two major drags besides job priority checks. Allowing us to set our own job priorities for dwarves and groups would probably cut lag in large forts by a ton as well. This problem could be circumvented by outsourcing the Jobs menu and feature to a separate program.

As I'm looking at it now, it definitely requires full cooperation from Toady. One thing it does not require is a rewrite of the program.

Really. Where are the credentials you're bringing to the table that say you know this? Do you tell your mechanic that no, he's wrong, just throw an extra set of wheels on it and it'll go faster? Because that's pretty much what you're doing here.

I've built monolithic single-threaded applications before and, uh, none of it's even remotely done this way, ever. The information-service architecture you're trying to suggest would almost certainly require even more restructuring than just manually parallelizing what's already there! Don't conflate this with stuff like the DF pathing library--that is being developed in a vacuum in hopes that Toady can later on integrate it himself (and they're doing fine work, I love reading that thread--I haven't posted there because algorithm grinding isn't my specialty, I don't have the head for it).

...No. Just...no

This isn't TVtropes, around here were support our ideas.

Really? You do? You, specifically, do? I couldn't tell from your half-redigested repetition of something that wasn't even relevant!

I'm not derailing this thread to indulge you and I won't reply to any silly attempts by you to rationalize what you said, but let's just go over this quickly. Vista "failed"--if an operating system that sold eight bajillion copies could be said to "fail"--because they put "ready for Vista" stickers on computers everyone knew weren't ready for it and, in doing so, poisoned the brand in the mind of Joe Public. It had nothing to do with diminishing performance returns from processor research. This is not the thread to debate this, so kindly don't. Just stop. Go make a "I think Vista failed because processors aren't getting faster no more!" thread if you really feel the need. Make sure you figure out why Win7 is a ridiculous success at the same time when it's pretty much Vista SP3, though.

And yes, I would say that Blacken's impatient tone of superiority is irritating. It would be nice to see some reasonable and well-thought, well-supported, well-written responses.

Then ask reasonable and well-thought, well-supported, well-written questions. You aren't dude. I can't be blamed for calling silliness what it is.

I asked for help and information, and got a smart-ass, "I'm tired of dealing with ignorant people" response. About half of what was said didn't even apply to my comments, but seemed more of a generic response to past irritations Blacken has experienced when dealing with irrational and ignorant people who demand the impossible.

With all due respect, I don't think you have the knowledge to determine what is relevant to your comments.

Look at everything that's been posted in this thread. I'm sorry that using blunt sentences isn't something you like, but everything I've said has been true. You are asking for what essentially amounts to the impossible. It sucks, everybody gets egg on their face once in a while--I'm sorry that your in-theory-great idea is practically not possible, but it isn't.

If we want reasonable and well-thought, well-supported, well-written responses: you start. Find some sources that suggest what you're talking about is even possible. Do some research before insisting that I'm wrong--you're asserting a positive, the burden of proof is on you.

I'll wait.

[The Architect]

It would be nice to see some reasonable and well-thought, well-supported, well-written responses. I asked for help and information...

So, Footkerchief did this. And subsequently increased my respect for him all the more. Thanks for the useful info, lookin it over now.

[Blacken]

It would be nice to see some reasonable and well-thought, well-supported, well-written responses. I asked for help and information...

So, Footkerchief did this. And subsequently increased my respect for him all the more. Thanks for the useful info, lookin it over now.

'Cause pointing out that OOE requires independent data sets (post #4, but that's OK, you are clearly reading what you think people are saying instead of what they are saying) and as such makes DF less than friendly to what you propose--oh yeah, that's totally not reasonable, well-thought, and well-supported. Except that it is. <_< >_> <_< >_> But recognizing that wouldn't let you play passive-aggressive games, so I guess we can't have that.

[Neonivek]

No Footkerchief you said huh and Blacken said "No".

How am I supposed to respond to No? even "What?" is more informative.

If we want reasonable and well-thought, well-supported, well-written responses

No I just want more then "No". no means nothing.

I couldn't tell from your half-redigested repetition of something that wasn't even relevant!

It was perfectly relevant. I started with the premise that perhaps all this focus on making DF better is pointless since computers may improve at the rate in which the problem will solve itself.

I then went onto say that the rates in which computers are improving is going down and then gave an example.

-----------

I like the casual style of conversation on the internet, I don't enjoy whipping out rhetoric and long posts. I really hope I won't have to in this case.

[The Architect]

If we want reasonable and well-thought, well-supported, well-written responses: you start. Find some sources that suggest what you're talking about is even possible. Do some research before insisting that I'm wrong--you're asserting a positive, the burden of proof is on you.

I'll wait.

You're fighting ghosts here, man. I don't think I would be wrong to say you are poisoning this whole topic. Stop going on personal crusades and play ball here! I have admitted my ignorance at every step. You're imagining an ignorant enemy, demanding that he's right and telling you that you are wrong. No one has done that here, and I'm not your enemy. Just chill the fuck out, if you'll pardon the rude expression. You've earned it.

We are looking at potential ways to solve a problem. If it's impossible, or impractical, then say so and give reasons. That's fine. But really, stop your personal crusade against the ignorant masses. That's all your posts are, and their helpfulness (though considerable) seems to be an accidental side effect.

I'm not an ignorant guy with the flu demanding antibiotics. I'm asking for information and proposing ideas. So like I said: play ball, or shut up.

[Blacken]

You don't get it, dude. What you're asking is like asking an architect how to make a thirty-mile bridge without any supports. Physics, whether on the bridge-building or the processor-architecture scale, does not work the way you think it does. You've been getting a "Whaaaaaaaaaaat?" reaction from people in-the-know (I'm not the only one in this conversation who's saying these things, I hope you've noticed) because it is not feasible.

If you have the money in your pocket to hire a dozen engineers from VMware to automatically parallelize object code, then by all means (just don't expect huge results)--but you don't, and this topic doesn't do anything. That's what I've been saying, and that's what other people have been saying, and that's what you don't want to hear. You keep saying you don't know anything about it, and people who do know about it are telling you it's not doable, and you get huffy and get mad! What the hell gives, man?

The way to solve this problem is to let Toady do it when he's ready. He has the code. It's his ballgame. Not yours, not mine. His.

I'm sorry that boundless optimism doesn't change physics and math. I really am. But getting pissed at me for pointing out the obvious is the wrong place to look.

[The Architect]

Ah geez man you really, really need to chill out. No one is mad at you for shooting down ideas. Like I said: YOUR CONTRIBUTION IS CONSIDERABLE. But your tone is constantly offensive and you constantly go off-topic over your personal crusade.

Let's look at other ways to do it. I will present the idea to Toady of we have something useful, if we can't come up with anything then that's fine. Is it impossible to outsource processes much the way you outsource labor? When DF normally queries for closest resources every time the dwarves perform a job, causing massive processor delays, can't we have it query an updating separate database? We would basically be rewriting a small part of the program separately without the need to change the very thing you keep saying it is impossible to change.

Toady's cooperation is necessary. Rather than assuming we can't get that cooperation, let's just consider whether it is possible that we might be able to do something if we can. It's not going to kill us to consider the hypotheticals here in this thread.

For the last time, if you dont' want to play ball, then leave. This isn't the place for your crusade against your invisible enemies. If you want to continue to contribute without the sarcasm and off-topic defensiveness, then it would be nice to have your knowledge.

Damn you're stubborn about it.

[G-Flex]

The thing is that if Toady were to knock off a chunk of the code (say, pathfinding) and pass it to the community for improvements like he did with the OpenGL code, then it would have to be made roughly independent of the rest of the program by him to such a degree that a lot of the work involved in multithreading it would probably already be done.

[bombcar]

Basically, you're asking for the source, which Toady has repeatedly said he's not releasing. That's more the problem than any understanding of modern CPUs.

[Neonivek]

Basically, you're asking for the source, which Toady has repeatedly said he's not releasing. That's more the problem than any understanding of modern CPUs.

Though there is one way around that. If you can create an algorithm/equasion that can find Prime Numbers then you won't need the Source Code.

[The Architect]

Basically, you're asking for the source, which Toady has repeatedly said he's not releasing. That's more the problem than any understanding of modern CPUs.

The last thing I want to do is hijack the Adams brothers' dream. It's also obvious that I couldn't do any of the required programming myself. But I would like to discuss the possibilities. From what's been said, we can't do it ourselves. Given cooperation from Toady on whatever necessary level, is it even possible to create an interface/utility that would do what I've suggested?

[Footkerchief]

The thing is that if Toady were to knock off a chunk of the code (say, pathfinding) and pass it to the community for improvements like he did with the OpenGL code, then it would have to be made roughly independent of the rest of the program by him to such a degree that a lot of the work involved in multithreading it would probably already be done.

That would only hold for an asynchronous approach, right?  I'm not sure, but I suspect the pathfinding people had a synchronous approach in mind, so that they wouldn't have worry about the map changing while a path request is handled (although I guess that isn't a huge problem from a dwarves-aren't-omniscient POV).  I suppose I should go ask them.

[Neonivek]

Has anyone brought up how switching the game to multithreading wouldn't have as much of an impact as it would seem?