freenode/#sicl - IRC Chatlog
Search
4:23:29
beach
Wow, I stumbled on a presentation by Emery Berger about performance, and I thought I recognized the name. Sure enough, I think he was an undergraduate working with Paul Wilson at UT Austin when I was visiting there for a year. And, it looks like Paul Wilson is back in business. He basically vanished at the end of my visit.
5:26:59
beach
I highly recommend "Performance Matters" by Emery Berger, September 13-14 2019, Strange Loop conference. I especially recommend it to Clasp developers since performance is important to Clasp at this point.
6:15:40
no-defun-allowed
The paper suggests the implementation wouldn't be too hard: https://arxiv.org/pdf/1608.03676v1.pdf
6:17:19
beach
There is so much interesting stuff out there. It is just hard to find because of all the noise.
6:42:23
beach
By the way, I think someone (easye maybe) is planning a Cleavir-based compiler for ABCL. Were you aware of that? Your work on turning HIR into JVM could be useful in that context.
6:43:09
no-defun-allowed
I think easye mentioned it in his Online Lisp Meeting presentation, and we did discuss it.
7:36:36
no-defun-allowed
If squinting hard enough, HIR is fairly simple to translate to JVM instructions. Lexical locations and control flow at least are explicated in HIR, then memory in MIR, then register allocation in LIR.
8:12:15
beach
shka_: Cleavir proposes two (for now) intermediate representations that are independent of the implementation, i.e. AST and HIR. And it takes care of propagating source information from CSTs to ASTs to HIR. We can then supply transformations on those intermediate representations, in particular various optimizations.
8:13:33
beach
Yes, and as no-defun-allowed points out, for certain implementations, MIR and LIR could be useful as well. That is certainly the case for SICL.
8:14:11
shka_
ok, and at least parts of those transformations you mentioned are expected to be portable between concrete implementations, right?
8:14:53
beach
So Cleavir does not make anything easier than it is in any other implementation, but it makes it unnecessary for an implementation to do the stuff all over again.
8:16:09
beach
My secret hope (but I didn't believe it very much) was that existing implementations would replace their specific stuff with Cleavir stuff. But it certainly makes things easier for new implementations like Clasp, or the CLISP compiler that karlosz wrote, and now with a new compiler for ABCL.
8:17:49
beach
Maybe if some implementation has a compiler that is so hard to maintain, they might consider replacing it.
8:19:55
beach
So far so good. But we are not optimizing enough (yet). Bike and karlosz are working on it of course, so things will improve.
8:20:24
beach
For now, all we can claim is that there is less work involved to get a compiler up and running, than if they were to roll their own from scratch.
8:23:08
beach
And I chose an intermediate representation (HIR, MIR, LIR) that is similar to what most algorithms in the literature use, so many algorithms should be straightforward (but perhaps not easy) to implement.
8:28:39
beach
Over the years, I think we have understood many things about how to develop code that is as implementation-independent as possible, and that can also be customized for different clients. The way Eclector, Trucler, Clostrum, CST-to-AST, AST-to-HIR turned out, reflects this way of structuring code.
9:23:21
no-defun-allowed
ACTION tries to collect some function names while running a test and crashes SBCL in the process.
9:26:41
scymtym
no-defun-allowed: did you make sure not to reference dynamic-extent data outside of the context of the original thread?
9:27:42
no-defun-allowed
I don't think so, but I used dissect to give me a call stack and it produced a bogus object somehow (while in my thread interrupting code, so it should still be in context).
9:30:16
scymtym
there have been a few sb-sprof changes regarding e.g. pinning of code objects. maybe dissect does something that is longer safe. but i'm totally speculating
12:56:27
beach
I ran a small benchmark to compare the execution time of the AST evaluator to that of native code. So I compiled and ran the Ackermann function with arguments 3 and 11. With native SBCL it took around 1.3 seconds, and with the AST evaluator less than 6 seconds.
12:57:21
beach
I remember doing a short test in the past with the HIR interpreter, and it was a factor 10k slower than SBCL.
13:27:28
mseddon
wouldn't Ackermann bog down into a lot of huuuuge bigint arithmetic pretty quickly?