freenode/#sicl - IRC Chatlog
Search
13:26:17
beach
So I guess of the two most significant bits of a 64-bit signed integer are the same, then shifting the number one position to the left will give the equivalent fixnum representation of that number.
13:30:34
beach
As I recall, the main reason for considering using fixnums was so that the code could be written using Common Lisp functions.
13:31:22
beach
But if (named) functions can take unboxed 64-bit integers and return such integers, then that reason may no longer exist.
13:37:15
heisig
If the limbs are stored in a specialized array, I see absolutely no problem with using 64-bit unsigned integers.
13:38:34
heisig
I see no reason why an individual limb should ever leave a function working on such a bignum.
13:38:52
beach
Well, if we do that, we either have to do all computation within a single function, or we need to make it possible for a function to return unboxed unsigned 64-bit integers.
13:41:28
heisig
Right. If we can efficiently return unboxed 64-bit integers, that is one more reason to use them to implement bignums.
13:44:05
beach
Each function that returns a full 64-bit number has two entry points. The default entry point just contains a call to the second entry point, and box instructions after the return.
13:44:23
beach
This call is going to be cheap compared to the boxing code, so there is no performance penalty.
13:45:39
beach
A call site can indicate that it is able to take either a boxed Common Lisp object as a value, or an unboxed value which is then either a double float or a 64-bit signed or unsigned integer.
13:50:18
beach
1. The caller accepts only boxed Common Lisp objects as values and the callee is not one of those special functions. Then the only entry point of the callee is called, skipping the argument-parsing prefix as usual.
13:51:11
beach
callee is one of those special functions. Then the call-site manager generates a call to the default entry point of the callee.
13:53:48
beach
3. The caller can accept either boxed or unboxed values, and the callee is not one of those special functions. Then the call-site manager generates a call to the only entry point of the callee, and at the end of the snippet, jumps to the return address that accepts boxed values, and the caller will then check the types and unbox them or call error or something.
13:55:37
beach
4. The caller can accept either boxed or unboxed values, and the callee is one of those special functions, and the value types match. Then the call-site manager generates a call from the snippet to the alternate entry point, followed by a jump to the address that accepts unboxed values.
13:56:35
beach
There is a 5 that happens when the caller can accept both, and the callee is special but the value types don't match. You get the idea.
13:59:35
beach
Definitely. One of my favorite applications is the analysis and synthesis of sound. And double floats would be the default data type then.
14:00:27
beach
And, as we said, if we want to implement the bignum code in Common Lisp with separate functions, then we need for unsigned 64-bit integers to be passed unboxed.
14:01:54
heisig
Also, double floats are the most common data type in scientific computing. And this is an area where performance matters, so boxing/unboxing is not an option.
14:03:19
beach
I want to be convinced that we can do this efficiently so that 1. I can include it in the paper so as to make the argument stronger, and 2. So that I can write this boxing/unboxing code for 64-bit integers and go on with HIR-to-MIR. :)
14:04:00
frodef
I suspect it will also be complicated to have unboxed floats everywhere, but I might be very wrong.
14:05:06
beach
Cleavir already allows for unboxed floats, and it emits box/unbox operations around array access to specialized float arrays.
14:06:39
frodef
My perspective (from video processing) has been that signal/float processing is a high performace activity that is best done by specialized functions, such as (somewhat higher-level) assembly etc, and the data exists mostly within specialized buffers.
14:07:39
heisig
I am still trying to parse the list of cases for the call-site manager. And I'm thinking about how this information could be encoded in practice.
14:08:29
beach
heisig: Each call site has a standard object that describes all this stuff associated with it.
14:10:25
frodef
seems to me high-performance signal processing is a very very different ball-game than what a general run-time should be optimized for.
14:10:45
frodef
..then again, if you can have the former without any penalty on the latter, then all the better :)
14:11:46
beach
frodef: I truly believe that the call-site optimization of the paper will give us function calls that are as fast or faster than those of a typical C++ implementation.
14:12:21
heisig
I think we should introduce the notion of an object encoding. Each encoding has, at minimum, a Common Lisp type and some methods for emitting a sequence of instructions to convert between that encoding and the canonical (boxed) encoding.
14:12:33
beach
Even in C++, if you have a shared library, function calls and accesses to global variables have indirections, and we can do better than that.
14:13:50
beach
heisig: There are very few object types that can exist both as unboxed and as boxed values.
14:14:35
heisig
There is the canonical encoding, specialized ones for double-floats and 64-bit unsigned integers, but maybe also encodings for certain SIMD data types.
14:15:13
heisig
I think the rule should be 'everything that fits into a single CPU register'. And this includes SIMD data types.
14:16:14
beach
I guess I need to hint something like that in the paper. But I really should be working on HIR-to-MIR, coding wise.
14:18:12
Bike
multiple values might also be conceived of in terms of boxing and unboxing. if the caller and callee can agree on how many values are returned you might be able to skip e.g. putting the number of values in a register. my vague understanding is that in haskell they do this by returning a sort of unboxed tuple or vector or something
14:18:13
Colleen
Bike: scymtym said 2 hours, 11 minutes ago: i updated the pull request, but i can't currently test things properly because of a problem in the reaching definitions system. i think you already fixed it in the renovate branch. could you add the fix to master?
14:21:34
Colleen
scymtym: Bike said 28 seconds ago: whoops, thought i merged renovate all the way already. done now.
14:26:27
Bike
i think reaching definitions is still broken in that it fails its tests, though it does load
14:44:09
beach
frodef: It would be great to have you on board. With your experience, it's an ideal fit.
15:03:43
scymtym
Bike: i updated the PR. those changes are enough to make everything (including test systems) compile and load in SBCL
15:15:38
scymtym
i don't know. if you at the diff, there are TODOs related to ctypes. i don't know whether the complete transition can already be made
16:11:47
Bike
cleavir-ctype is massively broken (or rather, not really used) and i'll have to figure out how to fix it... ech...
16:12:40
Bike
well, basically you can't use any of its operations without a system parameter, and not everything has a system parameter at all times
16:13:40
Bike
which works, but if you do that the system is kind of pointless since you can't customize it
16:17:52
Bike
i think the sensible solution would be to avoid computing type intersections in cleavir-env, and instead store the intersection in the local environment, so cst-to-ast can compute it
16:35:15
Bike
https://github.com/s-expressionists/Cleavir/pull/7/commits/f27c1d5744e3c1704e5c82ee2265eb5693fd7f70 we've been trying hard to avoid this kind of conditional - what trouble does sbcl have with the declaration?
16:41:08
beach
HIR-to-MIR passes, but there are a lot of FIXMEs in there, and I'll work on those incrementally. The good news is that processing time did not increase significantly.
16:46:37
scymtym
Bike: i think the "recursive" nature of the type is the problem. for me, this resulted in some obsolete instance update cycle that eventually landed in ldb
16:47:22
scymtym
may only happen because i use elevated safety so that SBCL inserts type checks for slots
16:49:32
scymtym
everything in the visualizer related to environments is also very wonky and should be redone properly in some way
16:50:37
Bike
if i do rewrite cleavir to use trucler that might go away, in that trucler's sbcl environment interface is probably less rotted than the one in Environment/Examples/ or wherever
16:52:42
scymtym
i use the environment to inject the policy chosen by the user. other than that, i just needed something that allowed compilation to finish
16:53:08
scymtym
but picking up global functions and variables from the host may actually make sense as a default
17:13:24
scymtym
yeah, it will potentially catch fewer cleavir bugs when running in SBCL. but without the exception, it might not run at all
17:14:30
Bike
i think i'll try loading your branch and convincing myself that it's an sbcl problem before merging
17:16:19
scymtym
sure. there is no rush. feel free to not merge now if you want to make certain improvements first
17:32:11
Bike
trucler doesn't seem to have a way to get info about DECLARATION proclamations. that may be a little sticking point
18:10:55
Bike
when i try to load the visualizer i get "Invalid initialization argument: :UPDATE-INSTANCES-ON-REDEFINITION in call for class #<STANDARD-CLASS COMMON-LISP:STANDARD-CLASS>." while loading application.fasl.
18:12:06
Bike
and i think my quicklisp is fully updated. i ran into some problems with that make-ea thing so i wiped the asdf cache entirely to get this far
18:16:17
ebrasca
beach: following your tip of removing pathname-% from (%type :initarg :type :reader pathname-%type) collides wiht funcition type.
18:17:13
scymtym
(it makes the window update when the corresponding code is redefined so users have no use for it)
18:47:33
scymtym
i don't have a proper recipe and i think there might complex preconditions, but when i compile and run everything with (proclaim '(optimize (debug 3) (safety 3) (speed 1) (compilation-speed 0))), just starting the visualizer triggers it
18:48:59
scymtym
i wouldn't be surprised if it also depends on which thread evaluates what and finicky stuff like that
18:52:05
scymtym
i forgot, i have to modify the form to trigger a compilation to make the problem appear
18:54:24
scymtym
Bike: this is the simplest way to reproduce it i could find: https://techfak.de/~jmoringe/sbcl-crash.png
18:55:30
Bike
do you have the proclamations in your sbclrc or something? because that looks like i did and i didn't get a crash
18:56:04
scymtym
as i wrote above, (proclaim '(optimize (debug 3) (safety 3) (speed 1) (compilation-speed 0))), or do you mean something else?
18:57:30
scymtym
in this context, this difference probably is that high safety generates type checks based on slot :TYPE options