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
7:31:08
beach
I see. Well, I want SICL to be good for real-time processing and generation of sound, and sound is much more sensitive to GC pauses than (say) video.
7:33:36
hayley
Hopefully performance-critical code has temporal locality of reference, and then fetching one more cache line per object once averages out over many accesses.
7:33:37
beach
None of this stuff has been tested in real situations, of course, so the verdict is still out.
7:35:50
hayley
I can't say I do any performance-critical stuff which is normal. The most performance-sensitive thing I have written is a server which basically always sends dirty cache lines around a few threads, so I can't speak on optimizing that sort of stuff.
7:37:59
hayley
(Though I am considering chunking elements to put on queues so that it doesn't have to be modified so often. But then if I make the chunks too large, I end up with a less "fair" scheduler by some description. How fun.)
7:39:08
beach
Also, performance is not my highest priority for SICL. Debugging support and maintainability are higher on the list. It would be totally fine with me if people use SICL for development and SBCL for deployment.
7:41:52
MichaelRaskin
Finally a chance that my rant about local variables will not apply at least to some implementation.
7:45:39
beach
... unless the Common Lisp HyperSpec says it is undefined behavior, in which case this should be a WSCL issue.
7:48:55
beach
Well, there is no particular reason to make such access impossible even in the presence of constant propagation, other than developer convenience.
7:49:59
beach
I think we had this discussion the other day, but also in the presence of strength reduction in loops, it is usually possible to do the (often linear) calculation in reverse for the purpose of the debugger.
7:50:34
MichaelRaskin
Oh, that would be cool; I probably wasn't paying attention to the channel at that time
7:51:10
MichaelRaskin
My not always paying attention to #sicl is surely a true fact that doesn't need being dreamed of
7:53:52
MichaelRaskin
Sure, I understood that. Just wanted to confirm that a priori probability of the other case is definitely very high
7:54:42
beach
So in many cases, it is possible to pretend that a variable is live for the purpose of debugging, even though it has been optimized away. It may not always be allowed to alter the value of that variable, but altering values of variables is tricky business anyway, because the compiler may have made assumptions about the types of the values.
7:55:41
beach
Some implementations would then perhaps let it happen and have the system crash or (worse) give the wrong result. I am not interested in that kind of trade-off for SICL.
7:56:01
MichaelRaskin
I guess my absurd-ish rewriting technique just breaks many of the optimisations. Which is fine, because it is to force debugging information be available speed be ignored.
7:57:02
MichaelRaskin
Fortunately it does so openly enough that the optimiser just shrugs at that code and walks away instead of breaking things
7:57:44
beach
Certainly. I am convinced that you technique doesn't break anything, except perhaps buggy compilers.
8:17:25
beach
I added a few more links to http://metamodular.com/SICL but I still have another 10 to put in. I'll do one or two per day.