freenode/#clasp - IRC Chatlog
Search
0:13:12
drmeister
Bike, cracauer: What do you think of this idea.... Currently to build aclasp, bclasp and cclasp we pass a list of partial pathnames to functions in clasp-builder.lisp.
0:14:38
drmeister
I will rewrite compile-aclasp so that it loads the files in a particular order and then compile-file's the source files in another order and links them in whatever order we want.
0:15:35
drmeister
The reason is to prepare for the coming GC of code and image building/dumping/loading we need more precise control over the compilation order.
0:16:33
drmeister
Currently we load all of the source files for aclasp in the order that we pass them in the command line.
0:17:12
drmeister
If I were to move the compile-file of setf.lisp to the end - then I could probably shave up to 10 minutes off of the build time.
0:18:08
drmeister
Why? Because then setf.lisp will be compiled by mostly compiled functions. As it is now, setf.lisp is compiled using mostly interpreted functions - and with MPS that takes 23 minutes!
0:18:51
drmeister
compile-file of setf.lisp --> Compile-file time seconds real(1412.0) run(1412.0) llvm(14.8) link(0)
0:20:26
drmeister
I haven't tried it yet, but if I moved setf.lisp compilation to the last files I think it will take a lot less time.
0:21:28
drmeister
The downside is that we will have separate lists of files that need to be maintained in clasp-builder.lisp and build_file_lists.py
0:23:08
Bike
i don't know about how it would affect speed, but separate load and compile sequences sounds like a good idea provisionally.
0:23:50
drmeister
In the future when we have GC managed code and image saving and loading I think aclasp, bclasp and cclasp will go away.
0:24:54
drmeister
All there will be is an explicit build script that will load files into the interpreter, then install the interpreted compiler, then load source code again, this time compiling it into JITted code, then loading what are now all of the bclasp files, then cleavir and then saving the image.
0:25:34
drmeister
There will be no incremental building - unless we decide to save an image at some intermediate stage and pick up from there.
0:26:23
drmeister
Is sbcl-ish a good thing in this case? Because you know how I revere everything sbcl.
0:28:15
drmeister
cracauer: Could you elaborate on your question "wouldn't we have enough debug info around to not even need to load a second time?" --- The purpose of loading things more than once in my mind is to first load code as interpreted s-exps and the second time to have the toplevel forms compiled and JITed.
0:30:29
drmeister
From what I read they look very similar but the reporters said the feel is different.
0:31:26
drmeister
Not as loud, smoother feel. I haven't heard any reports about how they behave six months in when a nanoparticle enters the butterfly mechanism.
0:32:34
cracauer
cases seem to be the same, aka of you want 4 ports then you have to take the touchbar.
0:42:36
cracauer
I have a first-generation 12" macbook, which is the worst of the butterfly keyboards. The main problem isn't even that keys go out. The main problem for me is that the key feedback is just leading to errors.
0:46:26
drmeister
But I need one that has no extra keypad on the side - so it can fit in a backpack.
0:51:18
cracauer
I ordered one each of the reduced keycount layouts. I think one of them will be small enough to drag around in my camera bag.
0:54:58
drmeister
(1) The static analyzer can tell us what classes have extra C++ information (on the C++ heap) that needs to be saved/loaded. Those that have extra info we can handle specially with obj_save/obj_load or eliminate from memory before saving the image.
0:56:00
drmeister
(2) I added code to generate backtraces whenever classes with a certain stamp are used to make an instance - this will let us track down where objects are being created and eliminate the problematic ones.
0:57:12
drmeister
(3) it will cut the build time in half - currently we load/compile/jit all of the code and then we compile-file it again and link it. Once we do image save/load we will only need to load/compile/jit and then dump the code.
1:18:05
cracauer
It is an interesting step. Normally the image saving of a system is done when they have their own GC and the GC is very primitive.
1:19:17
drmeister
I read about a proposed summer of code project that had as its goal to add MPS to sbcl.
1:24:15
cracauer
It was the phase where I was disappointed in GC speedups. All those hacks we tried didn't do much. Following a few pointers more or less (like 2x) didn't really make a dent into the time that was dominated by memory bandwidth and locality.
1:25:50
cracauer
When scavenging (scanning) a block of heap words it pretty much doesn't matter how many words you can skip looking at (in that block). As long as you don't needlessly follow more pointers the CPU just blasts through that. It is in a L1 cache line anyway and yo can noodle around almost for free.
1:29:49
cracauer
What you need is tools that allow you to figure out what could be effective without you having to implement a full GC change.
2:55:52
Kevslinger
I will be entering my third year of undergraduate study in the fall. Though the intermediate steps are unclear (Temple has some programs I may participate in which could extend my time there), the end goal is to enter a PhD program in some form of CS (right now Machine Learning / Natural Language Processing are the frontrunners for concentration).
3:05:21
beach
What cracauer is saying about GC is interesting. I don't understand the details because I don't know what SBCL does sufficiently well, but it will be interesting to see the performance of my planned SICL GC in comparison. Not imminent of course.
3:07:19
beach
It is also interesting to see what the plan for Clasp is. It is good that dead code will be possible to collect, but is live code going to be copied? I seem to remember some negative impact on cache performance for such things.
3:25:06
beach
This pool stuff sounds magic, but in the end you only have a linear memory, so the pool organization is going to have an influence as well I would imagine.
3:27:18
beach
Maybe one can now have any number of "holes" in the available memory and therefore manage any number of independent pools that can grow or shrink.