RISC OS; Pros and Cons

[AMcS]

Keith Sloan wrote:

Not sure about the latest version of RISC OS, but I remember writing a test program that I ran on an Archimedes 410 way back that basically just did wimp_polls.

They introduced lazy task swapping that improved things, although I'd wager task swapping is still reasonably expensive...

Keith also wrote:

When RISC OS renders some text in a window, it goes to the Font system which may have to do I/O to disk.

On machines other than the Pi - most Fonts are in ROM (in Pi in SD) - Fonts yes can be fetched from HDD - but then are usually Cached - and given the luxurious amount of memory in the Pi you can crank up the FontCache to limit such accesses. On the occasions where such accesses occur not having a proper Multithreading in place possibly does hit performance (but as fonts files are relatively small not a particularly noticeable one).

KeithSloan Wrote:

Just look at the number of appends to RISC OS forum compared to Raspbian its about a tenth

Well if we're at that how many did Debian have ? How many had ArchLinux? Raspian is THE recommended distribution - of course it's going to have more appends - the surprising thing is that RISC OS has been closing in on Debian and Arch (it's now the 4th most popular if Appends are a valid measure at all...). For a laugh how is Android doing by that measure RISC OS has Google whipped !!!!

I'd tentatively say this having some form of Multithreading would be useful (task swapping a la Wimp_Poll does work - but perhaps it can be improved on). The biggest problem in not having MT is that it makes it more difficult for developers to port to RISC OS from other OSes (such as Linux). Given the number of developers working on RISC OS it would be helpful to "leverage" code from places such as Linux.

And I'd agree with you it's (very) unlikely to see RISC OS running on large servers - for security reasons as well as the more obvious fact that it is *NOT* intended as a server OS and never was. The flip side of that (though) is the Linux IS a server OS and squeezing it onto smaller devices (like Pi) does not, I would humbly suggest, show Linux off to best advantage.

There is a definite place for Linux and (I would suggest) one for RISC OS - the place may not be the same one - but hey there's nothing wrong with diversity is there ?

I have noted though the comments from people in other posts who have noted that RISC OS does seem more responsive than Raspbian - obviously *something* in RISC OS does lead it to give a more satisfying user experience and any changes made to RISC OS should not throw that particular "baby" out with the bathwater (all in my humble opinion - of course !)

[pygmy_giant]

I suspect that something is cooperative multi-tasking.

[jojopi]

have you ever attempted Linux to cooperate on more thatn 8 CPUs on a single system now there is a bottleneck.

Have you ever had a heavy load on a Linux system with X and wondered why it took more than 1 second to draw all of the pixals of a single charactor, because the font manager whas not getting enough CPU time?

It would probably be better to keep your Linux questions in a separate thread and outside of the RISC OS forum. But basically, a normal time-slice in Linux for a task that is not blocked is 1 to 10ms. That is long in comparison to the CPU time required to paint a single character. If you see a simple graphic operation interrupted enough times to be noticeable, your system is thrashing to disk, not short of CPU time. (Since RISC OS does not use virtual memory, this problem cannot occur.)

It is very common to run Linux on servers with more than eight cores. Although inter-process bottlenecks may be possible in some types of application, if you are not getting full CPU utilisation it is most common again to find that you are I/O limited.

[DavidS]

.It would probably be better to keep your Linux questions in a separate thread and outside of the RISC OS forum. But basically, a normal time-slice in Linux for a task that is not blocked is 1 to 10ms. That is long in comparison to the CPU time required to paint a single character. If you see a simple graphic operation interrupted enough times to be noticeable, your system is thrashing to disk, not short of CPU time. (Since RISC OS does not use virtual memory, this problem cannot occur.)

It is very common to run Linux on servers with more than eight cores. Although inter-process bottlenecks may be possible in some types of application, if you are not getting full CPU utilisation it is most common again to find that you are I/O limited.

I whas exagerating a little to get acrossed the point that many of us love RISC OS, and it will not be left behind by multiprossesing systems.

Just today I got my 64 CPU qubes OS far enough to run a couple of RISC OS full desktop Wimp tasks. Yes they were simple tasks, though if this is possible on a cooperative multitasking OS that is written from the ground up by one person to test a "Many Core" Concept system, and only uses the same API as RISC OS because its designer and implementor feels that RISC OS has a well thought out API, then how much more is possible with updating the real RISC OS to run multicore, and still be a purely cooperative multitasking system.

Since it was asked: There has yet to be any trouble with a bottle neck on the Qube with the OS on a single CPU as it is usually the only thing running on that CPU and the ammount of time actually spent communicating with the OS is minimal. There has yet to be a situation where any system call has been delayed in ariving to the OS by more than 20ns and the same for a responce delay from the OS.

[DavidS]

Well if we're at that how many did Debian have ? How many had ArchLinux? Raspian is THE recommended distribution - of course it's going to have more appends - the surprising thing is that RISC OS has been closing in on Debian and Arch (it's now the 4th most popular if Appends are a valid measure at all...). For a laugh how is Android doing by that measure RISC OS has Google whipped !!!!

Well heck then. Linux is just kernel, and the Linux kernel thread has almost zero activity . So By the same mesure I guess that RISC OS is way past Linux .

[KeithSloan]

Seems Firefox is too much for Raspberry Pi to handle on Raspbian. How about RISC OS. What are peoples experience of FireFox on RISC OS on Pi?

[KeithSloan]

Another observation on Pro's/Con's of RISC OS.

Is that commercial(?) applications like ArtWorks and some word processors are not cheap. Okay !Draw is free as is !DrawPlus and there are others, but with RISC OS you have to shell out cash to get a reasonable/good desktop environment.

With the Pi and Raspbian Inkscape and OpenOffice are all free but a bit heavy weight for the processor. Linux on x86 and such things are free and good performance.

[AMcS]

Another observation on Pro's/Con's of RISC OS.

Is that commercial(?) applications like ArtWorks and some word processors are not cheap. Okay !Draw is free as is !DrawPlus and there are others, but with RISC OS you have to shell out cash to get a reasonable/good desktop environment.

Agreed, but there sometimes are lower cost upgrade options - so someone returning to RISC OS might be able to avail of that. Anyway having to shell out is not because of RISC OS - shelling out is because programmers (I guess) have to eat

Besides it's not a specific CON of RISC OS, Windows also has it - and I would not be surprised even in the midst of all the free software that there are some paid for applications even on Linux (gasp).

With the Pi and Raspbian Inkscape and OpenOffice are all free but a bit heavy weight for the processor. Linux on x86 and such things are free and good performance.

Won't argue on that, but it still means that to get good performance on a RPi probably means going the RISC OS route and using things like !ArtWorks, Easy/TechWriter et al.

Also people aren't always motivated by cost alone - people with x86 hardware well capable of running OpenOffice STILL buy MS Office. It may be from fear of incompatibility, or the notion that having paid for it the software will be better supported, that if it's purchased (and popular) it must be good or maybe just something they can stick on their CV... who knows.

[Markodius]

Speed.. on the pro's.. I estimate that RiscOS interprets high level language 5 times faster than Raspbian both on the pi.

[KeithSloan]

Speed.. on the pro's.. I estimate that RiscOS interprets high level language 5 times faster than Raspbian both on the pi.

Based on what exactly? The processor is the same and I don't see why the operating system should be involved very much with interpreting high level languages. Are you claiming that BBC Basic is much faster than BASIC in Raspbian or Python is quicker on RISC OS ( Does python even exist on RISC OS ?)

[rurwin]

I certainly would not be surprised if BBC BASIC was faster than any other BASIC. Acorn continued to make it faster while I was active on the BBC Micro, so that BBC Master BASIC was faster than any previous version by a significant amount (a factor of 2 maybe more?). In the meantime Spectrum BASIC was slower than ZX81 BASIC by maybe the same margin, and they were far behind Acorn. If the BBC BASIC on RiscOS still has the Acorn legacy optimisations, then it is quite likely that it will be faster than most other implementations.

One significant optimisation is that it was and is parsed for keywords, and each keyword is replaced by a single byte. Judging by what comes out if you try to read a RiscOS BASIC file on a Linux box, the "compilation" may go deeper than that now.

I seem to remember that the quick and dirty (and hopelessly unrepresentative) PCW Benchmark 1: a 1 to 10,000 FOR loop, took around 45 seconds on a Spectrum and under 2 seconds on a BBC second processor running BBC Master BASIC. (PCW Benchmark 1 was never supposed to be a benchmark, it was only to set the base level for the other tests. It was, however, quick to type and easy to remember.)

[neilf]

BBC BASIC V can run blisteringly quick on the R-Pi because its entire interpreter fits in the ARM's primary cache. That's the advantage of a small footprint OS with much of it hand coded for speed and efficiency - remember BBC BASIC is effectively built in to the OS.

In certain applications, other BASICs and Pythons can't even get on the same page for speed - accessing GPIOs for example. That's the advantage of an in-line assembler and native access to machine level SWIs etc.

[KeithSloan]

I too would not be surprised that BBC BASIC is much faster, but that is down to BBC BASIC rather than RISC OS. I would also expect applications that use the RISC OS GUI to be faster than X Windows on Raspbian.

It was the claim that interpreted languages are faster as a result of running under RISC OS that I was questioning. Like I said before I don't think interpreted languages use the operating system intensively, so its more down to the their implementation rather than the operating system.

[polas]

It was the claim that interpreted languages are faster as a result of running under RISC OS that I was questioning. Like I said before I don't think interpreted languages use the operating system intensively, so its more down to the their implementation rather than the operating system.

Whilst obviously there will be calls to the OS, I think your point about the bottlenecks being mainly in the lexing, parsing, state storage and general execution are very true. Likewise I guess it also depends on what you do with the language. On a related note, whilst it is great to see people excited about ROS, there is quite a lot of nonsense posted on this thread, I wonder if this over enthusiasm might put some people off.

[AMcS]

One significant optimisation is that it was and is parsed for keywords, and each keyword is replaced by a single byte. Judging by what comes out if you try to read a RiscOS BASIC file on a Linux box, the "compilation" may go deeper than that now.

If I recall correctly tokens (in 6502 BBC BASIC) were simply values above &80 - values unlikely to appear as ASCII "text". ARM BBC BASIC V needed more keywords so there are a few (AFAIK) that include 2 byte values. Also line numbers in both are also tokenised.

I take your point about compilation (it being in inverted commas that is) as BBC BASIC is still an interpreter - but the preprocessing of the line into something more amenable to interpretation and the fact that the language is written completely in ARM Assembly code does make it nippy alright.

[AMcS]

It was the claim that interpreted languages are faster as a result of running under RISC OS that I was questioning. Like I said before I don't think interpreted languages use the operating system intensively, so its more down to the their implementation rather than the operating system.

I'd agree with that, an interpreted language will try to avoid using system calls where possible as these are relatively expensive, so the influence of the OS on the performance of the interpreter directly is likely to be limited.

However, that having been said, the interpreter doesn't operate in isolation - in a multitasking environment if the OS is more efficient then the perceived performance of the interpreter (in running application programs) might be improved (as more time is spent executing these rather than task swapping or performing other background "housekeeping" activities).

[Markodius]

Speed.. on the pro's.. I estimate that RiscOS interprets high level language 5 times faster than Raspbian both on the pi.

Based on what exactly? The processor is the same and I don't see why the operating system should be involved very much with interpreting high level languages. Are you claiming that BBC Basic is much faster than BASIC in Raspbian or Python is quicker on RISC OS ( Does python even exist on RISC OS ?)

Be empirical - measure it! It is not a difficult task. I compared BBC Basic to Python. For the same value of output running at stock processor speed Python returned approx 65k revolutions to BBC Basic's 360k. 1/2 an order of magnitude in the hands of a journeyman programmer!

[rurwin]

I'm not particularly surprised; Python is rather more general-purpose even in its handling of numerics than BASIC, but you did code the Python to not do the compilation as well in the measured time, didn't you?

[KeithSloan]

Marcodius : I compared BBC Basic to Python

Apples to Oranges - then

[polas]

For the same value of output running at stock processor speed Python returned approx 65k revolutions to BBC Basic's 360k.

Is this a proper benchmark you ran or just some code knocked together? It would be interesting to compare the run times of BBC Basic code and some other language running under RISC OS (I think Python 2.4.x is available for ROS?) to help understand if the OS has anything to do with it or if the interpreter is just optimised.

[pygmy_giant]

I believe an Python run under older versions of RISC OS on other architectures and has yet to be ported to the Pi.

I understand however that Lua and Smalltalk/squeak are running.

[-rst-]

Would this be good enough (micro) benchmark http://www.raspberrypi.org/phpBB3/viewt ... 81&t=25418 ? There's a Python version...

[Markodius]

Marcodius : I compared BBC Basic to Python

Apples to Oranges - then

How are two BASIC's apples and oranges? No, Cox's and Pippins (they are both apples) possibly. The comparison is valid for those considering developing in Python under Raspbian vs BBC Basic under RiscOS.

[Markodius]

For the same value of output running at stock processor speed Python returned approx 65k revolutions to BBC Basic's 360k.

Is this a proper benchmark you ran or just some code knocked together? It would be interesting to compare the run times of BBC Basic code and some other language running under RISC OS (I think Python 2.4.x is available for ROS?) to help understand if the OS has anything to do with it or if the interpreter is just optimised.

[makes tutting sound..] Returned a value for every second elapsed. To what 'proper benchmarks' do you refer?

[dboddie]

See this thread on the RISC OS Open site for information about a recent version of Python. I've no idea if it works on the Pi.