These are chat archives for dropbox/pyston

4th
Jul 2016
Kevin Modzelewski
@kmod
Jul 04 2016 00:51
I agree, I think there's definitely room for us to use more aggressive speculation+invalidation in general
Right now we mostly use guarding
It's not just other threads though that can muck with your program state
Chris Seaton
@chrisseaton
Jul 04 2016 00:52
You can think of a safe point as one big fat guard (doesn't sound as good then)
Tristan Hume
@trishume
Jul 04 2016 00:53
true, but if you don't call any unknown functions in a tight computation loop, the main thing that can sabotage your ability to hoist the guards out of the loop is other threads.
Kevin Modzelewski
@kmod
Jul 04 2016 00:54
Well, I'm not sure how common a use case that is
It doesn't seem to happen that much at Dropbox, and in the numeric community they're pretty good about offloading that kind of stuff to numpy
Tristan Hume
@trishume
Jul 04 2016 00:54
If you have working hoisting, you don't have to offload stuff to numpy.
Kevin Modzelewski
@kmod
Jul 04 2016 00:55
Also there's the pathological case of signals coming in which can have arbitrary effects
Tristan Hume
@trishume
Jul 04 2016 00:56
right, I guess that is a form of concurrency even if you disable parallelism
you could have a special case that after a signal comes in you invalidate all JITed code, but that is basically a crappy form of safepoints
And also if you have an effect system for known functions, like flags for "modifies _ kind of hash table", you can hoist things even when other functions are called.
Although I definitely think safepoints are a better idea, now that Chris reminded me they exist and work really well.
They are pretty much strictly better than my original idea, other than perhaps being harder to implement than simply disabling threads.