freenode/#lisp - IRC Chatlog
Search
8:25:30
aeth
If you write a Forth implementation in CL (or any language) you have to call it Firth of Forth. https://en.wikipedia.org/wiki/Firth_of_Forth
8:31:33
lieven
Henry Baker did some work on that. for example http://home.pipeline.com/~hbaker1/ForthStack.html
8:38:46
no-defun-allowed
it just says [it hasn't been submitted](https://github.com/eshamster/cl-naive-bayes)
9:20:06
schweers
is it just my impression, or is compiling Lisp code really pretty fast, even with SBCL?
9:21:12
dim
well it depends, I think the fact that we often compile a small chunk at a time interactively makes it for a very low-latency feedback loop and it then seems very fast
9:21:39
dim
that said compiling pgloader sources to a binary image takes minutes, as you can see at https://travis-ci.org/dimitri/pgloader
9:21:55
schweers
I find it quite fast even when I empty the cache (~/.cache/common-lisp) and load my whole system it is reasonably fast.
9:23:35
schweers
hm, so it seems my impression is only partly correct. Nevertheless, it’s not extremely slow as one might naively expect
9:23:50
aeth
The problem with CL compilation is that it is not parallel and afaik that is a problem that would have to be solved by ASDF.
9:24:47
dim
schweers: I think most people attributes slowness to being “interpreted” languages and don't understand that a language isn't compiled or interpreted, the implementation is, and may be both (as in javascript), and also that the level of flexibility and dynamism we have in CL, people think it must cost a lot in perfs
9:25:42
aeth
dim: It *does* costs a lot, it's just that on 2018 hardware those costs are usually laughable.
9:25:59
loke
no-defun-allowed: CCL's code generation isn't as good as SBCL's but I've never really been in a situation where that matters.
9:27:16
dim
CCL/SBCL: pgloader shows the difference quite clearly, CCL is far better at Garbage Collection and memory maintenance while SBCL produces code that can be twice as fast
9:27:21
schweers
the programs maybe, but it seems that the runtime is still often too large for “embedded” devices. Which is why I don’t like said devices
9:27:21
aeth
shka_: Only because programs are using a lot more RAM than they used to. I am running several daemons that have almost bloated to the starting RAM usage of SBCL (including systemd and Xorg, which probably surprises no one)
9:27:53
aeth
But most SBCL programs don't compare to the web browser and browser-based 'native' programs
9:30:18
schweers
ah, speaking of garbage collection; does anyone know for sure what SBCL uses on AMD64? The manual is not exactly clear on the distinction between 32 and 64 bit x86.
9:31:47
aeth
The state of the art for garbage collectors are made for Java and/or the JVM, in general.
9:32:21
schweers
wow. Now I’m even more impressed with GC. TIME in SBCL reports how much time was spent in GC and out of GC. I was always impressed by how little time the collector needed. Now that you’re telling me this could be even better, I’m even more impressed and convinced that GC is good for performance.
9:33:26
aeth
schweers: The lowest hanging fruits in SBCL performance improvements are probably the GC and CLOS, at least based on stuff people say in #lisp
12:48:34
LdBeth
is there *fast* approch to implement binary op so add #xFFFF and #x0123 is #x0122 and subtruact #x0123 form #x0121is #xFFFE
12:55:31
shka_
somehow sbcl seems to be able to infer that this operation is allowed to overflow and produces slightly different code
13:24:20
Shinmera
but the good news is you don't need to, just spawn a swank server and connect to it with slime (tunnelling the port through ssh for instance)
13:24:46
Shinmera
systemd will automatically log any stderr/stdout output to journald for all its services, so you don't need to do anything for that
13:25:12
dingusman
ok, yeah, if I didn't run screen I guess the second question is no longer relevant
13:26:44
dingusman
Does it matter what's in start.lisp in this example? seems to me this will still start sbcl in interactive mode
13:28:09
dingusman
I tried something like this already. But (IIUC) systemd points process' stdin at /dev/null
13:32:37
dingusman
And I'd still be able to connect the swank server since it's running in a separate thread?
13:58:02
dim
dingusman: you can also have a look at https://github.com/dimitri/pgcharts/blob/master/src/pgcharts.lisp if you want, for an alternative implementation, still with the idea of (loop :while *server-is-running* :do (sleep 1))
14:05:31
dingusman
dim: thank you, that's helpful. I've been looking for some real-life hunchentoot server code. There's a lot for me to learn in there
14:11:02
dim
dingusman: the part I like a lot is the serving of static files from memory, and building a binary image that includes those static resources, so that you only have one file to deploy
14:16:01
dingusman
That is neat. I'm doing something pretty similar. Generate a ql dependency bundle, html/js with who/parenscript, then load it all in and dump it to a core image to deploy
14:17:07
dim
hehe... do you compress the core? it might make the startup time a little longer, but gives a much smaller image
14:26:53
dingusman
dim: managed to kill my emacs in the process, but compression makes a big difference
14:29:26
Shinmera
there's a noticeable difference if you want to do scripts and stuff but for a heavy-weight thing like a server or a gui it's perfectly fine.
19:02:31
jackdaniel
hey. I want to write a fast function which does alpha-composition between two rgba pixels, here's what I've got: http://ix.io/1kSL/lisp
19:02:45
jackdaniel
I'm not very good with bit fiddling so I'd appreciate any hints how I could improve this code
19:43:14
jackdaniel
_death: thanks. it is internal function because I care about speed in there (it is for McCLIM framebuffer image rendering)
19:43:40
jackdaniel
I'll look up the look-up tables though, may be useful for testing if I didn't mess things up