The latest ESP32 Version of uLisp now supports PSRAM

#1

The latest release of the ESP32 Version of uLisp, Release 4.6b, now lets you take advantage of the PSRAM (pseudo-static RAM) available on many ESP32 boards, allowing you to run larger Lisp programs, handle massive arrays, or process large text files.

For example, the following recommended boards include 2 Mbytes of PSRAM that you can now use with the latest ESP32 release of uLisp to give 260000 objects of workspace, nearly 30 times as much as with the standard RAM:

In most board configuations on the Arduino IDE the PSRAM is enabled by default, but if you prefer to run uLisp in the standard RAM, as on previous releases, set PSRAM to Disabled on the Tools menu before uploading uLisp.

The following table shows the difference in performance for a typical ESP32 board, the Adafruit ESP32 Feather V2 (using ESP32 Core 2.0.12):

Option Objects GC time Tak Q2
PSRAM Enabled 260000 162 ms 7.9 s 20.9 s
PSRAM Disabled 9500 462 µs 6.0 s 16.8 s

The most significant difference is that with the larger workspace garbage collections take longer, but they will of course occur less frequently.

For details of the Tak and Q2 benchmarks see: Benchmarks.

For information about the implementation see: Extended RAM.

Thanks to @Kaef for his original work on supporting PSRAM.

Arduino GIGA R1
Ulisp-2.4-esp with 4 MByte PSRAM support
#2

I’ve updated the Performance infographic accordingly:

http://www.ulisp.com/show?36M3

#4

Since the garbage collector has to both mark and sweep, I think two GC benchmarks might be good:

One that marks nothing and sweeps the entire workspace:

(progn
  (mapc #'makunbound (globals))
  (gc))

And one that marks almost everything and sweeps nothing:

(let* ((n 129900)
       ; replace with WORKSPACESIZE/2 minus some buffer
       (dummy (make-array n)))
       ; use up a lot of memory
  (gc))
#5

Good point. Garbage collecting empty memory isn’t a very good test. I’ll think about how to automate that.

#6

On second thought, filling up the entire memory with a giant array would probably break the garbage collector instead of just stress it:

Since the arrays are a binary tree the garbage collector would be forced to recurse on the left side (car) of the tree, and blow the call stack.

Maybe a flat list would be better… just append a list onto itself until (room) is below some threshold…

#7

To test the recent PSRAM implementation I tried creating vast arrays, such as by running the Sieve benchmark on a large number, and the garbage collector seemed OK.