[Oberon] Python vs oberon: requirements to store 1 byte in memory

[thutt at harp-project.com]

oberon-eth at email.cz writes:

 >    In a programming language python following code:
 >    sys.getsizeof('a') outputs 50 bytes of memory required for one
 >    character (!) while in oberon, procedures SIZEOF(CHAR) or
 >    Strings.Length("1") both give only 1 byte (as expected).  Note
 >    the ratio 50:1.  Imagine you would consume in your programm 1G
 >    of memory and it will all of sudden turn into 50G!


 >    My question: is the ratio so huge because python is an
 >    interpreter language and the python function reports some data
 >    required for an interpreter to run or is it just so big because
 >    of lack of an efficient python language implementation?
 >

I can't speak to the internals of the Python interpreter, but the
internal representation of Python data is probably going to ahve more
overhead because it's an interpreted language.  For example, the
string (or character) 'a' is not just going be 'a' in memory.  It's
going to have additional administrative overhead attached -- much like
runtime descriptors in Oberon.

 >    On the other hand, does oberon really report correctly all the
 >    data associated with CHAR type?  Isn't there any hidden memory
 >    being consumed without being reported by this oberon function?

Oberon will report the size of the data correctly, with caveats.

If you use 'SIZE', that will always be a compile-time constant value.
it will be directly associated with the compile-time size of the data
type.

If you use LEN() on an array to retrieve the number of elements, there
can be a runtime aspect.  If you take the length of a dynamically
allocated, or open array, the compiler will generate code to extract
the length from the associated array descriptor.

Finally, the size of the data stored in the heap may not be equivalent
to the block of memory holding it.  The minimum block size in my
Oberon system is 16 bytes, and heap-allocated blocks must be a
multiple of 16 bytes.

If you have:

   Point = POINTER TO RECORD
      x, y : SHORTINT;
   END;

The SIZE() of the record will be 2, but the amount of memory used in
the heap will be at least 16.  This additional heap overhead is not
reported.



 >    Python reports size including overhead caused by garbage collector.
 >
 >    Is this the same case in oberon? Surely not, so what is the memory size
 >    required for oberon garbage collector to handle one CHAR?

In Oberon, the type descriptors created by the compiler (which are
used for, among other things, garbage collection) are not reported or
accessible through the language.


--
Pickled beets.  Pickled beaks.  What's the difference?