freenode/#clasp - IRC Chatlog
Search
16:17:17
Bike
the stuff i had to speed up typecase probably isn't immediately suitable for subtypep because it's simplifying in different ways
16:19:00
Bike
and of course for type inference we can lose a lot of precision. karlosz, what kind of types do you think will come up most? i mean we can probably lose stuff like satisfies, right?
16:21:11
Bike
optimizing just cl:subtypep generally might be something to avoid. we need it early which severely limits our options, and it has a lot of distinct use cases
16:24:55
Bike
handling numbers, arrays, functions, and values types and collapsing everything else to classes might be good. maybe conses, not sure
16:32:05
Bike
although i'm not sure of the imprecision semantics. if a function is defined as taking a (satisfies foo) argument and we collapse that into T and eliminate the test that seems unfortunate
16:44:46
karlosz
Bike: from instrumenting subtypep the main problems right now are that it doesn't handle cons types at all
16:45:12
karlosz
so everytime subtypep (canoncialize-type) encounters a cons type it does a C++ unwind tanking compiler performance
16:46:30
karlosz
i think right now subtypep unwinding on cons types contributes to 10-20% compiler overhead at the moment on certain system
16:47:42
karlosz
the next thing that subtypep encounters a lot are unknown types coming from type declarations in defclass's and stuff like that
16:48:11
karlosz
about 90% of the types we encounter in self build that we can't handle right now in subtypep are CONS types
16:50:39
karlosz
to implement cons types properly we'll need to throw the bit vector implementation out and replace it with a normalizing interpreter like the one in sbcl i think
16:51:20
Bike
well what i mean here is we don't need to use cl:subtypep in the compiler, we can have the ctype methods do something more specifically tailored to our needs
16:55:01
karlosz
Bike: it seems hard to make subtypep in cleavir handle cons types without invoking cl:subtypep
16:58:13
karlosz
yeah, that's why i thought it might be difficult to handle cons types outside cl:subtypep
16:59:07
karlosz
so essentially this restrictred subtypep will just handle compund and specialized types and punt to cl:subtypep for the more rpimtiive sutff
17:00:17
Bike
yeah i meant like, specializing the methods rather than using the default implementation
17:01:49
karlosz
ironclad dumps out a lot of bignums, i'm guessing for all the unsigned-byte 64 declarations
17:04:32
Bike
if you look at core__next_primitive_string in bignum.cc you can see how to get at the raw data. it's pretty simple. i guess we'd want functions to read and write it from a stream, or something?
17:05:51
Bike
next-primitive-string prints out the words for the bignum. you can try like (core:n-p-s (* m-p-fixnum m-p-fixnum))
17:09:15
karlosz
well i was just thinking of dumping the bignum by dumping the bytes directly into the stream with a header for how many bytes
17:10:19
Bike
the data is just a size (which is sometimes negative to indicate that the bignum is) and an array of mp_limb_t, which is uint64_t or so
17:21:55
Bike
ok it looks like sbcl actually does do what i was thinking of doing but i was worried about the performance of
17:42:50
Bike
the definition is in src/core/byte-code-interpreter.cc. it's generated by that stuff at the end of cmpliteral
18:00:38
karlosz
i guess the way the mp interface is written it would be better to dump out the limbs and then load them in
18:09:10
kpoeck
(mp:process-run-function :foo #'(lambda() (mod 1 0))) does not hang, but cpu is at 100%
18:10:31
kpoeck
after evaluating (mp:all-processes) 3 times, I finally get the expected DIVISION-BY-ZERO exception and cpu lod is back down
18:18:16
Bike
well, maybe it is doing an FPE and it ends up in our signal handler and that hangs for whatever reason
18:35:19
kpoeck
If i put the following in the beginning of clasp_truncate, the error goes away (not surprising)
20:24:03
karlosz
i changed ltvc_make_next_bignum to take a length argument instead of a string and now i get ("Mismatch of ltvc read types read '7' expected 's'")
21:16:51
drmeister
A light is starting to come on above my head. This mysterious stuff in the boehm gc_mark.h file is starting to look less mysterious.
21:17:56
drmeister
It's a tagging scheme for objects in Boehm. It's got tag bits and something like a stamp (proc_index) and something they call (env).
21:18:51
drmeister
Maaaayyyyyybbbeeeee? (env) is used to keep track of work when partially scanning large objects?
21:24:52
drmeister
This probably solves the mystery of what ECL is up to - the tag bits can control how the marking system works with an object.
21:27:03
drmeister
Ahhh - interesting - they have a tag to treat the rest of the header as a bitmap for marking pointers.
21:28:29
drmeister
I'll have to ensure that pointers are word aligned - but that's just a bit of work.
21:32:52
karlosz
now i'm getting This single dispatch generic function #S(SINGLE-DISPATCH-GENERIC-FUNCTION-CLOSURE GET-TYPE #slots[4]) does not recognize argument class #S(BUILT-IN-CLASS FIXNUM )
23:59:23
drmeister
Right now I think cons cells will need headers - I think I'll just make them 4 words [ boehm-header-word | clasp-header? | car | cdr ]
0:00:48
drmeister
Although - I increased the alignment to 16 bytes for some reason - why did I do that?