bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
kevingal_ has quit [Ping timeout: 255 seconds]
kevingal has quit [Ping timeout: 255 seconds]
rogersm has quit [Read error: Connection reset by peer]
rogersm has joined #commonlisp
jeffrey has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
tyson2 has joined #commonlisp
occ has joined #commonlisp
<shunter>
Hey nij- I just got your message on posix-shm, I haven't logged onto my bouncer for months and I'm not sure how long that message was. Could you repeat it here if it wasn't too old?
<shunter>
I've did a fresh download from quicklisp and while I'm getting first-time compiler warnings from grovel, no errors on quickload.
NicknameJohn has joined #commonlisp
<shunter>
Ah.. that was 5 days ago
<shunter>
Ohh I see, I need to generate the spec files so that users of the library doesn't have to install c2ffi
dcb has quit [Read error: Connection reset by peer]
dcb has joined #commonlisp
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
dcb has quit [Quit: MSN Messenger v2.16.1]
epony has quit [Remote host closed the connection]
jeosol has joined #commonlisp
nij- has joined #commonlisp
occ has quit [Ping timeout: 276 seconds]
occ has joined #commonlisp
nij- has quit [Ping timeout: 240 seconds]
tyson2 has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
epony has joined #commonlisp
kevingal has quit [Ping timeout: 250 seconds]
kevingal_ has quit [Ping timeout: 250 seconds]
epony has left #commonlisp [PART]
<beach>
Early on in the SICL project, I wrote code for functions in the Conses dictionary, and I had this idea that there would be a compiler macro for functions such as MEMBER or ASSOC that will avoid the keyword argument parsing, and that would have more efficient versions for a KEY argument being IDENTITY and a TEST argument being EQL or EQ.
<beach>
So I ended up with a dozen or more special versions of many functions. Just naming these special versions was a headache. Now, I am working on extracting (and improving) the functions in the Conses dictionary to a separate repository, and I am questioning this early decision to create so many special versions.
<beach>
Perhaps one single special version without keyword parameters would be enough? That version would then have a test to see whether the KEY argument is IDENTITY and whether the TEST argument is EQ or EQL, so it would have a few more tests. But maybe that overhead will be negligible compared to the body of the function. Thoughts?
tibfulv has quit [Remote host closed the connection]
tibfulv has joined #commonlisp
<beach>
Also, it is likely that SICL itself won't need the compiler macro because of the technique for call-site optimization that I came up with, so I hesitate putting in too much work that will be useful only for other implementations (of which there is likely to be none) that use the new library.
<beach>
I guess I could try to come up with a macro or some other code-transforming code to generate the special versions (and the compiler macro) automatically.
<edwlan[m]>
That was my inclination
<edwlan[m]>
But it might not be worth it
<beach>
Exactly. Programmer intuition is often wrong it seems, which is why I am looking for input on the subject.
<beach>
I am also concerned about error reporting. It would be unhelpful if all those special versions resulted in a backtrace that said that argument #:G123123 of function #:G4345345 must be of type LIST.
<beach>
I mean, take a function like ASSOC. It has to iterate over the list elements. In each iteration, there is a termination test, a test for the type of the element, a memory access to get the CAR, and a test for equality of the key. It seems to me that if the alist has more than two or so elements, then an initial test for the KEY and the TEST argument would be negligible. No?
<edwlan[m]>
Yeah, although I wonder about branching cost in a loop
<beach>
There won't be any such test in the loop.
<edwlan[m]>
But I guess there's already enough indireciton
<beach>
There will still be special versions of the loop for different values of KEY and TEST.
<edwlan[m]>
Yeah
<beach>
But they will all be inside a single function, say ASSOC-NO-KEYWORD-ARGUMENTS.
<beach>
Put differently, it seems to me that the main cost to get rid of is the keyword argument parsing, and we can live with a run-time test on the KEY and TEST arguments.
<edwlan[m]>
That sounds right
<beach>
Great! Thanks!
ebrasca has quit [Remote host closed the connection]
etimmons has quit [Ping timeout: 252 seconds]
tychoish has quit [Ping timeout: 260 seconds]
etimmons has joined #commonlisp
tychoish has joined #commonlisp
mfiano has quit [Ping timeout: 252 seconds]
nij- has joined #commonlisp
mfiano has joined #commonlisp
rtypo has quit [Quit: WeeChat 3.8]
semarie has quit [Quit: WeeChat 3.8]
semarie has joined #commonlisp
tibfulv has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
tibfulv has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
m5zs7k has quit [Ping timeout: 240 seconds]
m5zs7k has joined #commonlisp
rgherdt has joined #commonlisp
tevo has quit [Ping timeout: 248 seconds]
tevo has joined #commonlisp
pve has joined #commonlisp
semarie has quit [Ping timeout: 255 seconds]
kenran has joined #commonlisp
LW has joined #commonlisp
semarie has joined #commonlisp
Gleefre has joined #commonlisp
LW has quit [Quit: WeeChat 3.8]
igemnace has joined #commonlisp
occ has quit [Ping timeout: 264 seconds]
shka has joined #commonlisp
occ has joined #commonlisp
Bocaneri has joined #commonlisp
Bocaneri is now known as Guest2353
Sauvin has quit [Ping timeout: 246 seconds]
attila_lendvai has quit [Ping timeout: 250 seconds]
occ has quit [Ping timeout: 240 seconds]
treflip has joined #commonlisp
treflip has quit [Remote host closed the connection]
treflip has joined #commonlisp
jon_atack has joined #commonlisp
jonatack has quit [Read error: Connection reset by peer]
edgar-rft has quit [Quit: Leaving]
nij- has quit [Ping timeout: 250 seconds]
azimut has quit [Ping timeout: 255 seconds]
waleee has quit [Quit: WeeChat 3.8]
waleee has joined #commonlisp
jmdaemon has quit [Ping timeout: 246 seconds]
<scymtym_>
beach: didn't heisig make machinery to handle this kind of optimization for the SICL sequence functions?
lordmzte has quit [Quit: You have been kicked for being idle]
scymtym_ is now known as scymtym
jeffrey has joined #commonlisp
jmdaemon has joined #commonlisp
scymtym has quit [Ping timeout: 246 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
uddipiggu has quit [Remote host closed the connection]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
<beach>
His stuff was about sealing classes and generic functions. I am not sure how applicable that would be.
<beach>
Furthermore, he declared that his stuff would largely be superseded by call-site optimization, though I am not so convinced about that.
Brucio-61 has joined #commonlisp
<beach>
But call-site optimization should be able to avoid the compiler macro altogether.
scymtym has joined #commonlisp
<scymtym>
beach: you are probably right, i haven't looked at the code in any detail. that said, there seem to be at least two mechanisms: 1) fast generic functions (i.e. sealing and all that) 2) macros for handling predicates, keys and traversal. the latter is the impression i get from, for example, https://github.com/robert-strandh/SICL/blob/master/Code/Sequence/count-if-not.lisp#L7
<ixelp>
SICL/count-if-not.lisp at master · robert-strandh/SICL · GitHub
varjag has joined #commonlisp
<varjag>
is there a reason other than historical why usocket uses direct syscalls for wait-for-input rather than wrapping the implementation provided function?
<varjag>
looking at lispworks backend in particular
<varjag>
git blame goes to late 00s, unsure if LW had wait-for-input-streams then already
shka has quit [Ping timeout: 240 seconds]
shka has joined #commonlisp
<beach>
scymtym: Sure, but that doesn't eliminate the overhead of parsing keyword arguments.
ewf has quit [Ping timeout: 248 seconds]
<scymtym>
beach: sure. i assumed there would be similarities when implementing the function bodies
<_death>
wouldn't you have the compiler generate multiple entry points?
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
<beach>
scymtym: Indeed. I think I invented those macros actually. And I should use them for the Conses functions too.
<beach>
_death: Yes, at east two. One for parsing keyword arguments and one for the case when this has been done. But the question this morning was about a separate library and I don't control how the compiler is made then.
<_death>
ah.. then yeah, maybe a macro that generates a function that only takes required arguments, the front-facing function, and a compiler macro
<beach>
Right.
<_death>
but maybe the user of such a compiler wouldn't expect such performance niceties anyway
<beach>
A compiler that handles it automatically you mean?
<_death>
a compiler that doesn't
<_death>
then all of the naive keyword-taking operators will be slow anyway
<beach>
Sure.
<_death>
(operator uses)
<_death>
it could also mean that your code would be worse on a compiler that does optimize
<ogamita>
beach: your :test :key problem seems to me similar to what you've already done to generate optimized bodies for other functions. Ie. just use macros to generate the variants, so you may write the algorithm only once. You may still want to go thru compiler macros to optimize out the dispatching. (but in some case it'll have to be done at run-time, we may still want optimized versions of the bodies).
jeosol has joined #commonlisp
<beach>
_death: Worse than what?
<beach>
ogamita: Sure.
<ogamita>
beach: also, beware EQ vs EQL : they don't have the same semantics on characters or numbers…
<beach>
ogamita: I don't control what TEST is supplied by client code.
<ogamita>
(one may have the inclination to coallesce them and write only an EQL version. In a way that could be taken as implementation dependent behavior for EQ, but if it's not consistent with the behavior of EQ elsewhere, this may be counted against the implementation).
<ogamita>
That said, if the implementation defines (defun eq (a b) (eql a b)), I guess it remains conforming, so we could do that.
<_death>
beach: worse than a "naive" version, where the compiler generates multiple entry points, possibly for a variety of special cases, and considering interaction with other optimizations.. if your code generates a keyword-taking stub, then that may get optimized but may result in worse situation than an ordinary keyword-taking function with a full-fleshed body..
<_death>
beach: not just in runtime, but also code size and compilation time
<jackdaniel>
(if (something) (fast-path) (slow-path)) makes the slow path slower because it adds a single if
<beach>
_death: That's entirely possible. Though I think the only compiler that I know that will contain my technique for call-site optimization is the SICL compiler, and I can write it so that the code generated is no worse for this library.
<ogamita>
But it doesn't matter: the slow path is already slow. What matters is that we may take the fast path and be faster then.
<jackdaniel>
that depends on how expensive is something and how frequently the fast-path is chosen; I'm not saying that it is a bad approach but saying that it doesn't matter may be an overstatement
<beach>
jackdaniel: I don't think anyone has suggested something like that. But perhaps I missed it.
<ogamita>
If it takes 2 days and 3 hours, it doesn't matters that it takes 2 days, 3 hours and 4 minutes. On the other hand, if by testing 0.5 second we can take a fast path that's only 1 second instead of 2 minutes, it's all win.
<ogamita>
Right, we need benchmarks.
<jackdaniel>
beach: that was my comment on how adding an optimization by a smart compiler may be slower than using a naive one; I think that it was a simplified version of _death's remark
<_death>
I think also the stub generation may be tricky, if you want to consider type declarations that the user may make
<_death>
jackdaniel: one example is that a compiler macro may not have access to information that's available to the compiler, so may make a suboptimal decision and go with a slow expansion
<_death>
I guess the stub definition could tell the compiler to locally inline the actual body so that may solve the running time issue, but there's no guarantee that the compiler will do that, and anyway may still have worse code size and compilation time
nij- has joined #commonlisp
cage has joined #commonlisp
random-nick has joined #commonlisp
tyson2 has joined #commonlisp
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
dcb has joined #commonlisp
glaucon has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
dtman34 has joined #commonlisp
karlosz has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
morganw has joined #commonlisp
dcb has quit [Quit: MSN Messenger v2.16.1]
fbytez has left #commonlisp [Leaving]
lucasta has quit [Read error: Connection reset by peer]
NotThatRPG has joined #commonlisp
pestctrl has quit [Remote host closed the connection]
Equill has quit [Ping timeout: 246 seconds]
attila_lendvai has joined #commonlisp
zxcvz has joined #commonlisp
Equill has joined #commonlisp
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
karlosz has quit [Quit: karlosz]
jeffrey has quit [Ping timeout: 256 seconds]
kenran has quit [Remote host closed the connection]
skin has joined #commonlisp
nkatte has joined #commonlisp
skin has quit [Remote host closed the connection]
skin has joined #commonlisp
nkatte has quit [Read error: Connection reset by peer]
nkatte has joined #commonlisp
pranavats has joined #commonlisp
treflip has quit [Ping timeout: 252 seconds]
nkatte has quit [Read error: Connection reset by peer]
nkatte has joined #commonlisp
nkatte has quit [Read error: Connection reset by peer]
edgar-rft has joined #commonlisp
karlosz has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
skin has quit [Ping timeout: 240 seconds]
nkatte has joined #commonlisp
skin has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
skin has quit [Ping timeout: 246 seconds]
tevo has quit [Read error: Connection reset by peer]
azimut has joined #commonlisp
tevo has joined #commonlisp
glaucon has quit [Quit: WeeChat 3.5]
skin has joined #commonlisp
nkatte has quit [Read error: Connection reset by peer]
taichi has quit [Quit: WeeChat 3.8]
skin has quit [Client Quit]
skin has joined #commonlisp
nkatte has joined #commonlisp
nkatte has quit [Read error: Connection reset by peer]
mariari has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
alhazraed has quit [Quit: Connection closed for inactivity]
nkatte has joined #commonlisp
NotThatRPG has joined #commonlisp
nkatte has quit [Read error: Connection reset by peer]
rtypo has joined #commonlisp
nkatte has joined #commonlisp
szkl has joined #commonlisp
nkatte has quit [Read error: Connection reset by peer]