freenode/#clasp - IRC Chatlog
Search
19:06:51
Bike
what is source-debug-use-lineno-p? it'sin function descriptions buti'm not sure i see anything actually using it
19:20:31
Bike
they have totally different mechanisms... the itanium way seemed harder to arrange, though
19:24:55
nickbarnes
The OS needs to figure out what the stack frame layout is, for any given RIP, so it can unwind. On Windows you register a helper function to tell it this information. Unfortunately, everything in the data structure and API for that helper function is 32 bits, so …. For starters, you have to register it separately for each 4GB of heap.
19:25:01
drmeister
Bike: The source-debug-XXX is something I added for slime and C-c C-c so that the temporary file that is generated can spoof the entire source file. I'm a little unsure of how it all works - but it does appear to work - so if I could leave it alone right now - that would be appreciated.
19:28:23
drmeister
Right - I think I had an idea that I needed to support the offset being a line number or an absolute character offset - that's what I think source-debug-use-lineno-p controls. I think it currently only uses one or the other - I don't recall which and I don't recall if source-debug-use-lineno-p actually does anything.
19:28:59
drmeister
The offset being the start of the snippet compiled with C-c C-c relative to the larger source file.
19:29:26
Bike
i'm not sure i understand how that could possibly be part of the description of a function.
19:30:07
drmeister
I don't recall right now either. I have have only partially understood what was necessary to implement C-c C-c properly - but this worked and I stopped once I had something working.
19:30:57
drmeister
It's only used for C-c C-c If we don't need the source-debug-xxx stuff - I can remove it.
19:31:53
drmeister
When I was implementing FunctionDescriptions I thought "I don't recall how this all worked - should I strip it out? .... No - I had a good reason for doing it back then - and I don't want to break slime right now - so I'll just carry the info into FunctionDescriptions and deal with it later if we need to".
19:32:09
drmeister
I got a whole two weeks out of that before you started asking me questions about it (sigh)
19:33:33
Bike
there's some weird stuff going on with the source pathnames that i'm looking at for the source tracking interface. particularly, if you use COMPILE, the function's source pathname is the string "repl-code", and various things treat that like a pathname
19:44:07
drmeister
Bike: I was messing around with FUNCALL in bclasp. I noticed that it was really slow because it's going through the C++ machinery that implements FUNCALL.
19:45:02
drmeister
I changed the code generator so that (funcall 'foo ...) compiles as (foo ...) and (funcall <something> ...) as (<evaluate something> ...)
19:45:47
drmeister
Meaning I generate code to evaluate the first argument and then call the result with the remaining arguments. That's all I need to do - right?
19:48:05
drmeister
Thank you. So at runtime I need to check the result returned by the code that evaluates the function and what are the possibilities? (1) It could be a closure - in which event I can just call it. (2) it can be a symbol - in which case I call the symbol-function. Anything else?
19:49:07
Bike
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cleavir/inline.lisp#L802-L811
19:55:01
Bike
deleting the lineno thing didn't break the build, and slime still works, and C-c C-c still works, and the source location is hooked up. so i guess it'sfine.
19:57:51
Bike
and i see, the source debug pathname business sets it up so that slime's temporary file is like the actual file for source pos reasons. right right right. that makes sense. maybe we can avoid storing it in the function though.
19:57:52
drmeister
I've been writing some code to time microbenchmarks to see if I can spot things that are really slow.
19:58:51
drmeister
It figures out how many operations can be run per second and summarizes them in terms of the log base 10 of the number of operations that can be run per second.
19:59:05
drmeister
The code needs to use funcall and funcall turned out to be a bottle neck in bclasp.
20:00:53
drmeister
I recalled that you wrote a compiler macro for cclasp - but that we can't use it because of ... startup/circularity/bootstrapping issues.
20:01:23
drmeister
So I thought since I control the bclasp compiler - I can implement the optimization in the bclasp compiler directly.
20:05:44
Bike
cleavir-primop:funcall is what you referred to as the "(<evaluate something> ...)" case
20:13:04
Bike
i see. we write in the *actual* source pathname for functions, so for slime, the tempfiles
20:29:50
Bike
good that i learn this now, because it means i set up source locations for classes wrong
22:46:15
drmeister
The debug information of the temporary file will be relative to the temporary file - won't it?
22:47:33
Bike
the source information written into the cst doesn't need to have anything about the temporary file at all, i don't think
22:48:10
drmeister
The temporary file name is passed to compile-file. That opens the stream and the stream file offset is relative to the start of the temporary file.
22:49:55
Bike
am i wrong? i mean, at some point we do need to worry about offsets and stuff, but i think we can handle that right off instead of preserving it throughout.
23:13:00
drmeister
Once you write the changes to the original file then the source file and offsets recorded in the debug info will be correct.
1:43:23
drmeister
Bike: Is your make-instance optimization in place - or is it stymied by startup/bootstrapping issues?
1:45:40
drmeister
make-instance is the first thing that jumps out at me as being radically slower in clasp than sbcl 1000x
1:47:35
drmeister
I wonder if we were to slow down clisp's make-instance by 1000x how that would effect it's speed of running cleavir.
1:51:37
drmeister
So: 5.40 (PUSH (MAKE-LIST 100) *MAKE-LIST*) (DEFPARAMETER *MAKE-LIST* NIL) means...
1:52:03
drmeister
10^5.4 (push (make-list 100) *make-list*) can be evaluated per second after (defparameter *make-list* nil) was evaluated.
2:04:24
drmeister
I'm trying to figure out why bclasp is so slow relative to clisp when running cleavir.
2:07:09
drmeister
When I compare cclasp with bclasp using these micro-benchmarks the numbers come out pretty close. It doesn't look like cclasp is getting us much in the way of performance.
2:08:31
Bike
maybe the real problem is we have all these confusing flags so we can't tell what we're benchmarking :p
2:21:58
drmeister
I'm looking for possible explanations why clisp is so much faster at compilation than clasp.
2:25:05
drmeister
I have this in one file called timing.lsp - I use (load (compile-file "timing.lsp")) What does that use?
2:27:20
drmeister
Right now I'm just benchmarking bclasp against clisp. bclasp is comparable and a bit faster on many things.
2:27:44
drmeister
Except make-instance is about 10x slower in bclasp. This gives me something I can test.
2:28:31
drmeister
I can slow down clisp's make-instance to a comparable degree and then compare how clisp+cleavir performs relative to bclasp+cleavir.
2:29:52
drmeister
I think it's fair to compare bclasp+cleavir to clisp+cleavir compilation performance.
2:30:48
karlosz
although you want to watch out and make sure you arent running clisp interpreted cleavir
2:34:51
karlosz
Bike: if you want to try the SSA, the ssa.lisp file is self contained. convert-ssa in that file will convert a closure converted hir properly.
2:36:37
drmeister
Clasp: 4.26 (MAKE-VGIBBLES :X 1 :Y 2 :Z 3) (DEFSTRUCT (VGIBBLES (:TYPE VECTOR) :NAMED) X Y Z)
2:36:53
drmeister
clisp: 6.73 (MAKE-VGIBBLES :X 1 :Y 2 :Z 3) (DEFSTRUCT (VGIBBLES (:TYPE VECTOR) :NAMED) X Y Z)
2:38:38
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/lsp/defstruct.lsp#L262-L269
2:40:37
Bike
well... that's a bit simpler https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/lsp/defstruct.lsp#L334
2:51:04
drmeister
7.25 (SETF (AREF *TARRAY2* 15) :TEST-SYMBOL) (DEFPARAMETER *TARRAY2* (MAKE-ARRAY 20 :ELEMENT-TYPE T))
5:05:54
drmeister
Some of the timing results were off a bit because of generic function discriminator compilation. I added a warm up stage to the micro-benchmarks that evaluates the form a few times before running the timing loop.