4 ms·

uLisp includes a mark and sweep garbage collector. Garbage collection takes under 1 msec on an Arduino Uno or under 3 msec on an Arduino Mega 2560. I wonder ho

by pcl 10y ago

uLisp includes a mark and sweep garbage collector. Garbage collection takes under 1 msec on an Arduino Uno or under 3 msec on an Arduino Mega 2560. I wonder how predictable and controllable that is. Adding GC to what is likely to be a real-time device seems like a potential showstopper. But if the numbers can be a bit more firm, or if the application can receive alerts on pause / resume, that might not be such a big deal.

Varriount 10y ago
As I said in another thread recently, garbage collectors don't have to be of the stop-the-world, non-deterministic kind. It's perfectly possible to have real-time garbage collection [1], and the language I commonly work with supports soft real-time use with the default GC [2]. I'm no expert on garbage collection techniques, but what I have picked up is that most of the challenge lies in timing of the collections (when to run the GC) and how to deal with things like cycles. [1] http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle... [2] http://nim-lang.org/docs/gc.html http://nim-lang.org/docs/gc.html
- pcl 10y ago
  Yes, but the language chosen implied to me that it's using a stop-the-world approach. I've confirmed this by looking at the (surprisingly readable and small) code: http://www.ulisp.com/list?1BWZ http://www.ulisp.com/list?1BWZ Also, it looks like the algorithm is mostly deterministic, so that's good from a real-time standpoint. And it only runs if memory is about to be exhausted, so if the application ensured that it stayed within the Arduino's memory budget, it's essentially a no-op.
chipsy 10y ago
In a real-time application that has to run on constrained hardware, the most interesting use of a GC language is as part of a compilation/configuration process for the actual runtime code or assets. This is the approach of e.g. Naughty Dog's old GOAL language: it isn't doing Lispy things in the engine code, so much as using Lisp as a very powerful macroassembler. This approach is potentially advantageous over having a batch process to compile and upload to the device since it presents some important groundwork for doing "live editing". The performance of the shipped application is effectively unlimited, since the user code has so much control over the resulting output. The main downside is that the resulting app isn't designed for portability, being so oriented towards the machine code rather than an abstract layer: Getting the portability and the live-editing functionality and the performance is a considerably harder problem to visualize, but production C++ game engines are doing it now.

by pcl 10y ago

Varriount 10y ago

As I said in another thread recently, garbage collectors don't have to be of the stop-the-world, non-deterministic kind. It's perfectly possible to have real-time garbage collection [1], and the language I commonly work with supports soft real-time use with the default GC [2]. I'm no expert on garbage collection techniques, but what I have picked up is that most of the challenge lies in timing of the collections (when to run the GC) and how to deal with things like cycles. [1] http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle... [2] http://nim-lang.org/docs/gc.html http://nim-lang.org/docs/gc.html

pcl 10y ago
Yes, but the language chosen implied to me that it's using a stop-the-world approach. I've confirmed this by looking at the (surprisingly readable and small) code: http://www.ulisp.com/list?1BWZ http://www.ulisp.com/list?1BWZ Also, it looks like the algorithm is mostly deterministic, so that's good from a real-time standpoint. And it only runs if memory is about to be exhausted, so if the application ensured that it stayed within the Arduino's memory budget, it's essentially a no-op.

chipsy 10y ago

In a real-time application that has to run on constrained hardware, the most interesting use of a GC language is as part of a compilation/configuration process for the actual runtime code or assets. This is the approach of e.g. Naughty Dog's old GOAL language: it isn't doing Lispy things in the engine code, so much as using Lisp as a very powerful macroassembler. This approach is potentially advantageous over having a batch process to compile and upload to the device since it presents some important groundwork for doing "live editing". The performance of the shipped application is effectively unlimited, since the user code has so much control over the resulting output. The main downside is that the resulting app isn't designed for portability, being so oriented towards the machine code rather than an abstract layer: Getting the portability and the live-editing functionality and the performance is a considerably harder problem to visualize, but production C++ game engines are doing it now.