Print

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

[K.I.L.E.R]

Have we got any sort of confirmation of any performance related work being done by Toady?

[G-Flex]

In real world scenarios, 64bit is actually slower.

Er. What?

[DrKillPatient]

In real world scenarios, 64bit is actually slower.

Er. What?

I think the difference is that 64bit has the ability to support more than 4GB RAM. Some 32bit programs don't run as well on 64bit, because they're not optimized for that architecture.

[G-Flex]

Your code shouldn't really be "optimized" for 32-bit architecture except in relatively odd circumstances.

Also, there are more differences between x86 and x86-64 than being able to utilize more memory space. People have mentioned some recently in this thread.

[devek]

Big pointers, hehe.

[G-Flex]

What about them?

[devek]

They are slower?

[kaenneth]

It's not the size of the pointers, it's how you use them.

 

DF seems chock full of referances between objects, every object has a creator, owner, holder..., every open tile has objects in it, every creature has a mother, father, every intelligent creature has relationships... if the size of each of those properties doubles (that is, if it's a pointer, instead of a char/int16/int32 array index), it not only can increase the actual amount of main memory required, it also pushes other data out of the lowerest level CPU cache, which means more memory accesses, which means much slower running.

If it is just an index, that means there is another level of indirection to actually access anything, which again, is slower.

The reason 64 bit is great for huge photoshop images, and enterprise databases is that it's a small number of huge objects; so that the space taken up by referances to the objects is minimal; this also works for games with chunky 3d models/textures/sound clips; for DF, not so much; until the map itself occupies more than half a gig (like a huge embark)