Spiral Knights - Performance notes from a bottom of the scale computer

Performance notes from a bottom of the scale computer

5 replies [Last post]

Sun, 12/12/2010 - 13:55

BehindCurtai

Legacy Username

So I wanted to see if I could make my system more responsive, and get more reliable numbers to report.

My system is basically a bottom of the "playable" systems. A 9550 mobility card, which is about the equivalent of the bottom of the acceptable video cards. A 1.42 GHz G4, 1 GB of ram -- plenty of ram, plenty of CPU, but using the Mac Java (slightly lower 3d performance) and mac drivers (note that the windows drivers keep (or kept) getting updates and improvements).

My latest testing environment uses a Terminal window running "top -s 5 -o rprvt" (to watch the free memory, and the biggest memory consumers -- on the mac, that's Java, and the "Meta Data Server" -- basically, the main cache server process), a second terminal window showing the "projectx.log" file, and TextEdit to take notes. (Plus Finder and Dock, which I cannot turn off. Plus all the system daemons. Etc.)

The biggest surprise? Top consistently shows idle time of around 1-2%. That's right -- SK does not use 100% of the available CPU. Most of the time.

** And as long as I see that 1-2% available CPU, SK is very responsive **

My Brandish -- a fast sword -- is able to reliably execute the combo attack. I can aim my sword in combat with the trackpad while hitting space to attack.

The response problems only occur when the free CPU time goes away. This generally happens when monsters spawn, when the amounts of animations increase (/em looks at confetti boxes), or in some combats with lots of monsters (/em looks at trees with thwack lumbers). On the other hand, it's not just numbers -- I can spawn 9 jellies, and two frames after they spawn, the game is responsive. I can spawn 6 lichens and two trees, and be in graphic pain.

Once things become unresponsive? At that point, I'm down to "shield on, switch to the heavy sword, and try to time my 'drop, attack, re-shield' move".

Except that I've now tested; since the rebalance, the troika doesn't do significantly more than the brandish. Maybe it will when the brandish goes from 8 heat to 10; maybe it will if I go deeper down. Equally, the shield no longer protects as well as before. I'm no longer able to offset the poor performance by playing in a safer zone.

** I'm no longer able to offset the poor performance by playing in a safer zone **

I used to be able to use 2-star equipment above moorcroft, and while my computer's performance was less than ideal, the safer play zone made up for it. That now seems to be gone.

Mon, 12/13/2010 - 21:36

BehindCurtai

Legacy Username

Alright, time for some more

Alright, time for some more comments. This is from last night's 1-7 run with 1 and 2 star swords.

On Devilish Drudgery, where you have lots of devilites, managers, and chains of explosions after explosions, my idle CPU dropped below 1% fairly consistently -- and at that low level, responsiveness dropped.

I tried turning on activity monitor. I was expecting idle CPU to drop more, to zero. Instead, it went up.

The only way to go up is to process fewer frames. Fewer frames should mean less responsiveness, right?

WRONG.

The higher idle CPU, presumably from fewer frames per second, resulted in more responsiveness.

So the next level was Blight Boulevard (1). But here, turning Activity monitor on or off had no effect on idle CPU. About 1.5% either way. Responsiveness was uniformly poor (not horrendous, but bad enough). Looks like 2% is the "minimum nice point".

But all of those "bright shiny points" for the brambles. I cannot help but think that this is more overhead that could be turned off for low resolution.

Tue, 12/14/2010 - 00:59

Evolution

Legacy Username

Isn't that normal Curtai? If

Isn't that normal Curtai? If your CPU is choked up at 100% from processing your game-content, then it can't process your actions very well? If you have a higher "idle" percentage, then it leaves more room to quickly process what your inputs are to the game?

Tue, 12/14/2010 - 20:30

BehindCurtai

Legacy Username

> If your CPU is choked up at

> If your CPU is choked up at 100% from processing your game-content, then it can't process your actions very well?

Well, what is the game trying to do?

Is the game trying "Process every possible moment of CPU available to draw as many frames as possible"? If so, then idle CPU would be zero.

Swapping isn't an issue: dynamic_pager is actually disabled until free memory drops below a threshold, and it never gets close to that. So that can't account for idle time. Equally, since the free memory never gets low, the system never tosses stuff out from the cache. In-use objects stay in memory, video card has everything loaded in it, everything becomes memory resident, so how can any significant idle time be detected?

The answer: The game doesn't do 100% cpu to draw. At some point, it says "I cannot do anymore for a moment", and pauses. Maybe this is something that happens in the graphics libraries as a vertical sync emulation (LCD screen). Maybe there's something else going on.

But whatever it is, the key point seems to be: As long as the frame rate is "decent", and the idle time is "high enough" to indicate that the client is actually catching my actions and sending them to the server as they happen, then the game is responsive.

And this happens even on my bottom of the scale computer in situations where there isn't much happening.

Adding another program that consumes at least 6-9% CPU does not reduce my responsiveness noticeably -- and that's 1 frame per second gone.

The point seems to be: A slightly lower FPS rate seems to provide better response. As long as the FPS is above a "sufficient" level, idle time is a better indication of repsonsiveness than FPS.

Maybe a testing option to "Reduce FPS by one" to test this?

Tue, 12/14/2010 - 21:40

Dogrock

The Java virtual machine does

The Java virtual machine does have a limit for how fast it will cycle commands and it has been mentioned that the Java environment speed is linked to the graphics speed. In my case the game cannot push past 35% CPU usage or 40% graphics usage except in the final arena stage. Activating VSync to limit the frames also lowers CPU time used, in my case this is maybe 3-4% difference. Loading up my CPU to it's limit creates a slow responding system.

Part of you problem is likely that your old PowerPC CPU can only handle one instruction thread at a time, and the relative speed at which it attacks each thread is relatively slow. Spawning enemies opens a small handful of new threads and the start of which is very hard on the CPU. This is on top of the ~7 active threads SK keeps open while idling (total thread count after a run is 52 when I checked). When at 95+ percent the CPU has a notable time delay switching threads because it has to finish the current thread's command before it can switch, even if the current thread is low priority. That's why Intel's Hyperthreading back on the Pentium 4 was so major a trumpet tooter at the time. The CPU had the ability to shelve a low priority thread and move to a high one. However, the advent of multicore CPUs rendered this at questionable usefulness (even in the current Core i series).

By slowing the graphics down you slow down the command rate of what looks to be the thread that sends graphics commands. On the other hand, more frames rendered means your input will show up on screen faster, barring no other bottlenecks. In your case of the old CPU it seams any toe hold that G4 can get is useful and it seems a multi-threaded program can choke it up. Meanwhile on my PC there are 4 high-speed cores that can crank through commands lickety-split, so the extra program threads work in my favour.

Also, Anantech did a great write up about VSync and Triple Buffering and how it can affect gameplay experience. It can be found here: http://www.anandtech.com/show/2794
And another on input lag: http://www.anandtech.com/show/2803
Of course those are more tangential in nature but still excellent reads that apply

Wed, 12/15/2010 - 18:59

BehindCurtai

Legacy Username

> When at 95+ percent the CPU

> When at 95+ percent the CPU has a notable time delay switching threads because it has to finish the current thread's command before it can switch, even if the current thread is low priority.

Gaah! I forgot about this.

The OS can switch native processes and threads as needed. I'm so used to thinking of multitasking in this way.

Each Java "thread" is just a state in the JVM managed data.

...

So ... what if the JVM implemented separate OS threads for each java thread, linked java and OS priorities, etc.: That would allow a java thread to be switched by the OS to another java thread as fast as switching from one thread in one native program to another thread in the same native program. That would be fast. Seems too easy, too obvious. Right?

Search

Performance notes from a bottom of the scale computer