yauhsien has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
X-Scale` has joined #commonlisp
orestarod has quit [Ping timeout: 244 seconds]
azimut has joined #commonlisp
epolanski has joined #commonlisp
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
yauhsien has quit [Ping timeout: 240 seconds]
anticomputer has joined #commonlisp
anticomputer_ has quit [Ping timeout: 268 seconds]
cage has joined #commonlisp
<resttime>
So I've found that lisp objects in SBCL are represented in memory with a technique called 'pointer tagging'. I've learned that 'NaN boxing' is an alternative that although to accomplish the same thing used in other compilers. Was there an architectural decision in SBCL to using 'pointer tagging' over 'NaN boxing'?
<beach>
I don't think NaN boxing was a thing when the decision for SBCL was made. Also, NaN boxing is probably more costly in terms of tag removal and type checking.
<beach>
I know of no Common Lisp implementation that uses NaN boxing. Isn't it mainly for Javascript?
<resttime>
It exists in LuaJIT iirc as well
<beach>
I see.
<resttime>
Guess I'm jut wondering why some compilers use one over the other, trade-offs and benefits
<jackdaniel>
is nan boxing better than pointer tagging?
<resttime>
No idea, that's what I'm trying to figure out :)
<beach>
Also, aren't there fewer bits left with NaN boxing? Like for fixnums?
<jackdaniel>
in my understanding the only advantage of nan boxing (over pointer tagging) is that you may encode doubles with it
<beach>
That makes sense.
<jackdaniel>
on the other hand you automatically throw away ieee floating point compliance and have more tricky bit operations; in principle it should be as fast as pointer tagging on 64 bit architectures
thelounge7669 has joined #commonlisp
<jackdaniel>
I wonder whether nan-boxed values would be 2x slower than pointer-tagged immediates on 32-bit architectures
<beach>
Let's see, with tagging, once you have determined that something is (say) a CONS cell, you can do CAR and CDR in one instruction. With NaN boxing, isn't it a bit more complicated?
<hayley>
I think one can map the heap so that pointers reside in the space of NaNs, but I have absolutely no intuition for IEEE floats nor NaN boxing, so that might not work.
<beach>
Interesting.
<hayley>
The exponent part has to be all ones, and the sign and fraction can be anything, so it is likely possible.
<jackdaniel>
for nan boxing you use 2 bits to signal, whether something is a boxed value or not
<jackdaniel>
in principle you could use the two bits to encode the immediate type and still "whisk away" the pointer
<hayley>
My own guess is that fixnums are more common than double floats in Common Lisp but (semantically) JS and Lua and such only have floats.
<jackdaniel>
in contrary, with pointer tagging you may represent more immediate types because you have 3 bits (- one value)
<hayley>
JS implementations do try to use integers, when it is known integer arithmetic can be used while preserving semantics.
<jackdaniel>
without losing that pointer value
* hayley
goes to GC for the night, mumbles why they haven't made concurrent GC for humans yet
<jackdaniel>
(of course the most interesting - immediate values - fixnums, characters, single-float's, don't need the pointer)
<resttime>
I'm guessing as well fixnums might be more common in Common Lisp as a result of using pointer tagging vs nan boxing
<resttime>
AKA if the underlying object type was theoretically on doubles in a nan boxing Common Lisp implementation it'd be full of floats
<resttime>
I wonder what makes JS and LuaJIT choose nan boxing
Dynom_ has joined #commonlisp
<White_Flame>
js uses nan boxing?
Dynom_ is now known as Guest9823
<White_Flame>
I thought they just represented integers as floats literally
<beach>
I think fixnum addition (a very common operation) would be more costly with NaN boxing.
<resttime>
White_Flame: If my understanding is correct, a lot of JS compilers use nan boxing for encoding other types into doubles
<resttime>
beach: Goes to my thoughts thinking that were NaN boxing used, whether fixnum addition and such be replaced with float ones as the common operation
<beach>
resttime: I couldn't parse that. But I think NaN boxing is useful where floats are more common than small integers, if that is what you meant to say.
<beach>
Isn't float the only numeric type in some languages?
<resttime>
Sorry my understanding is still kinda fuzzy. My meaning is that did someone think "we're gonna be using a lot of floats so lets use nan boxing" vs "let's use nan boxing... ok looks like float operations are most efficient lets architect the rest of the compiler around float'
<resttime>
So SBCL could have used pointer tagging in the beginning because nan boxing didn't exist historically. And that results in why fixnum is so common
<resttime>
Because efficiency of the decicion using pointer tagging leans towards fixnums rather than floats
tyson2 has quit [Remote host closed the connection]
<resttime>
And probably, I'd have to look since I dunno any for specific langs off top of my head
<beach>
resttime: Javascript uses floating point exclusively, and it doesn't have an integer type. That's probably why NaN boxing is so attractive for JavaScript. Common Lisp uses small integers a lot and it would be relatively costly to use NaN boxing for things like fixnum addition.
<resttime>
Oh okay then maybe a good question here is, why does Common Lisp use small integers a lot, whereas Javascript uses floats?
<beach>
I suspect Javascript doesn't care about performance of things like arithmetic.
<beach>
Common Lisp couldn't do without an integer type, because it would lose exact arithmetic for integers and ratios.
<beach>
Every time you have a loop counter, or use array indices, you need small integers.
<beach>
So any language with loops and arrays would need to use small integers. The question then is whether you care about the performance for their operations.
<beach>
Common Lisp was designed with performance in mind.
<White_Flame>
re js, I'm pretty sure they have a bignum integer type now as wel
<beach>
Ah, OK.
<yitzi>
They do.
<beach>
My information must be several weeks old.
<White_Flame>
also, JS could be told to use integers internally with aggressive use of &&0xffffffff, which turned into the asm.js style
<yitzi>
beach: Its still a "crippled" language IMHO.
<beach>
I should be silent about languages I know little about.
<White_Flame>
they were float-only for a very long time, though
tyson2 has quit [Remote host closed the connection]
epolanski has quit [Quit: Connection closed for inactivity]
aartaka has quit [Ping timeout: 268 seconds]
aartaka has joined #commonlisp
azimut has quit [Remote host closed the connection]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
azimut has joined #commonlisp
Volt_ has joined #commonlisp
McParen has joined #commonlisp
tyson2 has joined #commonlisp
euandreh has quit [Ping timeout: 240 seconds]
euandreh has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
Guest46 has joined #commonlisp
Guest46 has quit [Quit: Client closed]
Volt_ has quit [Quit: ]
aartaka has quit [Ping timeout: 272 seconds]
MajorBiscuit has joined #commonlisp
Volt_ has joined #commonlisp
SunClonus has joined #commonlisp
livoreno has joined #commonlisp
epolanski has joined #commonlisp
Guest9823 has quit [Quit: WeeChat 3.5]
serbest has joined #commonlisp
<jcowan>
NaN boxing is completely compatible with pointer tagging, and does not create any serious incompatibility with IEEE arithmetic, because it only preempts the signaling NaN space. IMO any dynamic language that is meant to run on 64 bits only should use NaN boxing.
<jcowan>
You do need to do double rotation, but that is much cheaper than unboxing doubles.
akoana has joined #commonlisp
<jcowan>
By combining the techniques, small integers (up to 48 bits), Unicode characters, booleans, single-floats, and double-floats are all unboxed
<jcowan>
(also nil)
<jcowan>
s/language/& implementation
<jcowan>
NaN boxing does *not* mean that floating-point operations are used instead of integer ones.
serbest has quit [Remote host closed the connection]
serbest has joined #commonlisp
SunClonus has quit []
serbest has quit [Quit: Leaving]
tyson2 has quit [Remote host closed the connection]
SunClonus has joined #commonlisp
SunClonus has quit [Client Quit]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
thuna` has joined #commonlisp
causal has joined #commonlisp
random-nick has quit [Ping timeout: 240 seconds]
rogersm has quit [Quit: Leaving...]
<aeth>
the only disadvantage is that 48 bits is quite small
<aeth>
If hardware quadruple floating point was common (even on 64-bit machines), then it would be a win no matter what
<aeth>
although those would be 128-bit in memory so I guess that complicates things
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
pve has quit [Quit: leaving]
random-nick has joined #commonlisp
waleee has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 240 seconds]
sndr has quit [Quit: So long! :)]
<jcowan>
I suppose it's because I come from the 32-bit (and even 16-bit and 12-bit) world, but a most-positive-fixnum of 140,737,488,355,327 seems quite respectable to me.
sander has joined #commonlisp
Volt_ has quit [Quit: ]
tyson2 has joined #commonlisp
ksp has joined #commonlisp
<ksp>
Is there a way to make FORMAT produce output in radixes other than the "standard"?
<ksp>
The reader already allows most bases that are of any use, so I would expect this is possible.
<ksp>
oh wait
<ksp>
i cant read lmao
ksp has quit [Client Quit]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
nyx_land has quit [Ping timeout: 256 seconds]
ssafar has quit [Remote host closed the connection]
shka has quit [Ping timeout: 240 seconds]
thuna` has quit [Remote host closed the connection]
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #commonlisp
epolanski has quit [Quit: Connection closed for inactivity]