We have been doing similar tests here at Opto (cant say why, or on what hardware).
Enough to say, yes, your right, it all depends on what code you are running. If you add a few I/O units and some analog or serial modules into the mix, things change again.
For a base line, you have the right idea, do some stuff and time it. Make it the same code on both platforms and you can get a very rough approximation.
Hint, if you throw some ‘heavy’ float calculations in there, you will see (very) different again numbers.
One thing that is super super super super super critical is that your chart must must must must must must must have a delay in it. All charts, through all loops must must must must must have a delay (At least 1msec, but honestly, 10msec or so would be better). Can not stress this strongly enough.
Regarding the Windows CPU / speed . You are not seeing things. Windows is not deterministic. It is happy to let its different programs just float around the grid as the master control program (MCP) wishes… sorry, my Tron might be leaking… But seriously, we saw the exact same thing here. Depending on what programs were or were not doing, the softpac speed would go up and down, and not always in an expected or logical manor.
Best result is on a headless unit with a really minimal install.
This really shows why a PAC R or PAC S controller is the best for consistent performance. (Unless you can dedicate said headless Windows box).
The other thing that is interesting is that some hardware platforms will throttle CPU speed (clock) as they heat up.
We could plot this really clearly in PAC Display or groov trends. Again, the R and S controllers DO NOT do this.
Computer BIOS settings will also impact these sorts of speed ‘tests’. (No, I cant say more on this).