English Amiga Board - View Single Post - Experimental/testing builds of WinUAE 2.7.0 with VS 2013

mark_k · 08 December 2013, 20:08

I have created experimental/testing builds of WinUAE 2.7.0 using Visual Studio 2013. (The official WinUAE binary is built with Visual Studio 2010.)

~14.5MB archive (nine executables and source code): 4-s-h-a-r-e-d. (Copy and paste link into your browser, change hxxp to http and remove - symbols before pressing enter.)

These are not official builds, so don't bug Toni if they don't work properly; post here instead. They should be compatible with Windows XP SP3 and later. Please let me know if they crash or otherwise misbehave on your XP SP3 system. The source code is unmodified, but the built-in AROS ROM is probably an earlier version than that in the official build. (I used aros.rom.cpp_AROS-20131028.zip as uploaded by acd2001; Toni doesn't include aros.rom.cpp in the official source archive.)

They might be slightly faster than the official build, assuming Microsoft improved their compiler between VS2010 and VS2013. However any difference probably won't be huge, or perhaps even noticeable at all. And I haven't done any testing. There is probably most likely to be a difference when using a C-language CPU core (68030/040/060 with MMU) or running a demo which has effects which are very CPU-heavy to emulate.

There are speed- and size-optimised executables for x86, SSE, SSE2 and AVX. It probably makes sense to use the "best" one that your computer's CPU supports. I didn't add any CPU check code, so if you run one which uses instructions your CPU doesn't support it will probably crash. Pentium III doesn't support SSE2 and Core 2 Duo doesn't support AVX for example. There probably isn't much point using the size-optimised ones, but I compiled them to see how much difference optimising for size made (about 1MB).

Optimisation settings used:
Full Optimization (/Ox)
Inline Function Expansion: Any suitable (/Ob2)
Favor fast code (/Ot)
Omit Frame Pointers: Yes (/Oy)
Whole Program Optimization: Yes (/GL)

Also included as an experiment is a build (for SSE2) using the "fast" floating-point model (instead of precise). I'm not sure how that difference could affect emulation, so why not test it out?

Other possible ideas for building faster executables (any comments Toni?):

Use __fastcall for functions. With that, the first two arguments are passed in registers instead of on the stack which could improve performance.
Use profile-guided optimisation (PGO). Having some way to script WinUAE so it automatically boots different demos/HDFs using different CPU cores would really help there.
Add zlib, 7z and other libraries to the WinUAE project so the various libraries can be built with whole-program optimisation too. (I just used Toni's winuaeinclibs.zip archive here.)

08 December 2013, 20:08	#1
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,347	Experimental/testing builds of WinUAE 2.7.0 with VS 2013 I have created experimental/testing builds of WinUAE 2.7.0 using Visual Studio 2013. (The official WinUAE binary is built with Visual Studio 2010.) ~14.5MB archive (nine executables and source code): 4-s-h-a-r-e-d. (Copy and paste link into your browser, change hxxp to http and remove - symbols before pressing enter.) These are not official builds, so don't bug Toni if they don't work properly; post here instead. They should be compatible with Windows XP SP3 and later. Please let me know if they crash or otherwise misbehave on your XP SP3 system. The source code is unmodified, but the built-in AROS ROM is probably an earlier version than that in the official build. (I used aros.rom.cpp_AROS-20131028.zip as uploaded by acd2001; Toni doesn't include aros.rom.cpp in the official source archive.) They might be slightly faster than the official build, assuming Microsoft improved their compiler between VS2010 and VS2013. However any difference probably won't be huge, or perhaps even noticeable at all. And I haven't done any testing. There is probably most likely to be a difference when using a C-language CPU core (68030/040/060 with MMU) or running a demo which has effects which are very CPU-heavy to emulate. There are speed- and size-optimised executables for x86, SSE, SSE2 and AVX. It probably makes sense to use the "best" one that your computer's CPU supports. I didn't add any CPU check code, so if you run one which uses instructions your CPU doesn't support it will probably crash. Pentium III doesn't support SSE2 and Core 2 Duo doesn't support AVX for example. There probably isn't much point using the size-optimised ones, but I compiled them to see how much difference optimising for size made (about 1MB). Optimisation settings used: Full Optimization (/Ox) Inline Function Expansion: Any suitable (/Ob2) Favor fast code (/Ot) Omit Frame Pointers: Yes (/Oy) Whole Program Optimization: Yes (/GL) Also included as an experiment is a build (for SSE2) using the "fast" floating-point model (instead of precise). I'm not sure how that difference could affect emulation, so why not test it out? Other possible ideas for building faster executables (any comments Toni?): Use __fastcall for functions. With that, the first two arguments are passed in registers instead of on the stack which could improve performance. Use profile-guided optimisation (PGO). Having some way to script WinUAE so it automatically boots different demos/HDFs using different CPU cores would really help there. Add zlib, 7z and other libraries to the WinUAE project so the various libraries can be built with whole-program optimisation too. (I just used Toni's winuaeinclibs.zip archive here.) Last edited by mark_k; 01 December 2014 at 13:24. Reason: Updated link due to crazy EAB policy...