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
15:51:46
fwoaroof[m]
(It's been a long time, and I see C++ developers complain about virtual methods all the time these days)
15:53:11
fwoaroof[m]
I think it's a combination of dynamic dispatch being slow and dynamic dispatch makes control flow confusing
15:54:06
beach
Yeah, me neither. But given the table-driven dispatch, it might be slow in the eyes of a C++ programmer.
15:55:06
beach
But it was my impression that virtual methods and dynamic dispatch (which some people here say doesn't exist anymore) was one of the mechanisms required for the OO style that C++ recommends.
16:11:53
beach
I don't believe it, but this is not the right forum to discuss C++ and its implementations, so I did not protest too much.
16:15:28
jackdaniel
"Since C++ does not support late binding, the virtual table in a C++ object cannot be modified at run-time, which limits the potential set of dispatch targets to a finite set chosen at compile time. "
16:16:14
jackdaniel
(taken from wikipedia, but it matches my prior knowledge) -- https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implementation
16:16:59
beach
Limiting it to a finite set sounds different from "all resolution is done at compile time"
16:17:27
dra
So it's instruction cache vs. branch prediction. Not that it generally matters much anyway.
16:17:54
beach
But I am not going to participate any further in this discussion. It is off topic, and I need to go start dinner anyway.
16:17:54
jackdaniel
uhm, at least this "finite set" is what I've meant when I said that it is indeed sad and that you can't extend it by loading .so libraries
17:01:27
sjl_
This should work and return (1 nil 2 nil) right? (loop :with (a b) = '(1) :for (c d) = '(2) :do (return (list a b c d)))
17:01:33
sjl_
> During loop expansion, each variable in the variable list is matched with the values in the values list. If there are more variables in the variable list than there are values in the values list, the remaining variables are given a value of nil.
17:01:57
sjl_
It works like I expect in SBCL and CCL, but signals an error in ECL and ABCL. Am I misreading the spec?
17:05:45
scymtym
jackdaniel: quick, check SICL loop. maybe it behaves like ECL and ABCL. you can still get a majority
17:07:48
jackdaniel
I've reported the issue: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/605
17:08:05
easye
sjl_: According to the CLHS paragraph you quoted, the references should clearly by NIL.
17:08:49
jackdaniel
ACTION walks away while pretending that he does not hurry to be faster than easye with the fix
17:08:58
sjl_
easye: yeah that was my reading. But two unrelated implementations having the same behavior made me second guess myself
17:10:13
sjl_
It would be convenient if it destructured like destructuring-bind, but that would complicate the (loop for (a b c) of-type (integer integer float) in ...) type declaration syntax I guess
17:14:16
jackdaniel
easye: "just" using sicl's loop is buying into a strategy, where you bootstrap from fully-features common lisp - that is a fine strategy, but not something automatically agreeable. I think that sicl's loop implementation requires working loop implementation
17:15:13
jackdaniel
you may always replace abcl's loop /after/ everything is built, so you have your old loop for building abcl, and this new loop for users
17:15:53
jackdaniel
adopting first class global environments will allow even switching loop implementation by the user without breaking the implementation internals
17:16:42
jackdaniel
but still doing all that is not the most obvious thing to do where it comes to fixing a bug ;)
17:18:01
sjl_
jackdaniel: for 100% clarity, in the issue you linked, it should work for both WITH and FOR
17:19:06
sjl_
No idea if with/for are implemented by the same code or not, so might be worth checking both.
17:22:02
fwoaroof[m]
I tend to care about this sort of issue, because it's the sort of thing that prevents me from using the libraries I like in LispWorks
17:26:00
ferada
hiya, anyone worked with commonqt/qtools/... and possibly has an example of subclassing/delegates usage (e.g. for custom listview elements)?
17:30:49
fwoaroof[m]
Depending what you need, maybe this? https://github.com/Shinmera/qtools/blob/master/examples/melody/melody.lisp
17:32:11
fwoaroof[m]
I believe this also used qtools extensively: https://github.com/Shinmera/parasol
17:37:40
fwoaroof[m]
https://lisp-journey.gitlab.io/blog/gui-programming-in-common-lisp-part-1-of-5-tk/
17:40:16
fwoaroof[m]
https://gitlab.com/eql/EQL5 maybe too, it's embedding strategy seems more stable to me than attempts to FFI
17:43:10
fwoaroof[m]
There's some valiant efforts to maintain GUI toolkits in the various programming language communities, but there's little money or thanks in that effort
17:45:46
fwoaroof[m]
And the big toolkits that do exist (Cocoa, Gtk, QT, Flutter) are actively hostile to using non-approved languages
17:46:08
ferada
well i'd wish to have more resources to dedicate to native ui, but time's limited isn't it
17:46:39
fwoaroof[m]
(I believe the Gtk developers, for example, explicitly have said something like "we don't care about non-Gnome use cases"