Print

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

[Knight Otu]

- Baron appointment bug; you have to put off meeting with the diplomat until after the caravan has already left the map in order to get the prompt to promote a Baron.

That one's supposed to be fixed since 31.17, and I'm pretty sure I've seen it work correctly. Are you sure you're still seeing this bug?

[Khift]

- Baron appointment bug; you have to put off meeting with the diplomat until after the caravan has already left the map in order to get the prompt to promote a Baron.

That one's supposed to be fixed since 31.17, and I'm pretty sure I've seen it work correctly. Are you sure you're still seeing this bug?

Well slap me silly and call me Shirley. I was not aware it had been fixed; haven't had a fort large enough to get a Baron since .31.14.

[Spectre Incarnate]

Now you can ask him about problems connected with multithreading

Uh.. yeah, sure. 

Now, what in particular do you want me to ask him? Is there a concern about methods to prevent deadlock? Do you want to know what his opinion on what method would be best to use for DF?

I can ask him those things or whatever you'd like me to, but he's already said that multi-threading is the way the future is going, whether people like it or not, because companies will not be working toward adding more capacity to an individual core, but continue to add more of the same cores. If we want to utilize future processors, Toady (or someone willing to help him) is going to have to deal with the problems of deadlock. Otherwise we will be stuck using one single core at 3-4Ghz and it won't matter if you buy more cores, more RAM, or get a 64 bit computer. I guess I'm confused by all this wariness when it's obvious that adding more and more features to an already very complicated "fantasy world simulation" is going to need a much larger and more robust optimization at some point in the near future.

Edit: If the OP would like me to move this conversation, I understand.

[Caldfir]

To clarify, I wasn't saying that multithreading doesn't help programs run faster.  What I was saying is that just slapping threads into a program and splitting up tasks without some very careful planning about memory access ends up not working.  Saying what to do about it is impossible without a complete picture of what algorithms are being used.  Getting actual real noticeable improvements out of multithreading is hard.  Those improvements can be amazing, but hold an absolute cap of the number of cores available, so even if Toady did some insane genius programming that carefully respected caching issues, an ~8x speedup on some futuristic machine is the best you can hope for with multithreading alone.  If Toady in stead decided to focus on generic improvements to algorithms, a similar speedup might be possible. 

Not to mention that traditional multithreading isn't the only impressive new technology asset that might be helpful.  Mathematical computing packages that exploit architectural advantages of modern GPUs can have some pretty amazing results, IF you have the right programming problem to solve. 

Anyway, I'm just saying that it isn't as cut-and-dry as everyone seems to make it out to be.  Sure, running multiple processors can make some great improvements, but actually getting a program to that point is very difficult to do well, and making that kind of time commitment at this point of DF's lifecycle would be, in my opinion, more trouble than it would be worth.  Multithreaded programs are good, but hard to code. 

Edit:

Edit: If the OP would like me to move this conversation, I understand.

Yeah, we are pretty far off topic here. 

[deek0146]

even if Toady did some insane genius programming that carefully respected caching issues, an ~8x speedup on some futuristic machine is the best you can hope for with multithreading alone.

Thats not how it works, multicore processors have a seperate cache for every core. There is no way a program could slow down if multithreading was put into it, poor programming of multhreading just leads to race conditions which at (the very very very) worst makes the program run as fast as a single threaded one - unless its not actually running on a multicore machine.

EDIT: Or hang indefinately and crash

[AutomataKittay]

Thats not how it works, multicore processors have a seperate cache for every core. There is no way a program could slow down if multithreading was put into it, poor programming of multhreading just leads to race conditions which at (the very very very) worst makes the program run as fast as a single threaded one - unless its not actually running on a multicore machine.

EDIT: Or hang indefinately and crash

Are you so sure about not being possible to slow down? I'd imagine that multithreading would put in some real overhead, and possibly badly implemented one would be much slower than simpler single-threaded approach even with multiple cores supporting it?

[ZeroGravitas]

Was that capitalized laughter really necessary? In terms of longstanding bugs fixed, these releases are a significant step forward.

Absolutely not. In many ways we are worse off than we were since 40d.

[Vercingetorix]

Absolutely not. In many ways we are worse off than we were since 40d.

True, but it's also the case that the 40d version was the product of a long series of fixes with fewer additions over the period it was outstanding.  I think this cycle of concentrated bugfixes between major releases is eroding the buglist but there's still a lot left to do.  Some major issues should be addressed before we get too deep in new content and new bugs; hopefully this will happen after this next content release.

[YetAnotherStupidDorf]

I just shrudder on thought how much bugs we will have in next release. He did some crazy feature creep and did not release it properly (I mean, he IMO should release before implementing necromant misadventures). We will be lucky if bugfixing session will fix more bugs (old and new) than bugs introduced in this coming soon(tm) release.

[Cruxador]

I just shrudder on thought how much bugs we will have in next release. He did some crazy feature creep and did not release it properly (I mean, he IMO should release before implementing necromant misadventures). We will be lucky if bugfixing session will fix more bugs (old and new) than bugs introduced in this coming soon(tm) release.

Toady fixes new bugs for however long that takes, and then fixes big bunches of old bugs. There will certainly be new bugs that aren't immediately fixed, but it will still be a huge step in the direction of buglessness.

[tolkafox]

IMO we aren't paying for the game which makes finding bugs a fun competition. But Toady does his best to find bugs before he releases them, nonetheless some will no doubt get by.

Unlike some others who have no excuse for such things.

[Quietust]

A fix for crystal glass would be really nice, especially since I went through the trouble of tracing through the game code with a debugger and actually finding the source of the bug, as well as making a binary patch for the Win32 SDL version to make crystal glass production work properly.

[Maklak]

A fix for crystal glass would be really nice, especially since I went through the trouble of tracing through the game code with a debugger and actually finding the source of the bug, as well as making a binary patch for the Win32 SDL version to make crystal glass production work properly.

Interesting. Can you recommend a Windows hex editor that works? I need to load a file, jump to offset, edit some bytes in hex, and save file. I tried three differnt "hex editors", and couldn't get any of them to do all of these things. Editing seems to be the hard part. Gah :/

[Quietust]

Can you recommend a Windows hex editor that works?

Try XVI32.

[deek0146]

Thats not how it works, multicore processors have a seperate cache for every core. There is no way a program could slow down if multithreading was put into it, poor programming of multhreading just leads to race conditions which at (the very very very) worst makes the program run as fast as a single threaded one - unless its not actually running on a multicore machine.

EDIT: Or hang indefinately and crash

Are you so sure about not being possible to slow down? I'd imagine that multithreading would put in some real overhead, and possibly badly implemented one would be much slower than simpler single-threaded approach even with multiple cores supporting it?

The overhead is very little, not much more than a cache miss I think, and as long as it wasn't so badly implemented that the other cores weren't actually being utilised, then no.

I'll give you an example from the first time I used multithreading:

I had a complicated maze with enemies pathing towards me - this was also the first time I had written any pathfinding and it was incredibly slow (I think I was using an STL list for the working set and calling sort() on it lol).
It was running on a single thread using 100% of one core on a dual core
I put the pathfinding on another thread, this left left the one core using ~95% and the second core using 35% and I got a 30% increase in framerate. If you do the maths, it appears that the overhead is negligable (p < 0.01)