libera/#clasp - IRC Chatlog
Search
15:45:39
drmeister
If we hardwire to use `/usr/local/opt/llvm@14` and rebuild then it will always go for llvm@14 on our systems.
15:46:01
yitzi
When I rerun the build on a system with llvm15 present it will link to llvm14's actual location
15:46:41
yitzi
the location is gotten from llvm-config so it will return the correct value for the updated system with both versions present.
15:47:50
frgo
This seems not to be flexible enough. On my ARM-based Mac I had to install homebrew from scratch and homebrew not sits in /opt/homebrew - with llm being at /opt/homebrew/opt/llvm ...
15:48:38
drmeister
yitzi: I tested the idea using: `install_name_tool -change /usr/local/opt/llvm/lib/libLLVM.dylib /usr/local/opt/llvm@14/lib/libLLVM.dylib /usr/local/Cellar/cando/1.0.0-529-gc6c8ae3c6-g7371ab99/bin/iclasp-boehmprecise`
15:49:07
drmeister
That changes the path in the executable to hardwire it to `/usr/local/opt/llvm@14` - now it works.
15:49:31
drmeister
frgo: On an M1 Mac you need to use x86 terminal/shell and install homebrew from there.
15:50:00
drmeister
frgo: Sorry about that - but llvm is still missing features that would allow us to build M1 native clasp.
15:50:27
drmeister
frgo: Have you heard from kpoeck lately? I've been emailing him but have gotten no response. I'm a bit worried.
15:51:33
drmeister
frgo: Clasp is totally ready to support ARM/M1 - the problem is the llvm LLJIT doesn't handle unwinding properly yet.
15:53:05
drmeister
frgo: I just asked on the discord server for llvm/#jit what the status is of M1 support for LLJIT.
15:54:34
drmeister
frgo: The Apple engineer that is developing LLJIT is someone I know. He's been working on it off and on over the last couple of months.
15:56:25
drmeister
Buuuuut - any fixes like that usually need wait for an official llvm release. Unless he fixed it weeks ago and it's in llvm@15 it's going to be a wait until llvm@16
15:57:04
drmeister
I've been doing everything under x86 emulation with Rosetta2 - it's totally painless once you set things up that you only use x86 terminals.
15:57:42
drmeister
Running under x86/Rosetta2 is a contagion. Anything you execute from an x86 shell/terminal is x86.
15:59:10
drmeister
There will probably ALSO be a problem with the fmt library: `-L/usr/local/Cellar/fmt/9.1.0/lib`
15:59:54
drmeister
Nope, that will probably be ok. That was a problem yesterday - but not today for some reason.
16:00:27
drmeister
yitzi: Did you suggest a while ago that we LOAD everything with bytecode compilation?
16:01:51
Bike
we could have bytecode call god knows what, which then calls bytecode, and that will need to know where the stack pointer is so it can orient itself, so i guess the stack pointer does sort of need to be "global"
16:02:18
Bike
saving the stack pointer around calls doesn't seem to obviously be terribly slow, either... i guess it might be fine
16:03:11
Bike
so then making it a local would just be like the pc stuff, in that it's kind of a microoptimization... might still matter of course
16:11:16
yitzi
I did suggest loading via bytecode. It might be useful to control via a dynamic variable.
16:12:24
drmeister
I think it might be a good idea - there may be issues with the inlining code in cleavir.
16:23:53
Bike
the fancy locally notinline thing in the error compiler macro (a) works in the bytecode compiler now and (b) is unnecessary if error has a properly defined type, so i'm gonna edit and reenable it
16:24:16
Bike
then i'm thinking of moving the type proclamations in inline.lisp to a new file and putting that back into the build
16:28:12
drmeister
I think I figured out how to profile code running in the VM - to put that code on the same level as native code.
16:29:13
drmeister
Then when profiling we would need to swap backtrace IP addresses that are in the bytecode_vm function with VM._pc addresses.
16:30:54
drmeister
If the VM is perfectly efficient then we wouldn't need to profile it. We would want to profile the stuff running in it.
16:35:50
drmeister
I learned something about thermodynamics yesterday and the "ergodic hypothesis". Fruit flies are fundamentally different from gas molecules.
16:36:46
drmeister
This device can trap fruit flies - but if it could trap gas molecules then it would violate laws of thermodynamics.
16:43:36
Bike
if we make the virtual machine use enough instructions, maybe it will hit the thermodynamic limit and we can just use statistical physics instead of all this "computer science" nonsense
16:58:23
drmeister
DEBUG_DRAG_CXX_CALLS, DEBUG_DRAG_NATIVE_CALLS, DEBUG_DRAG_INTERPRET_DTREE, DEBUG_DRAG_CONS_ALLOCATION, DEBUG_DRAG_GENERAL_ALLOCATION
16:58:41
yitzi
Bike: we could make a thermodynamic ensemble with 10,000 virtual machines in the same box with a different state that can't see each other.
16:59:27
drmeister
DEBUG_DRAG_NATIVE_CALLS isn't implemented yet - we need to insert a call to `extern "C" void drag_native_calls();` in every xep function.
17:00:12
drmeister
If you add one unit of DRAG to one of these things then it adds about 10 machine instructions/unit-drag.
17:00:36
drmeister
If adding one unit of DRAG doesn't impact something important - then it's not worth optimizing out 10 instructions.
17:00:39
karlosz
drmeister: what exactly are the instructions inserted? not all machine instructions are created equal (in terms of cycles etc)
17:01:37
drmeister
The idea is whatever I do here - it's only a rough comparison to anything we might optimize away.
17:05:18
drmeister
If adding one unit of DRAG to a thing doesn't impact performance then optimizing away the equivalent amount of machine instructions from that thing won't matter.
17:14:50
karlosz
Bike: i suppose it made sense to put the fp as a local variable because the fp is constant for the duration of a bytecode call frame
17:15:25
karlosz
but still it should be possible to do it funciton locally and pass it around through the vm struct at the boundaries
17:34:53
drmeister
We need to look carefully at the tagging stuff. I'm thinking that some of it is an artifact of how C++ debug info works.
17:35:40
drmeister
I added gc::As_assert<Foo_sp>(x) <- this is a cast if DEBUG_ASSERT is not defined and a type check if DEBUG_ASSERT is defined.
17:36:42
drmeister
Here is a video stepping through the 437 instructions in the forward direction...
17:36:42
drmeister
https://www.dropbox.com/s/ffcyzkx8rm23d02/Screen%20Recording%202022-09-19%20at%201.26.58%20PM.mov?dl=0
17:46:32
drmeister
Now, after compile-file-serial of predlib.lisp a couple of times to settle down the GF dispatch compilation ...
17:52:07
karlosz
drmeister, Bike: i got PC-as-a-local-variable to build, so that should shave another ocuple instructions
17:52:25
Bike
this might slow down build again, since it can insert type declarations in safe code... hopefully not too bad though...
18:02:17
Bike
what's the easiest way to see how long the overall build takes. can i just wrap ninja in time
18:09:44
Bike
not loading inline.lisp also means we won't save new inline definitions, so the compile time will also be affected by that, in addition to the actually applying the inline
18:17:27
drmeister
I have to compile-file-serial predlib.lisp a couple of times to get the timing to settle down.
18:19:54
Bike
i can put in something to force all the dispatchers to compile if you want. actually i feel like i already did that at some point but it went out of use.
18:22:09
drmeister
Just exposed cxx functions that have non-trivial lambda-lists - ones with bytecode wrappers
18:28:48
Bike
says that arithmetic functions return numbers, ERROR doesn't return, that kind of thing
18:29:15
drmeister
With auto-compile.lisp disabled cleavir won't run - or did you move that into proclamations?
18:32:06
Bike
oh, wait, do you mean that if it's before auto compile the type procalmations won't get saved
18:32:41
drmeister
I don't know about that. auto-compile.lisp is where cleavir turns on. inline-prep.lisp is where cleavir inlining gets prepared for.
18:51:24
drmeister
I'm building code and something to do with single stepping (I think) is messing up.
18:53:20
drmeister
https://github.com/clasp-developers/clasp/blob/main/src/lisp/kernel/cleavir/translate.lisp#L615
18:58:00
Bike
...and what exactly the index is of, like, what's the source position that's being dumped
18:58:49
drmeister
https://github.com/clasp-developers/clasp/blob/main/src/lisp/kernel/cleavir/translate.lisp#L616
19:05:29
Bike
that either means that the cst is completely messed up, or that we're inserting a step before a literal constant, which would be silly
19:05:46
drmeister
What should I trace to get to the bottom. I have a compile-file-serial that is reproducibly screwing this up.
19:22:49
Bike
what's happening here is we have a call instruction, and for some reason its source is a literal zero. that seems messed up.
19:23:07
Bike
maybe you can check the cst:source of the origin to see exactly which 0 it is? i don't know. this is pretty bizarre.
19:37:54
Bike
either declare debug to be something less than 3, or just (declare (optimize (clasp-cleavir::insert-step-conditions nil))) should do it i think
19:56:01
yitzi
At some point some of the cleavir files (auto-compile, inline, etc) got moved out of the clasp-cleavir.asd and put into the system list explicitly. At point we should move them back to the asd and let koga grovel them as it does with the rest of clasp-cleavir.
20:45:41
drmeister
I tried to push like three times and each time got distracted by someone elses push and then a distraction here.
20:49:27
drmeister
Little things like As_assert give me a visceral thrill to use - it's a clever little thing that keeps the code clean and adds safety with no release runtime cost.
20:54:28
drmeister
yitzi: Commenting on something you said earlier on the phone. ECL does have (sys:install-bytecode-compiler) - that installs the bytecode compiler as the default compiler.
20:55:41
drmeister
We should be able to put it under control of a dynamic variable once the bytecode compiler can do anything that it is missing.
20:56:18
drmeister
There is some fussy stuff like some compiler macros that cleavir can use, the bytecode compiler cannot.
20:58:04
drmeister
I'd be all for LOADing everything with the bytecode compiler and then COMPILE-FILEing things with Cleavir.
20:58:37
drmeister
The only hitch is that the inlining code may get really bogged down if its running in bytecode.
21:18:40
drmeister
Bike: I'm going to stick a call to extern "C" drag_native_calls() right at the top of every generated function IFF sys:*drag-native-calls* is T.
21:27:46
drmeister
That let's us slow all compiled functions by about 20 instructions for each drag unit.
21:39:10
drmeister
drag = 0. Time real(8.470 secs) run(8.470 secs) consed(2752278536 bytes) interps(2186) unwinds(0)
21:39:41
drmeister
drag = 100. Time real(12.079 secs) run(12.079 secs) consed(2749859640 bytes) interps(2182) unwinds(0)
21:40:19
drmeister
drag = 0. Time real(8.473 secs) run(8.473 secs) consed(2739291616 bytes) interps(2178) unwinds(0)
21:40:32
drmeister
drag = 100. Time real(10.581 secs) run(10.581 secs) consed(2754494432 bytes) interps(2182) unwinds(0)
21:41:16
drmeister
drag = 0. Time real(8.552 secs) run(8.552 secs) consed(2755525056 bytes) interps(2186) unwinds(0)
21:41:51
drmeister
drag = 10. Time real(14.150 secs) run(14.150 secs) consed(2754744056 bytes) interps(2186) unwinds(0)
21:42:50
drmeister
drag = 0. Time real(8.555 secs) run(8.555 secs) consed(2755360640 bytes) interps(2186) unwinds(0)
21:43:33
drmeister
drag = 100. Time real(24.954 secs) run(24.954 secs) consed(2740699464 bytes) interps(2178) unwinds(0)
21:44:36
drmeister
So in order of importance for speeding things up... cxx-call wrappers, general-allocation, cons-allocation, native-calls
21:46:09
drmeister
Bike: What was the bytecompile that you tried to do early when clasp was starting up that gave you a mysterious problem?
21:47:19
drmeister
I want to look at that now - because it feeds into my idea to compile the wrappers.
21:47:22
Bike
cmprepl-bytecode does (setq *implicit-compile-hook* 'bytecode-implicit-compile-repl-form)
21:47:37
Bike
i got the error when i changed it to (setq *implicit-compile-hook* 'bytecode-implicit-compile-form)
21:53:59
drmeister
yitzi: I'm getting this when I load_vclasp-boehmprecise stopping early - hang on...
21:57:53
drmeister
I put in a test... Could not use file-write-date on #P"SYS:SRC;LISP;KERNEL;CONTRIB;ACCLIMATION;PACKAGES.LISP"
22:00:51
drmeister
There is something wrong with `(probe-file #P"sys:src;lisp;kernel;contrib;acclimation;")`
22:03:34
drmeister
is export CLASP_STAGE_COUNT=2 ; `ninja -C build load_vclasp-boehmprecise` something I should be able to do?
22:07:19
drmeister
Bike: What problem did you see? Because I can start up the interpreter with nothing else and `(setq cmp:*implicit-compile-hook* 'cmp:bytecode-implicit-compile-form)` and it compiles and evaluates forms.
22:10:48
karlosz
drmeister: good to know we are at 392 instructions for that snippet now. this wrapper stuff is where drag showed the most impact right? i think thers more instructions to be squeezed out. the nil tag thing is really weird
22:13:16
drmeister
Bike: When you use CL_DEFUN - I think you need the package designator in front of it.
22:13:37
drmeister
So it should be: `CL_DEFUN T_mv comp__bytecode_implicit_compile_form(T_sp form, T_sp env) {`
22:15:02
drmeister
::notify Bike Ping me when you are online about CL_DEFUN - I have some questions and might clear up some things.
22:15:57
drmeister
karlosz: I'd like to move the cvm code into clasp - could we do that? as in clasp/src/cvm ?
22:16:46
drmeister
I'd like to move the have one definitive source of VM opcode info and one definitive reference compiler.
22:35:20
karlosz
Bike: i think optimizing the stack pointer access will be just as if not even mor effective than the pc optimization. here's the code for every instance of vm.pop which gets inlined https://paste.gnome.org/2ldoNSB6D
22:36:12
karlosz
whereas we really need just 2: a memory load into the value variable, and then a pointer increment.
22:41:33
drmeister
How should cmp__bytecode_implicit_compile_form differ from cmp__bytecode_eval_with_env ?
22:42:45
drmeister
`export CLASP_STAGE_COUNT=2; ninja -C build load_vclasp-boehmprecise` is the correct way to stop after stage 2 - right?
23:09:59
drmeister
Yesterday I switched the code to use fmt::fprintf(std::iostream ...) - it WORKED on zeus and I thought "great - the fmt people made fprintf work with iostreams". Now you tell me it doesn't work with iostreams. How is all of our code working???
23:12:40
drmeister
I am in effing version hell right now. fmt just changed from 9.0 to 9.1 - did they drop support for ostreams in just the last couple of days?
23:13:01
drmeister
Did I change all of our code to use ostreams within a few hours of fmt dropping support for it?
23:13:38
Colleen
Bike: drmeister said 58 minutes, 36 seconds ago: Ping me when you are online about CL_DEFUN - I have some questions and might clear up some things.
23:36:45
yitzi
Actually I think the issue might be that fprintf is exclusively for FILE, whereas print is for ostreams.
23:41:33
yitzi
Nope, they completely removed them in 9.1.0 .... wow I guess they consider a point release to be a "major" release. Amazing.
23:46:03
Bike
tracing the vm, i can see it going through a function, hitting return, and then somehow ending up at a previous instruction, with the same frame pointer
23:46:13
Bike
this function shouldn't be recursive and in any case the previous instruction isn't after a call
23:53:03
Bike
what it specifically does is special-bind, then some save-sp's, then bla bla bla return
0:01:22
Bike
i see... because all returns have been nonlocal so far... so it'll just escape from any number of interposed special-bind frames
0:06:04
Bike
::notify karlosz save-sp/restore-sp is broken with respect to unbinding special variables, for now
2:03:39
drmeister
Bike: Other than boostrapping issues I'm not having any problems installing the bytecode compiler as the implicit compiler.
2:08:48
drmeister
If you turn that on in configure_clasp.h then it turns on the bytecode compiler right from the start.
2:32:41
drmeister
The OUT-OF-EXTENT-UNWIND was me - I removed whatever caused it by unwinding some changes I made to the early code to allow bytecompile to work.
2:57:19
Bike
do is defined... really early. i don't think it depends on anything except some other simple macros like when and dolist
3:08:06
drmeister
I moved a bunch of macros into `export.lisp` and I load that before `jit-setup.lisp` in `init.lisp` - I get a lot farther.
3:09:59
drmeister
It's surprising how tangled this all is. I implemented some macros in the interpreter long ago to allow us to bootstrap.
3:11:33
drmeister
That's so you can see everything load and you see what the context is when it crashes.
3:20:06
drmeister
There were two hooks that need to be defined - one hook was starting up the interpreter and that fed a ValueEnvironment_O into the system
3:30:06
drmeister
https://github.com/clasp-developers/clasp/blob/vm/src/lisp/kernel/lsp/seqlib.lisp#L881
3:30:37
drmeister
You have: https://github.com/clasp-developers/clasp/blob/vm/src/lisp/kernel/lsp/seqlib.lisp#L885