[racket-users] Re: Embedded Racket reimplementation for constrained hardware?

[George Neuner]

On Sun, 6 Jun 2021 07:26:09 -0700 (PDT),
"schle...@gmail.com"
 wrote:

>I think in such an environment I would like to control memory usage myself, 
>or maybe have a #lang that allows very fine grained and low level control 
>over resources. (outputting lowerlevel code than racket/base). 
>If you need persistent data-structures they are nice, but often times you 
>don't need them. 
>Basically I would use a smaller language and build only the things I really 
>need, instead of starting with racket and stripping away everything I don't 
>need. 
>(although if you manage to create a tool that accomplishes this in a very 
>radical manner that could be cool as well, I just don't think that is easy)

I doubt Racket can be used directly as it was not designed to work
with programmer managed memory, but it could be used as a cross
development environment.  For reference there is Scheme48 which was
designed for embedded use.  Scheme48 compiles to C and does /not/ use
GC but rather forces the programmer to manage memory explicitly.
However, there's no particular need to go through C if you're willing
to write your own compiler and runtime.

>That would boil down to partially evaluating racket specializing it to the 
>target program, I don't think tools like `raco exe`, `raco distribute` etc. 
>go so far that they would try to eliminate
>base language features, which probably aren't "unused" anyway in any 
>reasonably complex program.

Yeah, I think some significant work would have to be done to separate
'base' into smaller libraries ... if that even can be done at all.


>Said another way: I think in a lot of cases it is easier to start creating 
>a program with a language with less features, than trying to get rid of 
>certain features after the program was already written using these 
>features. If you start out without the features it is easier to reason 
>about what features are worth implementing, for the particular program and 
>what is over-engineered for the use-case.
>That is just my perspective, I think there are many approaches to this, 
>depending on the circumstances and concrete goals.
>
>Simon

As a technical matter, GC works fine in small memory as long as it is
designed for that purpose.  The problem is that the GCs employed by
(BC and CS versions of) Racket were /not/ designed for particularly
small systems.

But the design space of GC is large, and collectors have been designed
to work in almost every environment except HRT with sub-millisecond
deadlines.  There are systems that are completely deterministic and
which can be used for HRT as long as the periods when the mutator must
be stopped are short enough for the purpose.

YMMV,
George

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/mmhubg92kiggthhlrfp483sfu0hga86r79%404ax.com.

[racket-users] Re: Embedded Racket reimplementation for constrained hardware?

[schle...@gmail.com]

I think in such an environment I would like to control memory usage myself, 
or maybe have a #lang that allows very fine grained and low level control 
over resources. (outputting lowerlevel code than racket/base). 
If you need persistent data-structures they are nice, but often times you 
don't need them. 
Basically I would use a smaller language and build only the things I really 
need, instead of starting with racket and stripping away everything I don't 
need. 
(although if you manage to create a tool that accomplishes this in a very 
radical manner that could be cool as well, I just don't think that is easy)

That would boil down to partially evaluating racket specializing it to the 
target program, I don't think tools like `raco exe`, `raco distribute` etc. 
go so far that they would try to eliminate
base language features, which probably aren't "unused" anyway in any 
reasonably complex program.

Said another way: I think in a lot of cases it is easier to start creating 
a program with a language with less features, than trying to get rid of 
certain features after the program was already written using these 
features. If you start out without the features it is easier to reason 
about what features are worth implementing, for the particular program and 
what is over-engineered for the use-case.
That is just my perspective, I think there are many approaches to this, 
depending on the circumstances and concrete goals.

Simon

gneuner2 schrieb am Samstag, 5. Juni 2021 um 19:13:21 UTC+2:

> On Sat, 5 Jun 2021 06:45:44 -0700 (PDT), dbohdan
>  wrote:
>
> >Has anyone tried making a small embedded implementation of Racket? I mean 
> >"embedded" not in the sense of 8-bit microcontrollers but more powerful 
> yet 
> >still constrained devices, like routers with 64 MB RAM running Linux or 
> the 
> >PlayStation 2. I think you don't have to work from scratch to make one. 
> >You can implement Racket on top of an embedded Scheme like Chibi-Scheme 
> >. It doesn't need to be a full, 
> >maximally compatible port of Racket like Racket CS, just a large subset. 
> >For example, you can skip futures and places.
> >
> >What features do you need to implement natively in the interpreter rather 
> >than in Scheme? You can implement delimited continuations in terms of 
> >call/cc. The concurrency primitives (threads, boxes, etc.) and the FFI? 
> >You may be able to, but don't have to, optimize the interpreter for 
> >immutable conses.
> >
> >This is just something I have been musing about. If no project like this 
> >exists, I am not starting one soon.
>
> Racket can run in less than 64MB, but severely limited memory
> typically results in a lot of GC churn.
>
> George
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d5f3114-ddaa-4e4b-af6b-e7f82a2fc670n%40googlegroups.com.

[racket-users] Re: Embedded Racket reimplementation for constrained hardware?

[George Neuner]

On Sat, 5 Jun 2021 06:45:44 -0700 (PDT), dbohdan
 wrote:

>Has anyone tried making a small embedded implementation of Racket?  I mean 
>"embedded" not in the sense of 8-bit microcontrollers but more powerful yet 
>still constrained devices, like routers with 64 MB RAM running Linux or the 
>PlayStation 2.  I think you don't have to work from scratch to make one.  
>You can implement Racket on top of an embedded Scheme like Chibi-Scheme 
>.  It doesn't need to be a full, 
>maximally compatible port of Racket like Racket CS, just a large subset.  
>For example, you can skip  futures and places.
>
>What features do you need to implement natively in the interpreter rather 
>than in Scheme?  You can implement delimited continuations in terms of 
>call/cc.  The concurrency primitives (threads, boxes, etc.) and the FFI?  
>You may be able to, but don't have to, optimize the interpreter for 
>immutable conses.
>
>This is just something I have been musing about.  If no project like this 
>exists, I am not starting one soon.

Racket can run in less than 64MB, but severely limited memory
typically results in a lot of GC churn.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3pbnbgtsk18g1dpg8951h9nvjuu448gmja%404ax.com.