Has my watch stopped...?

Today I wanted to print out a large scale RiscOSM map, so I exported it as a !Draw file (2100kb approx) and dropped it into Artworks for resizing to A4 landscape. The file needed resizing to exactly 50%. I hit Return, and everything locked: !Alarm’s clock display, the keyboard, the mouse. 6 minutes and 55 seconds later control returned, with the resized Drawfile. Now, I have a Pi4, and multitasking is enabled in Configure-Filer-file operations; I also know that exporting the file as a sprite would have allowed resizing in a fraction of the time, but I needed the extra precision afforded by a vector object. I think what this tells me is that RISC OS’s version of CMT is imperfect, to say the least; Artworks is by no means the only offender. Is there any way of compelling software to run in the background? I wouldn’t have minded if the above operation had taken 20 minutes, provided I could have got on with other stuff in the meantime. The other issue is VFP support: presumably the Pi possesses hardware that could have done the resizing in seconds, had it been available. The odd thing is, the Pi4 is so quick in other ways that when this happens it is more frustrating than was the case with slower hardware: I wasn’t so troubled when I had a Risc PC!

Is there any way of compelling software to run in the background?

Ask the author to write their software properly? (in this case the author has gone but the new maintainer might be able to figure something out…)

On a CMT system, operations that take time ¹ should not freeze up the entire machine. That’s just lazy lame-ass programming, yet it happens all the time.

6 minutes and 55 seconds later

Imagine that on an ARM710 RiscPC!

The other issue is VFP support

Yeah, that’s a drum I keep banging because every use of float (double, etc etc) in the DDE compiler gets you screwed by this everlasting reliance upon a software FP. Which made sense in the Acorn days, but just seems ridiculously illogical on a machine with actual FP hardware that’s easily two orders of magnitude faster.

Is ArtWorks assembler or C? It’s a CC creation, so I’d be inclined to think “painfully obscure assembler with an eccentric custom way of assembling all the bits” ².

¹ It’s highly subjective, but I’d suggest that anything that blocks the machine for more than about fifteen seconds is broken. And anything that blocks the machine for more than a single second without bothering to pop up an hourglass is broken.

² Working definition of Impression, that.

Is ArtWorks assembler or C? It’s a CC creation, so I’d be inclined to think “painfully obscure assembler with an eccentric custom way of assembling all the bits”.

Trying to remember the details Martin once told me about the codebase…

Originally, Artworks was 100% assembler code. But apparently “clean” assembler, so Martin was able to more-or-less-mechanically transform it into 32bit clean assembler. Later parts by Martin were at least partly done in C (I think the “TextArea” module is mostly C).

without bothering to pop up an hourglass is broken.

I should have mentioned in the OP that the hourglass did appear the moment the process started: for nearly 7 minutes it was the only part of the desktop that moved ….

Imagine that on an ARM710 RiscPC!

Funny you should say that. I decided to try the same operation on (1) RPCEmu and (2) VRPC, both running on the same 2.6GHz Win7 laptop*. I had an idea that emulation might take advantage of the base system’s presumably superior floating-point arrangements, but not so: RPCEmu took 44 minutes and VRPC took one minute longer to resize the drawfile. Makes the Pi4 look rather impressive, in retrospect! But it does highlight the shortcomings of RISC OS’s current VFP system.

[*Both displayed a similar 150-160 Mips and used 24-28% of the base system’s processor capacity]

EDIT: to reference an adjoining thread, it would be interesting to try this on Timothy Baldwin’s RO Linux port. I can supply the Drawfile if anyone is interested.

Draw makes no use of floating point numbers, does it?

Fixed point numbers are absolutely fine for !Draw. Perhaps someone somewhere needs a drawing over a kilometre across, with details more precise than a thousandth of a millimetre, but I’ve not met them.

And of course fixed point numbers are handled more quickly than floating point.

Draw makes quite a lot of use of floating point. Just drop all the sources into Zap and search for “double” and you’ll see that rotations and such use floating point, and Béziers are full of heavy FP use – https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Draw/-/raw/master/c/bezierarc

All of that will use the emulator. :-/

…a drawing over a kilometre across

FWIW the map in question was slightly smaller than A2 format when exported as a Drawfile at 100% and covered an area of approx. 300 sq.km. It required a reduction to 50% to fit on A4. I wouldn’t have thought that constituted excessive size in Drawfile terms but I’m happy to be corrected. The filesize was 2365k. Would the Pi’s floating point hardware, assuming RO could use it, have made a difference?

Draw makes quite a lot of use of floating point.

Which raises the old topic of a FPE_shim to present VFP as something the system sees as FPE

Or simply use 64-bit integer math to do Draw transforms, as Fireworkz and PipeDream have done since forever.

@Steve Pampling

Which raises the old topic of a FPE_shim to present VFP as something the system sees as FPE

That sounds like an interesting project…

I’ve downloaded the RISC OS source code, but having never built it before, I have a hard time finding the source code for FPEmulator, i.e. the part that implements the FP instructions.

Could anyone provide a pointer?

Terje – on my sources (an old tarball), it is at: …mixed.RiscOS.Sources.HWSupport.FPASC

Which raises the old topic of a FPE_shim to present VFP as something the system sees as FPE

Or try to talk ROOL into creating/releasing a VFP version of the compiler. ;-)

I would guess this may be “in the pipeline” as it looks (looking at the compiler binary) that it can accept “-fpu” to specify what sort of code to generate, which will accept one of none/fpa/vfp/vfpv2/vfpv3/vfpv3_d16/vfpv4/vfpv4_d16 as possible targets.

Or simply use 64-bit integer math

It’s enough to work out algorithms using normal maths, it would just be nice if in 202x the compiler could output code for the technology of 202x, not 198×. ;-)

Would the Pi’s floating point hardware, assuming RO could use it, have made a difference?

I did a test on my Pi1 back in 2015.

Performing FPA MUL 4,096,000 times: 80779.853376 in 388cs
Performing VFP MUL 4,096,000 times: 80779.853376 in 7cs

Yes. That’s “nearly four seconds” compared with “seven hundredths of a second”.