These are chat archives for dropbox/pyston

1st
Aug 2015
Sun
@Daetalus
Aug 01 2015 02:15
@kmod #787 updated. Please review if you have time.
Sun
@Daetalus
Aug 01 2015 02:56
Hi, @rudi-c . Are you there?
Rudi Chen
@rudi-c
Aug 01 2015 03:18
On my phone. What's up?
Sun
@Daetalus
Aug 01 2015 03:22
It's seems alreay at weekend.
I saw you create some issues. I believe these related with Numpy support. I will work on it. Does copy and modify the CPython complex implementation is acceptable?
Rudi Chen
@rudi-c
Aug 01 2015 04:07
Yeah it's worth trying that first because it'd be a lot less effort. Otherwise we'd have to deal with a lot of edge cases. We can probably get better performance if we implement our own version but complex number performance isn't very high priority for Pyston to begin with.
Sun
@Daetalus
Aug 01 2015 04:09
Ok, then will try to work on it. Hope it will help the Pyston-NumPy support
Rudi Chen
@rudi-c
Aug 01 2015 04:13
Thanks :D
Sun
@Daetalus
Aug 01 2015 04:41
Hi, I am also working on test_int issue. I made some modification, but encounter a test error: statcheck: noninit_count('slowpath_runtimecall') < 10.
I saw there have some statement log the slowpath stuff. What does it mean. What may cause the statcheck error? Could anyone give some tips, please? Thanks!
Rudi Chen
@rudi-c
Aug 01 2015 04:44
Ah, we're getting to the interesting and challenging part. We have a bunch of runtime functions that have a slow path (implemented in C++, does a bunch of things like check if the argument is string for example). If the function gets called enough, we might generate faster assembly and replace the slow function with it.
The assertion checks if the functions gets rewritten after some number of calls.
If you hit the assert, this could mean a couple things. The function gets called more often in ways that are hard to rewrite (e.g. type of argument keeps changing). Rewriting fails. A new guard fails and we fall back to the slow path.
Kevin Modzelewski
@kmod
Aug 01 2015 04:56
did it print another number after that line about the stat failure?
something like
('noninit_count("slowpath_runtimecall") < 10', 'slowpath_runtimecall', 12)
Dong-hee Na
@corona10
Aug 01 2015 05:44
@kmod if you re okay can u review #774??
Sun
@Daetalus
Aug 01 2015 06:11
Yes, @kmod ('noninit_count("slowpath_runtimecall") < 10', 'slowpath_runtimecall', 1xxx), four digit number. in test `int_ics"
Kevin Modzelewski
@kmod
Aug 01 2015 06:50
oh interesting
yeah that means it's failing to rewrite the call to int()
Sun
@Daetalus
Aug 01 2015 06:50
I see.
I made some change in int(). I will find what cause it.
Kevin Modzelewski
@kmod
Aug 01 2015 06:51
int() is tricky since int is actually a constructor, which has more complicated rules than just a simple function call
(or technically, "execute a constructor" is a normal function call but it's important for performance that we take the actual function behavior into account)
if you changed intNew to a capi-style int_new that would probably cause this issue
Sun
@Daetalus
Aug 01 2015 06:53
Yes, that's what I did....
So leave int_new in Pyston cpp style?
Kevin Modzelewski
@kmod
Aug 01 2015 06:54
either that or update typeCallInner
I would recommend leaving it as Pyston style for now
Sun
@Daetalus
Aug 01 2015 06:56
Ok, got it.
Kevin Modzelewski
@kmod
Aug 01 2015 06:56
I think new and init are cases that it's currently better to leave things in pyston style
well, there are still the compatibility benefits of switching to exactly cpython's code, but for __new__ and __init__ there are some more performance benefits to leaving things in the pyston style
Sun
@Daetalus
Aug 01 2015 06:57
Understood.
Kevin Modzelewski
@kmod
Aug 01 2015 06:57
(specifically, since capi versions of those functions are supposed to take *args which is more expensive than our register-based calling convention)
Sun
@Daetalus
Aug 01 2015 07:02
I wrote it to my note book. :smile:
Travis Hance
@tjhance
Aug 01 2015 07:03

comment above callattrInternal (pretty sure this is an old, old comment)

// For rewriting purposes, this function assumes that nargs will be constant.                           
// That's probably fine for some uses (ex binops), but otherwise it should be guarded on beforehand.

Why ever would the number of args not be constant?

Kevin Modzelewski
@kmod
Aug 01 2015 07:18
probably never
I guess it was just an attempt to be explicit about what arguments were properties of the rewrite vs inputs to a specific call of the rewrite
ex the attr is also assumed to be constant
I guess neither of those can actually get triggered
but I guess you could imagine a runtime-IC usage that would be invalid, like
ic = createCallattrIC();
ic(attr1, 1, arg1);
ic(attr2, 2, arg1, arg2);
and you might expect that the new attr2 and nargs=2 would apply, but really it had already generated a rewrite that assumed that attr was attr1 and there was one arg
Kevin Modzelewski
@kmod
Aug 01 2015 23:29
hey @tjhance, here's another related rewriter project:
it'd be nice if we could support something like val = condition ? f() : g()
ie take a branch and then get the return value from whichever branch we took
I think we have all the branching stuff, but I think we're missing the ability to join values together from different branches (phi nodes)
like, make sure that both branches put the return value in the same register or stack slot
Travis Hance
@tjhance
Aug 01 2015 23:33
What do you want it for?