freenode/#clasp - IRC Chatlog
Search
16:01:29
drmeister
I wrote a compile-file2 function that separates out AST compilation from everything else.
16:02:34
drmeister
If I compile-file2 a file and suppress everything after compiling the AST the compilation of predlib.lsp takes 6.6 seconds.
16:05:46
drmeister
So if we parallelized the compilation after the AST we could get up to a six-fold speed up of the compiler. (assuming additional cores are kept very busy).
16:08:16
drmeister
quicklisp is serial and now it's taking more time than building the rest of the system.
16:11:04
drmeister
We are always going to be slow with the llvm compiler - we can reduce the amount of code we give it (working on that) but it's always going to be slow.
16:12:58
drmeister
Oh - the literals. No we don't have any new solutions there. What do you recommend?
16:15:35
Bike
right now we, like, compile a bunch of calls just for easy shit like numbers and conses
16:20:22
stassats
you just need to do prin1-to-string, and then read-from-string, with some special print-object mode that handles anything you need to serialize
16:21:27
stassats
which can simply print out #.(make-array 3 :element-type 'fixnum :initial-contents '(1 2 3))
16:24:50
[1]ringer1
drmeister, saw the talk to LLVM devs from a few weeks ago, excellent, hearing you speak always leaves me wanting to hear even more.
16:27:11
scymtym
Bike: drmeister: does clasp use ECLECTOR.READER:{FIXUP,WRAP-IN-*}? i would like to make those consistent with the rest of the protocol (which requires lambda list changes) as i document and test them
16:29:37
drmeister
Bike: When compile-file compiles literals - maybe we could take the literal vector and write it out using the fields/(de)serialization protocol.
16:36:03
drmeister
We have this facility built into clasp for serializing complex objects. C++ classes have a 'fields' method that serializes and deserializes objects. It works with the CL printer and handles circularity.
16:43:48
drmeister
The literal table that we generate - can we just write it out and then read it back in?
17:45:03
drmeister
Ok - so when we compile-file code we get this object that describes the constants/literals
17:46:57
drmeister
It's a linear sequence of instructions to invoke functions that create objects at the index indicated right after LITERAL-NODE-CREATOR
17:47:26
drmeister
#(LITERAL::LITERAL-NODE-CREATOR 0 "ltvc_make_nil" "NIL" NIL) --> Puts NIL at position 0 of a vector of constants/literals/roots.
17:49:54
drmeister
It then puts the string "ERROR" at index 2, string "COMMON-LISP" at index 4, looks up the package "COMMON-LISP" using the string at index 4 and puts it at position 3, interns the symbol COMMON-LISP:ERROR at index 1 ...
17:50:41
drmeister
So I guess the idea is we run this little program at compile-time and serialize the vector that it creates?
17:54:25
drmeister
There are funcalls in there as well - top-level forms and load-time-values - but they all run in the top level environment - so I should be able to move them out.
18:03:26
drmeister
Yeah - could that work? We run the literal-node-creator program at compile-time and serialize the resulting literal/constant vector. We would move the funcalls out of the code and they would run after the literal vector is initialized.
18:14:49
drmeister
A simple first test would be to pull the LITERAL-NODE-TOPLEVEL-FUNCALL's to the end - if it still worked - then the LITERAL-NODE-CREATOR's can run independently of the LITERAL-NODE-TOPLEVEL-FUNCALL's and they could be run at compile-file time if we can figure out how to serialize the result in a more compact form.
19:30:19
drmeister
I think I'm coming around to what you are suggesting. When we compile-file build this list of instructions that is then compiled to code that constructs the constants/literals table.
19:30:50
drmeister
I think I can construct the constants/literals table at compile-time and then I just need to figure out how to serialize it and de-serialize it.
19:31:52
drmeister
It might be simple as printing the table and reading it - but I'm not sure about that yet.
19:39:27
drmeister
Nvidia's stock dropped 20% yesterday - I suspect it's because hardly anyone showed up at my talk.
19:45:56
drmeister
That's not causality - it's coincidence. They've got way too many people focused on fads.