Can you please share more background information about the project, in particular why you wanted to take on this huge challenge, and why you didn't just start from an existing implementation, and why you chose C as the implementation language? Do you assume that you can still use the same GC with the addition of multi-threading?
Well, I like and use SBCL and ECL, but I was curious if I could make something as big on my own. I was also curious about implementing that GC algorithm that I found in literature; I'm pretty satisfied with the result, though I don't exclude providing an alternative more classic GC as an option in the future.
I chose C because I love its clean design, and the portability of C89 can't really be matched.
About multi-threading: I still haven't thought about it much, but I'm optimistic; according to the paper, the algorithm is quite amenable to concurrency, since each object carries local information (the two refcounts), so some collection doesn't need global state. I agree, but we'll have to wait to see it in action
The size is indeed impressive (31 kSLOC, compared to e.g. Lua 5.1 with 13 kSLOC). I will have a closer look at the code. Maybe I can transpile it to my Luon language and run it on LuaJIT.
The implementation looks easier to handle than e.g. ECL or CLISP, cool.
Do you have an estimate how complete your implementation is?
How does the performance compare with e.g. ECL or CLISP?
Did you run conformity tests, e.g. with https://gitlab.common-lisp.net/ansi-test/ansi-test?
Based on the number of symbols implemented, I'd say that more than three quarters of the standard are done, almost enough to load a system with ASDF.
Performance seems on par with clisp, but important optimizations are yet to be done, for example my program is still single-threaded
That's amazing, thanks.
Can you please share more background information about the project, in particular why you wanted to take on this huge challenge, and why you didn't just start from an existing implementation, and why you chose C as the implementation language? Do you assume that you can still use the same GC with the addition of multi-threading?
Well, I like and use SBCL and ECL, but I was curious if I could make something as big on my own. I was also curious about implementing that GC algorithm that I found in literature; I'm pretty satisfied with the result, though I don't exclude providing an alternative more classic GC as an option in the future. I chose C because I love its clean design, and the portability of C89 can't really be matched.
About multi-threading: I still haven't thought about it much, but I'm optimistic; according to the paper, the algorithm is quite amenable to concurrency, since each object carries local information (the two refcounts), so some collection doesn't need global state. I agree, but we'll have to wait to see it in action
The size is indeed impressive (31 kSLOC, compared to e.g. Lua 5.1 with 13 kSLOC). I will have a closer look at the code. Maybe I can transpile it to my Luon language and run it on LuaJIT.
You can support my implementation on Patreon (https://www.patreon.com/andreamonaco), even subscribing to the free tier is helpful. Thanks everyone!
What are the pros and cons of this vs other Common Lisp implementations such as clisp and others?
My implementation builds very easily, like 20 seconds on my laptop. More importantly, debugging and stepping work very well
> like 20 seconds on my laptop
About the same time on my old EliteBook 2530p.