[racket] Greetings!

Welcome!

John Carmack wrote on 03/18/2015 02:59 PM:
> I would be interested in hearing any guidance for high performance servers written in Racket.  GC delays in the tens of milliseconds will be problematic for at least part of this application, but I could split that part off into a separate server and still leave the other part in Racket if necessary.  The main benefit is currently development productivity, so obnoxious micro-architectural optimizations aren't useful, but broad strategic guidelines would be appreciated.

Architecture-wise, for dynamic HTTP serving, I've started to play with 
different ways to avoid GC delays, as well as reducing general 
contention serving simultaneous requests.  The direction I'm heading is 
scheduling requests among multiple Linux processes each running Racket, 
or Racket "Places" (which can at least distribute across cores).  The 
worker processes might be short-lived (in which case maybe GC could be 
disabled altogether). The front-end might be in Racket, or in C, or use 
some Linux kernel facility.  It might turn out to just be an 
off-the-shelf load-balancing problem, but I'd like to see whether there 
are any wins from doing it in Racket (e.g., awareness of GC info, 
sharing information within Racket space), as well as keeping it 
"lightweight" (in the sense that anyone could get it by simply loading a 
library and hitting the Run button on DrRacket, without setting up any 
infrastructure).  No results to report yet.

Micro-optimization-wise, I like doing I/O-intensive stuff in C-like 
ways, such as managing ring buffers in Racket `bytes` with routines like 
`read-bytes-avail!` (and generally reducing copying and allocations), 
and with `sync/timeout`.

BTW, agreed on the temptation to use sexps over JSON (if the transport 
is not something that arbitrary JS programmers would be working with 
directly).  For the trivial embedded Scheme, a good starting point is 
R5RS, and then strip out any parts that hurt performance in your 
particular implementation approach (e.g., first-class continuations, 
numeric tower beyond native integer and float).

Neil V.