Discussion about the ZBasic language including the System Library. If you're not sure where to post your message, do it here. However, do not make test posts here; that's the purpose of the Sandbox.
No comments on this? I thought it was rather cool.
I did find a couple of potential problems than need further investigation:
A period is printed for each task when it is created. There is a noticeable slowdown at around 1300/1400 tasks and then it speeds up again. I don't have the performance hooks yet to measure the time to create tasks, but they are easy enough to add.
The maximum number of tasks I was able to get running is just over 1700. However this doesn't quite match up with the amount of available memory on the device. For a ZX128e, the first 768 bytes are unavailable, and the main task needs a stack of 49 bytes. Each task needs 1 byte for the counter and 35 bytes for its task header and stack. That means for 64K of RAM the theoretical maximum number of tasks is (64 * 1024 - 768 - 49)/(35 + 1), which equals 1797 tasks for a ZX128e.
The first item may highlight a general problem with the performance of memory allocation.
The second item may highlight a problem with the both the documentation and the heap allocation implementation. Although I don't believe this is documented, my analysis leads me to believe that each allocated block of memory requires a two byte pointer. This means that 1700 tasks need 3400 bytes for heap pointers. This extra 3400 bytes is equivalent to 3400/36 = 94 tasks. I think this explains why the real limit is 1703 tasks and not 1797. There is a check in the code for a 0 return from System.Alloc but the error message is not printed and the device just seems to hang after the 1703rd task has been created. I haven't had an opportunity to try this yet but this can be proven by using a single large memory allocation block and then using a sub-block of 35 bytes at a time for each task.
Yes, and interesting as a learning and research tool.
mikep wrote:my analysis leads me to believe that each allocated block of memory requires a two byte pointer.
The additional two bytes for each allocation is used to store the size of the allocated block. This is needed when the block is freed. Another undocumented implementation detail is that the minimum allocation size is two bytes. This, together with the two-byte length field allows a deallocated block to be linked into a free list.
mikep wrote: the device just seems to hang after the 1703rd task has been created.
mikep wrote:A period is printed for each task when it is created. There is a noticeable slowdown at around 1300/1400 tasks and then it speeds up again. I don't have the performance hooks yet to measure the time to create tasks, but they are easy enough to add.
There is a definite slowdown that is worst at around task number 1360. This doesn't appear to equate to any specific memory boundary (i.e. system RAM to external RAM) so I'm stumped for an explanation right now.