log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Elsear brings super-fast Networking to Risc PC/A7000/A7000+ (News:)
- November 2024 News Summary (News:1)
- Latest hardware upgrade from RISCOSbits (News:)
- WROCC November 2024 talk o...ay - Andrew Rawnsley (ROD) (News:3)
- Accessing old floppy disks (Gen:3)
- November developer 'fireside' chat on saturday night (News:)
- RISCOSbits releases a new laptop solution (News:4)
- Announcing the TIB 2024 Advent Calendar (News:2)
- RISC OS London Show Report 2024 (News:1)
- Code GCC produces that makes you cry #12684 (Prog:39)
Related articles
- Native versus emulation in 2016 (Part 2)
- ABug provide more interesting retro talks to pass the time this Christmas
- Pass the time this Christmas with a selection of RISC OS and BBC Micro talks
- Native versus emulation in 2016 (Part 3)
- First Impressions of RComp's TiMachine
- Newsround
- RISC OS - the week in comments
- Wakefield 2006 show report
- Wakey Wakey, it's show time again!
- RISC OS on TV take 2
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: News and features: Native versus emulation for running RISC OS in 2016 (Part 1)
 

Native versus emulation for running RISC OS in 2017 (Part 1)

Posted by Mark Stephens on 10:49, 7/12/2016 | , ,
 
This old chestnut has been around for many years now, and I think it always will be. But Christmas is a time for chestnuts, so let us see if we can put a new Iconbar spin on it by comparing the latest Apple and Elesar hardware for a 2016/7 take on the question....
 
I have both a shiny new TiMachine (using the Titanium motherboard) and a snazzy new MacBookPro on my desk which I am going to pit against each other. This article is split into 2 parts. In part 1, I am going to explain all the details and part 2 will give you the actual results.
 
RISC OS on native ARM hardware
ARM options have exploded in the last few years and you now have a wide range of machines on which RISC OS can be run directly (RapberryPi, Pandaboard, ARMX6, IPEGv5, Titanium). Exact performance will vary between machines and also depend on the type of disk you have (SD card, Zip drive, SSD drive).
 
If you are upgrading from a RISC PC or Iyonix, all of them will give you a welcome speed boost. I have several RaspberryPis, a Panda and a TiMachine and they all provide solid platforms for running RISC OS.
 
RISC OS on a MacBookPro
The latest version of the high end Apple laptop was released in October 2016. They added some additional features to excite/annoy you (touch sensitive screen to replace function keys, only USB-C sockets). The current machines use Intel processors (Skylake release) with fast RAM and SSD drives. So RISC OS is run using an emulator program (running on macOS) which converts ARM code into Intel code. There are ways to speed this up, but it is slower than it would be if running on ARM directly. The critical question is whether the faster speed of the Intel processor can compensate for the extra work involved.
 
If you want to run RISC OS on Mac you have a choice of the commercial VirtualRPC (which runs RISC OS 4/6) and the free RPCEmu (runs RISC OS 5). Both programs emulate a complete RISC OS machine (either running full-screen or in a Window) which can also access the macOS filing system. I find VirtualRPC to be faster in my tasks so I will be using that for this comparison.
 
How to compare?
We are going you use the benchmark program ROMark which you can find on Chris Hall's excellent website, where he has lots of data on performance for different machine running RISC OS. Any benchmark is going to be a proxy because everyone will use their machines in different ways and it does not include details which may be important (such as power usage, budget, need for speed, personal sentiment, etc). VirtualRPC cannot do 1920x1200pixels in 16 million colours, so we will use 1680x1050pixels in all tests to provide a common reference. The tests give very slightly different results on each run but are reasonably close each time.
 
It does give us a fairly good proxy for comparing different machines in a reasonably consistent way. It will also allow us to look at several options, particularly on the MacBookPro. Is RISC OS faster in full-screen or window mode? What happens if we are on batter power? We will be finding out...
 
See you in Part 2 for some numbers. Anyone prepared to make any bets?
 
  Native versus emulation for running RISC OS in 2016 (Part 1)
  Bucksboy (11:05 8/12/2016)
  arawnsley (12:43 8/12/2016)
    Bucksboy (17:30 8/12/2016)
      Bucksboy (17:31 8/12/2016)
      arawnsley (18:31 8/12/2016)
        nunfetishist (09:38 9/12/2016)
          Bucksboy (12:33 9/12/2016)
            nunfetishist (16:04 10/12/2016)
              Bucksboy (23:14 10/12/2016)
 
George Greenfield Message #123952, posted by Bucksboy at 11:05, 8/12/2016
Member
Posts: 91
I'd expect the higher-end native hardware (Titanium, IGEP, ARMX6) to show a substantial edge over emulation on any MacOS or Windows platform. The Pi3 should just shade it over VRPC. There wouldn't be much to choose between RPi2/Zero and emulation; I'd expect the emulator to shade the Pi1.
  ^[ Log in to reply ]
 
Andrew Rawnsley Message #123953, posted by arawnsley at 12:43, 8/12/2016, in reply to message #123952
R-Comp chap
Posts: 600
I actually ran some Datapower tests recently between x86-native (DP for Windows), RISCube (RISC OS), ARMX6 and TiMachine. This was a monster database where the processing time was in *minutes*. It could probably have been redesigned better, but this was what the customer was using.

Quite intriguingly, there was negligable difference between TiMachine, ARMX6 and RISCube (4 to 5 seconds out of several minutes). TiMachine won, RISCube (which was also doing video encoding at the time) was two seconds slower, and ARMX6 a further second or so after that. Essentially all within about a 2-3% margin.

This could be altered a bit by copying data to RAM disc which helped both ARMX6 and TiMachine, but not dramatically so.

The test was won, I'm afraid, by native x86 DataPower by a margin that would make a practical difference to the customer. He has gone for a RISCube setup where he can click to pass through his database from RISC OS to Win Datapower transparently, thus giving him the best of both worlds.

It is interesting, because it really says whatever you pick, you're going to get a great RISC OS experience.

Note that from what Aaron once told me, MacVA isn't as optimal as RISCube setup, so that may also affect things. I'm not a Mac person, so I can't speak from much experience. I'd assume the core emulation would be the same (as both systems use x86 CPUs and the ARM->x86 translation should be similar), but I don't know how many other layers are involved etc.

Regarding these "other layers", I experienced this the other day. Without going in to detail, I found "night and day" differences by altering various things and making adjustments to a VA system last week. Because I'm so used to building things my own way (where all of this is second nature), it was quite shocking how much worse "real world" vendor/DIY-system ran/felt.

Also, 16M colours at sensible res *should* be possible on VA, as I've used that myself. My "day-to-day" VRPC setup is 3440x1440 @ 32k (VRPC is optimised for 32k) running at a smooth 75hz. That needs more than 1920x1200 in 16M.

[Edited by arawnsley at 12:47, 8/12/2016]

[Edited by arawnsley at 12:52, 8/12/2016]
  ^[ Log in to reply ]
 
George Greenfield Message #123954, posted by Bucksboy at 17:30, 8/12/2016, in reply to message #123953
Member
Posts: 91
I'd imagine Datapower makes heavy use of floating point ops, in which case x86 systems (including VRPC) with access to hardware fp would have a considerable advantage? I ran RPCEmu on a reasonably quick (3.4GHz Core i7) Windows desktop for a couple of years and overall I would say my current RPi2 with SSD hard disk is a bit faster for most tasks. But we mustn't pre-empt Matthew! Roll on Pt. 2!
  ^[ Log in to reply ]
 
George Greenfield Message #123955, posted by Bucksboy at 17:31, 8/12/2016, in reply to message #123954
Member
Posts: 91
But we mustn't pre-empt Matthew! Roll on Pt. 2!
Wrong evangelist! Sorry Mark.
  ^[ Log in to reply ]
 
Andrew Rawnsley Message #123956, posted by arawnsley at 18:31, 8/12/2016, in reply to message #123954
R-Comp chap
Posts: 600
Don't think DP uses FP (certainly not on RISC OS) but the Windows results might be skewed by that - hard to say. It's just an interesting case of the same program being available for all test platforms. I've never seen VA benefit from FP (to my knowledge).

Note that I wouldn't (personally) set much stay in RPCemu as an example of a virtual RISC OS machine performance-wise. It may well have improved, but it was no substitute for my RISCube setup last time I tried it. My understanding is that it has improved quite significantly, but at the time (about 3 years ago, I think?), the difference was night and day.

For reference, my work setup is about two-thirds RISCube, and 1/3 ARMX6/TiMachine depending what I'm working on. I actually find it very hard to tell much practical difference between any of them, unless you stress test with something like OtterBrowser.

[Edited by arawnsley at 18:33, 8/12/2016]
  ^[ Log in to reply ]
 
Rob Kendrick Message #123957, posted by nunfetishist at 09:38, 9/12/2016, in reply to message #123956
nunfetishist
Today's phish is trout a la creme.

Posts: 525
Database operations are almost always IO-bound, and RISC OS's IO is pretty rubbish. Running on an emulator, you get the benefit of all the may layers of block caching and write-through buffers that the host OS (Linux, OSX or Windows) provides; from the software running on the emulator's point of view, the hard drive will appear to run at Ludicrous Speed.
  ^[ Log in to reply ]
 
George Greenfield Message #123958, posted by Bucksboy at 12:33, 9/12/2016, in reply to message #123957
Member
Posts: 91
... from the software running on the emulator's point of view, the hard drive will appear to run at Ludicrous Speed.
That's the upside of emulation: the downside is that the processor will seem deplorably slow (MIPS = 15-20% of the underlying h/ware clockspeed). You pays your money....
  ^[ Log in to reply ]
 
Rob Kendrick Message #123959, posted by nunfetishist at 16:04, 10/12/2016, in reply to message #123958
nunfetishist
Today's phish is trout a la creme.

Posts: 525
... from the software running on the emulator's point of view, the hard drive will appear to run at Ludicrous Speed.
That's the upside of emulation: the downside is that the processor will seem deplorably slow (MIPS = 15-20% of the underlying h/ware clockspeed). You pays your money....
Yes, but for many tasks the CPU is not the bottleneck; in these situations emulators absolutely smash the real hardware. And frankly, managing 15-20% of the host processor's clock speed is a marvellous achievement. Five host instructions to emulate a guest one? Fantastic effort by both RPCemu and VirtualRPC. (Ignoring statistical complexities like the JIT.)
  ^[ Log in to reply ]
 
George Greenfield Message #123960, posted by Bucksboy at 23:14, 10/12/2016, in reply to message #123959
Member
Posts: 91
Fantastic effort by both RPCemu and VirtualRPC.
Couldn't agree more. But it remains the case that, for example, the 12-image Thump slideshow taking 26 secs on the Pi2 requires 40 seconds under RPCEmu/RO5, and 55 seconds on RPCEmu/RO4.02*, and on a 20% smaller desktop into the bargain. But speculation is idle: Mark is about to give us the answers smile
(*RO5 runs about 30% faster under RPCEmu than 4.02, given the same setup)
  ^[ Log in to reply ]
 

The Icon Bar: News and features: Native versus emulation for running RISC OS in 2016 (Part 1)