[Oberon] ... MOD 65536

[Jörg]

Hans

 

Indeed, first I thought the culprit is the random number generator.

The treesort algorithm in the Hennessy benchmark uses two things that can go wrong:
First, it uses the recursive procedure Insert and Checktree.
Second, it allocates a node on the heap for the tree structure.
 

So, either the stack underflows (because of the recursion is too deep) or the heap overflows or both.

 

Let’s look at the stack: the recursion depth of Insert varies depending on the values generated by Rand(). I played a little with different start values of seed and found the recursion depth varies between 20 and 27. Nothing to be worried about. Stack underflow is not going to happen.

 

Let’s look at the heap: How many times CreateNode is called, depends on the values generated by Rand(). Generally a “node” uses 12 bytes, but the smallest allocation granularity on the heap is 32 bytes à every call to CreateNode needs 32 bytes on the heap.

 

With DIV 65535 in the random number generator, CreateNode is - by luck - only called 767 times = 24.5 kB. As Time() repeats Trees() 10 times, we’ll need overall 245 kB of heap space. Trees() terminates happily.

With DIV 65536, CreateNode is called 4999 times = 160 kB. After 2 iterations in Time(), the available heap is exhausted.

 

One remark, even if you use DIV 65535 you can’t call Hennessy.Do several times, as the garbage collector can not do it’s job. Reason for this is that “tree” is not set to NIL. If you want to improve Trees a little, put “tree := NIL” at the end of Trees(). But this does not help in case of DIV 65536.

 

br

Jörg

 

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Hans Klaver <hklaver at dds.nl>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Freitag, 10. April 2020 um 01:18
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] ... MOD 65536

 

Jörg, you wrote:

 

Just take the well-proven random generator.
Below I inserted my version in Oberon-07

 

Thanks for the suggestion.

 

The Lehmer-Schrage RN generator from the Reiser-Wirth book (with your prime number modification of the a constant!) has been in my Oberon-07 library for some time already (see https://github.com/hansklav/Oberon-07/blob/master/Random.Mod).

 

But in the case of the Hennessy benchmarks I would regard it as a form of 'cheating' to use another function than the one that is part of the benchmark, because the most pure comparisons are only possible if the same list of random numbers is used in each implementation, even if the random function is not perfect.

 

Now I suspect the crash of the Oberon System V5 described by me is caused by some external code used by Peter de Wachter's RISC emulator, because only now I noticed that the following error message is shown on the command line where I started the emulator: 

Assertion failed: (data && data_ptr < data_len), function clipboard_data_write, file src/sdl-clipboard.c, line 78.

Abort trap: 6

 

Maybe it is even specific to the macOS version of SDL2 (I use the RISC emulator under macOS).

I have never used the clipboard function of the RISC emulator.

 

Again: the OBNC Oberon-07 compiler has no problem with the Rand function as it should be, and OBNC also uses the SDL2 library for certain functionality, but probably not this particular function.

 

--

Hans Klaver

 

-- Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200410/76da2795/attachment.html>