libera/#sicl - IRC Chatlog
Search
12:03:02
Bike
in clasp we're looking at non boehm GCs, and even now we're using boehm with precise collection
12:03:47
jackdaniel
Bike: what happens if you pass something from Lisp world to C++ world and the latter "saves" the pointer for later use?
12:03:52
heisig
My experience is that boehm is essentially as good as it gets, under the constraints imposed by the C language.
12:04:37
jackdaniel
I think that bocl is an old idea of his, for bootstrapping on debian without relying on clisp or ecl (:
12:04:40
beach
heisig: This is a project I started some time ago. I just give it some thought from time to time.
12:05:27
jackdaniel
obvious way of crashing is better, because it may be easily tackled when identified. dangling pointers are another story
12:07:24
beach
heisig: There are some real concerns as well. Some Linux distributions apparently require that their packages can be built using only the C tool chain.
12:09:27
beach
heisig: BOCL is also an element in the debate about the best way of writing a Common Lisp implementation.
12:10:29
hayley
I remember ECL being easier to bootstrap from, mostly because I couldn't find a copy of libsigsegv which the CLISP build scripts liked, and that ECL is a fair bit faster.
12:11:14
beach
heisig: With a very simple, but conforming implementation like BOCL, there are fewer reasons to write Common Lisp implementations in any language other than Common Lisp.
12:11:24
jackdaniel
right. otoh clisp is more portable because libgc requires a few lines of code that are platform-specific
12:12:32
jackdaniel
beach: there are other benefits - libgmp is by far the fastest bignum implementation afaik
12:12:52
heisig
My hunch is that BOCL wouldn't be much different from Clisp in the end. Maybe one could simply fork Clisp as a starting point and simplify it further.
12:14:30
beach
heisig: You apparently haven't done the exercise of thinking about simplifications that can be made when performance is not an issue.
12:15:35
jackdaniel
that said, if bocl is say slower than clisp, then it would be quite troublesome to bootstrap from it
12:16:21
beach
It would be used only to build the packages of those particular Linux distributions that impose this restriction.
12:20:03
beach
jackdaniel: Also, I just read up a bit on the GNU multiple precision library. I think it would be fairly simple to incorporate it into SICL for someone who would want that. Recall that the global GC in SICL is essentially malloc()/free(), and it is possible to configure the GNU multiple precision library to use any memory allocator.
12:21:02
beach
The rack of a bignum or a ratio would just contain an instance of the appropriate C object.
12:21:12
jackdaniel
I'm not denying a technical possibility, I was referring to writing the implementation in not "any language other than Common Lisp"
12:22:11
jackdaniel
in fact libgmp is being incorporated by ecl (and I think - optionally - by sbcl)
12:22:32
beach
jackdaniel: You are confusing two things here I think. One is my desire to have no C code whatsoever. The other is the implementation of the Common Lisp evaluator and "library".
12:23:35
Bike
as enticing as the prospect to try to compete with a schonhage-strassen implementation written by someone who knows what they're doing was
12:23:38
jackdaniel
beach: I was convinced you aim at the system that will minimize the dependency on c compiler to minimum
12:24:59
beach
Apparently, I am not doing a good job of expressing myself clearly today, so I'll go do something else instead.
12:28:52
pjb
jackdaniel: The current implementation choices made for my bocl will probably make it slower than clisp: it's an interpreter, not a compiler.
12:28:56
jackdaniel
(or, to be more precise, dependency on C libraries at runtime); sorry for upsetting you beach
12:29:37
jackdaniel
pjb: the argument that it won't be normally used is sound to me, so I'm already convinced that this is a non-issue from the bocl standpoint
12:30:59
jackdaniel
pjb: fwiw ecl has bytecodes compler/interpreter and performs a minimal compilation of the code (i.e doesn't interpret it, but doesn't optimize it either)
12:31:50
pjb
The problem has more to do with the C code, and how standard and compatible with a large range of platform it is (how few implementation specific or undefined behavior it contains).
12:32:31
pjb
Any CL implementation could be adopted if we can remove dubious C code from it and adapt to a large range of platforms.
12:33:44
pjb
That said, once the minimal compilation is performed, interpreting the function calls and the special operators walking a sexp cannot be much slower than interpreting the byte code of a VM.
12:35:10
pjb
So, using clisp as a base could be a possibility. The question is how intricate clisp C code is and how much it relies on non-purely standard C behaviors.
13:10:10
lonjil
I predict that most or all Linux distros will build SICL with Clisp or SBCL, regardless of BOCL being available or not.
14:21:45
beach
lonjil: Why do you think that? I mean, if (say) SICL were to be distributed as a package for some Linux distribution with instructions to just type `make', why would they do something different?
14:27:26
lonjil
Whether they decide *not* to do what you said would probably depend on how slow bootstrapping with BOCL ends up being. If it is very very slow they may use SBCL instead to save CPU time on their build servers.
22:53:10
Mondenkind
Bike: 'there aren't really a lot of options for a non in house GC' have you looked at mps?
23:01:52
Bike
i'm not sure if it was a lock or a shared atomic flag, but yeah, multithread performance was not good
23:03:23
hayley
The code is quite nice for C. I ported it to ARM about half a year before Ravenbrook did.
23:03:57
Bike
might have been, but neither i nor drmeister is especially interested in (re)writing a GC. kind of kills the non in house aspect
23:06:42
hayley
I still think some not-entirely-essential modifications are better than full in-house; but it's still maintenance effort, yes.
23:41:28
Bike
also fixing mps in this way would have required some pretty deep work, since the allocation stuff is all a bunch of hyper optimized macros and functions