freenode/#sicl - IRC Chatlog
Search
14:04:44
Bike
hm, dunno. the problem pretty much comes when you swap out a rack, so you need adjust-array or change-class or something.
14:06:23
beach
My take is that, if there is a loop of some kind, and a function call inside the loop, then there could be some side effect of that function call, so a slower version may be required.
14:07:39
Bike
and if there's some primitive operation that has a side effect, that also rules out the fast version?
14:08:27
Bike
doesn't seem like there are a lot of loops like this that could actually grab the rack, then?
14:10:59
beach
I don't know. You may very well be right. Though things like summing up the elements doesn't seem to have any side effect in it.
14:12:07
Bike
probably tricky to determine that for anything beyond a lexical variable that's not closed over (though that's an important case)
14:12:17
beach
And didn't we conclude that a simple test to check that the rack has not changed before each loop would be enough to give the right to continue?
14:14:28
beach
I guess you are well on the way, but there might be things that are highly implementation specific.
14:15:53
beach
By the way, are you changing the way Clasp represents standard objects. Your conversations are a bit to long for me to follow, and they involve lots of C++ which I don't really understand.
14:17:25
Bike
well, i was rearranging some things. right now in clasp we have kind of a funny arrangement with funcallable instances. since the code pointer is directly in the instance instead of in the rack, and matches the offset of the code pointer in functions that aren't instances, it's hard to arrange for the rack to be at the same offset in both instances and funcallable instances
14:17:58
Bike
for a while we fixed this by having a useless spacer in non-funcallable instances, so i was trying to arrange things so that the rack can be at different offsets with no problem
14:18:22
Bike
i'd still like to do that, but for now i just have the class at a different offset instead. it's not as important to access quickly, i think
14:18:53
Bike
and i might try putting the class in the rack and using triples and so on, at some point, but first i think i'll play with dfuns a bit
14:19:48
Bike
i just set it up so that the ctor mechanism is used for make-instance calls even when the class isn't constant, and that works fine
14:20:08
Bike
doubles the speed of instance creation in some really basic tests, from skipping the keywords check and the loops in shared-initialize
14:22:13
Bike
might have to reconsider how effective method functions are passed their arguments. i think a general case might mean passing all the required arguments, all those objects' racks, and then further arguments could maybe be spread out to avoid reprocessing
14:22:35
Bike
like if you have a method with (&key a) and another with (&key b), the discriminating function could look for both keys and pass them along as regular arguments
14:24:20
beach
Certainly, argument passing within a generic function may be very costly if done the most general way.
14:24:50
Bike
yeah, right now on clasp each method function with &key deconstructs it. it's obviously suboptimal
14:26:17
Bike
i don't know how SBCL generic functions handle keyword arguments. but yeah i should figure it out, let's see
14:27:26
Bike
nope, looks like the fast method function still takes &key, so there will be reprocessing
14:28:33
beach
Also, SBCL doesn't depend as much on generic functions as, say, SICL will, and Cleavir already does.
15:45:37
heisig
Inlining the keyword parsing step is one of the most rewarding features of fast-generic-functions. But it is hard to do it without sealing all involved entities.
15:47:15
heisig
If we had an extensible annotation/recompilation mechanism for functions then "Doesn't call change-class" would be an excellent annotation.
15:50:54
heisig
Another convenience feature could be that (maybe only on safety 3) change-class inspects the stack and asserts that no method dispatch assumptions are violated.
16:34:39
jcowan
The Oracle JVM has a concept of lightweight locks, which are used initially. If a lot of contention takes place, the lock is upgraded to a heavyweight lock.
16:44:22
jcowan
Spin locks are used first, but if they time out, then the regular locking mechanism kicks in. A lightweight lock involves only single CaS operation that gets inlined, whereas a heavyweight lock maintains a per-lock queue and a non-inlined procedure to manage it.
16:48:13
beach
My (admittedly small) family just announced that dinner is served. After dinner, I will spend time with her. I might check in later. If not, I'll be back tomorrow morning (UTC+2).
21:17:02
Bike
i realized i could reuse most of the ctor code for a dfun for reinitialize-instance, so i tried that out. in the simplistic case of one keyword argument and no custom methods, it's about fifty times faster than calling reinitialize-instance