Print

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

[athenalras]

I know nondescuid as already posted about this topic before here: http://www.bay12forums.com/smf/index.php?topic=23472.0

and there are currently temporary fixes to this but eventually, wouldn't DF become unplayable due to the sheer amount of processing power required and that its not utilizing multi-core?

I don't want any trouble. I'm just a bit concerned because that means that DF won't be able to utilize the full-extent of a modern machine in 2035, not to mention the modern computers we have now.

Or have I looked over something and am worrying about something pointless?

If not, its not like I want toady to delay the game and start rewriting to suit multi-core but would like to know if anything can be done at this point.

[Footkerchief]

and there are currently temporary fixes to this but eventually, wouldn't DF become unplayable due to the sheer amount of processing power required and that its not utilizing multi-core?

There are tons of potential optimizations that haven't yet been made, and not all future features are CPU-heavy (in fact, most of them aren't).  So don't panic.

[Neonivek]

Also I have a huge doubt DF will have any trouble on a 2035 computer...

Unless 10 core computers become a thing.

[Mel_Vixen]

Also I have a huge doubt DF will have any trouble on a 2035 computer...

Unless 10 core computers become a thing.

A thing again. Back in the day when processingpower was scarce we did go pretty much multicore althought the cores were physically seperate. In the Pre PC-era we laid the groundwork for much and most of todays multicoring. 

That being said: 8-cores are the newest consumer thing right now with the newesrt phone (iPhone 6) at 2.6 GHz.

I hope someday today rips out some guts of DF like fluids and pathing to replace them with more efficient algorithms. Still Df runs decently on most modern machines even on one that is almost 5 years old like my laptop.

[athenalras]

It does run decently on modern machines but it gets bogged down after a while with all the tattered clothings and when population reaches 200+ (I like to run more dense fortresses. In fact, in my own modded version, I have each civilization be capable of millions of inhabitants.
But then the world gen has to be short)

If toady could make more efficient algorithms for not only fluids, pathfinding and world gen such that it could still emulate a parallel world while not utilizing multi-cores, I would be the happiest man on earth.

It is comforting to know that future updates would not be as CPU-intensive but I have to ask about sending dwarven armies into the world to mess around. Would that potentially eat up a lot of CPU?

Because as of right now, the world is mostly stagnant when in Fortress mode. However, Toady said that eventually, the world will be running even during fortress mode so that different civilizations would interact with each other. This worries me a bit.

I, being a simulation freak, like to have things on a grand scale and as of now, vanilla DF is extremely small on its scale. Battles are more like skirmishes when compared to the real world (our world) and populations seem as if an apocalypse occurred, leaving only few hundreds of survivors. When DF implements the above feature, I feel that it would only run smoothly as vanilla without modding in civ's ability to breed hundreds of thousands of people.

[Manveru Taurënér]

Not sure what world gen settings you've been using, but I play unmodded and my civs usually have around a hundred thousand citizens, with battles between armies in the tens of thousands :>

[athenalras]

Really? I use advanced world gen so...I've tried both limited site cap and infinite site cap, infinite population, etc.

Before, my hamlets and towns would only have 25-100 pop. I don't know if changing the value in the entity file actually had an effect. I haven't really played vanilla and when I did, I usually did quick world gen at max years (I forgot value) with low savagery, etc. I never got battles that had tens of thousands.

But anyways, in my modded DF, battles of 100k+ vs 100k+ were pretty common so I was happy.
That aside, I was more concerned with the legends viewer. I rely on that app to view history and map more than ingame.

Also, when I generate my world, it takes an eternity once it passes 2000 years. Its not like I haven't read suggestions to lessen the generation time but I prefer to have an older world with more history.

But that's not the problem I have. As history goes on, more and more characters, events, sites, etc are being added (assuming that as the world continues living during fortress mode in future releases) so wouldn't it eventually reach a point where I have to go and start anew?

I don't know much about the average lifespan of a fortress but most of my recent forts make it past the first century with few problems.

Naturally, the feature for interaction with the outer world will become a feature in the distant future but I'm still a little concerned.

Put me at ease.

[Trickman]

Clueless person stating that a single-core with a high clock speed is the best thing towards playing DF in 3... 2... 1...

[Footkerchief]

But that's not the problem I have. As history goes on, more and more characters, events, sites, etc are being added (assuming that as the world continues living during fortress mode in future releases) so wouldn't it eventually reach a point where I have to go and start anew?

Storing a large and complex history becomes a performance problem only if you need to search it extensively (largely solvable with indexes) or load a lot of it into memory simultaneously (hopefully avoidable).

The activities of offscreen creatures could be a problem if you ran their simulations in full detail, but fortunately in most cases Toady can dial back the frequency and detail of offscreen events.  E.g. when a random caravan moves around the world map, there's no need to simulate the line-of-sight of lurking predators.  Also, people are abstracted into the anonymous sheep-like populace unless something important happens to them.

Also, there's a world population cap.

The major performance problem with armies etc. is a problem that DF already has: having lots of units on the screen.

[Putnam]

AFAIK the history searching is pretty efficient, with the vast majority of historical connections etc. being stored in particular object classes that contain a link and a hist fig ID which can be searched with binary search.

Which is to say, pretty damn fast. It shouldn't be that much of a problem, at worst n*log(n), where n is number of hist figures, if I were to guess.

The really big problem is the fact that it uses so much memory so often. RAM is really really slow compared to the CPU caches.

[Orange Wizard]

Clueless person stating that a single-core with a high clock speed is the best thing towards playing DF in 3... 2... 1...

Actually, a single-core processor with a high clock speed is the best thing for playing DF.


In all seriousness, the biggest FPS drain would be all those crappy clothes dwarves leave lying around. My most successful fortress (FPS- and population-wise) was one where I installed an atomsmasher to get rid of all of that junk.

[Necrisha]

Really? I thought it was a really powerful dual core processor- One for the game, one for the operating system and all the accessories...

[Orange Wizard]

Really? I thought it was a really powerful dual core processor- One for the game, one for the operating system and all the accessories...

Yeah, that is correct. I was joking in my previous post. I guess tone of voice doesn't transmit well over a written conversation.

[Idranel]

AFAIK the history searching is pretty efficient, with the vast majority of historical connections etc. being stored in particular object classes that contain a link and a hist fig ID which can be searched with binary search.

Which is to say, pretty damn fast. It shouldn't be that much of a problem, at worst n*log(n), where n is number of hist figures, if I were to guess.

The really big problem is the fact that it uses so much memory so often. RAM is really really slow compared to the CPU caches.

Binary search (on something thats sorted obviously) is always in log_2(n). The same goes for finding the spot where to insert or delete something. With a self-balancing search-tree its possible to deal with all sorts of tiny updates and queries quickly.

Having to access RAM isn't that bad, most of the time its unavoidable anyway. Its still a matter of nanoseconds compared to fetching stuff from a hard drive which will can take milliseconds just to physically move the head to where the data is stored. But in the end its mostly the access pattern that determines whether or not its going to grind to a halt; for example a matrix multiplication can either be pretty awful or reasonably fast depending on the order in which the is memory accessed

[gimli]

This looks promosing:
IBM carbon nanotube transistors could make CPUs five to ten times faster than today's silicon chips.

http://www.pcgamer.com/2012/11/01/ibm-carbon-nanotube-transistors-could-make-cpus-five-to-ten-times-faster-than-todays-silicon-chips/
http://upriser.com/posts/a-first-stanford-engineers-build-basic-computer-using-carbon-nanotubes