freenode/#lisp - IRC Chatlog
Search
0:40:16
no-defun-allowed
Odds are the upgraded element type of (integer 1 12) would be (unsigned-byte 8)
0:41:28
no-defun-allowed
(Right, a number is an inclusive integer designator unless I wrap it in a list)
0:42:02
no-defun-allowed
In CCL: (upgraded-array-element-type '(integer 1 12)) ; ⇒ (UNSIGNED-BYTE 8)
0:46:16
no-defun-allowed
I...don't think many processors have instructions for manipulating 4-bit quantities, so it would probably only be better at saving memory.
1:34:14
pjb
LdBeth: most implementations also have octet vectors. You can also assume fixnum vectors.
1:43:53
jcowan
there's a case to be made that 1 bit per byte is more performant if you can afford the space
1:47:50
pjb
It really depends on the operation. CL has a set of bit-* operations that work on whole bit-vectors. For those operations, packing bits in words is more efficient, both in space and time.
1:54:45
jcowan
But it's not true that aref is the only slow operation: for example "rotate (CL) byte" is not efficient at all with 1 bit per bit
1:58:48
pjb
Again, (rotatef (aref bv 0) (aref bv 1) (aref bv 2) (aref bv 3) (aref bv 4) (aref bv 5) (aref bv 6) (aref bv 7)) can be very efficient in CL (one read, one rotation of the octet, one store).
2:01:36
jcowan
Those are the simple cases. Try using the constants 2, 3, 5, 7, 11, 13, 17, 19 instead
2:13:11
aeth
The inability to declare something pure (beyond inlining and hoping) is probably one of the biggest weaknesses of CL optimizations. That is, you can have something effectively constant that's not seen as constant, unless you go out of your way to e.g. run it with #.
2:14:59
aeth
A pure FP subset of CL that compiles to CL should be able to beat idiomatic CL in performance in some cases.
2:17:04
aeth
A related weakness is that you can have something literal like '(1 2 3 4) and you can see (e.g. with disassemble) the compiler have fun optimizing it within a function, but that's as far as it can go.
2:17:40
aeth
(defun foo () (let ((l '(1 2 3 4))) (car l))) ; disassemble this in SBCL and you can see that it returns 2, i.e. 1 with the fixnum tag. and caddr will return 6, i.e. 3 with the fixnum tag.
2:20:44
aeth
The compilation model is also a weakness here. The compiler can't substitute (foo) with 1 (except within the file, which it might do if not notinline!) because FOO can be redefined at any time.
2:23:17
aeth
Finding a way to retore multi-file block compilation in SBCL could make a lot of this possible, but without a pure declaration, it would still be pretty easy to accidentally deoptimize your code.
4:47:19
pjb
LdBeth: in any case, you can always specify a specific element-type for your arrays. Perhaps the current implementation doesn't optimize it, but the next one will!
4:48:42
aeth
pjb: this has been discussed before and some of the element-types people might want (e.g. structs, if someone is used to C/C++/etc.) would be problematic to optimize
4:52:29
pjb
aeth: exactly. In the current implementations. But in the future it may be different. And it's a way to document the code.
7:09:53
phoe
I've hit the 50-page milestone on my "article" about the Common Lisp condition system. I guess it's time to start calling it a book instead.
7:13:17
beach
phoe: I am still very busy. Now I need to finish reading and assessing the document by Didier Verna, regarding his "habilitation".
7:25:53
aeth
phoe: when you do have a book, you should put it on one of those sites that does low-volume publishing so people can buy it
8:12:51
ATuin
seems that sbcl was updated at some point to 2.0.3 (dunno if that's the problem or now though)
8:15:52
ATuin
looks like a problem with the paths right? since the binary is the same (one the symlink and the other dereferencing)
8:16:43
ATuin
yep, i think the same, but i want to understand the root of the problem so i can fix it
8:19:59
ATuin
i tried to use (trace) but it does not provide enough info to see exactly what's taking the cpu so busy
9:11:21
phoe
the syntax inconsistencies between HANDLER-BIND and HANDLER-CASE and between RESTART-BIND and RESTART-CASE are kinda gross now that I think about them
9:12:09
phoe
HANDLER-BIND has a &body that accepts forms to be execused while HANDLER-CASE has a &body that accepts handler definitions
9:13:22
no-defun-allowed
The committee did care for aesthetics; there's a section for it in every issue writeup.
9:14:25
shka_
yes, but it is very likely that weirdness like above is the result of the backward compatibility requirements
9:15:00
no-defun-allowed
Maybe. Not so much a "committee" problem as a "don't break things" problem then.
9:36:33
phoe
restart-bind's :test-function accepts #'foo, but restart-case's :test does not accept #'foo
11:24:40
phoe
I remember someone mentioning a macro named HANDLER-CASE* which worked exactly like HANDLER-CASE, except the cases were executed before unwinding the stack. Is anyone aware of any existing permissively-licensed implementation of it?
12:23:41
eta
loading it and running (ROOM) results in 50,077,648 bytes for 1,311,232 dynamic objects (space total)
12:27:21
_death
it includes the runtime, the compiler, docstrings, caches, libraries, docstrings, etc.
12:27:27
p_l
CMUCL (and thus SBCL, which derives from it) compiler is famous for generating fast code. However, the same rules that help it generate fast code mean that it takes more space, due to inlining et al
12:28:17
p_l
eta: immobile space is the stuff that is, for various reason, "pinned" in memory location
12:28:40
p_l
eta: btw, the optimization features? They also take space in terms of compiler code, so you get more space used by compiler, too :)
12:30:40
p_l
the GC algorithms work better if you have large address space + budget for ~2x the amount of memory used at any particular time (it's a quick approximation, not hard rule)
12:31:33
p_l
ACTION remembers when people used to complain about VCL's size when compiling binaries with Delphi :/
12:37:12
phoe
nowadays people run whole virtualized OSes to run their tiny apps; compared to this, SBCL footprint feels smol