21–30 of 58 posts
Original site with almost same description verbiage: https://web.archive.org/web/20110704041631/http://force7.de/...
Earlier quoted context omitted.
It's deferred reference counting, so the 1-2ms claim is perfectly reasonable because all it has to scan is the stack (though if they want to break cycles they will have to do something costlier). The downsides are all of the downsides of reference counting, plus the fact that last I looked Nimrod's GC is not thread safe. That last one is a huge downside IMHO. I think DRC is interesting but I'm not much of a fan of it…
Deferred means you eventually have to do the work. Same for reference counting - when you free that last element it will have to actually do the freeing. If you've filled up ram and are allocating objects fast then you can either crash or do some garbage collection and if the tree is large it will have to take more than 1-2ms.
Cool project. How does it accomplish the realtime GC max pauses of 1-2 ms after compiling to javascript? Wouldn't the js implementation's GC have the final say on GC pauses? Thanks.
I have no idea what Nimrod is doing, but I suppose one could output JS where a heap is simulated through a TypedArray, such that the JS GC only has a single memory reference to keep track of. Then you could give guarantees on GC performance, given reasonable assumptions about the JS runtime.
Am I in a time warp? Nimrod is over 5 years old. Yet most comments here think it's new and groundbreaking with statements like nimrod sounds even better than google go . Nimrod is a cool language, but am I missing something here? Original site with almost same description verbiage: https://web.archive.org/web/20110704041631/http://force7.de/...
Some very interesting features of Nimrod which I would like to emphasize: - clean Pythonic syntax (whitespace relevant but tabs are forbidden) - native Perl syntax for regular expressions (slide 42) - subrange types as in Ada - set types as in Pascal - strings as case (switch) selectors - easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas) - typed macros (te…
> Nimrod actually is where Python should be. I guess you meant "what I wanted Python to be". I don't see how Nimrod is a natural evolution of Python. Static types and meta-programming by templates are far from anything Python proposes. I believe not even the syntax comparison applies too much, it's syntax is more reminiscent of Pascal than Python itself.
A GC with a deadline is what caught my attention, seemingly can specify a max pause time (in ms) and GC wont' take longer than that. That is very good for soft realtime stuff -- games, audio processing. Also, Nimrod has a very nice library. Definitely has enough "batteries" in it to get started. http://nimrod-lang.org/lib.html Just a few impressive ones: http client, server, json parsing, actor support, redis db driv…
If you want to do some serious experimentation with Nimrod, I recommend using 0.9.3 (the Github version). It is considerably more mature and stable than 0.9.2.
The one oddity that I'm still getting used to is Nimrod's preference for value types. I.e., the string and seq[T] types use copying for assignment [1] by default, when most other languages assume reference semantics (you can use reference assignment instead, but have to say so explicitly). This may create inadvertent overhead if you are unaware of it, but also avoids some pitfalls you otherwise may run into with mutable strings.
As for the default GC, it's not that you can actually guarantee a maximum pause time [2]. The GC uses deferred reference counting (i.e., eliding most RC operations and batching the ones that are needed). As long as your data structures are acyclic, that allows for a very low upper bound on GC pause times. Pause times for dealing with cyclic structures depend on the size of the cycles involved (and the size of data structures attached to those cycles). A practical workaround for when you have to deal extensively with cyclic data structures is to make use of the fact that each thread has its own heap: thus, putting all time-critical stuff in one thread where cyclic data structures aren't used, and the rest in another thread.
[1] Copying is not used for passing arguments to a procedure or for returning a result, only actual assignment.
[2] You can influence it to some extent by changing the value of ZctThreshold in system/gc.nim, which specifies the size of the zero count table. Each GC iteration will still have to scan the stack, of course.
Edit: Oops, to correct myself, Nimrod does actually have a GC_setMaxPause() procedure, though I still don't think it can guarantee hard upper bounds on pause times.
Earlier quoted context omitted.
It's deferred reference counting, so the 1-2ms claim is perfectly reasonable because all it has to scan is the stack (though if they want to break cycles they will have to do something costlier). The downsides are all of the downsides of reference counting, plus the fact that last I looked Nimrod's GC is not thread safe. That last one is a huge downside IMHO. I think DRC is interesting but I'm not much of a fan of it…
Deferred means you eventually have to do the work. Same for reference counting - when you free that last element it will have to actually do the freeing. If you've filled up ram and are allocating objects fast then you can either crash or do some garbage collection and if the tree is large it will have to take more than 1-2ms.
Am I in a time warp? Nimrod is over 5 years old. Yet most comments here think it's new and groundbreaking with statements like nimrod sounds even better than google go . Nimrod is a cool language, but am I missing something here? Original site with almost same description verbiage: https://web.archive.org/web/20110704041631/http://force7.de/...
Some very interesting features of Nimrod which I would like to emphasize: - clean Pythonic syntax (whitespace relevant but tabs are forbidden) - native Perl syntax for regular expressions (slide 42) - subrange types as in Ada - set types as in Pascal - strings as case (switch) selectors - easy C interface with automatic type conversion (only functions as parameters need additional compiler pragmas) - typed macros (te…
Cool! Is what you're working on public?
A GC with a deadline is what caught my attention, seemingly can specify a max pause time (in ms) and GC wont' take longer than that. That is very good for soft realtime stuff -- games, audio processing. Also, Nimrod has a very nice library. Definitely has enough "batteries" in it to get started. http://nimrod-lang.org/lib.html Just a few impressive ones: http client, server, json parsing, actor support, redis db driv…
I have been using Nimrod for some personal projects and internal tools since about version 0.9.0. It is quite usable -- especially the current Github version -- but as you may expect from a 0.x project, it still has some rough edges. These haven't stopped me from being productive with it, but you should be prepared for the occasional "huh?" situation (the most common problem I've had was that when I experimented with…
Could you elaborate if possible a bit on a thread private heap. I know Erlang's actor and Dart's isolates allow that (which makes it easy for it to implement a concurrency GC).
What is the mechanism for creating private heaps (if there is one)? Or is it just by convention as in "just know that from this one thread I only create objects and no other thread will access it"?