These are chat archives for dropbox/pyston

25th
Apr 2015
Chris Toshok
@toshok
Apr 25 2015 00:00
weird. this little microbenchmark:
import time

for i in xrange(100000):
    try:
        start = time.time()
        float("hi")
    except:
        elapsed = time.time() - start
        print "%4.1fms" % (elapsed * 1000.0,)
with python, uniq -c prints: 100000 0.0ms
with pyston, i see this:
     36  0.0ms
      1  1.0ms
     37  0.0ms
      1  1.0ms
     36  0.0ms
...
Kevin Modzelewski
@kmod
Apr 25 2015 00:08
looks like we need #define HAVE_GETTIMEOFDAY 1
Michael Arntzenius
@rntz
Apr 25 2015 00:10
hm, looks like we might be feeding the wrong segbase in _U_dyn_register
Chris Toshok
@toshok
Apr 25 2015 00:11
oh man.. i’ve been benchmarking using time(time_t*)? :(
that’s better. looks like python is ~2-3us, pyston is 20-30us
Kevin Modzelewski
@kmod
Apr 25 2015 00:27
are exceptions still a big part of the django runtime, even with getTraceback gone and the libgcc patch?
Chris Toshok
@toshok
Apr 25 2015 00:44
appears to be. there’s got to be some overhead with all the time.time() calls i’m doing, but:
compile filter : Variable(var) took 1.9ms = pyston
compile filter : Variable(var) took 0.0ms = cpython
that’s the constructor that does float(var). in this case, var == “block.super”
Chris Toshok
@toshok
Apr 25 2015 00:50
oh hm, maybe it’s the __float__ conversion in unicodeobject.c?
we coerce to a string in that case
will see about that after I get some food
Michael Arntzenius
@rntz
Apr 25 2015 01:16
aha! found the problem. we were passing the wrong information to _U_dyn_register - our start ip offset was wrong
only 3 tests failing under -n now on the unwinder branch
Chris Toshok
@toshok
Apr 25 2015 02:24
Awesome
Chris Toshok
@toshok
Apr 25 2015 03:55
are the cmake builds usable in gdb?
specifically is pyston_release? building pyston_dbg now
Kevin Modzelewski
@kmod
Apr 25 2015 18:54
I think cmake builds pyston_release without debug info
I wouldn't mind changing the default to including the debug info
Marius Wachtler
@undingen
Apr 25 2015 20:03
I'm not really sure what todo with pycrypto _fastmath.c it implements a conversation between cpythons longs and GMP. And currenty fails to build because our representation is different.
Is it sensible to change pycryptos code to take advantage of pystons longs and that they are already GMP compatible?
Marius Wachtler
@undingen
Apr 25 2015 20:10
The _fastmath.c file is also optional. if unavailable the library will do normal python long math
Which is probably slower and also more vulnerable to timing attacks
Daniel Agar
@dagar
Apr 25 2015 20:15
@kmod cmake has a built in mode called RELWITHDEBINFO that's -O2 -g -DNDEBUG
Marius Wachtler
@undingen
Apr 25 2015 20:43
oh .... we hit an assert inside LLVM currently when running the pycrypto tests because llvm does not support machine operands with more than 255 arguments because the number has to fit in 8bits and we generate patchpoint instructions with more arguments...
Marius Wachtler
@undingen
Apr 25 2015 20:50
This is the file which let's use generate patchpoints with hundreds of args: https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/SelfTest/Cipher/test_AES.py
Marius Wachtler
@undingen
Apr 25 2015 22:53
I think we have to supply real implementations (no wrappers) for the PyNumberMethods members or have to reimplement the binaryop/ternaryop functions: I copied the implementation from ternary_op over but it wont work correctly.... For example __pow(int, long, long)
It will retrieve tp_as_number[nb_power] from the lhs (which in the example is an int) and calls it. int.pow(long, long) is unimplemented (also in cpython) so it retrieves the tp_as_number[nb_power] function of the second argument (long) and tries the same...
Marius Wachtler
@undingen
Apr 25 2015 22:58
long.__pow__(int, long, long) is implemented so this should work, but it won't in pyston because all of the tp_as_number[nb_power] implementations are just slot_nb_power wrappers which call the "__pow__" attribute of the argument passed as first which will always be the int.
sorry for the bad formatting....
Travis Hance
@tjhance
Apr 25 2015 23:02
Gitter does let you edit posts, in case you weren't aware
I frequently have to edit to add in backfires haha
Marius Wachtler
@undingen
Apr 25 2015 23:03
Oh I already used the edit feature... I just don't know how to prevent the formating
lol.... I meant the underscore underscore bold feature...
Travis Hance
@tjhance
Apr 25 2015 23:03
Well adding backticks should fix it right?
Marius Wachtler
@undingen
Apr 25 2015 23:05
true
Ok now the formatting is better, but how I'm going to fix my bad english? :-D
Travis Hance
@tjhance
Apr 25 2015 23:08
Hm I don't have enough context to understand what you said
What do you mean by "real implementations (no wrappers)"
Marius Wachtler
@undingen
Apr 25 2015 23:26
when the cpython pow function is called it will call the ternary_op function (it supports a 3. modulo arg). This one will retrieve the pow function implementation of all 3 passed args and try them one after another until one is implemented. In cpython every tp_as_number entry will point to the implementation of the function (for capi types). In pyston this will just be a wrapper which will call the __pow__ attribute on the first argument. This means we loose the ability to call a different implementation because it will always be the one of the first argument and we can't swap arguments because this would change the result.
I could reimplement ternary_op so that it directly calls the __pow__ attribute (or the one which we want to access) instead of going thru tp_as_number or we could supply non wrapper implementations for this function... But now I'm thinking changing it to directly call the attribute is much better and much less code to change...