freenode/#clasp - IRC Chatlog
Search
15:14:12
drmeister
scymtym: I'm pretty sure it's clasp - it looks like SLOT-VALUE was incorrectly placed in the CLOS package rather than the COMMON-LISP package. Testing now...
15:19:43
karlosz
is there any type representation like what sbcl's #'sb-kernel:specifier-type returns in cleavir?
15:21:27
beach
I don't know what that is. Maybe Bike is more familiar with SBCL. And he has been working on the type inferences in Cleavir as well.
15:22:36
karlosz
the closest thing i could find was the type descriptors in the type inference folder, but th type lattice there is very coarse
15:23:26
karlosz
its used for the type lattice in sbcl which is how it does its constraint propagation pass (i.e. its type inference like capabilities)
15:33:03
drmeister
cclasp is now compiling once I moved the slot-value symbol into the common-lisp package.
15:38:43
drmeister
Clasp now reports time spent compiling, llvming(?) and linking - it's way off the mark on compile-file - I'm working on that.
16:17:04
drmeister
The new times that are being reported have some problems - so don't believe them yet. I'm working on that.
16:36:00
drmeister
I found the problem timing compile-file - I actually have to time the compile-file.
16:54:58
Bike
so mps won't work unless the static analyzer has run since the last change to theC++ hierarchy, right?
16:55:39
karlosz
Error (METHOD-CALL-ERROR) during printing: #<CLEAVIR-CST-TO-AST:INCORRECT-NUMBER-OF-ARGUMENTS #x0000100000B21299>
16:56:29
drmeister
I fixed the compile-file timing issue and now it accurately reports the llvm time spent generating code, optimizing, and generating object files.
16:58:32
Bike
it seems to me like putting bit vectors and null terminated strings in their own pools might be helpful
17:05:04
scymtym
karlosz: could be because there is no REPORT-CONDITION for that condition type in Code/Cleavir/CST-to-AST/condition-reporters-english.lisp
17:06:30
drmeister
Because SimpleBaseString_O and SimpleBitVector_O are already stored in the AMCZ pool - this pool is for objects that don't contain internal pointers
17:06:56
drmeister
Bike: You know this already - right? static GCInfo_policy constexpr Policy = atomic; means the AMCZ pool.
17:07:41
Bike
i think the more important thing is just cutting them out of obj_scan, which is easier.
17:08:01
Bike
the mps docs are really insistent that obj_scan should be as fast as it can possibly be, and right now we're doing a few conditionals that will never happen.
17:08:48
drmeister
Because that is straightforward as well. We add the new pools, we add the thread-local allocators for those pools, we define a new policy (a C++ type) for those pools and a template class that maps the policy to the allocator at compile-time and then we specify static GCINFO_policy constexpr Policy = your_new_pool_policy;
17:12:08
Bike
anyway yeah. just poking around there. i saw you put in some stuff to inline cl:cons, too.
17:13:57
drmeister
For boehm we just keep using the same pools we use now - because they don't support additional fancy pools.
17:15:45
drmeister
Yes, now that we know that MPS is going to be the production GC, I wanted to convince myself that I could get the cons allocator inlined in the CL code. It's doable with __attribute__((always_inline))
17:16:38
drmeister
Right - boehm doesn't have pools, it does have a MALLOC for objects that don't contain internal pointers
17:19:45
drmeister
This is the typical thing that I'm getting when timing compile-file (here with Boehm compiling alexandria/numbers.lisp) Compile-file seconds real(160.2) run(160.2) llvm(142.6) link(0)
17:20:52
drmeister
This is running bclasp compiled cleavir. bclasp isn't so pokey now that I added the my llvm-ir editing optimization passes.
17:25:00
drmeister
We need to look carefully now at LLVM to see what it is doing and whether it is running redundant optimization passes that add no value to the clasp runtime.
17:51:31
Bike
drmeister: was there a problem assigning to function descriptions? like changing a docstring for example?
18:04:52
drmeister
Now I'm compiling predlib.lsp with cclasp (again Boehm) The timing is: Compile-file seconds real(12.2) run(12.2) llvm(4.0) link(4.5)
18:07:32
drmeister
cclasp compile-file of alexandria/numbers.lisp - Compile-file seconds real(30.4) run(30.4) llvm(12.6) link(9.9)
18:10:15
drmeister
Also, cclasp spends 22.5 seconds in llvm+link and bclasp+cleavir spends 142.6 seconds in llvm+link
18:13:10
drmeister
stassats: There is a -O0 build. I'll run that later tonight and report back the comparable results.
18:18:01
Bike
it's just that when i tried setting things up to do that i got really weird errors that make me wonder about corruption
18:18:02
drmeister
But what you are actually doing is assigning to slots in the CONTAB vector indexed by a fixnum index in the FunctionDescription.
18:20:01
drmeister
Make sure you aren't actually writing into the FunctionDescription. The FunctionDescription is one pointer to the CONTAB vector of literals - these are all of the literals for the Module.
18:21:01
drmeister
The remaining fields in the FunctionDescription are either integers or indices into slots in the CONTAB vector
18:23:58
Bike
void setf_docstring(T_sp x) const { this->fdesc()->gcrootsInModule->set(this->fdesc()->declareIndex,x.tagged_()); }
18:53:13
drmeister
Uh - I just noticed - this is the setf_docstring function but you are using the declareIndex
18:56:09
Bike
i think this might have messed up the build somehow, but also there's a lot of output just in aclasp, so i guess it works on itsown
18:57:22
Bike
the problem that happens if i change (setf documentation) to use (setf function-docstring) is a type error in https://github.com/keithj/alexandria/blob/master/macros.lisp#L310-L311
18:57:44
Bike
which is magical and doesn't trigger the debugger. the type error is apparently in the loop itself, rather than in the (setf documentation) function.
19:20:52
drmeister
I just gave my talk - it went well as judged by the gauntlet of "well done's" I got leaving the podium - it will take a little while to come down and focus.
19:21:47
drmeister
But why is your body: void setf_docstring(T_sp x) const { this->fdesc()->gcrootsInModule->set(this->fdesc()->declareIndex,x.tagged_()); }
19:23:00
drmeister
Ok - so you have: void setf_docstring(T_sp x) const { this->fdesc()->gcrootsInModule->set(this->fdesc()->docstringIndex,x.tagged_()); } in your code
19:24:06
drmeister
I realized I can try -O0 very quickly with: (let ((cmp::*optimization-level* 0)) (time (compile-file "/Users/meister/quicklisp/dists/quicklisp/software/alexandria-20170630-git/numbers.lisp")))
19:34:34
drmeister
https://www.google.com/search?q=beautiful+gauntlet&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwirqNCbsqncAhWoVN8KHalzDmEQsAQIJg&biw=1230&bih=926#imgrc=FJ7BvGR279xfiM:
20:05:14
Bike
the problem is if i change the definition of (setf documentation) in clos/inspect.lsp, and build with that
20:07:21
Bike
basically it just calls setf function-docstring instead of using set-documentation or annotate or whatever
20:07:47
drmeister
Right - that sounds like the proper thing to do now that we have function-descriptions
20:41:35
Bike
i get it twice, which might be weird, since it should be setting docstrings of two different functions
20:43:59
Bike
i mean, it builds the clasp executable, but when it starts the executable to build serve-event and asdf it fails.
20:44:13
Bike
so i can start the clasp executable afterwards and it runs, but with the weird type-error.
20:45:02
Bike
with lldb i intercepted and found that it's in the alexandria form i linked before, but there's basically no info in the backtrace
20:46:17
drmeister
Not starting the debugger means something is broken. If I had a penny every time the debugger didn't start ... I'd have a lot of pennies.
20:48:36
drmeister
Try those other break points - maybe its not making it to cl__error. cl__error is the entry point from Common Lisp. The type error may be in C++.
20:48:49
attila_lendvai
hi! drmeister: do you have an estimation on how long until the dust settles on the new way of clasp startup? i.e. is it a couple of weeks, or a couple of months?
20:50:44
drmeister
General: I'm building cclasp using *optimization-level* bound to 0. Essentially -O0 for everything.
20:54:14
drmeister
Bike: It is calling ERROR - so it's coming from Common Lisp - gotta think on that.
21:21:13
drmeister
(let ((cmp::*optimization-level* 0)) (time (compile-file "/Users/meister/quicklisp/dists/quicklisp/software/alexandria-20170630-git/numbers.lisp")))
21:22:24
drmeister
When I compile cclasp using -O0 - so the compiler is now de-optimized and I'm going to compile numbers.lisp the same way I just reported...
21:23:39
drmeister
So we are spending a lot of time optimizing cclasp to get marginal improvement in performance.
21:26:26
drmeister
Bike: That type-error you are getting - it's coming from this top level form - right?
21:27:07
Bike
in a minute i'll pinpoint the particular function again, but i think it's from the(setq name (first %dolist-var))
21:28:42
drmeister
Ok, I'm going to walk and get a sandwich before the streets roll up and I'm forced to pay a ruinous price for a lousy meal in the hotel restaurant.
21:46:02
drmeister
I kind of think we must - right? We must have been testing for list before and if that was broke - then everything would be broke.
22:33:32
drmeister
Building cclasp at -O0 took 56m40s - so turning off optimization isn't that big of a win.