freenode/#sicl - IRC Chatlog
Search
15:31:05
beach
(unsigned-byte 8), (unsigned-byte 32), (unsigned-byte 64), (signed-byte 32), (signed-byte 64)
15:40:07
pfdietz
There's that annoying NIL element type as well, that the letter of the standard requires. :)
15:43:29
pfdietz
Also, if you support (signed-byte N) and (unsigned-byte N), the spec requires you support (unsigned-byte N-1)
15:45:13
pfdietz
No one will complain much if you just document a variance from the standard on that point.
15:45:43
pfdietz
The situation with complex types is less happy. The spec is just inconsistent on upgrading there.
15:54:41
pfdietz
ALso strictly speaking, the "maintains the lattice" thing talks about subtypes, not "recognizable" subtypes. Which in the presence of SATISFIES types means it's undecidable. They probably meant it to be consistent with what the implementation does with SUBTYPEP, but that's not what they wrote.
16:01:40
jcowan
and compared to general vectors it provides a guarantee that the value really is a fixnum.
16:02:08
jcowan
The other thing I wanted to bring up is immediate doubles via NaNboxing or some variant of it
16:04:01
jcowan
with such a design, 32-bit floats are short-floats, 64-bit floats are single, double, and long-floats (unless you want to use arbitrary precision floats as long-floats)
16:06:13
jcowan
I agree, but CL insisting that default float is always single-float makes it hard to avoid. Every other language I know of defaults to double-float except Fortran
16:07:46
jcowan
Historically the drag of 32-bit systems has held down NaNboxing as a strategy, but with 64-bit (almost) everywhere and all pointers still 48 bits or less (except on Slowlaris), it starts to look like the go-to strategy.
16:17:02
jcowan
You can rotate nanboxed values so that pointers look native and doubles have to be adjusted, which is called "punboxing"
16:17:32
beach
So that will ruin the property that you can add and subtract fixnums using machine add and sub instructions?
16:17:33
jcowan
https://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations explains it, but incorrectly refers to punboxing as "nunboxing" (which is actually a different idea)
16:17:58
pfdietz
ARM64 can do something special with the type byte of pointers; does anyone exploit that?
16:20:48
jcowan
then pointers and fixnums have all high bits 0, and to interpret a double you exchange the high tags 0 and NaN before operating on it
16:22:58
jcowan
"So, when you choose to do nan-boxing, you basically choose to do one of two things: you favor pointers, or you favor doubles. To favor pointers means that you recognize pointers as having initial (most-significant) 0 bits; if the initial bits are not 0, then it's a double, and you have to add or subtract a bit pattern to get to the double value." --from the above link
16:23:27
jcowan
where "pointer" here includes fixnums and other immediates distinguished by their low tag.
16:26:18
jcowan
Floats are, as I say, encoded such that the all-0s exponent is mapped into the all-1s exponent and vice versa.
16:26:56
jcowan
Lisps have historically had very good float performance; today, not so much. IWBN to get back there
16:28:05
jcowan
You actually want to occupy only the signaling NaN space for pointers/immediates because you do not know which quiet NaN various processor operations will return.
16:29:56
jcowan
so with 53 mantissa bits and a 1-bit low tag of 0 for fixnums, you get 52-bit fixnums, which should be enough for practical use
16:36:21
Bike
on the other hand, couldn't you add a bunch of fixnums together without checking overflow until the end, since it'll just fill up some high bits?
16:37:20
beach
Another interesting piece of information would be to determine how many double floats need to be tagged in a typical program that uses floats.
16:38:39
Bike
sbcl with high optimization settings notes when it has to do tagging and untagging. i've hit it a few times
16:45:20
frodef
maybe with nan-boxing it will be easier to include a javascript compiler frontend? :)
16:46:34
Bike
i remember hitting it mostly at function boundaries, which is kind of hard to fix while allowing recompilation if floats aren't immediate
16:50:52
Shinmera
and efficient floats are of course very important for a wide array of applications, many of which I personally care about :)
16:52:08
Bike
for GPUs i'd think the cost of transferring data back and forth is probably going to dominate tagging and untagging costs? dunno...
17:27:30
beach
Shinmera: I'll think about it. When I did audio research, we decided to you double floats everywhere. They are fast and there is plenty of space these days.
17:29:21
Shinmera
beach: really, double floats? single floats are becoming more widely used now and I agree that it's the best choice for processing it, but for storage in end formats, 24 bit integers unfortunately still happen.
17:30:04
jcowan
That's the experience of the Big Data platform company I used to work for. The speed of transfer out of the GPU totally obscures any improvement in computation
17:30:43
Shinmera
jcowan: GPU still has unique things to watch out for like the fact that branching is expensive again
18:01:27
|3b|
though most of the data in those formats is just getting shovelled from disk to GPU without much CPU interaction
18:02:38
|3b|
(and also motivation for wanting 16bit specialized arrays, graphics data is still big enough that cutting size in half is nice)
21:21:34
Bike
beach: cleavir loses information about when block/tagbody dynamic extents are exited. i think we could add an invalidate-catch instruction of some sort, and then have ast-to-hir maintain a stack of contexts so that we can generate the appropriate invalidations whenever we exit a block, without too much trouble