News for hackers. Stuff that matters.
Re:Measuring GC latencies in Haskell, OCaml, Racket by ronjouch on Monday December 05, 2016 @11:18AM (#13106442)
Well, Today I Learned that Racket is GCed; I assumed the contrary due to John Carmack being enthusiast about it in the context of video games.

I understand the fact that not everything in a game belongs to the critical 16ms budget (and know about e.g. Unity, which lets you talk C# to it), but I'm still puzzled; can someone expand on:

- Which are these non critical parts? Rendering / physics / animation are certainly in the critical path. That leaves only simple "client" game logic out of it, right? What else?

- For these non critical parts, what are the typical acceptable time boundaries? For example, the article mentions "maximal latencies of around 22ms" for Racket. How is it acceptable for non-critical-path parts? How much would still be acceptable? 50ms? 100ms? "That depends"?

- And regarding Haskell and OCaml, which I only vaguely know about, I had never asked myself how they handle memory. Which makes me ask: are there non-GCed functional programming languages? Does it make sense? (Especially given the kinds of deep complex data structures produced by the immutability that often comes with these languages.)

Re:Measuring GC latencies in Haskell, OCaml, Racket by carterschonwald on Monday December 05, 2016 @11:39AM (#13106645)
The cogent language by nicta (an easy google away) has functional semantics but uses linear logic / linear types to make sure that no gc is needed. The code is on github and they have a very cool approach to generating proofs that any code generation maps the cogent code to equivalent c code. https://github.com/NICTA/cogent/tree/master/cogent

I've also been looking into how to add resource logic / linear logic to ghc Haskell / languages with a similar internal rep as ghc core. Still need to write that stuff up mind you.

There's a long history of no gc free functional language research. Mlkit and clean are probably two of the older but accessible implementations in the wild

Re:Measuring GC latencies in Haskell, OCaml, Racket by eatonphil on Monday December 05, 2016 @12:30PM (#13107213)
As a datapoint, bone-lisp [0] is a Lisp-1 without a GC. There is prescheme [1] as well. Mlkit supposedly uses region-based management as well but I'm pretty sure it also has a GC too.

[0] https://github.com/wolfgangj/bone-lisp

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40...

Re:Measuring GC latencies in Haskell, OCaml, Racket by dom0 on Monday December 05, 2016 @11:30AM (#13106562)
How much client code kinda depends a lot on genre, doesn't it? A shooter doesn't have a lot of that. Something like CSGO or BF1 might have things like the announcer, some LoD perhaps, streaming of skins and tags going on. Something like a TESV has all that content streaming, NPC pathfinding, quest tracking and those 10 million lines of scripts the user installed through mods going on.
Re:Measuring GC latencies in Haskell, OCaml, Racket by patrec on Monday December 05, 2016 @05:52PM (#13110582)
There are at least functional programming languages that try to let you get by without or at least less GC:

ATS: https://bluishcoder.co.nz/2011/02/27/linear-datatypes-in-ats...

Stalin does global static life time analysis and MLKit uses GC only to augment it's region based scheme, but you can turn it off (at the cost of guaranteed space safety).

Of course Rust is a bastard child of ML as well.

Re:Measuring GC latencies in Haskell, OCaml, Racket by nickpsecurity on Monday December 05, 2016 @12:19PM (#13107075)
PreScheme was a C replacement. It had manual de-allocation. Carp LISP is a new one with code being updated. MLkit supports reference-based GC, region-based management, and disabling GC for real-time use.

https://github.com/carp-lang/Carp

http://www.elsman.com/mlkit/

Re:Measuring GC latencies in Haskell, OCaml, Racket by jakevn on Monday December 05, 2016 @12:12PM (#13106979)
And in Unity3d, the GC is actually very problematic. For complex games, you need to focus on zero-allocation or there will be noticeable pauses. (See Kerbal Space Program) Object pooling is the way to go here.
Re:Measuring GC latencies in Haskell, OCaml, Racket by nightski on Monday December 05, 2016 @02:13PM (#13108323)
I don't know if "problematic" is the right word seeing as even with manual memory management you have to do the same techniques. The problem is with allocation/destruction in general within the core loop.
Re:Measuring GC latencies in Haskell, OCaml, Racket by yoklov on Monday December 05, 2016 @05:17PM (#13110262)
It's more problematic in languages that encourage allocation since you have to work more to avoid it.

I've done game development in C++, C#, and JS, and I had to worry about memory management far more in JS than in C# or C++, simply because even something as innocent as adding two vec3s requires you come up with a space for the result first, if you want to avoid gc hitches.

C#'s struct types help here, but it still has plenty of its features increase GC pressure.

Re:Measuring GC latencies in Haskell, OCaml, Racket by pjmlp on Monday December 05, 2016 @01:32PM (#13107895)
A consequence of a pre-historic Mono implementation.
Re:Measuring GC latencies in Haskell, OCaml, Racket by wyager on Monday December 05, 2016 @03:48PM (#13109382)
It is challenging to deal with functional languages, especially non-strict functional languages, without GC. You can do it to some degree, but it requires some clever and inconvenient limitations on the language. Lifetimes and linear types are two approaches that can help. Clash and lambda-ccc can convert non-monomorphically-recursive Haskell code to a fixed-memory implementation (not even a stack, let alone a heap). Closures, unbounded recursion, and all those other things that make functional programming so convenient often require GC.
Re:Measuring GC latencies in Haskell, OCaml, Racket by ronjouch on Monday December 05, 2016 @04:30PM (#13109837)
Exactly what I was hoping. Thanks for naming these things, names are what those of us without the academic baggage need to be able to investigate/study what we are talking about.
Re:Measuring GC latencies in Haskell, OCaml, Racket by samth on Monday December 05, 2016 @08:41PM (#13111589)
Just to be clear, in the Oculus scripting with Racket that Carmack has done, I don't think Racket is being used in the real-time way that you're suggesting. Instead, Racket is used to control and send commands to the Android device running the VR simulation.
Re:Measuring GC latencies in Haskell, OCaml, Racket by agentgt on Monday December 05, 2016 @11:31AM (#13106571)
> Well, Today I Learned that Racket is GCed

I'm curious how did you expect Racket to work without a GC or any Lisp like language for that matter or did you just assume because of video game usage?

> - And regarding Haskell and OCaml, which I only vaguely know about, I had never asked myself how they handle memory. Which makes me ask: are there non-GCed functional programming languages? Does it make sense? (Especially given the kinds of deep complex data structures produced by immutability.)

Rust and C++ depending on your definition of FP. I believe there are some old ML languages as well (and even some old lisps).

Re:Measuring GC latencies in Haskell, OCaml, Racket by monsieurbanana on Monday December 05, 2016 @12:03PM (#13106908)
Am I misreading something? The first half of your comment seems to suggest that no lisp language could work without a CG, while the second half suggest there're some lisp languages that do.
Re:Measuring GC latencies in Haskell, OCaml, Racket by agentgt on Monday December 05, 2016 @12:22PM (#13107104)
Because I don't know how modern Lisps can do it (I believe there was hardware like lisp machines made specifically for Lisp that would deal or help with memory allocation/reuse as well as some code generation).

I honestly was curious if the OP had some insight that I did not. I realize re-reading the comment it sounds snide but I didn't want to assume the OP's knowledge.

For all I knew Racket could have some ability to avoid GC.

Re:Measuring GC latencies in Haskell, OCaml, Racket by hajile on Monday December 05, 2016 @02:35PM (#13108519)
Re:Measuring GC latencies in Haskell, OCaml, Racket by ronjouch on Monday December 05, 2016 @11:35AM (#13106610)
> "I'm curious how did you expect Racket to work without a GC or any Lisp like language for that matter or did you just assume because of video game usage?"

Just because of video game usage and my perception of Carmack as a performance freak who wouldn't compromise on performance. (Sloppy reasoning, I know! Thus, my questions on where GC makes sense in games)

Re:Measuring GC latencies in Haskell, OCaml, Racket by agentgt on Monday December 05, 2016 @12:48PM (#13107432)
I actually was curious and not trying to be snide. For example I wasn't sure if Carmack or whoever might be using Racket for code generation (ie multi-stage programming) which in theory would avoid GC. I wasn't sure how he was using Racket.
Re:Measuring GC latencies in Haskell, OCaml, Racket by ronjouch on Monday December 05, 2016 @01:10PM (#13107668)
No problem, your comment was clear and I didn't perceive it as snide, at all. Thanks for your carefulness in the discussion.
Re:Measuring GC latencies in Haskell, OCaml, Racket by bojo on Monday December 05, 2016 @06:44PM (#13110973)
It should be noted that he used Racket to teach his son game programming. He mentioned in his QuakeCon 2013 talk that he was enthusiastic about FP concepts, but is too entrenched with C++ to make a change.
Re:Measuring GC latencies in Haskell, OCaml, Racket by nickpsecurity on Monday December 05, 2016 @12:20PM (#13107087)
Re:Measuring GC latencies in Haskell, OCaml, Racket by otabdeveloper on Monday December 05, 2016 @12:59PM (#13107539)
> are there non-GCed functional programming languages?

Yes, C++. For the last 18 years the C++ standard has been busy adding functional features to the language. With mixed success, but still the result is quite impressive.