freenode/#lisp - IRC Chatlog
Search
21:34:20
Shinmera
even without that you basically need to wrap a ton of stuff in lambdas and thus create a lot of indirection and allocation that is otherwise not necessary. Without direct implementation support you can't do much better.
21:35:24
_death
Feldman: not only that, it calls f/cc-function (a generic function) each time as well.. no dynamic-extent declaration for the &rest arg though maybe it's inferred
21:36:04
_death
you can do much better.. personally I like https://8c6794b6.github.io/posts/Delimited-continuations-with-monadic-functions-in-Common-Lisp.html
21:36:06
Feldman
_death: Not quite sure how dispatch is done for funcallable instances, but would implementing Robert Strandh's fast dispatch solve or help that?
21:37:02
Bike
a funcallable instance is just a function with some other slots attach. it doesn't do any kind of dispatch unless you define it to do so.
21:38:59
_death
https://gitlab.common-lisp.net/cl-cont/cl-cont/-/blob/master/src/special-transformers.lisp#L211
21:39:15
Feldman
I would've imagined if FIs weren't generic, they would be as fast as normal functions
21:40:21
Bike
i mean, slow because every call does an apply of this other function, which i guess applies VALUES?
21:41:00
phoe
but given the sheer number of repetitions I seriously don't think that fin overhead is what makes things slow
21:41:10
Bike
phoe: huh, that's way worse than i'd expect... oh, well, actually sbcl is almost certainly going to inline your second lambda there
21:42:41
Bike
defining them both as global functions declaimed notinline is one way, but ofc then you get a little bit of overhead from looking up the global
21:44:08
Bike
anyway, it looks like this other stuff cl-cont is doing is going to be slow regardless of how instances work.
21:44:53
Feldman
I'm asking because I was thinking about a tagbody (and possibly symbol-macro) based approach that would avoid wrapping stuff in lambda (they would be wrapped in tagbodies instead, which I assume are lighter)
21:46:31
luis
fiddlerwoaroof: maybe my next computer will be a mac again, but right now I don't have any macs (not sure if the powerbook still boots :D). Last one got stolen a few years back.
21:48:00
_death
Feldman: just removing that f/cc-function call would likely make it much faster (funcallable-standard-instance-access?)
21:51:48
Feldman
_death: yeah I saw that and was like ??, I suppose FGF would actually help there!, still I wonder why the overhead is 10× for funcallable instances on SBCL in general...
21:52:07
_death
Feldman: I'm guessing for the funcallable-instance-function simply having (apply function #'values args) will do.. if the function slot does not change
21:53:45
Bike
i tried making them global and the funcallable instance is called pretty much exactly as quickly as a regular function.
21:55:17
Bike
luckily, death has identified several other horrible efficiency issues to gasp in distress at
21:57:07
Bike
seems like some other stuff will get screwed up too, here. if every lambda expression is made into one of these funcallable things, that's going to inhibit a lot of normal compiler optimizations
21:59:05
_death
Bike: me neither.. there's use of the reader, and that can turn into f-i-s-a or something..
22:03:14
asarch
This is a meme about how hard a programming language could be. What is "The Lambda Tessaract"? Is it related to Common Lisp? https://pasteboard.co/JVwyaeU.jpg
22:47:36
thomasb06
Bike the 'Status' section in the readme.md says to get in touch with Nvidia issue: https://github.com/malcolmstill/ulubis/issues/64
3:17:36
charles`
It has for me too, but in this one situation, it continues to pull form latest quicklisp release
3:22:48
thermo
i'm using sbcl, and i'm struggling to diagnose a slow OOM. i was hoping to get some related info by setting sb-kernel:gc-logfile and inspecting the output --- but nothing seems to be being written. are there further flags i'm meant to set?
3:28:26
thermo
i'd also be happy to just hear generic tips about diagnosing memory problems. if there's a way to see statistics what's still alive and where it was allocated, that'd be amazing
3:31:15
no-defun-allowed
If you break and evaluate (room t), SBCL provides a list of object types which have instances which occupy the most memory.
4:10:06
charles`
beach, no-defun-allowed: I'm not sure 😁. I would really appreciate a you taking a look. It works perfectly on sbcl. Let me write a test that displays what is wrong. Then I will share a link.
4:58:43
minion
charles`: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL
5:02:00
charles`
that would be when you need to do some operations, how to decide which registers to put the data in?
5:02:20
beach
It is based on the OPT (imaginary) paging algorithm in that it estimates the distance to the next use of lexical variables, and when it needs to spill, it spills the one with the greatest estimated distance.
5:02:45
beach
More like deciding which register to spill to the stack when there are not enough of them.
5:15:44
beach
Registers are typically grouped into (overlapping) categories like general-purpose, caller saves, callee saves, floating point. Usually, any register in the right category will do for an operation.
5:15:45
beach
But when there are not enough registers, but you need for a lexical variable to be in a register even though right now it is not, you need to "steal" a register from some other lexical variable. Performance depends crucially on that choice.
5:16:37
beach
If you steal a register from a lexical variable that is going to be needed in a register fairly soon, you waste load/store operations.
5:23:10
no-defun-allowed
Yes, all of the compiler is written in Lisp. (This is also the case for SBCL and Clozure at least.)
5:32:53
charles`
I know that is the idea, but I just can't wrap my head around how you would manipulate registers like that.
5:34:32
aeth
Effectively, via custom "inline assembly" except it's syntactically just s-expressions so it's not really "inline assembly".
5:34:42
beach
Oh, you write a "code generator" in Common Lisp. You turn the Common Lisp code into machine code, and the program doing the turning is just another Common Lisp program. It is that program that inspects the instructions that are needed and makes decisions about what registers to use.
5:34:55
no-defun-allowed
You generate assembly in the end with any compiler. But the code manipulating the assembly is written in Common Lisp, yes.
5:37:04
charles`
hmm, so even though you aren't writing a compiler in assembly, there is some assembly written as output (maybe in a string). I got that it is at compile time.
5:39:19
no-defun-allowed
ACTION remembers "assembly" is the text form of machine code with labels and instruction names. Oops.
5:40:22
beach
charles`: As no-defun-allowed says, there is no particular reason for a compiler to generate assembly code. Assembly code was invented so that humans would have less trouble writing machine code. But a compiler does not need that human-friendly aspects that assembly provides.
5:43:18
moon-child
White_Flame: for the assembly representation, 'label' is more useful because it enforces an ordering, which you need to compute offsets (and decide when to generate short jumps, for supported platforms)
5:44:12
no-defun-allowed
I had generated acceptable assembly output from Cleavir's LIR once (which was used to make verifying it by eyeball somewhat easier).
6:17:21
charles`
Could someone help me understand how complex asdf are supposed to work. Ones with multiple systems defined in a single file, and stuff like cl-unicode/base
6:25:40
fiddlerwoaroof
charles`: I tend to find it's nice to group related systems into a single .asd
6:26:01
fiddlerwoaroof
ASDF now has some logic to complain if the system names don't follow a specified format, though
6:26:04
White_Flame
probably because they're intimately related. Broken out components of the same library for organization purposes, as well as tests & examples