[Oberon] ... MOD 65536
joerg.straube at iaeth.ch
Mon Apr 13 21:09:57 CEST 2020
Separate module or not, is not the key question. It does not help much.
As it is coded today (sort 5000 elements) Trees needs (worst case scenario) 160 kB heap space.
The Oberon system having only a total amount of 1MB offers ~420 kB heap space. So, it is impossible to run the algorithm 10 times.
The garbage collector freeing up unused heap space is programmed in module Oberon but it‘s not exported. So officially, you can’t run the GC while your program runs. The allocated and now unused memory is only collected AFTER the Hennessy terminates.
With a little bit of trickery you could program your own garbage collector that frees up all data structure Trees allocated with NEW after every call of Trees. But this is a little far fetched...
> Am 13.04.2020 um 20:36 schrieb Hans Klaver <hklaver at dds.nl>:
> Ah, now I see.
> So my current implementation of the Tree benchmark in Hennessy.Mod is not correct, and is 'cheating'.
> Maybe I should isolate the Tree benchmark as a separate module. This is also done in the C versions of the LLVM test-suite (for all benchmarks of the suite). And I suspect that the original Pascal versions of the Hennessy benchmarks also were separate programs, but I have never seen them.
>> Op 13 apr. 2020, om 20:15 heeft Joerg <joerg.straube at iaeth.ch> het volgende geschreven:
>> That „Trees“ seems to run faster is because I skip the execution if there is not enough memory.
>> In other words, although Time() calls every algorithm 10 times, Trees will in a lot of cases only run 2 or 3 times (of those 10 calls) depending on the amount of heap space left...
>>>> Am 13.04.2020 um 19:47 schrieb Hans Klaver <hklaver at dds.nl>:
>>> Hi Jörg,
>>> Just now I noticed that my reply to your modification of Hennessy.Trees (below) did not make it to the list (possibly because I included a few screenprints of run times).
>>> So now again:
>>> Thanks Jörg, this modification is great!
>>> Everything runs as it should now.
>>> Now also in Oberon System V5 Hennessy.Mod can be used with ...MOD 65536 (sic!) in procedure Rand.
>>> All reference output is as it should be.
>>> And as a nice side effect of your modification the treesort benchmark runs nearly three times as fast as before:
>>> Run times Hennessy Mm and Sort procedures in V5 (10 runs, ms):
>>> MOD Trees Intmm Mm Quick Bubble Tree
>>> 65535 original 983 998 900 2016 747
>>> 65536 original 984 1016 933 2017 --
>>> 65535 modified 966 1014 876 1954 647
>>> 65536 modified 970 1016 908 1971 *259*
>>> These are all benchmarks that make use of procedure Rand. As can be seen in most of them there is no noticable difference whether 65535 of 65536 is used in the MOD expression, but sometimes there can be a huge difference.
>>> This is an illustration that in benchmarks it is important to consistently use the same pseudo-random generator and initial seed.
>>> Hans Klaver
>>>> Op 10 apr. 2020, om 13:20 heeft Jörg <joerg.straube at iaeth.ch> het volgende geschreven:
>>>> I did the following:
>>>> PROCEDURE Trees* ();
>>>> VAR i : LONGINT;
>>>> IF Kernel.heapLim - Kernel.heapOrg - Kernel.allocated > 160000 THEN
>>>> (* here the rest of Trees *)
>>>> tree := NIL; Oberon.Collect(0) (* tell the GC to start after Hennessy terminated *)
>>>> END Trees;
>>>> With these modifications you can take whatever random number generator you wanna use.
>>>> DIV 65535 (wrong) or DIV 65536 (corresponds to the C original) or any other.
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon