Print

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

[Quietust]

Linux 64 linked, but I get a compression error trying to run it.  Wrong zlib maybe?  Not sure how to check which one it is using.  Or I have some 64 bit problem with the file loading code itself that bothers linux and not windows.

Are you saving and loading "long" variables anywhere? If so, that's going to cause major problems on Linux and Mac, because while "long" is 32 bits wide on Windows x86_64, it is 64 bits wide on Linux/OSX x86_64. You might need to go through and change them all to "int".

[edit]

Code: [Select]

char file_compressorst::flush_in_buffer()
...
//WRITE IT
f.write((char*)&compsize,sizeof(long));
f.write(out_buffer,c_stream.total_out);
...
Yep, that's definitely going to be a problem.

[Veroule]

Using chroot on Linux is definitely one of the easier ways to setup independent compile environments. This page provides a very detailed step by step for having multiple chroot environments.
http://forge.ryzom.com/wiki/Building_Ryzom_Client_On_Debian
It was written based on Debian which is almost entirely identical to Ubuntu, the things to change should be easy to spot. If you go with such a setup you should be able to get the compile part down to one command.

I really strongly recommend using explicit sizing whenever possible. 64bit processors have been around long enough, and with core speed and die limits being what they are, the move to 128bit is not too far in the future. Taking the time to shift to specific sizing now can make the next transition painless. See http://en.cppreference.com/w/cpp/types/integer When you use the type intptr_t or uintptr_t you will always get a size that matches the register size of the architecture and that will have the highest speed. There is a small speed loss on some operations on 64bit architecture when working with a 32bit integer, the same is true of 16bit on 32bit architecture. Making sure counter variables are sized to match the registers will keep the speed from being lost.

[Thief^]

I really strongly recommend using explicit sizing whenever possible. 64bit processors have been around long enough, and with core speed and die limits being what they are, the move to 128bit is not too far in the future. Taking the time to shift to specific sizing now can make the next transition painless. See http://en.cppreference.com/w/cpp/types/integer When you use the type intptr_t or uintptr_t you will always get a size that matches the register size of the architecture and that will have the highest speed. There is a small speed loss on some operations on 64bit architecture when working with a 32bit integer, the same is true of 16bit on 32bit architecture. Making sure counter variables are sized to match the registers will keep the speed from being lost.

Actually, that's mostly nonsense.

For starters, there's no appreciable speed difference in performance by using a smaller integer size than the CPU's bitness, and due to the reduced ram need it can actually be faster to use smaller types. There's also no guarantee anywhere that intptr_t is faster than "int". If you specifically want a "fast" type, use the fast types, e.g. int_fast32_t. On Visual Studio at least, the only one that's not the same size as its fixed-size version is int_fast16_t.

As for "the move to 128bit is not too far in the future": Depending on how you work it, either we already have 128-bit CPUs, or we never will (at least for many decades).
"never will": The primary benefit to 64-bit CPUs is the size of the addressable space. 32-bit could address a maximum of 4 GB, 64-bits can uniquely address every byte of over a million 2 TB hard-disks. This is way beyond desktop requirements (intentionally!). We didn't get 64-bit CPUs until we were already hitting the 4 GB limit of 32-bit addressing with RAM, having one system with millions of terabytes of ram in a home system is utterly ludicrous at this point.
"Already do": SSE2 / AVX. Vector registers are already 128-bits wide, and on some newer CPUs are 256-bits wide. While they can actually be used on up to 128-bit integers, they're still primarily used for parallel computation on 32-bit numbers.

You got one thing right though. Use the fixed-size types (like int32_t) for pretty much everything. It'll save you many headaches.

[trousermonkey]

Toady,

Use ldd get the list of libraries linked into your executable:

Code: [Select]

~/df_linux/libs$ ldd Dwarf_Fortress
linux-gate.so.1 =>  (0xf772a000)
libSDL-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL-1.2.so.0 (0xf7655000)
libgraphics.so => /home/na/df_linux/libs/./libgraphics.so (0xf7226000)
libstdc++.so.6 => /home/na/df_linux/libs/./libstdc++.so.6 (0xf7148000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf70f3000)
libgcc_s.so.1 => /home/na/df_linux/libs/./libgcc_s.so.1 (0xf70d8000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf6f22000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6f05000)
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xf6dee000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf6de9000)
...


[LordBaal]

Ok,
Windows 10 Pro 64 bit.
Core i5-4570 (Runs at 3.20 GHz).
8GB DD3 @ 798MHz (11-11-11-28).

Trying the 64 test. A world of the biggest size and 1050 years of history gets made under the hour. It peaks at 1.4 GB of memory.

Embarking on the biggest size possible (I think is 16x16). It loads in about five minutes. The game peaks a little over 2GB of memory and runs just fine (albeit slow but that's another issue). Played during the first season, the memory never got higher than 2.1 GB. Even sometimes dipped to 1.8.

[supertango]

Made an account just to say I'm finally able to have decent FPS(51(48) with the 64bit test, 114 dwarfs and 35 pets with 48 on a 3x3 embark at 79 years and i don't remember the worldsize but it was decent. It's a spectacular improvement for the "2014" release era

The only issue I'm having is that the game no longer seems to care what i set in the init for child cap despite seasonal save and other features working just fine, not sure if thats intentional or a bug

[Toady One]

We'll see in another hour where we are at with the long/int battle.  Fortunately, I've been using u/int<n>_t throughout the main dwarf code for years.  Except for char.  char was my friend.  And then it betrayed me over some signed char vs. unsigned char vs. char thing not long ago.  Now I'm on int8_t, if I ever get used to it.

That's right...  ldd.  I guess I'm just going to forget and have to be retold everything every six years or however long it has been.  I had some notes, but they only go so far.


edit:

Here's an initial 64-bit test for Linux
64bit linux test

I put in the usual libraries.

[ragundo]

Tried the 64 bit linux build
Error when starting the file
./libs/Dwarf_Fortress: error while loading shared libraries: libSDL_image-1.2.so.0: cannot open shared object file: No such file or directory

Running ldd Dwarf_Fortress  | grep SDL on the DF executable gives
libSDL-1.2.so.0 => /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 (0x00007f0bc840d000)
 libSDL_image-1.2.so.0 => not found
 libSDL_ttf-2.0.so.0 => not found

Running latest Ubuntu 64bit. 32 bit works fine.

Greetings

EDIT:
sudo apt-get install libsdl-ttf2.0
sudo apt-get install libsdl-image1.2

and now works ok

[majiin]

On my Gentoo Linux the 64 bit DF works fine so far. I've generated medium world, embarked and played a little.

There was however an error about missing OpenAL library and a popup window with broken icon which triggered another error about CXXABI:

Code: [Select]

Dynamically loading the OpenAL library failed, disabling sound

(Dwarf_Fortress:1537): Gtk-WARNING **: Error loading theme icon 'dialog-error' for stock: Unable to load image-loading module: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /home/majiin/Downloads/df_linux/libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib64/libicuuc.so.57)
Initializing OpenAL failed, no sound will be played
The CXXABI error is caused by different GCC versions (my system is compiled with GCC 5.3.0). But despite those errors game worked fine, and after installing OpenAL both errors are gone.

Oh and the game still works even if I delete df_linux/libs/libstdc++.so.6 and libgcc_s.so.1 (same as with 32 bit DF)

[Toady One]

Are there more libraries I should include/not include?  I don't know what the best set is for 64 bit Linux.

---

For Mac, I'm not sure where to start.  There doesn't seem to be a reference to the number of bits in the script (linux had various -m32 and pentium arch stuff in place), just a minimum architecture version.  Do I just add a -m64 and watch it break, or is that not even a valid option here?  Also, gcc --version gives

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1

from 2005.  Not sure what to do with that.  Too old for hope?

[Veroule]

I downloaded and ran the 64bit Linux test. Got the main screen with 0 problems. I did not go any further because my entire week would be shot. I have to say YAY! No more having to play in Windows VM.
-------------------------
@Thief^

no appreciable speed difference in performance by using a smaller integer size than the CPU's bitness

Sure it is only a few clock cycles. A few clock cycles times 200 billion operations is very noticeable. I always advocate learning and applying best practices and making them habit. Note that I suggested it for counter variables that are likely to be short lived registers instead of stored in RAM, which is where the greatest speed benefit is found.

As for "the move to 128bit is not too far in the future"

Time will tell. I have been through transitions all the way from 8bit processors. The 8086 was a huge change in computers not only in instruction set but 16bit. It only took a decade (8086@1978 to 80386@1986) to move to 32bit. Sure memory capability was the strongest driving factor in those increases for data width. On current machines at 64bits the memory capacity is not likely to be exceeded for a long time, but as you noted we already find 64 bits of computational capacity to be limiting. I know what it is like to play with calculations on 8192 bit numbers, I wrote those for myself 20 years ago. There are many real world applications that will require 1024bit processors long before we need more addressable RAM than a 64bit number. It is very short-sighted to think that only the need for memory will drive computational power.

Use the fixed-size types (like int32_t) for pretty much everything.

Thanks for the backup. Toady One stated that he has been employing specifically sized data elements for a long time and I might say that is in part due to my advocacy of doing so many years ago when the SDL port was done. If the portions of code that were taken over during that port are representative of Toady One's patterns prior to the port, then he used long and int randomly and the only size specific he used was char.

[Miuramir]

A few general notes; my experience is more in scientific computing than game dev, but the needs of DF seem to be closer to the first than the second most days. 

* If you are using Ubuntu, I strongly recommend a LTS (Long Term Support) version, usually either the current or previous version.  These are supported for five years.  Non-LTS releases are only supported for 9 months, and are not generally suitable for production use.  14.04 LTS (Trusty Tahr) is supported through April 2019, and 16.04 LTS (Xenial Xerus) is supported through April 2021.  16.04 has only been out a few months, though, and there may not be as much useful info out there for it; 14.04 is probably the safest choice. 

* Linux packages come in three, not two, general levels of relevant processor support: i386, i686, and amd64 (aka x86_64).  For some packages & libraries, it is possible to have two or even all three loaded; for others it's a mess.  My general suggestion, and the general trend elsewhere, is to have the base system on pure 64; and some sort of sub-system (Virtual Machine, chroot setup, docker container, etc.) to handle 32 bit compilation; although some still prefer to just have a completely separate entirely-32-bit system (virtual or physical) for that.  If your needs are simple you may be able to get away with a multi-library single system and compiler flags, though. 

* Try really hard to avoid building packages yourself these days.  yum or apt-get are really your friend; and if you stick to a standard set of repositories the odds that things will "just work" go up. 

* Darwin, the Mac underlying environment and particularly compiler, is careening further away from BSD, Linux, gcc and the rest of the world with each release.  Where I work, we've had to largely give up on it for compiling; we use HomeBrew to set up a full gcc chain and work with that.  (Admittedly, however, the software we're using doesn't need to do much if any Mac-specific stuff.)  Anecdotally, for instance, gfortran doesn't even remotely work on a modern stock (Darwin) Mac, is a hassle to get set up under fink, and "just works" under Brew once you install the gcc chain and tools. 

* XCode has gotten very picky about only installing more recent versions on more recent OS X versions.  Generally, you're OK for about one to two versions back, but rarely more these days.  This may not be an issue for DF currently. 

* More of my experience is on RHEL-based Linux than Debian-based Linux; if you end up dabbling on that side, a current version of RHEL / CentOS / Scientific Linux 6.x is probably easier to get running on older hardware than the newer 7.x.  Conversely, if you end up with a shiny new machine, supporting all the modern boot stuff may require 7.x. 

I've unfortunately got some deadlines for the end of the month, but if things still need testing in July I'll try and find the time to spin up some VMs and compare things. 

[Miuramir]

For Mac, I'm not sure where to start.  There doesn't seem to be a reference to the number of bits in the script (linux had various -m32 and pentium arch stuff in place), just a minimum architecture version.  Do I just add a -m64 and watch it break, or is that not even a valid option here?  Also, gcc --version gives

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1

from 2005.  Not sure what to do with that.  Too old for hope?

See comments above; at work we've had to give up on Darwin and use Brew to install a full gcc toolchain.  I am not optimistic about your odds on the old mac, old OS, and old compiler. 

[mifki]

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1

What does it say if you try to use -m32/-m64 flags with a simple source? I don't know what archs were included back then.

If you have an Apple dev account (free), you can install XCode 3.1.4 (latest that supports 10.5) from https://developer.apple.com/download/more/ and use it.

Or, you can install Homebrew http://brew.sh and use it to install any version of GCC. You can try it first, but as lethosor pointed out, it doesn't officially support 10.5. I'm pretty sure it will work, however it may require having XCode installed first anyway to build GCC.

[lethosor]

Well, you're definitely not using that in 0.43.03. Try gcc-4.5?