freenode/#lisp - IRC Chatlog
Search
17:44:34
p_l
JuanDaugherty: a lot of difference is that Haskell is the baby of academic PL research, you can see similar effort in Racket which has same case
18:17:30
jasom
beach: One thing I've noticed is that some of the literature assumes most allocations are small; e.g. comparisons of space overhead in mark/sweek vs. semispace often assume that the typical allocation size is 2 words (i.e. a cons cell). I also agree with didi, in that a lot of real world code these days run on VMs, which are often quite tightly memory bound, so going over your memory allocation means swapping,
18:17:32
jasom
which hurts more than more frequent GCs. Also I have often seen SBCL quit with the heap exhausted just because it is so conservative about when to GC that it waits until it is too late...
18:19:25
jasom
Were earlier time-share systems that lisp ran on single address space? VMs tend to have fixed partitioning of RAM, which means CPU time can be time shared, but memory cannot...
18:46:02
p_l
jasom: also, a lot of problems with GC'ed languages these days is at the huge heap sizes
18:47:49
jasom
The graph on the left was not made by me, but it fits my experience with SBCL: https://tech.grammarly.com/assets/articles/lisp-mem.jpg
18:48:25
jasom
for maximizing throughput you put off GC as long as possible, but that has repercussions...
18:49:07
p_l
Azul, Shenandoah and similar make for nice solutions, but they aren't exactly doable for SBCL
18:49:35
jasom
I ran into a similar issue with a wear-leveling flash file system. It would have great throughput, but then just stop responding for 30 seconds. Investigation determined that it was delaying moving data as long as possible to decrease write amplification.
18:50:05
jasom
p_l: well the graph on the right was made after implementing a simple workaround for sbcl (just manually GC on a timer)
18:51:18
jasom
p_l: though the true metronome requires an incremental collector; if you set aside X% of CPU time for GCing and you can GC incrementally, you are now realtime.
18:51:55
jasom
or rather you can achieve realtime. True hard realtime systems require a lot of analysis, so it's the job of the various tools to make analysis tractible.
18:51:59
p_l
jasom: well, so long as you ensure that GC runs within specified quanta and not any longer you technically have metronome
18:54:10
jasom
but yes, SBCL with a 1GB heap and a background thread invoking the GC every few seconds can probably be made to meet a hard realtime requirement of 2-3 seconds :)
18:54:30
jasom
though there are a troublingly large number of places where GC is excluded in the runtime.
21:13:35
stacksmith
Good morning. Is there some hook in the pretty-printer to track its progress across the list being printed? For instance to know what object is printed on a fresh line, etc.
23:07:14
specbot
Pretty Print Dispatch Tables: http://www.lispworks.com/reference/HyperSpec/Body/22_bad.htm
23:09:00
pillton
It won't tell you what object is printed on a fresh line, but you could possibly use a custom stream and an entry in the dispatch table to get that information.
23:19:03
stacksmith
pillton: a browser/debugger of sorts. I would love to not reinvent the wheel with layout/indentation but have some idea about where things wind up.
3:16:48
blep-on-external
how do i get all the class slots of a class? i've tried sb-mop:class-slots but it doesn't have applicable methods for the symbol or an instance of the class
4:11:43
beach
blep-on-external: Either you have TABs in your code that pastebin can not handle, or you line starting with COLLECT is incorrectly indented.