Our great sponsors
-
Eclector
A portable Common Lisp reader that is highly customizable, can recover from errors and can return concrete syntax trees
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Observe, I am not asking for libraries or frameworks to enable writing threaded or task based and concurrent user applications, I am aware of those myself, for example lparallel for CL. What I am interested about is, if it is worth, or even possible, to parallelize core lisp runtime itself.
You mean the parts of the reader that is capable of reading from a stream object and returns strings, booleans, numbers? These are just functions that accept a stream and they return Lisp objects. See e.g. Eclector for an implementation of a Lisp reader as an external library.
You mean, speaking in CL terms, gethash and setf gethash? These, again, are just functions that work on a hash-table-like data structure. See e.g. Luckless for an implementation of a hash table that's additionally lock-free (and therefore should work in presence of multiple threads).
SBCL already bootstraps from any compliant Common Lisp with the C core containing only the OS interfaces and garbage collector. The SICL project is slowly forming up to make it possible to bootstrap Common Lisp from just Common Lisp, without a C core.
Pointer-soup languages aren't the best fit for GPUs, but there are Lisp libraries which compile array-munging code for GPUs from a higher level notation.
https://github.com/Kindelia/HVM potentially adjacent ideas there