Default RAM size in UNIX build

[ha5di]

Default RAM size for UNIX build is 128k which is too low, in a UNIX system you have much more available and in practice you run out of memory frequently working with dictionaries, lists.

Advice to set default value to few megabytes, like 4M.

[dhylands]

You can use:

micropython -X heapsize=1m

to get a 1Mb heap. The default heap was set to match stmhal so that similar scripts would have similar memory usages.

I would imagine that adding a MICROPY_DEFAULT_HEAP_SIZE option which defaulted to 128K but which could be overriden at build time would be acceptable.

[ha5di]

Hi Dave,

thanks for the help. I didn't aware of -X option. I will rebuild it with increased heap size, just wanted to feedback my experience on LINUX.

Béla

[dpgeorge]

I also hit the 128k limit quite often on unix. I'd be open to increasing the default to around 1M.

[pfalcon]

To remind, unix version's heap set to 128K on 32-bit systems (double that on 64-bit) to be close to stmhal version, with the premise that one of the expected uses of unix version would be debugging "embedded" applications.

Now that that unix version offer much more complete environment, with good subset of stdlib, package manager, I guess it indeed makes sense to increase default heap size. Also, probably mention heap size issue in the README if people miss to run micropython --help.

[dpgeorge]

Ok, 1m or 2m or 4m or? Sometimes I use 10m to be safe when running some code for a while, but usually 1-2m is enough.

Happy to mention heapsize option in README.

[pfalcon]

Let's stay conservative and use 1MB (32bit) - we know that larger heaps may hurt performance. Actually, would be nice to test pystone first ;-).

[pfalcon]

Well, I don't see any noticeable degradation with micropython -X heapsize=1wM -m pystone.

[dpgeorge]

Ok, 1wm sounds good.

[pfalcon]

I'm on it.

[pfalcon]

Added in aa65e1e , 5ab0a4a .

[ha5di]

Looks good, now my scripts runs fine without -X heapsize=...

However on a LINUX system 1m seems to be low. I would vote for 4-8m. But we will see.

Thanks

[pfalcon]

@ha5di : Feel free to implement #1168 , and there will be all memory available.

Otherwise, the ideas behind MicroPython is to prove that it's possible to write resource-efficient apps in Python, and teach people how to do that. And making sure people are aware that resources are finite is first step to that ;-). Of course, specific figures may vary over time, and we can revisit it in half a year. Good argument for adjusting would be "many people use unix version of uPy now" (hint-hint, spread the word ;-) ).

[ha5di]

I'm spreading it. Added MicroPython to the new piCore-7.0 Linux base. It is a unique system with only a few megs base system, applications are in squashed read only files loop mounted and symlinked at startup. I rewrote the startup extension mounter in MicroPython (original is ash). Now it takes 50% of the time only, and it is single threaded. Will test a multithread version.

Adding MicroPython to the minimalistic core and rewriting crutial shell scripts significantly boosts performance where no room for a full blown Python.

bmarkus

[pfalcon]

I'm spreading it. Added MicroPython to the new piCore-7.0 Linux base

Great! If you have any links (code/docs/discussion), please share them, I'd like to take a peek when I have a time.

So, if you face any issues 1MB heap, please report it, and we'll bump it. Just understanding when it happens will allow to make better decisions on default heap size. Because otherwise any figure is arbitrary - I for example had to run uPy with hundreds of megs heap. But garbage collection takes seconds on such heap sizes, so setting heap higher than needed will affect all apps even those which don't need such heap.

[dpgeorge]

Sounds great @ha5di! Any feedback you have on using uPy in the wild is very valuable and can be used to improve it.