19:48:05drmeisterYes, it means what we suspected - there is still a problem with caught exceptions in bclasp - but funwind_protect is now working as it should.
19:55:37Bikei'm really not sure what's going on with this non-optimization thing.
19:55:52Bikesometimes methods aren't marked as leaves and i don't know why. if i run the defmethod again it fixes itself
19:56:56drmeisterIt's using the code walker - I don't know how it could get confused
19:58:40drmeisterTiming data for fast methods (assuming they are working)
20:06:00drmeisterI'm guess that we are still spilling registers into the register save area of the generic function... checking...
20:07:26Bikeby the way, to test the outcomes, just look at the call history. there's a fast-method-call structure
20:07:50scymtym_drmeister: you could also declare N to be of type fixnum to avoid generic arithmetic overhead. i have seen these things matter in my own fastgf benchmarks
20:08:50Bikeoh, yeah, the loop is definitely going to be slower on clasp
20:09:21Bikethat's a problem with optimizing this closely
20:09:29Bikethere's all kinds of other stuff to work on, of course
20:11:04drmeisterThere's double and float arithmetic code in there.
20:12:20drmeisterBike: They are fast-method-call structures! Good job!
20:12:43stassatsok, my speed would be potentially unsafe
21:22:26drmeisterIt's calling llvm.va_end on an uninitialized va_list in dispatch-va_list* - that's not good.
21:22:42drmeisterI don't know what llvm.va_end does - it might be a noop.
21:23:58drmeisterThen it reads the stamp from the first argument in a register
21:24:33drmeisterThen it reads the rack, checks if the result is boundp
21:25:31drmeisterThen it bundles up the result and returns.
21:25:55drmeisterRegister spilling only happens if there is a dispatch-miss - good.
21:28:22Bikei found a bug in applicable-method-p, not sure if it's what's causing the weirdness though
21:28:32drmeisterWe could get rid of some of the bit shifting if we compared the stamp to tagged stamp values - but other than that - I don't see much more room for improvement.
21:29:43Bikeapplicable-method-p thinks that a call history entry with an eql specializer never has any methods without eql specializers in that position apply to it, which is pretty wrong
21:33:17drmeisterBut you are saying that if the eql specialized method calls call-next-method - it should end up in the symbol class specialized method.
21:43:56Bikei just like noting what i'm doing, i guess
21:44:48drmeisterUnderstood - I only say that because it involves code walking and the code walkers (bclasp and cclasp) are a little squirrelly.
21:46:02Bikeyeah, i'm worried about that. but i'm not there yet.
21:46:14Bikei just noticed it's mostly things with eql specializers where this happens
21:48:39drmeisterWe inherited this generic-function slot called spec-list - it keeps track of when a generic function argument position includes eql specializers or not - I only have a vague idea of how it works.