Print

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

[Urist McVoyager]

Multithreading is end level stuff, just like the UI. And with 20 years to do it, I think Toady could learn enough to finish the end product without having to do it all at once.

My 2 cents: Organization would be good, but that's something Toady would have to keep up on, and I can understand why he wouldn't want to. I'm going to be looking into the files myself to see what can and can't be redone, see if I can organize some of it for myself. Doubtful, I'm sure others would have already posted fix-it files if the menus themselves were modifiable. But I won't know for sure until I look.

As for graphics . . . having a unique symbol for everything would be nice, just because of the repeats we've had with goblins and goats and stuff like that. No 3d. None at all. Full 3D like Minecraft limits what the game can keep up with. And forget the half step that RTSes have been doing for years. It amounts to nothing more than tilting the game board up just enough to start blocking your sight of stuff. It gives an illusion of depth that isn't worth the aggravation of not seeing every tile. DF's From The Top viewpoint is the best way to portray a game like this.

[wierd]

Careful!

Re-ordering the entries in the raws will alter the game's behavior! There was some research into this some months ago, and it was determined that the data structures in memory are unsorted object arrays read straight from disk.

A world genned with reorganized raw entries will not repeat on vanilla raws!

Again, this is a very good reason to have graphics processing information seperate from simulation information.

[Putnam]

I'm not sure what the data structures containing all the raw objects being read straight from disk in file order is really related to graphics info.

Besides, creatures do have a sorted vector, sorted by their singular noun.

[wierd]

For certain, I know mineral layer objects are only sorted by layer type, but otherwise don't get a sort done on them. I would bet (a small amount of) money that creatures are similar, and that if you have an embark infested with lizards, you could swap the vermin creature raw location with that of say, brown recluse spiders, and get those to show up instead. (As long as both have suitable biome tags at least-- didn't check)

Sorting the raw data to make it easier to find things will still have an effect on gameplay, even if it is just constrained to mineral choices during worldgen.

As for why that's important, let's play devil's advocate, and make some assumptions:

1) toady has implemented "full tileset graphics", but has done so without moving where the ascii glyph assignment info is placed.
This means things like the plant raw will contain data for trees, bushes, and grasses; etc.

If the graphics mod maker dislikes how those files are structured, and restructures them to make it harder to make duplicated entries, and to streamline checking off maintenance edit lists, then his modpack will alter object order in the array, and poses a risk of making worlds unrepeatable to other players without that mod.

True, that could easily be fixed by sorting all the object arrays by name after sorting them by type, but toady so far has not seen any reason to do that.

If, however, the rendering information is contained in a single location, and those get mixed up by an organization focused modder then it won't impact the simulation engine, and the effects of being in a different order won't be so serious.

[Urist McVoyager]

I was referring to the menu stuff, really. Not the creature data. I don't wanna mess around with the creatures and plants myself, just see if there's a way to get this level of organization everyone wants on our own, instead of asking Toady One to do it for us. If we can, someone can do another mod like the Utilities we already have, and just update it for every release.

[wierd]

New menus can be injected using dfhack, take for instance the "auto material selection" plugin, used for putting constructions down. It puts new menu entries in the building menu, and alters gameplay behavior to make it easier to make large constructions.

In addition to that, there's also "whole new menus" injected with dfhack, like the "therapist"-alike plugin, which adds an ascii therapist like menu for mass-management of skills.

That combined with custom keybinds, and full graphics mode support would give basically full control over the UI to the modding community. The "truly serious" could make it happen.

The missing feature is full graphics mode.

[MrWiggles]

Toadyone isnt into multi threading the game either.

If I recall correctly it isn't that he's against multithreading as such, it's that he doesn't know enough about multithread coding to do it without it resulting in massive work on his part better spent other stuff. (?)

And the graphics stuff was done by Baughn :>


Edit: Not that your phrasing necessarily is incompatible with the real picture, but other people could get the idea Toady just didn't like multithreading for no reason

He said in one of the Dwarf Talks that he feels there would be little to gain from the amount of work it would take to multi thread dwarf fortress.

[Urist McVoyager]

At some point someone's going to break things down and show him math that either supports or refutes that feeling. Assuming he hasn't actually done the math himself, in which case he already knows.

[wierd]

Toadyone isnt into multi threading the game either.

If I recall correctly it isn't that he's against multithreading as such, it's that he doesn't know enough about multithread coding to do it without it resulting in massive work on his part better spent other stuff. (?)

And the graphics stuff was done by Baughn :>


Edit: Not that your phrasing necessarily is incompatible with the real picture, but other people could get the idea Toady just didn't like multithreading for no reason

He said in one of the Dwarf Talks that he feels there would be little to gain from the amount of work it would take to multi thread dwarf fortress.

I am disinclined to accept that thinking; DF most certainly is computationally heavy and memory bound, but not all multiprocessing architectures are created equally. Specifically, there are major differences in how memory is handled between processors in SMP, CUDA and NUMA architectures.

Intel and AMD processors use SMP, which can become memory bound over the shared memory bus, however NUMA and CUDA architectures are significantly less prone to this, and many of DF's computations appear to be purely mathematical; in specific, weather, heat, and fluid computations.  Making use of recent trends of GPU computing could very well give a tremendous payoff. (and no, saying that there is too much disparity between GPUs in the market for proper targeting is a canard. There are only 2 major types, and both major x86 chip makers are now embedding such silicon on the CPU itself these days. By the time toady gets around to trying something like that, it will have been on-die silicon for years, and be a standard feature. Saying the on die gpus wont give the same performance boost to a memory bound application as a discrete one is at least a proper argument. However, it discounts abusing the on-die GPU in clever ways to serve as both a processor for math functions as well as a rather large number of what would essentially be CPU registers which would be just a handful of nanometers away from the APUs inside the CPU, meaning some of his computations need never touch outside memory anyway, reducing the memory bound nature of the problem. This can be further diminished by the increased cache size available to the program by dividing it over multiple discrete processing cores; or rather, the increased efficiency of cache use. The repetitious nature of DF's hard math computations would lend themselves quite well to heavy cache munching like that.)

Would it be an epic shitton of work? Certainly. Is there any real payoff to putting it off until later? NO. (1)

Is there a serious disadvantage to putting that kind of work off until later? YES. (1)
Will Intel and AMD return to the "Faster silicon!" marketing direction? NO. (2)
Will Toady eventually have to switch to SMP? YES (2)-- If he wants DF to run at faster than 3fps on a gaming rig.

(1) As the complexity of his logic increases, trying to find ways to salvage the work already done when porting it to SMP type architectures becomes increasingly difficult. If it is hard now, it will only be at least geometrically harder later. This means he is not saving himself any effort by avoiding SMP now, at the "Early" side of development (given his ambitious goals). He might think he is, but he isn't.

(2) The whole reason we are getting multiple core CPUs instead of ever faster silicon like we got in the 90s, is because we are reaching the thermal and electrical limits of silicon. Unless some new wonder material actually manages to take real marketshare, we will NOT return to faster silicon as the status quo in processor revision. Since all the contenders for silicon rely on either radically expensive manufacturing processes (monoatomic thin sheets of tin, for instance), or on highly exotic materials (like synthetic diamond or on graphene) That is VERY VERY unlikely to happen within the next 10 to 20 years. Later than that? possible-- but not in the foreseeable future. Further, there is already a trend with some motherboard makers who specialize in SOHO server boards to make hybrid SMP/NUMA boards, which have multiple CPU sockets, intended for multiple core CPUs.  Each physical CPU has prefferential access to a chunk of the memory bus in a NUMA like configuration, where each chip then acts as SMP over that chunk. As the demands for better memory access increase due to the new direction chip makers have been forced to take, board makers will likely take these currently server-class ideas and implement them on commodity boards later. Making DF SMP aware now would reap the benefits of the hybrid NUMA architecture relaxing some of the memory bound IO issues when that eventuality comes to pass in the hardware market.

Again, I cant really tell toady his business; I just dont buy that line of reasoning, since I know better.

[MrWiggles]

Toadyone isnt into multi threading the game either.

If I recall correctly it isn't that he's against multithreading as such, it's that he doesn't know enough about multithread coding to do it without it resulting in massive work on his part better spent other stuff. (?)

And the graphics stuff was done by Baughn :>


Edit: Not that your phrasing necessarily is incompatible with the real picture, but other people could get the idea Toady just didn't like multithreading for no reason

He said in one of the Dwarf Talks that he feels there would be little to gain from the amount of work it would take to multi thread dwarf fortress.

I am disinclined to accept that thinking; DF most certainly is computationally heavy and memory bound, but not all multiprocessing architectures are created equally. Specifically, there are major differences in how memory is handled between processors in SMP, CUDA and NUMA architectures.

Intel and AMD processors use SMP, which can become memory bound over the shared memory bus, however NUMA and CUDA architectures are significantly less prone to this, and many of DF's computations appear to be purely mathematical; in specific, weather, heat, and fluid computations.  Making use of recent trends of GPU computing could very well give a tremendous payoff. (and no, saying that there is too much disparity between GPUs in the market for proper targeting is a canard. There are only 2 major types, and both major x86 chip makers are now embedding such silicon on the CPU itself these days. By the time toady gets around to trying something like that, it will have been on-die silicon for years, and be a standard feature. Saying the on die gpus wont give the same performance boost to a memory bound application as a discrete one is at least a proper argument. However, it discounts abusing the on-die GPU in clever ways to serve as both a processor for math functions as well as a rather large number of what would essentially be CPU registers which would be just a handful of nanometers away from the APUs inside the CPU, meaning some of his computations need never touch outside memory anyway, reducing the memory bound nature of the problem. This can be further diminished by the increased cache size available to the program by dividing it over multiple discrete processing cores; or rather, the increased efficiency of cache use. The repetitious nature of DF's hard math computations would lend themselves quite well to heavy cache munching like that.)

Would it be an epic shitton of work? Certainly. Is there any real payoff to putting it off until later? NO. (1)

Is there a serious disadvantage to putting that kind of work off until later? YES. (1)
Will Intel and AMD return to the "Faster silicon!" marketing direction? NO. (2)
Will Toady eventually have to switch to SMP? YES (2)-- If he wants DF to run at faster than 3fps on a gaming rig.

(1) As the complexity of his logic increases, trying to find ways to salvage the work already done when porting it to SMP type architectures becomes increasingly difficult. If it is hard now, it will only be at least geometrically harder later. This means he is not saving himself any effort by avoiding SMP now, at the "Early" side of development (given his ambitious goals). He might think he is, but he isn't.

(2) The whole reason we are getting multiple core CPUs instead of ever faster silicon like we got in the 90s, is because we are reaching the thermal and electrical limits of silicon. Unless some new wonder material actually manages to take real marketshare, we will NOT return to faster silicon as the status quo in processor revision. Since all the contenders for silicon rely on either radically expensive manufacturing processes (monoatomic thin sheets of tin, for instance), or on highly exotic materials (like synthetic diamond or on graphene) That is VERY VERY unlikely to happen within the next 10 to 20 years. Later than that? possible-- but not in the foreseeable future. Further, there is already a trend with some motherboard makers who specialize in SOHO server boards to make hybrid SMP/NUMA boards, which have multiple CPU sockets, intended for multiple core CPUs.  Each physical CPU has prefferential access to a chunk of the memory bus in a NUMA like configuration, where each chip then acts as SMP over that chunk. As the demands for better memory access increase due to the new direction chip makers have been forced to take, board makers will likely take these currently server-class ideas and implement them on commodity boards later. Making DF SMP aware now would reap the benefits of the hybrid NUMA architecture relaxing some of the memory bound IO issues when that eventuality comes to pass in the hardware market.

Again, I cant really tell toady his business; I just dont buy that line of reasoning, since I know better.

I always love post like this, as they have magical knowledge of the code and know whats best for it then the Dev that is actively working on it.

Can I have some lottery numbers, oh magical one?

[wierd]

There is more than one way to obtain knowledge about how a program runs, Oh cynical one.

DF uses large memory object arrays. The major performance issues with it are in memory related activities. Aka, "memory bound".   This is easy to derive: the published specs for memory access rates for consumer cpus are public knowledge, the width of the memory bus is likewise public knowledge, the size of the data in memory for the game is easily obtained, as the OS will simply tell you, and a process memory browser will let you see the structure of that memory.

With some math, you can easily derive where problems will happen.
(And, If you *REALLY* want to know, you can push it through something like IDA pro, disassemble the executable code in the stack, then fully trace it out yourself.)


Or, you can be a snide cynical jerk, and not think for yourself, choose to remain ignorant of how one might obtain such knowledge, and simply accept whatever you are told.

Your choice.

[se5a]

An architect doesn't have to look at a detailed plan of a building to criticize the design, looking at the building is normally enough.

[wierd]

Toady's design is simple, and leverages a few nice things about memory structure alignment. It is NOT a bad design.  The issue is that like many programmers that cut teeth on single chip machines, and ate the steak and potatoes of clockspeed increases at a predictable rate in the market, he has habbits and learned behaviors that are hard to break.

What works good in a single core, purpetually improving clockspeed world is simply not what works good in SMP or NUMA world.

DF is written for the former. The handwriting is on the wall. Multithreading is not going away, and the chip makers are not going to give any foothold for that old paradigm. Parallelism is here. All major software producers are being forced to it too, and as they do, the market's momentum is going to go that way too.

Eventually toady will run facefirst into the NUMA/SMP hybrid motherboards I mentioned earlier. If he stays on the "one big thread!" Model, his memory allocations will *NOT* align with the physical CPU chip's bus slice, and he will have WORSE performance than he has now. (The reason is because now another CPU must access the memory "outside" the slice allocated to the one running DF's process, pass it to that CPU, and then do the work on it. The OS will handle that with the read and write calls, but the actual speed of the call's completion will by greater than 2x the current time it takes to make that call. DF will choke and choke hard.)

For a desicion predicated on making sensible use of memory alignments, permitting that to happen is irrational.

While I can't make toady change his mind on the matter, Intel and AMD most certainly will, and the wind of that change is already blowing.


Toady's basic argument is that because DF is already saturating the memory bus's ability to service the physical cpu's data IO needs, using more cores inside that chip will not provide a benefit.  He is 100% correct in that respect. The application is memory bound.

It discounts the market's forces and momentum though. DF is NOT the only application with this problem. There are plenty of software packages in the high performance/high memory consumption demographic feeling that pain. Large database server daemons are a poignant example.

They solved that problem with the SMP/NUMA hybrid architecture. (But they inherited other problems doing so-- that's a whole other discussion.) It is becoming the status quo in high performance server designs. As such, it will eventually become the status quo in the consumer market too.

When it does, his opinion will come back to haunt him. I'd bet money.

[cyberTripping]

I am disinclined to accept that thinking; DF most certainly is computationally heavy and memory bound, but not all multiprocessing architectures are created equally. Specifically, there are major differences in how memory is handled between processors in SMP, CUDA and NUMA architectures.

Intel and AMD processors use SMP, which can become memory bound over the shared memory bus, however NUMA and CUDA architectures are significantly less prone to this, and many of DF's computations appear to be purely mathematical; in specific, weather, heat, and fluid computations.  Making use of recent trends of GPU computing could very well give a tremendous payoff. (and no, saying that there is too much disparity between GPUs in the market for proper targeting is a canard. There are only 2 major types, and both major x86 chip makers are now embedding such silicon on the CPU itself these days. By the time toady gets around to trying something like that, it will have been on-die silicon for years, and be a standard feature. Saying the on die gpus wont give the same performance boost to a memory bound application as a discrete one is at least a proper argument. However, it discounts abusing the on-die GPU in clever ways to serve as both a processor for math functions as well as a rather large number of what would essentially be CPU registers which would be just a handful of nanometers away from the APUs inside the CPU, meaning some of his computations need never touch outside memory anyway, reducing the memory bound nature of the problem. This can be further diminished by the increased cache size available to the program by dividing it over multiple discrete processing cores; or rather, the increased efficiency of cache use. The repetitious nature of DF's hard math computations would lend themselves quite well to heavy cache munching like that.)

Would it be an epic shitton of work? Certainly. Is there any real payoff to putting it off until later? NO. (1)

Is there a serious disadvantage to putting that kind of work off until later? YES. (1)
Will Intel and AMD return to the "Faster silicon!" marketing direction? NO. (2)
Will Toady eventually have to switch to SMP? YES (2)-- If he wants DF to run at faster than 3fps on a gaming rig.

(1) As the complexity of his logic increases, trying to find ways to salvage the work already done when porting it to SMP type architectures becomes increasingly difficult. If it is hard now, it will only be at least geometrically harder later. This means he is not saving himself any effort by avoiding SMP now, at the "Early" side of development (given his ambitious goals). He might think he is, but he isn't.

(2) The whole reason we are getting multiple core CPUs instead of ever faster silicon like we got in the 90s, is because we are reaching the thermal and electrical limits of silicon. Unless some new wonder material actually manages to take real marketshare, we will NOT return to faster silicon as the status quo in processor revision. Since all the contenders for silicon rely on either radically expensive manufacturing processes (monoatomic thin sheets of tin, for instance), or on highly exotic materials (like synthetic diamond or on graphene) That is VERY VERY unlikely to happen within the next 10 to 20 years. Later than that? possible-- but not in the foreseeable future. Further, there is already a trend with some motherboard makers who specialize in SOHO server boards to make hybrid SMP/NUMA boards, which have multiple CPU sockets, intended for multiple core CPUs.  Each physical CPU has prefferential access to a chunk of the memory bus in a NUMA like configuration, where each chip then acts as SMP over that chunk. As the demands for better memory access increase due to the new direction chip makers have been forced to take, board makers will likely take these currently server-class ideas and implement them on commodity boards later. Making DF SMP aware now would reap the benefits of the hybrid NUMA architecture relaxing some of the memory bound IO issues when that eventuality comes to pass in the hardware market.

Again, I cant really tell toady his business; I just dont buy that line of reasoning, since I know better.

This is a text argument. All craftsdwarfship is of the highest quality. It is encrusted with well thought out logic. It is It is adorned with hanging rings of terminology.

[misko27]

Now we could probably use a response from one of the few people who have worked the code. Obviously, even if many people here are experienced, DF is about 6 years worth of work basically entirely done by a single man. 


I do know the discussion has moved past where I and people like me can reasonably claim to fully understand. Which reminds me: this is, now more then ever, unrelated to playing Dwarf Fortress, or discussion of fort mode. That is what this particular board is about. It wasn't terribly related to the board to begin with. DF General Discussion could probably use some love.