OS_WriteN benchmarking tool?

Looking at the code for OS_WriteN, something is apparent – there is actually no limit on the value of R1 going into the SWI. The SWI goes from the OS SWI jumptable in Kernel.S, to vdu.vduswis.s. No clamping is done on the value of R1; it just goes straight into the loop, sending VDU codes.

This opens up the possibility of constructing some benchmarks of the VDU system (but not only the VDU system, also the SWI subsystem in general). It could allow testing of ‘kernel speed’ across a wide variety of platforms etc, and test speedups in various parts of the SWI code in general. It could also allow easy benchmarks to be constructed from BASIC, without needing to worry about the speed or otherwise of BASIC itself.

A benchmark that would mainly be a test of the SWI subsystem could be done like:

DIM benchmark% 1024*1024
FOR loop%=0 TO 1024*1024-1
benchmark%?loop%=0
NEXT loop%
TIME = 0
SYS “OS_WriteN”, benchmark%, 1024*1024-1
fintime%=TIME

This would test the speed of a million OS_WriteC 0 commands, which is a good test of the SWI subsystem itself (and allows testing through vector or direct to PMFWrchDirect as well), as not much processing occurs; the VDU command jumptable in vdu.vdudriver.S points to a MOV PC,R14!

Other tests could do things like moving rectangles (testing hardware acceleration, perhaps testing different approaches to GPU acceleration etc);

You could test including a switch to MODE 15 at the start to standardise the test, and compare performance across different Pis, Risc PC, Iyonix, even an A3000! (the A3000 would probably beat a Pi if the test was just a load of carriage returns; hardware vs software scroll etc)

I may put a little test suite together at some stage using this concept. What is good is that all you need is a precomputed file to point OS_WriteN at, and a single command starts and runs the whole test. It may also have some relevance in determining which parts of the drivers are slowest, to target optimisation there, especially in future CPU-agnostic ports of RISC OS, as the VDU commands are used a lot (even if you ignore the Sprite commands!)

FOR loop%=0 TO 1024*1024-1
:
SYS “OS_WriteN”, benchmark%, 1024*1024-1

I feel an out-by-one error has slipped through the net there.

TIME = 0

And please don’t assign things to TIME because it’s shared across all of the OS. Better is start%=TIME…duration%=TIME-start% to avoid disturbing anyone else using TIME in their own program.

As long as the extra byte isn’t a 2, we should be fine!

I do agree re: the TIME thing, which actually raises an interesting point;

the TIME variable itself is central to RISC OS of course, and can be changed by a lot more than just BASIC.

However, BASIC is probably the language used most often to do TIME = 0 without considering the consequences.

It would be possible in BASIC to return TIME as usual, but if a ‘TIME = command is issued, a ‘correction value’ could be updated and kept in the ARGP / VARS block. This could be used so that the program will think it has adjusted the TIME variable, and would get the results it expects when reading the TIME variable later on.

The main complication arise if a BASIC program did things like using TIME= (number) to set TIME, but then useddirect OS calls to read it back later on.