WinUAE 3.4.0 beta series

[AMIGASYSTEM]

I tried to time the system load speed AFA OS and OS4 the time taken was the same for all; is there any test in particular to do?

[Toni Wilen]

Originally Posted by amilo3438

With the same config and Jim Power title screen CPU usage:

winuae.exe = 96%
winuae_14_pre.exe = 120%
winuae_14.exe = 122%
winuae_15.exe = 122%

(note that the % is taken around most stable value)

Thanks. This confirms it isn't caused by different compiler versions.

And it is exactly b6 that is slower than b5? (Just to confirm it 100%+ )

(winuae.exe was old file that can be ignored..)

I tried to time the system load speed AFA OS and OS4 the time taken was the same for all; is there any test in particular to do?

Use basic A500 or A1200 config. No JIT, no nothing. It probably is chipset emulation related.

[Dr.Venom]

Originally Posted by Toni Wilen

Thanks. This confirms it isn't caused by different compiler versions.

And it is exactly b6 that is slower than b5? (Just to confirm it 100%+ )

Maybe the issues on the interlace frame type mismatches I reported earlier could also be related to the reported slowness for beta 6+ ?

Doing tests that also narrowed down to beta 5 being fine and beta6+ having the issues. Maybe (not) a coincidence?

http://eab.abime.net/showpost.php?p=...&postcount=342

Originally Posted by Dr.Venom

I've gone back and retested 3.0.0, 3.1.0, 3.2.0, 3.3.0, 3.4.0beta1 to beta 5 and they are all OK. The problem is introduced with beta 6. Sorry can't make anything else from it.

[snip]

[Toni Wilen]

I don't think so, keyword "Windows XP". (=can't be wasapi)

[Dr.Venom]

With regards to the beta series being slower, I ran some tests with the Jim Power title screen in a similar fashion like Amilo3438 did.

This is for a Windows 10 system with 3770K CPU. LED 50Hz, low latency vsync, and both Wasapi and DSound tested:

Note: The below values are taken after about a minute of the title screen scrolling, as the cpu% value seems to creep up a bit from the start before "averaging out"

Results with Wasapi:

All 64-bit versions:
3.3.0 = 65%
3.4.0 beta 1 = black screen (gui still accessible, back to screen shows yellow led)
3.4.0 beta 2 = 85%
3.4.0 beta 5 = 85%
3.4.0 beta 6 = 85%

This seems to indicate that the Wasapi event/pull mode, while being much more stable than push, is also quite a bit more cpu intensive.

Note: No difference between beta 5 and 6.

Results with DSound:

3.3.0 = 66%
3.4.0 beta 6 = 68%

So for DSound the speeds are about the same for 3.3.0 and 3.4.0 beta 6.

[Toni Wilen]

It is still irrelevant to this problem because
a) vsync is not used.
b) vsync will make CPU% unreliable (pull waiting counts for cpu%)

Don't add unknown variables, reduce them!

[Toni Wilen]

winuae2.7z updated. Two exes only, any change now?

[amilo3438]

Originally Posted by Toni Wilen

winuae2.7z updated. Two exes only, any change now?

Again, the same config and Jim Power title screen:

winuae_14_pre.exe = 120%
winuae_15.exe = 120%

p.s.
Just think, maybe it's not worth the effort.
Those with faster PC will not feel big difference and those with slower can always use older version when the new one start to create a problem with performance.

Originally Posted by Dr.Venom

With regards to the beta series being slower, I ran some tests with the Jim Power title screen in a similar fashion like Amilo3438 did.

This is for a Windows 10 system with 3770K CPU. LED 50Hz, low latency vsync, and both Wasapi and DSound tested:

In attachment on below link can be found simple configuration for the test ! (no vsync)
http://eab.abime.net/showpost.php?p=...&postcount=356

[Toni Wilen]

Not sure about being worth the trouble but something is weird because I can't find any reason for this..

winuae2.7z updated once more, 3rd exe added. Still same?

[amilo3438]

Originally Posted by Toni Wilen

Not sure about being worth the trouble but something is weird because I can't find any reason for this..

winuae2.7z updated once more, 3rd exe added. Still same?

Tested all again:

winuae_14_pre.exe = 120%
winuae_14.exe = 122%
winuae_15.exe = 120%

Interesting, I would expect winuae_14.exe to be same as winuae_15.exe, but its not ! (checked twice)

[michaljarz]

Hi. I quickly tested Jim Power with non official betas that i had:
3.3.1 2016.07.10 18:28 - OK
3.3.1 2016.07.15 18:10 - emulator won't start (AVRT.dll error)
3.3.1 2016.07.16 21:35 - much slower
(version between do not have, if any)

Tomorrow test more accurately.
Tested on Win XP.

(sorry for my english)

[Toni Wilen]

?? There are no official betas from July.

[michaljarz]

I downloaded sometimes winuae.7z, before thread "beta 3.4.0" begin...

[michaljarz]

The results may not be accurate (I tested once/two each version).

3.3.0 snd:-13/+5 cpu:63 fps:49.9
winuae.exe 20160710_1828 snd:-7/+5 cpu:62 fps:50
winuae.exe 20160716_2135 snd:-41/-28 cpu:169 fps:29
3.4.0b01 snd:-41/-28 cpu:74 fps:46
3.4.0b02 snd:-41/-28 cpu:74 fps:46
3.4.0b03 snd:-21/0 cpu:77 fps:49.9
3.4.0b04 snd:-20/0 cpu:77 fps:49.9
3.4.0b05 snd:-6/+5 (after 2min:-32) cpu:77 fps:49.9
3.4.0b06 snd:-6/+5 (after 2min:-32) cpu:74 fps:49.9
(latest winuae2.7z)
winuae_14 snd:-30/+22 cpu:76 fps:49.9
winuae_14_pre snd:-6/+7 cpu:79 fps:49.9
winuae_15 snd:-6/+5 cpu:75 fps:49.9

[Toni Wilen]

One random test: any change if you switch sprite collisions option (chipset panel) completely off?

[michaljarz]

Sprite collision off:
3.3.0 cpu:62%
winuae_15.exe cpu:59%

[Toni Wilen]

Looks much better.. Does winuae.7z now work with "normal" speed even with sprite collisions enabled?

[michaljarz]

Yes. 3.3.0 cpu 63%, latest winuae.7z 62% :-)
(this is for me, I do not know how it works for amilo3438)
Thanks :-)

[amilo3438]

Originally Posted by Toni Wilen

Looks much better.. Does winuae.7z now work with "normal" speed even with sprite collisions enabled?

This one is much better !

with the same config = 102% (sprite collisions disabled = 93%)

Edit: so..
Collision level:
None = 93% ... (Edit: same on official 3400b14)
Sprites only = 96% ... (Edit: same on official 3400b14)
Sprites and Sprites vs. Playfiled = 102% ... (Edit: 120% on official 3400b14)
Full = 102% ... (Edit: 120% on official 3400b14)


p.s.
On WinUAE3.3.0, when the sprite collisions is disabled the usage % is almost same (unchanged) !?
And also same on WinUAE3.3.1 (Public Beta 0, 2016,06,20).

[Toni Wilen]

Originally Posted by amilo3438

On WinUAE3.3.0, when the sprite collisions is disabled the usage % is almost same (unchanged) !?
And also same on WinUAE3.3.1 (Public Beta 0, 2016,06,20).

Because 3.3 and older had very stupid optimization that skipped it completely (practically same as only sprite-sprite collisions enabled in GUI), even in situations where program needs collisions (Jumpman Junior). Now it tries to do the same but there is no way to 100% know in advance if this collision test can be skipped or not.

Jim Power is extreme test case because whole background is made from horizontally repeated sprites!