freenode/#clasp - IRC Chatlog
Search
16:02:44
drmeister
I learned a bunch of things while at the llvm meeting. (1) a solution to debugging jitted code (working on that now) (2) A way to parallelize the slow parts of the compiler.
16:03:48
drmeister
The ORC JIT has had a big upgrade to deal with the slowness of llvm. They have this scheme where compilation is deferred until the user wants to compile things and then compilation happens in parallel.
16:04:04
minion
Bike, memo from beach: This is totally brilliant. I am convinced that it works. 1. Figure out whether any implementation does it. 2. If not, figure out what happens to the methods and call history as a result of DEFCLASS, and DEFTYPE. 3. Write it down. 4. Submit to ELS.
16:04:04
minion
Bike, memo from beach: There would be three kinds of methods: always false, always true, and requiring some action (for example if there is a DEFTYPE that expands to a compound type).
16:05:59
drmeister
I've honestly been spending the last 48 hours dozing or sleeping - that trip wiped me out.
16:11:53
drmeister
The new ORC API isn't yet in llvm7 (current) they will be in llvm8. So it means to work with them I'll have to move to tip of trunk again.
16:16:51
drmeister
https://github.com/llvm-mirror/lldb/commit/2829ee8e179e9d3381de08dba1502351e34867c0
16:17:46
drmeister
Lang Hames (developer of the ORC JIT) is going to see if he can get that changed when he gets back next week.
16:34:47
drmeister
The commit message says: "Disable JITLoaderGDB on "vendor == apple" for now due to performance … …slowdowns for every first run process as a global name lookup in all shared libraries if performed."
16:35:44
drmeister
But we were all a bit mystified why something so useful would be disabled rather than fixing the real problem.
16:48:37
drmeister
Who knows - but there were at least three people at the meeting who had tried to debug jitted code (me included), followed all of the directions on the internet and been completely mystified why it didn't work on MacOS.
16:54:34
drmeister
In addition to this there are three other steps I was given and the last one was looks like a doozy.
16:54:54
drmeister
"Last but not least, emit ELF objects instead of MachO or implement LoadedMachOObjectInfo:: getObjectForDebug() properly :)"
17:00:50
drmeister
Do you know something I don't? I don't know what we emit from the JIT - I can figure it out though.
17:01:31
drmeister
I figured it was whatever llvm felt was appropriate for the operating system we are running on.
17:05:16
drmeister
I'm trying to figure out how to use the JIT to parallelize the slow parts of compilation and save the results for later reuse.
17:08:19
drmeister
If we also parallelize AST->HIR and HIR optimization - then we can do more optimization without worrying so much about compile time.
17:09:40
Bike
okay because you said "they have this scheme where compilation is deferred [...] and then compilation happens in parallel"
17:09:50
drmeister
The new ORC machinery allows llvm to compile multiple modules to object files in parallel - so the backend is ready.
17:11:19
drmeister
At the meeting Lang demonstrated how the ORC JIT can be used to defer compilation to the point where the symbols that a compilation defines are needed. But after thinking about it for a few days I'm not sure the deferred aspects are that useful for Common Lisp.
17:13:08
drmeister
They way they described it, we would load a form, tell ORC what symbols the form will generate and then register the compilation so that it can be deferred.
17:14:01
drmeister
The semantics of Common Lisp (REPL) demand that we evaluate each form as it comes up. With Cleavir that means that we at least construct the AST - right?
17:15:42
drmeister
Will constructing the AST cause (eval-when (:compile-toplevel) ...) to be evaluated?
17:19:41
drmeister
I'd like (asdf:load-system xxx) to compile and load the system running as much of the compiler in parallel as possible and make the results of the compilation available next time for loading.
17:23:53
drmeister
If we wanted to parallelize compilation of forms in the compile-file, we would have to break it up into one module per top level form.
17:25:26
drmeister
No, I was thinking that compile-file could load each top-level form, generate the AST for it and then submit it to a thread queue to compile it to an object file.
17:27:06
drmeister
There is also load an entire file, generate all of the AST's and then submit the list of ASTs to a thread queue to compile them all to an object file.
17:28:46
drmeister
A loop where you (1) read each top-level form into a CST and (2) generate an AST (3) do something with the AST for each top-level form in the file.
17:29:42
drmeister
do something with the AST means (1) submit it right away (2) accumulate it in a list and submit it once the entire file is loaded.
17:30:29
drmeister
I'm confused about whether we can load the compiled results back into the system in that session or only in subsequent sessions.
17:33:44
drmeister
Bottom line: I know how to run llvm in multiple threads - can we use this given the semantics of Common Lisp.
17:36:29
drmeister
You and I have talked about parallelizing the compiler, beach has talked about it - I know how to get the backend to work with parallel compilation, I wasn't sure how to do it before.
17:41:15
drmeister
I'm looking for creative suggestions from people who better understand the ins and outs of Common Lisp semantics on how to move forward with that idea.
17:48:22
Bike
well the bottom line is that if we're compiling a file, we have to process the ASTs in order, but after that we can do things in whatever order we like.
17:53:15
drmeister
Hmm, does it compile-file all of the files of a system and then load all the fasls - or does it load each fasl as it comes available?
18:01:16
drmeister
Currently compile-file generates one module for the entire file so we can't parallelize a single compile-file.
18:08:32
drmeister
When we talked about parallelizing the compiler you remarked on how it's problematic because currently compile-file invokes llvm very early, in the outer-loop of compile-file. We could remove that and do all the llvm stuff just before we lower to llvm-ir.
18:11:30
drmeister
Then we could parallelize the compilation of top level forms within each compile-file and all threads would rejoin at the end of the compile-file.
18:12:31
drmeister
Where I was getting confused is I was thinking we could do this with LOAD as well - although now I'm not sure there is a point.
18:16:27
drmeister
The parallelization in the ORC JIT is relevant for a language where you load an expression, register symbols that it will define, defer its compilation and only when you need to call one of the symbols that were deferred will it compile everything in parallel that is required to call that symbol.
18:19:29
drmeister
If we move llvm stuff to the end - then we can still generate one module for the entire compile-file or one module for each top-level form. To compile in parallel within one compile-file we need to generate one module per top-level form.
19:36:52
drmeister
These are all the macros of compile-file that need to be moved into loop-read-and-compile-file-forms https://usercontent.irccloud-cdn.com/file/uY7oMzHf/1540150528.JPG
19:39:28
drmeister
Bike: I'm getting this error when building slime - is it anything you have been working on recently?
20:14:54
drmeister
I'm going to try writing a new compile-file. One that only invokes llvm after an AST is generated.
20:56:39
drmeister
hoist-ast - is it part of generating the ast or is it part of translating the ast?
20:57:14
drmeister
I'm guessing it's part of translating the ast - because it generates indices into the literal vector.
21:00:37
Bike
generate-ast and cst-to-ast is where compile time stuff is executed. it can't be paralellized in the main
21:01:34
drmeister
Understood - but then there is hoist-ast and translate-ast - does anything happen in those that cannot be parallelized?
21:02:14
drmeister
I'm trying to find the boundary between where parallelization can be done and where it cannot.
21:05:52
Bike
hoisting probably COULD be done in parallel, but right now i think it's tied to llvm pretty closely and i don't know.
21:07:43
drmeister
When you build with CST - where were you running into trouble with the inlining code?