freenode/#sbcl - IRC Chatlog
Search
19:15:40
stassats
i feel like there's a lot of room to make the compiler faster overall, nothing it does is inherently slow, just poor datastrctures, unnecessary work and slow fixed point detection
19:48:07
pkhuong
stassats: there's cool stuff to do to make the compiler faster, but in a lot of cases, I'm able to come up with pathological counter examples :\
20:19:54
aeth
Parallel compilation would be done at the level of something like ASDF and not SBCL, right?
20:21:44
aeth
Good question. I assumed files would be compiled in parallel, but one file could be compiled in parallel, too.
20:22:15
aeth
And the former would probably have to be done by ASDF and the latter would probably have to be done by SBCL
20:23:09
pkhuong
aeth: even parallelism at file granularity is hard in CL, apparently. I think that's what Fare is trying to achieve with uiop.
21:20:03
aeth
I wonder if it works with asdf's package-inferred-system or if that just infers things to be serial.
21:21:23
aeth
too bad most systems are defined to be serial so it wouldn't help with large dependencies
21:22:48
aeth
The longest compilation time I could think of for a realistic large application is probably 2 min (on my system, your experience might differ), which would be cut down to 15 seconds in a naive (/ 120 8) calculation. From noticable to not that noticable.
21:24:44
aeth
It wouldn't be really (/ 120 8) even at full utilization for various reasons, like hyperthreading (it's only really a quad core) and turbo boost (single-core is faster)
21:25:05
stassats
even 2 minute build times is not something that would bother me, since i rarely rebuild the whole thing
21:26:05
aeth
It depends on what you modify. If it has a foo/utils that almost everything depends on, then modifying utils would rebuild close to the whole thing afaik.
21:27:12
stassats
one of my projects takes around 2 minutes to bring up, but i do it once in a development session
21:29:16
aeth
#lispgames probably could get 20 minute build times if any of the engines actually became big and professional (like GNU?)
21:30:37
aeth
pfdietz2: Imo, one of the key ways to ensure correct code in SBCL is to use type declarations.
21:32:49
aeth
I haven't written it yet, but I think combining type declarations with (setf sb-ext:*derive-function-types* t) should essentially give static type checking, although obviously *derive-function-types* shouldn't be used when using CL interactively via SLIME.
21:41:39
pfdietz2
Program is built in reverse of control flow, so you don't generate assignments or bindings to dead things.
21:42:47
aeth
pfdietz2: That looks like it's designed for compilers, but I think something similar would be useful for frameworks.
21:43:46
stassats
pfdietz2: so, are you implying compiler instrumentation? cause i'm not really sure how to do that from "user space"
21:47:19
pfdietz2
Current random tester generated lots of dead code. Exercised dead code logic in the compiler a lot.
4:45:56
corci
Project sbcl-master build #3492: FAILURE in 1 hr 7 min: http://ci.cor-lab.de/job/sbcl-master/3492/
4:46:14
corci
Project sbcl-master-windows build #2712: FAILURE in 35 min: http://ci.cor-lab.de/job/sbcl-master-windows/2712/
5:16:38
corci
Project sbcl-master-windows build #2713: FIXED in 30 min: http://ci.cor-lab.de/job/sbcl-master-windows/2713/