libera/#sicl - IRC Chatlog
Search
3:18:06
beach
Bike: It looks to me like you are working mostly on non-Cleavir Clasp code. Does that mean that you consider the work on Cleavir pretty much done? I am not following in detail what has been done with Cleavir v2.
3:20:40
Bike
No, there's plenty left to do, mostly in the direction of replacing cleavir-env with trucler
3:21:43
Bike
once it uses trucler it should be possible to store more interesting type information in the environment, which is important for a lot of optimizations
3:22:42
Bike
but the nonspecific optimizations done by karlosz and i have already improved clasp performance a fair bit, so this all seems a little less urgent
3:24:28
Bike
https://github.com/s-expressionists/Cleavir/wiki/Musings-about-local-functions-and-closures this has been an important one
3:26:57
Bike
contification being essentially merging calls that have the same continuation, and then interpolating, e.g. rewriting (if x (f z) (f g)) as (f (if x z g)) so to speak
3:28:39
beach
I remember understanding contification at the time it happened, but I forgot it since. Is it a published optimization technique?
5:27:36
Colleen
Unknown command. Possible matches: 8, time, deny, set, say, mop, get, uptime, define, login,
5:28:19
hayley
I had written a fair bit about what I learnt about object layouts in SBCL from attending the Boston Lisp Meeting, but the Matrix bridge appears to have dropped my messages.
5:28:40
hayley
This morning I attended the Boston Lisp Meeting (which fortunately was at a reasonable time in the morning for me). One presentation was on the state of implementations of the Dylan programming language, and the other was about integrating a new GC into SBCL.
5:29:04
hayley
The latter mentioned a few things about object representation in SBCL that I didn't know about before. Bignums in SBCL follow the same "allocate for the maximum size of an operation, then have the GC shrink bignums which don't the most significant word" technique as planned for SICL.
5:30:32
hayley
Doug Katzman mentioned an experiment on the layout of standard instances. To use SICL terminology, the new layout effectively puts the rack in the header, which reduces the size of an object, as I guess the rack doesn't need its own layout header stuff.
5:30:56
hayley
The rack reference still exists, and it usually points back to the header. This is not the case after CHANGE-CLASS was called, in which case it points to a new rack. But I think fixing up the object requires the GC to stop the world, and possibly move objects if the new rack is larger than the old.
5:39:25
beach
The only benefit of the layout experiment that I can see is size. The pointer either has to always be followed, or there must be a test to determine whether the "rack" is separate or not.
5:40:54
hayley
Katzman only mentioned that it made objects smaller most of the time. But I also thought there might be some improvement to locality of reference.
5:43:13
hayley
Here are the slides, not that I think there is too much more to add: <https://docs.google.com/presentation/d/1X-oWcu2GUdZeo7TEhygvMBPqyGbqxEKBx0B4McK2Sgo/edit>
5:43:29
beach
I am going to buy food in a few minutes. Before the pandemic, I used to go twice a week, and now that I am vaccinated and the situation is slowly getting under control, I am going back to that habit.
7:06:22
froggey
Mezzano also uses the combined header/rack representation for standard instances and has for a few years now
7:10:06
froggey
yes, CHANGE-CLASS (and also updating obsolete instances) allocates a new instance and changes the old object's header to point at it
7:20:24
beach
1. My memory and my available energy for work is much less compared to maintainers of Mezzano, Clasp, and SBCL. So I could not cope with an optimization that complicates things in ways that give me more work and more things to keep track of. Especially if the gain is not proven.
7:21:07
beach
2. It would require a complete redesign of the SICL garbage collector, because it depends on headers (and CONS cells) to be two words so that they can all be managed in a free list.
7:22:14
hayley
Yes, I would not recommend this technique as it complicates the garbage collector. But it was interesting when I first heard of it.
7:22:27
beach
3. It seems to me that with this technique, you would either need to allow for pointers into the original object, so that different threads could update the old rack even after it has been abandoned. Or else you would need a lock for the object so that no other thread is accessing the old rack.
7:23:31
beach
This is another huge complication for the garbage collector, and I am wondering whether the gain in performance of the mutator would make up for the additional work in the garbage collector.
7:25:45
beach
I am betting that the concurrent and parallel GC design of SICL will compensate for perhaps some additional work in the mutators. So I am very reluctant to changing the GC design for a, perhaps small, gain in mutator performance.
7:25:49
hayley
I was also going to ask about thread-safety, but at the time I was more concerned with how maintaining the locality after CHANGE-CLASS would presumably require a moving collector, which either then precludes an on-the-fly GC or requires more mutator overhead.
7:27:55
beach
I mean, they can argue that it is no worse than always having separate headers and racks, and almost always at least as good.
7:29:12
moon-child
in general, I tend to bias towards more work in the gc, because it means that you can avoid the gc on performance-critical paths. But I think your other arguments are valid