freenode/#clasp - IRC Chatlog
Search
11:53:26
drmeister
kpoeck: Thank you for the heads up on that fixup.lsp build problem yesterday. That would have been nasty today.
11:54:37
drmeister
Well, that's not quite fair - we got a docker build that built cleanly - so we could have used that.
11:55:49
kpoeck
I actually tried to do git reset to older commit, but obviously didn't go back long enough
11:56:19
drmeister
Sort of. I got the bullet proof backtrace to work just before we left. I was thinking about it as I drove. When I got to the hotel I checked a few things and noticed that the fastgf inline code was way bigger than I remembered it.
11:57:13
drmeister
Bike had moved it for logical reasons - I had forgotten how sensitive the fastgf stuff was to inline code size.
14:11:52
Colleen
Bike: drmeister said 8 hours, 59 minutes ago: - I pulled cc_dispatch_miss and cc_dispatch_debug out of fastgf.cc and put them into link_intrinsics.cc. It builds again. Doing this drops the boehm-fastgf-cxx.ll file down to 654 lines but with them it is 12153 lines. This shouldn't cause a crash (dunno what's up there) but it's way too large to inline into every discriminating function. I was very careful to check boehm-fastgf-cxx.ll so make sure ...
14:11:52
Colleen
Bike: drmeister said 8 hours, 58 minutes ago: - ... it stayed as small as possible and didn't drag in a lot of other code, which is apparently what happens when we add cc_dispatch_miss and/or cc_dispatch_debug. These are slow path and debugging functions - and one or both cause a LOT of other code to get dragged in to boehm-fastgf-cxx.bc.
14:14:23
drmeister
Right - once I moved those two out, the bitcode file dropped from 20,000+lines to ~600 lines.
14:15:01
drmeister
I still don't know why it crashed - it shouldn't have crashed even if the file is large.
14:15:34
drmeister
Try moving them back and then look at the .ll file that is generated (boehm-fastgf-cxx.ll)
14:15:41
Bike
do you have debug flags on? are they on by default? can we move cc_dispatch_miss but not _debug?
14:16:29
drmeister
If you move anything, look at the resulting .ll file before and after. That's the criterion. The file has to stay small and tight.
14:18:18
Bike
builtins.cc is stuff that is inlined, and intrinsics.cc that's inlined depending on wh ether it's compile or compile-file, right?
14:19:28
drmeister
intrinsics.cc is less controlled, link_intrinsics are things that should be linked to.
14:21:53
drmeister
Well, there is some history here. intrinsics are functions that are called directly via linking, not indirectly via funcall.
14:22:25
drmeister
fastgf.cc and builtins.cc get inlined into EVERY discriminating function and module generated by COMPILE respectively.
14:23:14
drmeister
intrinsics.cc are intrinsics that might be inlined if they are small enough and llvm decides its a good idea.
14:23:51
drmeister
For fastgf.cc and builtins.cc, llvm has no choice. We declare them always_inline.
14:25:51
Bike
builtins: "Small functions used by the runtime that should always be inlined." fastgf: "Small functions used by the fastgf runtime that should always be inlined."
14:26:17
Bike
intrinsics: "Small functions used by the runtime that may be inlined at the compiler's discretion." link_intrinsics: "Small functions used by the runtime that should NOT be inlined."
14:55:27
Bike
i guess the fastgf binary might have gotten bigger because i had to include some stuff and in C++ that goes weird sometimes
14:55:39
Bike
it just seems implausible that just cc_dispatch_debug could add tens of thousands of lines
17:30:27
Bike
so looking at the discriminating function vaslist business, we write the registers into a save area, then "rewind" the vaslist based on the save area
17:31:04
Bike
but i guess the register arguments probably do have to get into contiguous memory somehow
18:00:48
shiho
I mean (language.smarts.parser:parse "[Na]" 'list) -> (:ATOM NIL :KIND :ORGANIC :SYMBOL "N" :BOUNDS (1 . 2))(:ATOM NIL :KIND :AROMATIC :BOUNDS (2 . 3))
18:04:52
drmeister
shiho: We can probably fix that - the usual way I do it is first to check against all two character element names and then one character element names.
18:07:05
drmeister
I set up a cando jupyterlab server on the iMacPro but I wasn't able to test it. I think it needs to be shutdown anyway and a new one started up.
18:13:25
scymtym
shiho: drmeister: one of the lists in https://github.com/scymtym/language.smarts/blob/future/src/smiles/parser/grammar.lisp#L59-L73 must be incomplete. i'm surprised how this went wrong since i copied those lists
18:15:29
drmeister
scymtym: Can we just reorder the lists? Two character names first, one character names second?
18:16:41
Bike
https://github.com/drmeister/cando/blob/bfb02a4759a12d3acd47e195ef19d7c79c07757a/src/chem/msmarts_Parser.cc#L2436-L2444 not sure it's present in what you copied from
18:17:06
scymtym
but yes, if you add "Na", it has to go in before "N" (esrap will warn about the problem)
18:21:23
scymtym
drmeister: if this variant of the SMARTS language will be an important component of cando, a formal description of the language will be needed since it deviates from the existing specifications (and those aren't optimal either)
18:21:51
drmeister
Shiho: Regarding chemistry Alex's work. I can't get into the iMacPro to fix the jupyterlab server that I set up there - so we are spinning up an Amazon machine for him to try.
18:28:06
scymtym
i pushed a commit adding "Na" to INORGANIC-ATOM-SYMBOL to the "future" branch of https://github.com/scymtym/language.smarts . the tests assert that "[Na]" is parsed as (bracketed-expression … (:atom () :kind :inorganic :symbol "Na" …) …). is that correct?
19:09:40
Bike
I tried building with my lisp gf compiler, and it's a good deal slower (build took 48m instead of 22m like usual) but everything seems to work
19:14:45
drmeister
Ok - that's consistent with expectations. I guess efficient gf dispatch is really important for good performance from cleavir.