Print

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

[numerobis]

On the title screen, DF takes 50%-60% of CPU on my macbook pro (intel / 10.4, but I've also seen it on 10.5 mac pro also, I'm fairly sure).

Shark reports that the application is spending this all in the event loop; about half in TimerVector, which is a system thing that calls DF functions at addresses 0x18666 and 0x1862a -- the latter is pretty trivial here.  Most of the balance in mach_msg_trap in libSystem.B.dylib.

When I load up a fortress and pause, DF grows to take around 80-90% of CPU.  Most of this is in TimerVector again, split about evenly now between 0x18666 and 0x1862a.  mach_msg_trap is again the other big contributor; much less, but the same number of instructions as on the title screen.

My left buttcheek invents the just-so story that the mach_msg_trap is handling the timer interrupt, and the rest is setting up the canvas and redrawing it.  My right buttcheek might be mumbling something about milliseconds and microseconds, but it's kind of muffled from the way I'm sitting.

I'm not sure how to help you fix this, but it sure would be nice.

[numerobis]

Perhaps I should note that it's not calling into the kernel much; gettimeofday every second or two.

[Toady One]

I don't understand any of what you said, so I'm not going to be able to help.  I know the renders and logic aren't split up on the Mac, because we set up a simplified timer loop there and thought we might get back to it later.  I'm not capable of changing it myself.

[numerobis]

Shark is a profiler; I'm saying that according to that profile, the DwarfFortress main loop is spinning really fast -- so much so that the operating system is burning about 15% of one CPU just handling the timer, nevermind any redrawing.  It's also re-rendering even when nothing changed, but that's really just a side issue.

I'm betting -- this is where the butt-cheeks come in -- something weird is making the timer fire much faster than at the 100 FPS rate when the game is paused or on the title screen.  Would the best way to help you figure this out be to look at the kobold quest code?  I might have time to do that next week (I'm travelling a few days starting tom...uh, I mean today).

[The Dark Bunny]

If it's anything like a lot of programs I've seen, it's just the standard "doing nothing fast" loop.  DF computes the next step as soon as the one before it finishes, so a series of steps with nothing to compute (e.g. paused periods, job manager, title screen, etc.) just allows the timer to freewheel as fast as the processor will allow.

[Toady One]

Yeah, the loop in Mac KQ is basically the same as DF's.  I was under the impression that the timer would make the program work like window's Sleep() that stops the CPU from pegging on the title screen, but I don't know the first thing about the Mac stuff.  It is doing a lot of renders, but at least that load should be lessened (on both OS's) for next time, though I have yet to try it on the Mac so perhaps it will explode or something.

[numerobis]

OK, I get the same behaviour in mac KQ, so that's a start.  Unless enabler_mac.cpp (or whatever it's called) is going to change a lot with you pushing out stuff from 40a, I'll take a hack at fixing the sleep issue.

[numerobis]

My discoveries so far: (a) the loop actually really does run at 100 fps, based on a printf I added, so it's not a silly mistake.  (b) KQ in its normal configuration (sans music, via the NO_FMOD macro) consumes 40-45% CPU on the title page.  (c) if I turn off rendering, KQ takes less than 2% CPU, like you'd expect.

Clearly the answer is to play blind, because then it's really fast.

What confuses me is that the profiler run on (b) claims only one third of the time is spent in the renderer or in anything OpenGL-related.  So the mystery is: what's consuming the bulk of the time?  And how do we drop that part of the code into a channel filled with carp?