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)
15:03:35
beach
Bike: I was thinking that something like that would be ideal to use in Second Climacs. I just did a short experiment using SBCL to compile a non-trivial top-level form, and it took less than 10ms. So I think it is going to be very practical to compile top-level forms at typing speed (but only when needed, of course).
15:54:50
beach
I think we might want to use s-expression-syntax first, and that's not finished either.
17:06:57
Bike
and in bir you can get useful type warnings and some other things. the stuff left over for a linter to do is basically style
17:15:24
scymtym
i have some rule based stuff for style on the character ("avoid closing paren on separate line"), CST ("avoid double package markers") and AST ("use (when X Y) instead of (if X Y)") levels. but making what i have really usable will take more work on Eclector (not as much) and the s-expression-syntax library (the majority of the work)
19:27:58
Bike
as for what i have been working on... i have been doing stuff with the bytecode compiler we made. right now it is a bit clasp-specific, but i would like to make it portable lip again, and maybe put it in s-expressionists. the idea is that the bytecode compiler is fast and simple (no IR), and does enough "optimization" (e.g. macroexpansion) for most code to go much faster than an interpreter. then with that in
19:28:04
Bike
place, cleavir can be the big guns compiler with more sophisticated analyses, and it's less important how fast it goes.
19:28:42
Bike
with the improve-cleavir-optimization-so-cleavir-runs-faster strategy i have been continually frustrated by the optimization taking more time than it saves, because more optimizations need to be in place for things to be really efficient - so by splitting concerns like this i hope i can do better with that
19:30:31
Bike
for an idea of how long cleavir takes in clasp - i have been compiling and loading swank with the new bytecode compiler - cleavir isn't used except for constructing inline function ASTs, and for code walking in CLOS. it still manages to take 17% of the total time of compiling and loading
19:39:43
scymtym
Bike: i came up with yet another (the third, i think) solution for the NIL-as-eof-value issue: https://github.com/s-expressionists/Eclector/compare/master...end-of-input-fix . compared to the second(?) solution, this one avoids introducing yet another magic value
19:39:51
scymtym
i also took the opportunity to document the differences in terms of returns values between "CL mode" and "parse result mode". does this look OK to you?
19:43:24
Bike
documenting the additional values thing is definitely good. seems like something eclector does in a few places.
19:48:21
Bike
you could use m-v-call instead of dest-bind and m-v-list to maybe save some consing, but that's a nitpick