libera/#sbcl - IRC Chatlog
Search
5:10:54
|3b|
hmm, maybe a bit faster, but not as much as i hoped... back to wishing i had a profiler i guess :p
6:08:33
Josh_2
https://github.com/thephoeron/cl-isaac/issues/10 I put this here to make sbcl devs aware of this
6:23:24
|3b|
is the part that sbcl devs would care about that restrict-compiler-policy isn't working on macos?
8:08:05
|3b|
it also mentions something about THE with high safety, but not /what/ and seems to think it is working as intended so not a bug?
8:09:26
|3b|
behavior of THE when the value isn't that type (as in the earlier comments) is undefined, so is expected to be non-portable across implementations
8:26:24
|3b|
Josh_2: the pasted examples in the bug don't seem to show the code being recompiled in the macos case
8:27:36
Josh_2
Okay well unfortunately I dont actually know whats going on with cl-isaac itself, I am simply a messenger in this case. However I can say that I have used a build pipeline with gitlab to try and deploy software that was depending on cl-isaac that used restrict-compiler-policy and this problem has occurred when its set to safety 3
8:27:41
|3b|
ACTION 's guess was something else changing the restriction, but failing to recompile seems much more likely (and fits the available evidence)
8:31:53
|3b|
ACTION couldn't find any information about what was wrong with THE, particularly in context of undefined behavior where nothing is 'wrong' at the CL level
8:32:35
|3b|
(so SBCL and some other impl can do completely different things and still be 'correct' to their own interpretations, and users can't complain since their code is non conformant)
8:33:38
Josh_2
"Digging into SBCL internals, I discovered some completely non-portable behaviour surrounding the special-form THE when safety >= 2."
8:34:33
jackdaniel
it is a conforming behavior to not trust the - undefined consequences are undefined
8:37:17
jackdaniel
|3b|: how do you distinguish the behavior of trusted and untrusted the in a conforming orogram?
8:38:13
|3b|
ACTION means "The consequences are undefined if the values yielded by the form are not of the type specified by value-type. "
8:40:02
jackdaniel
you are right. I mean that whatever sbcl does with THE is not non-conforming or not portable. reading what you have said earlier we seem to agree :)
8:40:04
|3b|
the code in question masks off 64 bits of (the (u-b 64) ...), so pretty obviously doesn't actually expect that value to be u-b 64
8:40:34
|3b|
right, sbcl is conformant and internally consistent in how it chooses to behave in that case
8:44:06
stassats`
why doesn't trace respect the print variables on function calls, but does so on returns?
9:11:26
stassats`
that reminds me, i should port the (the (unsigned-byte 64) (ash n s)) optimization to x86-64
9:13:11
stassats`
(and no, it's not responsible for the issue, as it hasn't been released on arm64 either)
9:16:21
stassats`
for some reason porting assembly code is even more cumbersome than writing it initially
9:16:41
stassats`
i guess because when writing it's done incrementally, but when porting you already have the whole thing
9:17:24
stassats`
not having three-op instructions it the main pain point when going from arm64 to x86-64
9:18:26
stassats`
they reduce branching by not destroying the input operands, so you can repeat the same operation
9:21:34
Josh_2
looking at the incremental changes made to SBCL made me take a shallow dive into compiler optimization
9:22:27
Josh_2
most interesting thing I found was https://www.agner.org/optimize/ but still dont have the foggiest. What you are doing stassats` is epic :sunglasses:
9:23:21
stassats`
you don't really have to go down to the instruction level optimizations, as just going from a full call to some assembly is usually good
9:23:50
stassats`
i usually just try to make things small, the out of order CPUs are hard to comprehend
9:36:47
stassats`
looking at the unoptimized code for ash, i guess i see another possible optimization, for the (unsigned-byte 64) type check
9:37:19
stassats`
if it's known that it's some unsigned number no need to check if it's a single digit (signed-byte 64) without a sign bit