freenode/#clasp - IRC Chatlog
Search
13:04:16
kpoeck
I am getting spurious errors with find-class returning nil although the class is clearly defined
13:06:03
kpoeck
I have tried to defined a minimal test case in https://github.com/clasp-developers/clasp/issues/636
13:09:53
drmeister
kpoeck: Interesting about the spurious find-class issues - and you have a test - excellent!
13:10:51
drmeister
You may be used to using 'clasp', which is a symlink to 'cclasp-boehm', which is a single executable.
13:11:16
drmeister
'iclasp-boehm' contains only the linked C++ code and it loads the cclasp image as a fasl file.
13:11:27
kpoeck
The seg fault is not urgen, I have a second installation with older code that works fine
13:13:39
drmeister
Huh, I built the latest dev last night and I just counted the number of lines of llvm-ir using: wc `find . -name '*.ll' -print` --> 9,985,761
13:23:25
drmeister
That's a substantial reduction in code! Yet it says that it took more than 4 hours to build.
13:25:13
Bike
kpoeck: WITH_READ_LOCK will end at the end of the block it's in (so just after the "foundp =" there). it's raii stuff.
13:25:44
Bike
kpoeck: this particular function is organized like that because signaling an error while holding a lock is problematic
13:29:35
drmeister
Looking at the code I don't see how it could fail, even in a multithreaded situation, to report classes that are present.
13:30:05
Bike
i'm pretty willing to believe i'm missing something, when it comes to multithreading, though
13:31:11
drmeister
Ugh - actually I'm rebuilding cclasp - so I don't have anything to test with for a bit.
13:32:59
drmeister
If we have really knocked the amount of llvm-ir down by more than half then the build should be noticeably faster.
13:38:44
drmeister
I've seen wildly inconsistent build times before. I think it is something to do with macOS throttling processes that are in windows in the background.
14:26:44
drmeister
The build isn't any slower - it must have been power management issue that caused that 4h build.
14:27:26
drmeister
But inline.lsp and fli.lsp are taking a long time (707 and 866 seconds respectively).
14:27:52
drmeister
So it sits there doing serial compilation for a long time. I'm going to pull those two forward to start them first.
14:31:55
drmeister
But the overall build time was 1h7m - that's longer than the 27 min I saw before.
17:03:13
beach
I guess it could be. I am assuming Quicklisp loads all the installed systems, so the total amount of space could be significant.
17:08:52
stassats
have you noticed the RAM prices recently? it's all the clasp users buying more memory
18:43:32
pfdietz
I doubt quicklisp loads all the installed systems, as they are not all mutually compatible.
19:40:47
drmeister
I moved inline.lisp and fli.lsp up to compile them early in the parallel build I'm building it now.
19:41:28
drmeister
The real problem was inline.lisp. It takes the longest and it was started last - so the build system spends all the time building inline.lisp on one core.
19:43:26
drmeister
Well, when inline.lisp is last it means that everything else finishes while inline.lisp is compiling and then it spends a lot of time running on a single core.
19:43:56
drmeister
It's not an issue for fli.lsp because it was being started fairly early. Hang on...
19:45:13
drmeister
Compiling [112 of 439 (child-pid: 84660)] /Users/meister/Development/dev-clasp/src/lisp/kernel/lsp/fli.lsp
19:45:30
drmeister
So fli.lsp is the 112th file to start compiling but it's the second last to finish.
19:46:36
frgo
Yes, sure - so move the ones taking longer up the chain so that some cores are busy while other cores can take on "smaller" compiles.
19:46:39
drmeister
It's a load balancing thing. Ideally it builds on all cores right up to the end and then all cores finish at the same time.
19:53:48
drmeister
Hmm, even when I start inline.lisp as the first compilation - everything else finishes on all the other cores before inline.lisp finishes.
20:13:01
drmeister
It's way more balanced when I move inline.lisp to be the first file to start compiling
20:13:57
drmeister
I didn't do anything fancy - in clasp-builder.lisp I added a move-to-front command and then explicitly move fli.lsp and then inline.lisp to the front of the queue.
20:14:09
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/clasp-builder.lsp#L663