libera/#commonlisp - IRC Chatlog
Search
22:36:45
Lycurgus
in looking for a state machine thing in cl, i couldn seem to do better than cl-monad-macros
0:13:57
resttime
Bike: Asked in #sbcl about my add-vop and your answer seemed to be it. (move r x) (inst add r y) in the generator works as expected
0:44:44
Bike
ah, well there you go then. a little surprising it doesn't move them itself, it looks like the parent vop has stuff for indicating that
0:52:36
akoana
hmm, what's happening here: https://termbin.com/71e4, with (let ((prod 1))...) I'm getting a big number, with (let ((prod 1.0))...) it works as expected, strange
0:59:44
hayley
I wouldn't be surprised if you got a ratio with very large components, but the actual value is quite small.
1:03:12
akoana
sorry the 2n stuff is a remnant of previous experiments, here a cleaned up version + results: https://termbin.com/b9a4
1:05:28
akoana
I did the tests with 100000 iterations in emacs before, so I gave up looking at the result :)
1:08:05
akoana
Bike, hayley: Thank you very much - I was about losing my confidence in lisp - you have saved my soul
5:45:24
resttime
I have three functions, add-fixnums, add-floats, add-doubles and their disassembly with optimizations: https://plaster.tymoon.eu/view/3349#3349
5:46:25
resttime
Is there a reason why add-doubles seems use many(?) more lines of assembly than add-floats?
5:47:22
resttime
My thoughts were that a double-float operation would be at least as single-float, only that the instruction used for addition would be different
5:48:28
hayley
This can be avoided when the ADD-... functions are declared INLINE, and when the functions are used in another function. (Though the effect will only be visible when disassembling that other function, and not in disassembly for any ADD-... function.)
5:51:13
White_Flame
and add-floats is longer than add-fixnums because it has to tag the single-float
5:52:53
resttime
Ohhhhh, I'm seeing the unbox/box of doubles because of how SBCL uses pointer tagging instead of NaN boxing
5:56:26
resttime
hayley: If I understood this correctly does that mean the box/unbox is still necessary in this outer function, but only happens at the entrypoint and endpoint of the function once?
5:59:39
White_Flame
you don't see the unboxing, because sbcl hides some of the arg-handling prologue
6:05:07
resttime
Interesting, somewhat related is there an SBCL function for printing the real memory representation of an object? I wanna see how a double is represented in memory
6:13:53
White_Flame
of course, that's just a single (in the upper 32 bits), and will work for immediate values. It doesn't display the heap representation word layout, though
6:38:44
resttime
Hmmm, in the case of a simple-array of double-float's, are these doubles layed out in contiguously in memory boxed or unboxed?
6:46:05
resttime
Oh nice and I see that (upgraded-array-element-type 'bignum) ; => T which makes sense since to me since bignum would be considered more abstraction
9:58:14
aeth
in SBCL, the rule of thumb is to either inline or to box your own floats with double-float arrays (which can be 0D, 1D, 2D, ...) or structs with double-float typed slots, but you have to be careful about implicit return values because those will still cons if they leave function scope
9:58:52
aeth
Not every implementation will do the struct part. Afaik, only CLISP doesn't do (upgraded-array-element-type 'double-float) => double-float
10:00:08
aeth
By implicit return value I mean e.g. (incf (aref your-double-float-array 0)) ; returns a double-float, will still cons if that part is implicitly returned from your function