Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2]

Author Topic: Dispelling common myths about DF performance and optimization  (Read 14556 times)

Thief^

  • Bay Watcher
  • Official crazy person
    • View Profile
Re: Dispelling common myths about DF performance and optimization
« Reply #15 on: May 30, 2012, 01:07:09 pm »

That's all completely bollocks. Sorry.

Each program gets its own virtual memory space, completely contiguous, which is mapped to completely random blocks of physical ram which are in no way contiguous, and don't even need to be because it takes the same amount of time to access any page in ram.

No shuffling.
Logged
Dwarven blood types are not A, B, AB, O but Ale, Wine, Beer, Rum, Whisky and so forth.
It's not an embark so much as seven dwarves having a simultaneous strange mood and going off to build an artifact fortress that menaces with spikes of awesome and hanging rings of death.

SimplyPresea

  • Escaped Lunatic
    • View Profile
Re: Dispelling common myths about DF performance and optimization
« Reply #16 on: June 08, 2012, 07:05:38 pm »

Probably just anecdotal evidence, but I stepped my CAS latency down from 7 to 6, loaded my only maxed fort I have (220 dwarves + 80 animals) on v31.25 and it rose the calc rate from 34 to 40.
http://www.newegg.com/Product/Product.aspx?Item=N82E16820231370
Logged

alexandertnt

  • Bay Watcher
  • (map 'list (lambda (post) (+ post awesome)) posts)
    • View Profile
Re: Dispelling common myths about DF performance and optimization
« Reply #17 on: June 09, 2012, 05:38:48 am »

If you don't already know, spare RAM does nothing.  RAM is just storage capacity, and having excess RAM storage capacity is like paying for a whole warehouse even though you only are storing enough stuff in it to fill a small room.

It's more complicated than that, as if you have "exactly as much ram as you need" then the computer spends a lot of time shuffling around the allocations so that each program has a contiguous block.  But as each program's desire for space changes over time, your ram quickly becomes fragmented and applications slow down causing the computer to spend time trying to shuffle things around.

You do need extra space, but you don't need a lot of it.  50% more than you use is generally plenty.

Most OS's/hardware would use Virtual Mapping, so that it can get an allocated array of stuff (say 500 of something) even if there is no continuous block of memory large enough, the MMU just maps the 500 supposedly continuous allocation to fragmented memory in hardware with (supposedly) no loss in performance.

The image on wikipedia shows it better

That being said, individual OS's may do extra stuff. Also, it is always good to have some spare RAM, so if the OS or another process decides to allocate some than none of DF's memory gets put in the page file. Which would be a massive performance hit.
Logged
This is when I imagine the hilarity which may happen if certain things are glichy. Such as targeting your own body parts to eat.

You eat your own head
YOU HAVE BEEN STRUCK DOWN!
Pages: 1 [2]