Print

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

[Nadaka]

The incrementor operator in the java language specification is not guaranteed to be atomic, and it never has been.

You could to add Object lock = new Object(); near the top and replace Counter++; with synchronized(lock){Counter++;};

or You could define a synchronize method that calls Counter++;

Its a simple issue of concurrency and synchronization. Though in something as vast as DF, there is a good chance that even someone who knew what they were doing would have a hard time ensuring correct behavior.

And of course as soon as you start throwing around locks or mutexes or other forced synchronization you not only lose the benefits of multi-threading you end up with something slower and less efficient than a single threaded loop running twice (one after the other).

Even in ideal cases multithreading has overhead. The more often you have to synch between threads the bigger the overhead and the smaller the potential gain. There is certainly a point, and one that's easy to hit, where your overhead from locks and other synching mechanisms is greater than the gain.

I know. I was merely pointing out that its not a crazy magic bug, because ++ was never designed to be an atomic action.

[Asmodeous]

Note: I am not a programmer, as I decided it was boring when I started learning.

I think that there's a distinct lack of understanding in multithreading, as the programmery sorts have made evident, but I don't think anyone really thinks it's a simple task to convert a program to be multithreaded.

Though some aspects are easier than others, for instance, wouldn't it be feasibly easier to apply pathing to a separate thread than to multithread... er.. the entire program? That way when you're playing the game you don't get as horrible a slowdown when the pathing program needs to be called heavily because of, say, a large dump order, a large build order, or a purchase of a lot of goods at the trade depot?

I would think that sort of multithreading would make a huge impact, and have a greater net-positive gain than most other options.

..though I think that's what someone is trying to do with a mod they were trying to work on. . .

[Sizik]

It seems to me that splitting pathfinding into its own thread wouldn't actually solve anything, as you still need to calculate all of the paths before you go to the next frame. (Although, multiple threads for pathing may work, as they could be run in parallel on different cores.)

[John Hopoate]

I don't see why Toady couldn't share the source code with one or two experienced programmers if they signed binding legal documents and had something to lose in the event they leaked it, maybe 200k+ in net assets.

[Nadaka]

I don't see why Toady couldn't share the source code with one or two experienced programmers if they signed binding legal documents and had something to lose in the event they leaked it, maybe 200k+ in net assets.

I would volunteer, but I have -40k in assets. Hahahahahaa.

[G-Flex]

I don't see why Toady couldn't share the source code with one or two experienced programmers if they signed binding legal documents and had something to lose in the event they leaked it, maybe 200k+ in net assets.

This discussion has been done to death.

Toady doesn't enjoy working with other people to such a degree; it would make the project less enjoyable for him.

And the legal issues would still be a headache anyway. It's not like contracts are some magic button that siphons money from a person; court is expensive, and if the person lives in another country it would be even more difficult.

[dreiche2]

Some interesting tests going on here, thanks for doing them!

Pathing while hauling (though not to haul, for reasons I'm unsure of) also seems to be a significant FPS drain.

Maybe that's because of the way of how dwarves pick the item to be hauled and the stockpile once they have the item? I mean obviously if the observed effect is real, it must be something like this. But specifically, a dwarf with a haul job probably (I might be wrong) does a broad search to find the nearest stone to be hauled. After he or she picked that stone up, the dwarf does a broad search for the nearest stockpile that accepts stone.

Now, stones to be hauled are much more abundant and spread out over the map than stockpiles to be hauled to are. Thus, the search for a stone might be faster than then the search for a stockpile.

Makes sense?

[Goran]

I don't see why Toady couldn't share the source code with one or two experienced programmers if they signed binding legal documents and had something to lose in the event they leaked it, maybe 200k+ in net assets.

I would volunteer, but I have -40k in assets. Hahahahahaa.

All you need to do is copy and paste 240 letters 'k' from various sites on the internet and you will have enough of net resources to cover your deficit of 40k and have 200 more k to vouch for your integrity.

Worked for Kelly Bundy when she was collecting 50k from newspapers for a BMW.

[John Hopoate]

And the legal issues would still be a headache anyway. It's not like contracts are some magic button that siphons money from a person; court is expensive, and if the person lives in another country it would be even more difficult.

If you for a fraction of a second bothered to understand the implications of what I was saying, you'd have realised that I only advised Toady to work with viable litigation targets (US citizenship implied) and your "magic button" strawman isn't going to fool anyone. If you knew shit about law, American or otherwise, you'd know a little something about rhetoric.

[G-Flex]

And the legal issues would still be a headache anyway. It's not like contracts are some magic button that siphons money from a person; court is expensive, and if the person lives in another country it would be even more difficult.

>:/

I would use this opportunity to say you have a point, but your attitude came off stronger than the content.

[sproingie]

One thing I enjoy about the DF fora that's unique to almost any other gaming board is the maturity level of the discussion.  Let's try to keep that in mind.  Even if you think the other guy is a jerk, it doesn't automatically necessitate a public denouncement.  Same goes if you think the other guy is being a jerk to you -- mounting a strident defense of your honor isn't going anywhere productive.  Lead by example.

[sproingie]

Maybe that's because of the way of how dwarves pick the item to be hauled and the stockpile once they have the item? I mean obviously if the observed effect is real, it must be something like this. But specifically, a dwarf with a haul job probably (I might be wrong) does a broad search to find the nearest stone to be hauled. After he or she picked that stone up, the dwarf does a broad search for the nearest stockpile that accepts stone.

As mentioned before, jobs choose dorfs, not the other way around, and this may in fact be the rationale as to why that is.  Even the biggest fortress has less than 300 dorfs, which is a smaller space to search than every extant job.  Even fewer of those dorfs are even eligible to do the job, so that prunes the search even more.  So selecting a job is O(1) (you pop it off the queue), and selecting an eligible dorf is O(n) for a very small n.

What DF may be doing is iterating over every single object to see if it has an associated job, which then makes job selection O(n) for a large n (though I'd at least hope it only pays this cost once when refreshing the job queue).  The cache-busting and heap-thrashing effect this sort of behavior would have is not a help either.

 

[Vicomt]

yeah, I get you, it's sortof:

Code: [Select]

foreach object in objectlist
  foreach task in tasklist
    if object.matches(task)
      foreach dwarf in drawflist
        if task.matches(dwarf)
          dwarf.assigntask(task,object)
        endif
      next dwarf
    endif
  next task
next object

however you're still attempting to iterate over the entire object list once per frame, even with the benefits of matching objects to tasks to dwarfs better. One possible way to modify it would be to dump all the objects (or any valid task target) into chunks, making, say 5 separate object arrays, and iterate over each of those object arrays once every 5 frames.

it's a tricky subject, and one that probably has multiple best solutions for different initial states, if I was going to try and optimise it myself though, I'd probably start by doing this as an additional job matching algorithm, and switch to using it when the conditions are right. Not sure how hard it would be to find and check those conditions, and whether or not the expense of this would be worth it in the first place though.

sorry for the codespeak

[Zironic]

This is the spoken advantage of quantum a.k.a running something that should normally be only able to be run linearly in multiples. Quantum computers use quantum particles ( atoms basically) to store data instead of transistors which can only store a 1 or 0, (or) On or off. Quantum particles however, due to super position can store data on many more states created using different superpositions and entanglements a.k.a Magic. Also, because of how entangled particles work, it is also possible to transmit data without needing to actually connect them. What this means overall is if one could make a quantum/digital computer combination that gives programs that required sequential execution to the digital, while sections of the program which can be done in parallel will go to the quantem computer which can calculate all of them at the same time. Thus While the majority of Dwarf Fortress can be run digitally, things such as pathing could be handled by a quantum computer. But this would mean a lot more hardware-wise, slight adjustments to the program (making it so the pathing is not linear but can be done simultaneously with it's self etc.).

This would take advantage of the digital's computers ability to process consistently but also the quatum computer to process simultaneous, without having to deal with a digital computer's lack of multi processing for a single program that isn't prepared to run multithreaded and without dealing with a quantum computer's lack of quick single processing (Basically, Digital is a kine of bicyclists drafting each other riding on a path, while quantum is a line of bicyclists side by side riding on a path). A combination of these two computers would probably be slower anyways due to converting n stuff, so You're better off just getting a really fast digital. But imagine the program acting like a bunch of bicyclist on a  pre-defined path, while riding on a small linear path, it's best to draft each other, however when they approach say a wider area, maybe it's easier to go more across so each person benefits from working along side each other. Now make that path infinitely long and say at certain ratios the path becomes infinitely wide, and there is an advantage of riding with each other side by side on the infinitely wide paths. The only problem would be widening out.

[sproingie]

I guess we just need to donate a quantum computer to Toady then