Request for testing Compiler settings

[gid15]

I guess you have some "Step" methods to call periodically. The longest the compiled block is the slowest responsiveness is. It's kinda logical.

The calls to "Step" methods are left unchanged, it's just that the Java JIT doesn't like to compile large Java methods.
e.g. with 3000: the Jpcsp Compiler is compiling a mips function at 0x8000000 into a single Java method:

Code:

public static call800000() {
   instr1
   instr2
   ...
   instr1234
}

but the Java JIT usually doesn't compile this method due to its size.

And with 50: the Jpcsp Compiler splits the Java method in smaller ones having max. 50 MIPS instr:

Code:

public static call800000() {
    call800000_50()
    call800000_100()
    call800000_150()
    ...
    call800000_1200()
}
public static call800000_50() {
    instr1
    instr2
    ...
    instr50
}
public static call800000_100() {
    instr51
    instr52
    ...
    instr100
}

The java JIT compiler usually decides to compile the smaller methods, resulting in a faster code execution even with the overhead of the additional method calls...
There is probably some threshold in the JIT compiler based on the code size...

[Orphis]

And people might have a better FPS with the server JVM too because it's compiling bigger methods.

[MaXiMu]

Final fantasy Crisis core 22-42fps ingame -> using private int methodMaxInstructions 50 average 24-35fps

Final Fantasy Crisis core 20-35fps ingame -> using private int methodMaxInstruccions 3000 (Default) average 22-30fps

some games stability especially on the loading screen by millisecond/minute faster (Average) and small frame max up 2-6fps in ocasions Estability better.

great work

[Itaru]

Here are the results of my testing using r1951. I'm using the server JVM in all games tested using the following additional switches: -server -Xverify:none -Xrs -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ReservedCodeCacheSize=32m

The FPS numbers are directly taken from the emulator itself. I modified the source to keep track of min, max, and avg FPS then print the numbers out to the console when I exit jpcsp. The min and max FPS aren't that meaningful, but the avg FPS can be compared meaningfully for the most part.

The 3rd Birthday ULJM05798
50: min 11 - max 59 - avg 36.9
100: min 10 - max 60 - avg 38.2
500: min 17 - max 60 - avg 52.5
1000: min 27 - max 58 - avg 52.1
3000: min 4 - max 59 - avg 48.8
Comments: This game doesn't like small settings, it lags a lot when things get busy where FPS regularly drops in the low 20s and 10s. The game's a joy to play at 500/1000, but at 3000 performance drops although not quite as bad as 50/100. Also if I don't set ReservedCodeCacheSize to 32m, I get CodeCache full/Compiler disabled errors but the game keeps running. This game works best with 500.

Crisis Core Final Fantasy VII ULUS10336
50: min 6 - max 59 - avg 48.9
100: min 5 - max 58 - avg 48.1
500: min 2 - max 58 - avg 44.2
1000: min 6 - max 64 - avg 42.3
3000: min 6 - max 58 - avg 42.1
Comments: This game doesn't like large settings at all. It runs smoothest at 50, and the larger the setting the choppier it plays. Things get choppy starting at 500 and above. The avg FPS doesn't indicate a huge drop (mostly because I only tested for a very short time), but the choppiness is really bad at large settings. This game works best with 50.

Dissidia Final Fantasy ULES01270
50: min 5 - max 30 - avg 20.6
100: min 6 - max 29 - avg 20.6
500: min 4 - max 30 - avg 20.3
1000: min 8 - max 29 - avg 20.6
3000: min 11 - max 29 - avg 20.2
Comments: I randomly get weird sky corruption after tutorial battles and then ArrayIndexOutOfBounds crash regardless of the methodMaxInstruction settings. Letters are also missing in the text. In the tutorial battles, performance is decent and I noticed no difference at all with different settings.

Gran Turismo UCUS98632
50: Crash: EXCEPTION_PRIV_INSTRUCTION
100: min 11 - max 60 - avg 35.5
500: min 12 - max 61 - avg 35.9
1000: min 13 - max 61 - avg 37.0
3000: min 13 - max 61 - avg 37.4
Comments: I don't notice any difference in performance with different settings, except that at 50 it crashes at the beginning. I'll retest it with r1952 later. Racing performance is okay but the graphics is really bad with lots of missing textures.
Updated Comments: I tested with r1952 at 50 and there's no more crashing. The FPS numbers for 50 are pretty much the same as for 100 and 500.

Hatsune Miku Project DIVA 2nd ULJM05681 (with English menu patch)
Comments: The FPS is too out of whack here with max reaching 250s and avg FPS in the 100s. With different settings (50/100/500/1000/3000) I don't notice any performance difference at all and the FPS numbers are very close to each other. The visuals lag behind the music a bit but the rhythm game runs smooth enough to be playable. It's a bit difficult to get the timing right since I have to rely on visual cues only since the visuals and music are not synchronized properly (and listening to the music actually throws off my timing), but I've managed to clear 3 songs on easy mode.
Updated Comments: It turns out that the synchronization problem is due to Jpcsp playing the audio too fast. Details here: http://www.emunewz.net/forum/showthread.php?tid=3392

Hatsune Miku Project DIVA ULJM05472 (with English menu patch)
Comments: This game is just too choppy and unplayable regardless of the methodMaxInstruction settings. Like the sequel, it also has whacked out high FPS numbers. The sequel above plays so much better and smoother though, probably due to better coding in the sequel compared to this one.

I still have a few other games to test. I'll do more tests tonight if I have time. I still have Hexyz Force, Persona 3 Portable, Valkyrie Profile Lenneth, Ys: The Oath in Felghana, and Ys SEVEN to test.

[hlide]

I guess you have some "Step" methods to call periodically. The longest the compiled block is the slowest responsiveness is. It's kinda logical.

The calls to "Step" methods are left unchanged, it's just that the Java JIT doesn't like to compile large Java methods.

[...]

The java JIT compiler usually decides to compile the smaller methods, resulting in a faster code execution even with the overhead of the additional method calls...
There is probably some threshold in the JIT compiler based on the code size...

ok, I had a similar issue with the static recompiler (for pcsp) when I tried to output a big switch code using addresses to execute small basic blocks in every case block. VC2008 and gcc failed to compile the big result. I guess even having small methods may help because JIT would probably inlines them at the end.
I don't know how the details, but if by responsiveness you were spoken about faster loading because of smaller java methods compiling, "responsiveness" was a little abused term ^^.

[Itaru]

I only managed to test one more game last night. Using r1952 with the following switches same as before: -server -Xverify:none -Xrs -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ReservedCodeCacheSize=32m

Persona 3 Portable ULUS10512
50: min 11 - max 58 - avg 42.9
100: min 20 - max 58 - avg 44.4
500: min 19 - max 58 - avg 44.9
1000: min 16 - max 58 - avg 44.2
3000: min 18 - max 58 - avg 43.8
Comments: A setting of 50, 100, or 3000 causes occasional but noticeable lags/stutters while running around in Tartarus. Those lags happen a lot less frequently and also less noticeable at 500 or 1000. I'd say that the best setting is 500 for this game.

[Hykem]

Hmm...
It seems that 500 is the best candidate so far. The difference it's barely noticeable between 500 and 1000 in most games, but some games with heavier instructions can definetly improve from a 500 splitting.

[gid15]

OK, thanks all for the testing!
The results were interesting and quite surprising for me! I was expecting all games run better or unchanged with 50, but not worse .
As the effect depend on the game, I will add a compatibility settings with the following possible values: 50, 100, 500, 1000, 3000.

[Orphis]

Call it a speed hack and you'll get tons of worshippers ^^ (well, you'd better not, or people will complain it doesn't work :p)