User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Sat Jul 13, 2019 4:10 pm

Heater wrote:
Sat Jul 13, 2019 2:07 pm
Exactly.

It's not just "perceived" throughput. Caches are there such that work can be pipe lined, done in parallel, and increase throughput. Data can be prepared for writing at the same time the previously processed data is on it's way to the media. And vice versa.

If networking is excluded, and file system I/IO, and graphics, and multi-tasking apparently, what is left to compare?
I only want to test what can be imperically tested. YES WE WANT FILE STREAM IO, and graphics, etc. So what are you talking about.

Again just bashing without offering any suggestions at all?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Sat Jul 13, 2019 4:13 pm

Heater wrote:If you disable optimizations, like caching, you are likely to end up measuring the speed of your storage media rather than the files system software of your operating system.
Did you read any of what was posted?

That is the reason I suggested using a RAM disk on both targets, so that we are not comparing the storage media, though using somehting identical, and fast enough not to have a notable effect on the results.

File I/O is not complete until it is written out, or freshened on read in.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4675
Joined: Wed Feb 04, 2015 6:38 pm

Re: OS Features, responce.

Sat Jul 13, 2019 4:38 pm

DavidS wrote:
Sat Jul 13, 2019 4:13 pm
That is the reason I suggested using a RAM disk on both targets, so that we are not comparing the storage media, though using something identical, and fast enough not to have a notable effect on the results.
That's an interesting idea. Linux uses different file systems for ram disks by the way.
(tmpfs for virtual memory is the most common, or ramfs which is rarely used).
RAM disks as such are not popular because the memory is allocated all at once and is unavailable to the rest of the system. A 500MB RAM disk takes 500MB of memory even if there is only a couple of small files on it. Not good!
TMPFS disks on the other hand reside in virtual memory which means that 1) they only use enough memory to hold the files and 2) if the system runs low on memory, the memory used by the TMPFS disk may be paged out.

My choice for the test would be two identical SD cards. Brand new and from the same batch if possible.

Freshly install each OS on each SD card. No tweaking, tuning, nothing. Just a simple, typical, install.

Write a test program to create some files, copy a few small files around and a very large file, do some random access and updates, finally delete the files. The program should obviously be portable.

Reboot the machine and time the program.

Rebooting ensures that nothing is in the cache (running the program twice would yield different results - which might in themselves be interesting).
Last edited by jahboater on Sat Jul 13, 2019 4:50 pm, edited 1 time in total.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Sat Jul 13, 2019 4:49 pm

@jahboater:
Interesting concept on how to do the testing for file I/O. Though I thought that Linux had the ability to specify what FS when mounting a RAM-Disk.

Also it seems a bit expensive of a move to have to purchase two SD Cards when they may not otherwise be needed for every person that wishes to do such testing.

Of course another interesting point is that the FS itself is going to play a role (the on disk structure that is).

The use of a reboot to clear the cache is a good idea for the read tests. Does not help with the write tests, where the actual write may not happen for a very long time after the program is done running.

On the issue of portable:
While I agree that there should be as little difference between the two as possible, I feel it best to test the OS, not the C libraries, as the C libraries may have more overhead than the OS in some situations.

Just my view.

Thank you very much for the input.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4675
Joined: Wed Feb 04, 2015 6:38 pm

Re: OS Features, responce.

Sat Jul 13, 2019 5:05 pm

DavidS wrote:
Sat Jul 13, 2019 4:49 pm
While I agree that there should be as little difference between the two as possible, I feel it best to test the OS, not the C libraries, as the C libraries may have more overhead than the OS in some situations.
Yes, OK.
It would be fairly easy to make the system calls in assembler and avoid libc completely. I can do that for C on Linux with inline assembler, but I don't know how to on RISC-OS. The program can be timed with an external command ("time" on Linux) so that no timing calls are needed in the program.

I can only speak for Linux, but I think the basic file access functions such as open(), seek(), read(), write(), and close() are simply wrappers around the system call instruction (SWI or SVC). Because registers for the library call ABI and the system calls are the same (or very similar) little needs to be done by the library wrapper. It will assign the call number to R7 and do the call. Afterwards R0 gets the result which is -errno if it failed.
So no more than a few instructions I would hope.
Last edited by jahboater on Sat Jul 13, 2019 5:14 pm, edited 3 times in total.

jahboater
Posts: 4675
Joined: Wed Feb 04, 2015 6:38 pm

Re: OS Features, responce.

Sat Jul 13, 2019 5:09 pm

DavidS wrote:
Sat Jul 13, 2019 4:49 pm
Though I thought that Linux had the ability to specify what FS when mounting a RAM-Disk.
You may well be right, its just that I don't know how to do it, because I have never needed to (tmpfs works really well). I hope it doesn't require overlayfs or some such.

FYI, I just add:

tmpfs /tmp tmpfs defaults,noatime,nosuid 0 0
tmpfs /var/log tmpfs defaults,noatime,nosuid,size=16m 0 0

to /etc/fstab on all my Pi's which sets the "tmp" directory and the "log" directory to tmpfs disks to save wear on my SD card.
It seems to do it all in one go.

ejolson
Posts: 3548
Joined: Tue Mar 18, 2014 11:47 am

Re: OS Features, responce.

Sat Jul 13, 2019 5:38 pm

DavidS wrote:
Sat Jul 13, 2019 4:13 pm
Heater wrote:If you disable optimizations, like caching, you are likely to end up measuring the speed of your storage media rather than the files system software of your operating system.
Did you read any of what was posted?

That is the reason I suggested using a RAM disk on both targets, so that we are not comparing the storage media, though using somehting identical, and fast enough not to have a notable effect on the results.

File I/O is not complete until it is written out, or freshened on read in.
From the program's point of view, file output is finished as soon as the function returns. On Linux this usually happens immediately.

From the operating-system point of view, file output is finished after the data has been sent to the hardware RAID controller.

From the RAID controller's point of view, file output is finished after the data has been sent to the disks.

From the disk's point of view, the data is saved after the buffers have been written to the platter. If an SSD, then wear leveling may cause other data to temporarily be unsaved and hopefully saved again to other parts of the flash memory.

From the system administrator's point of view, the data is not saved until the disks are dumped to tape.

From the chief information officer's point of view, the data isn't saved until the truck has deposited the tapes off site.

From the user's point of view the data is never safe. However the user can sometimes opt to be notified, for example, when the data has successfully been written to tape.

For graphics many people like SDL on Linux.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Sat Jul 13, 2019 7:38 pm

@ejolson:
Thank you for that.

You skipped From the Software Engineers point of view the data is not saved until it has been printed to hard copy in triplicate and two copies stored in sepperate off site locations. :) This is a habbit that I still maintain, even for personal projectes.

Though once it has been written out to the local starage media, and is safe from power failure, the OS no longer has anything to do with it.

On SDL:
Well we have that as well. The question then becomes if using a cross-platform library that was first popular on MS/PC-DOS is a fair comparison of the OS's. I am definitely open to input on if it is a fair comparison of the OS's.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4675
Joined: Wed Feb 04, 2015 6:38 pm

Re: OS Features, responce.

Sun Jul 14, 2019 7:09 am

DavidS,

You were concerned about the overheads of the C library and if it should be excluded by making direct SWI/SVC calls instead, so that only the OS is tested.

Well for interest I did a quick instruction count comparison on Linux:

Code: Select all

#if 1
  int rc = SYS_write;
  asm( "syscall" : "+a" (rc) : "D" (1), "S" ("Hello, world\n"), "d" (13) );
  if( rc < 0 )
    errno = -rc;
#else
  write( 1, "Hello, world\n", 13 );
#endif
The library version of write() executes just two instructions more than the assembler version (probably the call and the ret).
I bet its much the same on RISC-OS - these calls get heavily optimized.

So portable library calls for open(), read(), write(), lseek(), and close() might as well be used in the test program.

User avatar
PeterO
Posts: 5004
Joined: Sun Jul 22, 2012 4:14 pm

Re: OS Features, responce.

Sun Jul 14, 2019 7:58 am

The fundamental problem with this whole thing is the belief that more speed is the only thing that leads to increased usability or usefulness.
PeterO
Last edited by PeterO on Sun Jul 14, 2019 7:43 pm, edited 1 time in total.
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Sun Jul 14, 2019 7:24 pm

PeterO wrote:
Sun Jul 14, 2019 7:58 am
The fundamental problem with this whole thing is the belief that more speed equates is the only thing that leads to increased usability or usefulness.
PeterO
I hope that people do not see it that way. That is far from the case for many applications.

People writing or porting applicans, modules, libraries, etc, as well as people keeping code small on memory and storage usage, and using a minimal of CPU cycles for the task at hand, is what creates increased usability. That has nothing to do with any feature of the OS, or its speed.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13281
Joined: Tue Jul 17, 2012 3:02 pm

Re: OS Features, responce.

Sun Jul 14, 2019 7:57 pm

Yes but don't wiggle.

The topic here is RISC OS vs Linux. See first post.

One is usable. The other is not.

Small, efficient code is always welcome. But above all it has to at least work first.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Mon Jul 15, 2019 3:05 am

Heater wrote:
Sun Jul 14, 2019 7:57 pm
Yes but don't wiggle.

The topic here is RISC OS vs Linux. See first post.

One is usable. The other is not.

Small, efficient code is always welcome. But above all it has to at least work first.
Define usable.
And usable for what?

They are both OS's, they both provide comparable services for applications and libraries.

What applications and libraries one whishes to use is a very subjective topic.

Obviously both are usable. There are things on each side for which the applications just are not present. So depending on what a person wishes to do they may need to port or write an application that is not yet there for either one. Or for those that do not wish to write applciations or port them they may consider either one unusable for there needs, depending on what they wish to do.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13281
Joined: Tue Jul 17, 2012 3:02 pm

Re: OS Features, responce.

Mon Jul 15, 2019 4:59 am

DavidS,
Define usable.
That is what we want to know from you.

So far, despite, your assertions above, none of the suggestion made re: a RISC OS vs <any other OS> comparison have been workable for you.

So what is?
And usable for what?
Concretely, today I want to tinker with adding a simple physics engine to this: https://otaniemi.conveqs.fi:3000/public/jatkasaari.html

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Mon Jul 15, 2019 1:41 pm

Heater wrote:
Mon Jul 15, 2019 4:59 am
DavidS,
Define usable.
That is what we want to know from you.

So far, despite, your assertions above, none of the suggestion made re: a RISC OS vs <any other OS> comparison have been workable for you.
Hold your horses. You are making a huge assumption:
You are assuming that more than 3 suggestions have been made, and that I am not considering the suggestions. Both assumptions would be wrong.

I am looking at what is suggested. I am being reasonable about it (to the point of even including your rediculous network speed in the current list of things).

Yes I ask counter questions, how are we supposed to come to an agreement if I do not?

So it is a case of an attempted thread killer by you?
So what is?
And usable for what?
Concretely, today I want to tinker with adding a simple physics engine to this: https://otaniemi.conveqs.fi:3000/public/jatkasaari.html
Well that is something for a web browser that has good JS Support (nothing to do with the OS at all).

Why do you love mentioning applications when talking about OS's, they are seperate things.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13281
Joined: Tue Jul 17, 2012 3:02 pm

Re: OS Features, responce.

Mon Jul 15, 2019 2:49 pm

DavidS,
You are assuming that more than 3 suggestions have been made, and that I am not considering the suggestions. Both assumptions would be wrong.
Nope. Many suggestions have been bandied about.
I am looking at what is suggested. I am being reasonable about it (to the point of even including your rediculous network speed in the current list of things).
I' pretty sure most of the worlds computer programmers and users would scratch their heads in disbelief at your suggestion that a desire for networking performance is ridiculous.
So it is a case of an attempted thread killer by you?
Nope.
Well that is something for a web browser that has good JS Support (nothing to do with the OS at all).
It cannot have escaped your notice that most web browsers, probably all of them, run on operating systems. Good support for web browsers in a desk top operating system is essential now a days.
Why do you love mentioning applications when talking about OS's, they are seperate things.
They are indeed separate things. But again, it cannot have escaped your notice that the whole purpose of operating systems is to run applications. If they can't do that what is the point?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: OS Features, responce.

Mon Jul 15, 2019 5:27 pm

Heater wrote:It cannot have escaped your notice that most web browsers, probably all of them, run on operating systems. Good support for web browsers in a desk top operating system is essential now a days.
And there is nothing stopping anyone from porting them to any OS if that is what they want.

Believe it or not, they are Applications, and the OS does not really matter as long as it provides a few specific features (which most current OS's do including Amiga OS, RISC OS, Linux, AROS, OS/2 4+, etc, etc). Yes I intentionally mentioned two older OS's so as to show the point even sharper.

The OS has nothing to do with specifically supporting them.
They are indeed separate things. But again, it cannot have escaped your notice that the whole purpose of operating systems is to run applications. If they can't do that what is the point?
I agree with that statement. And guess what; Both RISC OS and Linux are pretty good at running applications.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13281
Joined: Tue Jul 17, 2012 3:02 pm

Re: OS Features, responce.

Mon Jul 15, 2019 5:47 pm

DavidS,
And there is nothing stopping anyone from porting them to any OS if that is what they want.
Yes. Realisticly though, if an application requires, preemptive scheduling, task/process isolation, accerated 3D drivers, whatever, and the OS does not support them then it is going to be very hard/impossible to port it to that OS.

Given the difficulty of getting a simple BASIC program running on RISC OS the task of porting something as big as Chrome or Firefox and many others is not feasible.
Believe it or not, they are Applications, and the OS does not really matter as long as it provides a few specific features (which most current OS's do including Amiga OS, RISC OS, Linux, AROS, OS/2 4+, etc, etc). Yes I intentionally mentioned two older OS's so as to show the point even sharper.
I believe it. But see above.
The OS has nothing to do with specifically supporting them.
It certainly does, see above.
...guess what; Both RISC OS and Linux are pretty good at running applications.
Very true. As is CP/M. Problem is they don't run things people want to run today.

No problem with that, if the thing runs apps you want to run.

Return to “Off topic discussion”