threads on linux

Performance Tuning
#1

Hi,
I’m developing a platform game using java 2d. I’m working mainly on windows, but also testing on linux.

Speed is not an issue on windows, since java can use my graphics card - but linux seemed to be a lot slower.

I’m doing rendering on a seperate thread (a while loop in the run() method), and using thread.sleep(x) to control the speed.

I was getting about 33fps on linux with scrolling and a few sprites moving around. I was sleeping for about 12ms per frame. Then I set the sleep to 0 and I started getting 200fps!! But if I set the sleep to 1 I only get about 50fps.

I assume this is to do with how threading is handled on Linux - is there a better way to control the speed in my game?

#2

if 200 fps is slower than windows, can you tell me what is the framerate under windows??

Normally, linux has a millisecond grain for the timer. Window’s one is around 10 to 15 ms…
If you want to know your salt, code a loop with 1ms sleeps, and show the currentTimeMillis each time you quit the sleep.
You should have output at the same ‘date’ for some time. simply see what is the increment when the time changes.

#3

Actually I just got home and tried out the code on my windows machine (1ghz with geforce2 mx 32mb) and was rather dissapointed to find i (only?) got 150fps! - that was with a sleep time of 0 again.

The computer with linux on is one at Uni - it’s pretty new (does anyone know how to find out the processor speed/type on Linux?) It must be quite a beast to outperform my computer without any h/w acceleration!

Can anyone think of a reason why there should be such a speed difference between sleeping for 1ms and sleeping for 0ms?

#4

Except a big granularity in timers, nope.

#5

As pepe said you usually can’t sleep for 1ms, the minum amount is system dependant and about 10ms on WinXP.

I have trashed the whole sleep() stuff to get constant frame rates. I now have am anim-controller-class that extends java.util.TimerTask and that is called by a java.util.Timer as often as I want FPS. That works quite OK,not perfect, but it’s the most stable I got with a basic JRE in windowed mode (else you can use a HiresTimer form Java3d and busy-wait…)

#6

[quote]Actually I just got home and tried out the code on my windows machine (1ghz with geforce2 mx 32mb) and was rather dissapointed to find i (only?) got 150fps! - that was with a sleep time of 0 again.
[/quote]
There are other reasons as to why there could be such a performance difference between systems, not talking about sleep() here.
[]There are some known problems when using jre 1.4.1 with some geForce 2 MX cards. Although I don’t think it applies to you since 150fps is not bad anyways. They are working on this. (see the thread on side scrolling, there’s a mention there)
[]video memory is normally accessed through AGP. This might slow down graphics in some circumstances. I have a cheap motherboard that uses system RAM for video and, although sharing RAM between CPU and video is generally not optimal, there is no transfer of data through the AGP. This makes my cheap motherboard very fast when writing/reading on ‘video’ RAM. The same might apply to your linux box.

Seb

#7

[quote]video memory is normally accessed through AGP. This might slow down graphics in some circumstances. I have a cheap motherboard that uses system RAM for video and, although sharing RAM between CPU and video is generally not optimal, there is no transfer of data through the AGP. This makes my cheap motherboard very fast when writing/reading on ‘video’ RAM. The same might apply to your linux box.
[/quote]
Actually, I might be partially wroung here. My motherboard might still use AGP circuitry to negotiate the reading/writing on the video part of RAM, which might slow things down a tad. It might even send the data through the bus at 1x, 2x or4x speed.

In any case, this could still apply to your linux box, as it could have a completely different and straight forward architecture. I miss the old Atari ST days, that machine had all of system RAM available to video, working at twice the speed (16MHz!!!) of the CPU, the memory was accesed by both on alternate cycles. So the CPU never had to wait to use RAM. Anybody have any 4GHz DIMMs?

Seb

PD: Me, I didn’t mean to piss me off by correcting myself, so don’t flame me.

#8

[quote]does anyone know how to find out the processor speed/type on Linux?
[/quote]
To get info on the cpu open a shell and run more /proc/cpuinfo There are other intersting things in /proc too, take a look around.

lspci is a nice command too for info about what is on the pci bus.

#9

Note that your fps numbers may be off on *nux unless you do Toolkit.sync(); after each frame. X is asynchrous, so w/o the sync you’re really measuring the speed with which you can issue the commands to the X server.

#10

[quote]Note that your fps numbers may be off on *nux unless you do Toolkit.sync(); after each frame.
[/quote]
Thanks, I’ll try that. However, judging visually, it does seem to be going faster on linux than it does on my windows machine.

Does toolkit.sync() make any difference on windows? I’m using a buffer strategy to do my graphics in both full screen and windowed mode. I’ve tried inserting it before i draw my graphics, before I call bufferstrategy.show(), and after it - it’s still going at full throttle!

[quote]To get info on the cpu open a shell and run `more /proc/cpuinfo
[/quote]
I tried this - the linux machine I’m testing on appears to be an Athon 1.5GHz 1800+ with 512 meg of ram.

One other question. Does anyone know why in full screen exclusive mode, the framerate is limited to the refresh rate of the screen mode I’m in, whilst in windowed mode, it just goes as fast as it possibly can? (with tearing of course)

#11

If you’re using a flip buffer strategy on windows in fullscreen mode, you’re actually bound to your monitor refresh rate, so calling Toolkit.sync probably won’t make any difference.

It could make a difference in windowed mode, though.