Bay 12 Games Forum

It's up to you, as a developer, when your errors will show themselves; unit testing is one way, and neat little tools like Toady's arena are another.  Very simple errors will be caught by a compiler, but they'll rarely go unnoticed by a capable programmer for long.  I don't think I've lost more than an hour or two in every hundred to tracking down bugs caused by typos (in languages without declarations) and I've certainly gained more than that by not feeling constrained by declarations.  It's all a matter of style and self-discipline in the end, even in C.  (It's amazing what you can get away with.)

Have you ever tried a really high level language like Mercury or Haskell? I've had the compiler catch some pretty deep bugs that would have been a real pain to track down. I'm not just talking easy to catch type mismatches - Mercury for instance also tests the determinism if the code (is there a case that might fail? Is there an undeclared ambiguity?). I've found that once it compiles, it probably works (although the error messages are even worse than the ones given by C++ when using STL, which can make the learning curve horrible). Testing, unit tests, etc. are still important, but even as a very experienced programmer, I'll take all the help I can get to keep the bugs out of my code.

I agree that C and C++ are different languages (I use both, and declare them separately on my CV). C is great for embedded stuff, C++ for larger projects, and it's a travesty when C++ is taught as 'C with nicer output functions'.

The language I'd use for for something like this would depend on what level of collaboration I was aiming for. I'd use C++ if it was a multi-person project, because it would do the job, and lots of people know it (I might even consider Java if memory use wasn't going to be a bottleneck). I'd use Haskell (or maybe Mercury) if I was doing all the coding myself and never intended anyone else to develop it. Using a functional or logical language might slow development at the start, but as the project grows, a more disciplined language means better stability, an easier time debugging (many errors show up at compile time rather than runtime) and extending things, and a _much_ cleaner way of dealing with complex data structures.

I like save compatibility, but it only really matters to me for the megaprojects. I've been holding off a really big project until this release (still holding off while I wait for the Linux version), and wouldn't want a game breaking bug to mean I have to restart with a later version. On the other hand, I know how save compatibility can slow down development. I think the recent large gap between versions is an example of this.

My preference would be "keep save compatibility where possible, except where it would slow down development, in which case break it".

Should have thought about that earlier and bought a proper computer.

Some of us did go buy a proper computer (or a proper operating system anyway).

We get to wait 

Quote from: A for Anonymous on March 21, 2010, 10:47:35 am

What it boils down to, in the (possibly very) long run, is that the 32-bit install base will, at some point in the future, be so marginally small that supporting it becomes pointless.

However, at that point in time, starting a 64-bit build would take even longer to do than it would now, as the code base will have grown enormously and the probability for there to be issue with porting will be much higher.

"Starting...now..." 
Dude, it has been 18 MONTHS sense the last release.  There is no way Toady is going to take on the extra code maintenance he has to perform and reduce his development time just for the convince of a minority of his users and donors.  A couple years from now, when 64-bit hardware+OS is +90% of the install base he will probably do it.

A for Anonymous, I don't think anyone is seriously expecting a 64-bit version with the next release. However, if the code is clean from silly assumptions about pointer sizes, it's probably not a great deal of effort to port sometime afterwards, and very little effort to maintain once ported (it's not nearly as bad as another whole OS). It would need compilation and testing near release time and could be largely ignored the rest of the time. I write a lot of code that is designed to run on both 32 bit and 64 bit Linux - it's not hard.

I also disagree that waiting would make it that much harder - as long as Today is aware to not use any 32-bit specific coding practices, it should be easy to port any time. I hope not to have to wait two years though, as running 32-bit code on a 64 bit Linux system can be a real nuisance, especially when it is as library dependent as Dwarf Fortress.

doubt Toady would throw it away, i mean, why discard such perfectly good code, especially since he seems to feel that it handles the graphics better than his original graphics code did.

I'm sure he wouldn't throw it away. It's just that most other people would be celebrating a release, and I'd still be waiting - the new graphics code really is that much of an improvement for me.

That's basically correct. The extra registers available in 64 bit mode can really make a large impact on computations. When I was working on the path-finding stuff I was seeing a 5x improvement in pathfinding just by dropping the -m32 compilation flag. Obviously DF will not see such a large improvement, but something like 10%-20% would be quite reasonable.

shadow_slicer, was it you that added the "64bit native DF" paragraph to the eternal suggestions at http://www.bay12games.com/forum/eternal_voting.php ? Can I suggest you add something about ease of installation on 64-bit systems (not having to install a difficult to maintain 32 bit subsystem)? For me, that is the compelling reason to want a 64 bit version, not the speed increase.

I'm _very_ surprised at the 5x improvement in the pathfinding - that's off the charts compared to any improvement that I've ever seen (although I don't bother with 32 bit at all anymore). It must be something where the x86 register spill really hurts.

On 64 bit Linux (using gcc):

sizeof(char)=1
sizeof(short)=2
sizeof(int)=4
sizeof(long)=8
sizeof(long long)=8
sizeof(pointer)=8

so the sizes for int downwards are the same as for 32 bit, I'm not sure about longs on 32 bit.

I went to a seminar on this topic a few years ago, and the general result of moving for 32 to 64 bit seemed to be:

* Pointers get larger -> more memory -> more pressure on cache -> slightly slower
* More registers (only available in 64 bit mode) -> significantly faster
So overall things tend to be faster, as the register starvation of 32-bit mode gets avoided.

[As an aside, on PowerPC, moving from 32 to 64 bit made things slightly slower, as they get the larger pointers with no increase in registers].

My reasons for wanting 64 bit are only marginally to do with speed anyway - I'm more bothered about having to install lots of 32 bit libraries that the package system won't maintain. This could make them a security issue, and I'd really like to be able to get rid of them.

The only potential showstoppers I see for 64 bit are:
* If there's lot of coercion between ints and pointers. This would make 64 bit unlikely to ever be possible,
* Toady doesn't want to maintain more targets.