libera/#sicl - IRC Chatlog
Search
13:30:37
moon-child
would anything go wrong if you defined fixnums to be those integers which are guaranteed to be eq if they are eql?
13:31:59
moon-child
while I think it would be a good idea to make eq consistent for bignums et seq, I do appreciate that there are some optimisations that would be broken by that. But I can't imagine a high-performance implementation strategy which would not be able to guarantee eq on fixnums is the same as eql without sacrificing anything
13:32:25
hayley
Would an implementation which heap allocates all integers and implements EQ by pointer comparison have no fixnums?
13:33:20
moon-child
I think a few things like array indices have to be fixnums. So if you heap allocate all integers, you take a performance hit on eq
13:33:37
moon-child
but you take a much larger performance hit by heap allocating all integers, so I don't think it matters
13:38:14
jackdaniel
if fixnum is allocated as an immediate type and eq is implemented as a pointer comparison, then it will be eq; it is just a matter of tying your hands by commiting that the implementation will always do that by specifying it in the manual
13:39:15
moon-child
the question is whether specifying it thus constrains implementations in any interesting ways
13:39:36
jcowan
Even in Lisps that don't have a formal rule about it, it is generally true that the limit on the size of an array is the size of a fixnum, simply because both tend to be closely related to the size of a machine word.
13:40:05
jackdaniel
well, you won't be able to implement common lisp if there are no free bits in a pointer
13:40:28
moon-child
jcowan: well, also because you want to be able to do the bounds check as an immediate comparison
13:41:14
moon-child
you don't have to have immediate types. But if you don't, then performance will suck anyway, so making eq slower doesn't much matter
13:41:28
jcowan
You can write a CL in which there are no immediates, and then the fixnum limit is unrelated to any machine word size
13:43:06
jackdaniel
moon-child: statement that it does not matter because the performance will suck anyway is shaky at best
13:43:52
jackdaniel
either way that puts an interesting constraints on EQ on architectures where pointers doesn't have free bits
13:44:50
jackdaniel
(and couple that with a question -what is there to be gained by specifying that = fixnums are eq)
13:45:26
jcowan
(Turns out I'm wrong: "On the other hand, ABCL - like SBCL - supports unboxed fixnums. ABCL's fixnums support the full 32 bit range of integer values, while SBCL due to its boxing strategy can only use 29 bit integers (on 32bit platforms.")
13:46:39
moon-child
jackdaniel: it means that you can use eq in place of eql when you know you're not dealing with bignums (or don't care about bignum results)
13:47:10
moon-child
I think, if the pointer doesn't have any free bits, you had rather taken out some extra data beside the pointer as a tag, rathern than eaten an indirection
13:49:02
jackdaniel
perhaps I should phrase it better - what is there to be /practically/ gained by specifying that - did you hit a bottleneck in your program because eql is too slow?
13:51:00
moon-child
no, but I can imagine cases where it would get annoying. Eg eql likely becomes a drag on vectorisation. I'm also generally in favour of specifying more rather than less, where feasible--punish the implementor!
13:53:22
jackdaniel
I think that usually with numbers you use arithmetic operators like #'<; also if you can declare types then unboxed comparisons will be equally good for most cases (while eq could only be used instead of = at the expense of obscurity)