freenode/lisp - IRC Chatlog
Search
6:29:12
jdz
dim: My guess would be that SBCL has a fixed heap size, but CCL will dig into RAM until it is exhausted.
6:30:56
jdz
But I also like memory behavior of CCL better than SBCL, although having software with no upper bound to memory consumption is questionable.
6:58:11
aeth
Doesn't SBCL have a fixed default, like 1 GB or something (the manpage says it's platform-dependent)? Depending on what you're doing, you might prefer if it sets the starting heap based on total RAM instead, even though you can't adjust it later. There might be a way. "--dynamic-space-size <megabytes>" if that's launched from a shell script, there's probably something you can put inside of a $() to come up with a reasonable value.
7:42:44
luis
aeth: somewhat surprisingly, the GC will automatically use more space proportionally to the dynamic space size, so you're not just increasing the upper bound but also the lower bound (average bound? something like that)
8:25:09
p_l
SBCL on amd64 has default dynamic space size of 8GB. CCL on the same platform uses default dynamic space of 512GB
8:41:57
luis
p_l: I'm pretty sure the default is 1 GB: https://github.com/sbcl/sbcl/blob/88b98e2d20e0f7f85d2b26ee90dc1c775004d84d/src/compiler/generic/parms.lisp#L130
9:04:32
pve
Good morning! As part of a dogfooding exercise, I've made a simple linked list class, and now I'm looking at the output from sb-sprof and I'm wondering if someone could help me interpret it.
9:07:52
beach
I am not an expert, but it looks that way to me. SBCL generic dispatch is apparently not that great.
9:10:39
beach
SBCL uses PCL which was designed at a time when a memory access had roughly the same cost as a register operation, so table-driven techniques seemed appropriate at the time.
9:13:22
jdz
beach: Right, that seems to be the case for me, as well. Not profiling my code often enough.
9:49:22
beach
pve: That's correct, they are no longer appropriate. SICL generic dispatch compares a register to small constants, so the entire dispatch remains inside the processor.
9:53:41
beach
Great! If you have any questions, feel free to ask. #sicl might be more appropriate depending on the level of detail.
10:25:02
dim
jdz: typical memory usage of pgloader using CCL is ~400MB during a whole load, whereas it would exhaust a 4GB heap on SBCL with the same operation
12:48:26
ldb
beach: I'm reading the generic-dispatch paper. Does "immediate object" indicates that it is limited to certain data can be fit into a register?
12:51:02
phoe
so if I read this correctly, this means fixnums, #+64bit single-floats, characters, and such
13:03:31
pve
beach: I've also read the paper, very interesting.. at some point I may want to think about how the dispatch is done in this little language I'm working on
13:05:21
pve
it's a bit simpler, in that methods "belong to classes" like in smalltalk, and they only specialize on the recipient of the message (i.e. "self")
13:05:42
phoe
one option is to defer dispatch to the host CLOS and wait for that host CLOS to become good/fast enough
13:07:31
beach
So, I have a theory that C++ dispatch could be made faster if it used my technique. Currently, they try very hard to use a table-driven approach using so-called VTABLEs.
13:08:25
beach
And I think when they have multiple inheritance, the tables must be nested, so that should result in several memory accesses.
13:12:10
jackdaniel
it is. this approach makes writing c++ class extensions as dynamically loaded libraries not feasible at all
13:14:08
dlowe
they're "v"tables only to support so-called virtual methods. Non-virtual methods are resolved according to declared type, ignoring the type of the object
13:17:25
jackdaniel
ldb: but C and C++ make use of it, and they are fairly popular. only dispatch in C++ is crooked with this regard