You can test recursion and see how deep the recursion function call stack can go in different memory management architecture of those systems. I must note that this will mostly depend on the kernel and it's modules and not on the particular distribution. So you can basically test any one BSD and any one Linux kernel based operating system.

You can also test floating point operations. These will most probably be very close because both BSD systems and Linux based systems use GNU software packages which are almost the same in terms of implementation, but give it a go. Test particle simulation scenarios or post impact dispersion with particle interaction simulation. There are some nice libraries for this and you can set up simulations of almost any level of complexity (to target a particular execution length, just so that you don't wait forever between results).

You can test each system's graphical processing to do some 3D simulations (maybe shadow and reflection?) and see how high the FPS can be reached with using just the CPU and not to rely on the GPU at all. This is pure brute-force maltreating of the CPU that can be a good way to test the limits of the system running it. Any demanding physics test visualisation is a good choice.

You can also test the memory management, especially by "overusing" the cache mechanism, for working with prime number search. This is a good test because it can see how the memory behaves with very frequent lookups for already identified primes and number factors as the collection grows.

If you want to test the limits of both BSD and Linux kernel implementations of systems, you can make them undergo torture tests (stress tests), particularly in term of memory allocation and see how long they can survive. Normally, you would test the end of their usefulness in these conditions by them failing to keep a simple non-demanding process alive any more. The program should occasionally declare new variables in memory after some random time and repeat the loop. When that processes (program) crashes, the system has effectively become unusable because processes are becoming more and more unstable.

I can think of more tests that you can implement in any language (doesn't have to be R). If you require more examples, pass a note.

Excellent Milan. I take some ideas of your detailed answer. In this sense what do you think of a test such as:

dd if=/dev/urandom of=/dev/null bs=32k count=1000

Is this representative of cache memory or not?

Do you know an usable test with dd command or similar that can be easily implemented in BSD and Linux?

The dd command uses a simple method of parallel data transfer. It copies, in this case that you have written, 32KB of data from the input file (/dev/urandom) and than copies it to the output file (/dev/null) a total of 1000 times.

This is actually not a good test, first because of the uneven rate of acquisition of random values from the (slow) pseudo-random generator at /dev/urandom. Secondly, you are always using two full width buffers of 32KB each that will be initially allocated by the dd program and than used in an odd/even count while copying.

Initially, buffer 1 (32KB) is filled out with 32KB of data from /dev/urandom. Than, when it is full, the program will, in one thread start copying data from it (buffer 1) to the destination (/dev/null) while, in parallel, buffer 2 will be filled out with new 32KB of data from the input. When the copying to the output is done and the buffer 2 is full, the program will now start copying data from buffer 2 to the output while buffer 1 is being filled out with new data from the input. And the process is repeated until the count reaches the set 1000 or until the source or destination files cause the program to throw a read or write error.

This means that there is no dynamic cache checking. A total of 2x32KB is initially allocated and is being read from and to in an orderly fashion. This is the main reason why dd is very precise and predictable in terms of the completion time (unless a different factor causes the source or destination to change speed).

Also, aside from the fact that the /dev/urandom is variable in the tempo of pseudo-random data generation, the /dev/null is (in some versions of the GNU software that handles this virtual file) written so that it simply ignores the data written to it, while other implementations do something with the data, but ultimately end up ignoring it. This does not just depend on the kernel, but also on the version of the kernel and on the version of GNU software around the kernel (be it Linux or BSD).

You can use dd with real, physical disks, and not virtual files to test the disk speed. But, this is not really a good example for testing the system or the system's implementation.

Ok thanks. Then is it possible to use this command as a cache memory speed test?

sysbench --test=memory --memory-block-size=1M --memory-total-size=4G run

This utility is in OpenBSD and Linux between others...

If this command is not useful for this test what do you propose for testing cache memory speed?. Must be a command present both in BSD as Linux. 

Thanks again by your assistance. I am ecologists not expert in computers ;-) but for me is it very relevant to optimize my machines...

SysBench allocates a buffer and in a loop it reads or writes it a random or sequential manner. Regardless of the manner (random of sequential) it is still a pre-allocated memory segment, so it does not really employ any method of caching data.

You still need a permanent storage source, like you could have had with dd, but were not using it with files.

The problem with these tests is that it does not use files. Caching can only be done when you have two locations (a source and a destination) in the read-write process that operate at different speeds, like when one is RAM and the other is a hard drive.

A buffer represents a segment of RAM which is allocated in order to store a certain portion of some data. Cache is similar to a Buffer. However, it differs in this that it is used to "cache" a "page" of data from a file (i.e. on disk).

In your dd example above, you were using /dev/urandom and /dev/null. These are not really "files" on the disk, so there was no caching. They are operated by an algorithm or a function in memory, so there is never any hard drive usage there. It is all virtual and in RAM.

In your second example here, with sysbench, you also use only the RAM.

Both of these utilise only a buffering mechanism. You should make at least one part (if or of in case of dd) a file on disk.

If you have a USB Flash drive or an hard disk sitting around being useless and put it into your PC. BSD and GNU/Linux systems will give it a /dev/* name, for example /dev/sdc.

I will assume that you have a 4GB USB flash drive.

Partition it in two partition and first, prepare the first partition with a lot of random data. Instead of the slow /dev/urandom use this:

time openssl rand 2147483648 | head -c 2147483648 > /dev/sdc1

This will put exactly 2GB of random data into the first partition of the USB drive. It will be useless for browsing because there will be no file-system on it, just plain data.

Than, zero out the entire second partition before the test (not really necessary, but to be precise):

dd if=/dev/zero of=/dev/sdc2 bs=64K count=32768

This will zero out the entire 2GB of the second partition.

Than, you can test the "hard disk's cache" as well as the cache implementation in dd by running:

• dd if=/dev/sdc1 of=/dev/sdc2 bs=8M count=256
• dd if=/dev/sdc1 of=/dev/sdc2 bs=4M count=512
• dd if=/dev/sdc1 of=/dev/sdc2 bs=2M count=1024
• dd if=/dev/sdc1 of=/dev/sdc2 bs=1M count=2048
• ...

This is to test dd with different buffer sizes (which act as cache blocks when working with disk-RAM-disk copying) as I've explained before).

Normally, you would like to select a buffer size that is larger than the size of the cache of your hard disk. You can find the cache size on your hard disk specifications.

Also, take a look at this web page: http://www.linuxatemyram.com/play.html

Really great. Thanks a lot... I will follow your excellent explanations...

You are very welcome. This is an interesting topic. It is worth exploring.

I would like it if you would share your results (if possible) at some point when you finish analysing your test result data.

Of course. Thanks again

@Peter: Yes, you are right. The operating system/kernel does not handle the depth of the recursion call return stacks. I explained it very poorly, at second glance at my answer. I was referring to the default per process memory configured to be allocated at spawning. Of course, this also depends on the language. Interpreted languages, such as Python can have this set at run-time in their configurations because the Python shell will fork a process with different parameters for each program that it will be interpreting and that program might be doing recursive calls. However, this still does not represent "cache", as I have already explained to Mr Patón above.

Some results from a laptop HP 250 (i3 4GB RAM):

1) Testing using two partitions in an USB (average of the four bs/count)

Debian Linux 8.6 (4.8.7 compiled): 5.07 MB/s

Slackware Linux 14.2 (4.4.14 generic): 4.62 MB/s

OpenBSD 6.0: 0.32 MB/s

FreeBSD 11.0: 4.26 MB/s

DragonFlyBSD 4.6.1: 4.29 MB/s

An expert in computers of my University comment that this test is not too much useful due to the slow speed of the USB device ¿?

2) I have combined some ideas proposed here but I used dd again (I am sorry) inspired in this web page:

https://ianix.com/pub/comparing-dev-random-speed-linux-bsd.html

Particularly I have tested dd with the bs/count combination and I have calculated the average of the four trials. These are the results:

OpenBSD 6.0: 236 MB/s

FreeBSD 11.0: 113 MB/s

DragonFlyBSD 4.6.1: 187 MB/s

Slackware 14.2 (generic 4.4.14): 16.7 MB/s

Debian Linux (generic 3.16.0): 13.3 MB/s

Debian Linux (compiled 4.8.7): 259.3 MB/s

NetBSD 7.0.2: work in progress..... ;-)

I conclude that CPU performance in generic BSDs in higher BUT I CAN OBTAIN SIMILAR RESULTS in Debian GNU Linux ONLY if I compile the kernel.

Also, for a Desktop probably OpenBSD is not useful for me due to I need certain applications and Linux compatibility have been lost. The practical question for me is: Can I obtain even much better results compiling kernel in FreeBSD or DragonFlyBSD or only a little more than in Debian Linux?. If the difference is very high I migrate my 20 computers to BSD. If not, too much work for small results. "To be or not to be. That's the question"

Many thanks for your useful comments...

Ufff more important that the Science is the personal attitude of the scientists. You need increase your efficiency in this... a lot... I am sorry but terms such as rubbish are not scientific. Do you refer to organic rubbish or your problems of control of aggressive behaviour? Probably you don't understand that I do not work in computer science. I simply study Numerical Ecology and I use computers for data analysis. This is not an experiment for any paper. Also, results are averages of four trials in one computer. For me is enough as indicator. My intention is simply: give me some patterns to take decisions on which OS I need. The response was answered with some useful indications. Thanks to both. However, it seem as if you objective  was demonstrate your knowledge and not give useful and didactic indications. This have a name: intellectual pride, a serious defect of personality... I am sorry very much by you... I do not try disturb you but you have a serious problem. The knowledge and the intelligence without a correct attitude is less useful (Confucio...). Care with this... Good luck with the digestion of this message.

Signed: a ex-MENSA member (ex... precisely by colleagues with your type of profile)

@Daniel: In terms of effective testing, if you with to be certain of your results, what Peter is suggesting is pretty reasonable, although I too feel that the style in which it is all written is a bit uncomfortable, but it is true about the methods.

However, I do understand that you are not doing this as a scientific research problem what you plan to formally report in a form of a scientific study report/paper.

Since you only wish to see how a certain "out of the box" operating system will behave, maybe testing "cache" as a specific target isn't really necessary.

You've said that you want to identify which system will give you the best results at it, but I suspect that you've originally developed this idea to choose the best OS solution to run the software for your work (analysis etc).

Maybe (I am just suggesting), you should not target a specific programming optimisation technique, such as the use of cache and buffers, but instead just test the entire software that you are using for a different set of scenarios and a variety of data that you might encounter in your work and see on which OS your software gives the best results.

Personally, I do not think that you will be manually compiling and configuring each aspect of the OS just so that the software that you are using will gain a small edge in performance. You will probably stick with the out of the box installation of the selected distribution (be it one built around a Linux or BSD kernel).

Therefore, if you wish to do a proper test, what Peter is suggesting is a reasonable method and concerns such as specific issues with different drivers, settings, additional processes choking the CPU etc. will probably have to be cancelled out for the results to be dependant as much as possible on the kernel itself, when all other factors are minimised.

https://romanrm.net/dd-benchmark