Technologies: C, Common Lisp, some Perl and Python, GNU/Linux, networking, some HTML and Javascript, low-level, Linux drivers, interpreters and compilers
Email: it's in the description of my profile
My name is Andrea Monaco and I'm 31 years old. I'm writing an implementation of the Common Lisp language with more than 80% compliance (https://savannah.nongnu.org/p/alisp). I have other projects at https://github.com/andreamonaco, among them an online multiplayer game called Zombieland, a Linux driver for my video card, and an utility to record screen on Linux.
I have a bachelor in Mathematics.
I'm looking for a job, either contract or employed. Mostly remote, unlikely to relocate
I fully agree, in fact I'm writing a game in C too, it's https://github.com/andreamonaco/zombieland.
Plus I have at least another idea for a game project in mind with the same language.
Hello, I'm writing an implementation of the Common Lisp language that uses an enhanced reference counting algorithm (that I've taken from literature) that detects and handles cycles. Performance seems okay, though I still haven't tried large programs.
A somewhat different approach was recently proposed here: https://news.ycombinator.com/item?id=44319427 but it seems to have non-trivial overhead. (Still very much worthwhile, given the potential advantages of deterministic cycle collection.) The paper you reference is quite a bit older so it would of course be interesting to do a proper comparison.
I'll look at that.
About performance: people in practice have always favored GC, so I think there's a lot to be discovered in optimization of reference counting algorithms, including concurrent traversal (which is easier because each node has local info in the form of refcounts and flags) and maybe detection of problematic worse-case graphs
Naive ref counting (RC) and tracing GC are very different, but they start looking more and more similar the more you optimize them. Adding cycle collection to RC means adding some tracing. Adding deferred/batched destruction to RC is similar to making a tracing GC incremental. Saturated ref counts (or otherwise avoiding updates) are similar to creating an older generation in a tracing GC. Barriers in a tracing GC (for incremental/generational/concurrent collection) are similar to the ref count updates when mutating RC objects. RC cycle collection time is heavily determined by how much of the graph is traced through from "suspected" roots, so it can be optimized by tracing known-live stuff and removing it from consideration.
But some significant performance-relevant differences remain. RC's cycle collection tends to take time proportional to the amount of dead stuff. Tracing GC tends to take time proportional to the amount of live stuff. (Both use optimizations that weaken the connection, but they still show their origins.)
I'd say the latter, since I felt the need for debugging tools similar to other languages like C. Watchpoints for example are entirely non-existent in current implementations, as far as I know
Remote: Yes
Willing to relocate: Very little
Technologies: C, Common Lisp, some Perl and Python, GNU/Linux, networking, some HTML and Javascript, low-level, Linux drivers, interpreters and compilers
Email: it's in the description of my profile
My name is Andrea Monaco and I'm 31 years old. I'm writing an implementation of the Common Lisp language with more than 80% compliance (https://savannah.nongnu.org/p/alisp). I have other projects at https://github.com/andreamonaco, among them an online multiplayer game called Zombieland, a Linux driver for my video card, and an utility to record screen on Linux.
I have a bachelor in Mathematics.
I'm looking for a job, either contract or employed. Mostly remote, unlikely to relocate
reply