[racket] Greetings!

I will second that. The performance difference between the racket dedicated
executable, and running something under a DrR REPL can be surprisingly
huge. It's one of the reasons why I've been slowly transitioning to using
racket-mode under Emacs instead.

On Thu, Mar 19, 2015 at 1:25 PM, Neil Toronto <neil.toronto at gmail.com>
wrote:

> Welcome!
>
> Thank you for your past work. Trying to emulate it concretized and
> motivated almost all of my high school and undergraduate math classes.
>
> On 03/18/2015 02:59 PM, John Carmack wrote:
>
>> ...
>>
>> I have a specification for a VR related file format that is headed
>> towards JSON, but I am seriously considering changing it to s-expressions
>> and embedding a trivial (not Racket) Scheme for scripting.
>>
>
> What kind of Scheme did you have in mind?
>
> It's not terribly hard to embed Racket, nor to create a "#lang" language
> that gives access to only the leanest parts of the language and libraries.
>
> On the other hand, it's easy to write a Scheme interpreter. But you don't
> get the JIT, optimizer, and other goodies.
>
>  I'm teaching my son with Racket.  He has worked in a few different
>> imperative languages prior.
>>
>
> If he's interested in 3D, he might like Pict3D, a 3D engine written in
> Racket that has a purely functional interface. (Most of the internals are
> purely functional as well.) Disclaimer: the API is stable, but I'm still
> expanding it, and I haven't used my own kids as guinea pigs yet.
>
>  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.
>>
>
> Listen to Jay. :) He doesn't use DrRacket, though, so he's left something
> out.
>
> When you do performance testing and statistical profiling, it's fine to
> use DrRacket if you turn off debugging and (the other) profiling support,
> and uncheck "Preserve stacktrace" in the "Choose Language" dialog.
>
> But when measuring GCs, run programs from the command line. DrRacket and
> its tools use a lot of heap. In their initial state, this adds about 10ms
> to minor collections and 500ms to major collections. Using Typed Racket
> will magnify the differences because its compile-time analysis is quite
> memory-heavy.
>
> Neil ⊥
>
>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150319/a3e73724/attachment-0001.html>