These are chat archives for dropbox/pyston

23rd
Jun 2015
Chris Toshok
@toshok
Jun 23 2015 00:11
ahah, okay finally figured out what was going on with page faults with larger mmap blocks
linux clusters pages such that when it faults, it reads a certain number of pages ahead. it’s basically 2^n where n = the value in /proc/sys/vm/page-cluster (3 on jitdev)
i’m guessing it’s not just read-ahead, and also works for private/anonymous mappings
Chris Toshok
@toshok
Jun 23 2015 01:48
I’ve been seeing this intermittently today when doing make quick_check:
-- Constructing LLVMBuild project information
CMake Error at /home/toshok/pyston_deps/llvm-trunk/CMakeLists.txt:409 (message):
  Unexpected failure executing llvm-build: Traceback (most recent call last):

    File "/home/toshok/pyston_deps/llvm-trunk/utils/llvm-build/llvm-build", line 6, in <module>
      llvmbuild.main()
    File "/mnt/toshok/pyston_deps/llvm-trunk/utils/llvm-build/llvmbuild/main.py", line 919, in main
      opts.optional_components)
    File "/mnt/toshok/pyston_deps/llvm-trunk/utils/llvm-build/llvmbuild/main.py", line 427, in write_library_table
      os.remove(output_path+'.new')

  OSError: [Errno 2] No such file or directory:
  '/mnt/toshok/pyston/build/Debug/llvm/tools/llvm-config/LibraryDependencies.inc.new’
Chris Toshok
@toshok
Jun 23 2015 21:42
what’s the lifetime for a BoxedWrapperDescriptor?
do they live for as long as the BoxedClass does?
Chris Toshok
@toshok
Jun 23 2015 22:41
i think the new rewriter changes are shifting pressure onto the gc
Travis Hance
@tjhance
Jun 23 2015 22:42
what do you mean?
are they actively hurting the gc? or do you just mean they’re making it relatively more important as a fraction of our time
Chris Toshok
@toshok
Jun 23 2015 22:46
the latter
i think it’s actually less additional pressure, and more just the rewriter changes are removing the other stuff from perf output
Travis Hance
@tjhance
Jun 23 2015 22:51
speaking of the re-writer, does anybody know offhand what are the most complicated things we re-write? (I want to look at some assembly to better understand the effects of some of my changes)
getattr, perhaps?
runtimeCall?
anything else?
Chris Toshok
@toshok
Jun 23 2015 22:52
callattr?
Travis Hance
@tjhance
Jun 23 2015 22:52
oh yeah callattr
definitely
Chris Toshok
@toshok
Jun 23 2015 23:20
interesting. looks like __eq__ is the hottest class slot, on unicode objects. and just setting a breakpoint on my printfs and doing c 100 pretty much always lands on some python code doing something like:
    if command in parse_until:
Kevin Modzelewski
@kmod
Jun 23 2015 23:23
I should probably merge this kmod/pyston@073245a
Chris Toshok
@toshok
Jun 23 2015 23:24
ah nice I was just going to check out something like that
cherry-picking now
yeah that makes a pretty large change - from 41k boxedwrapperobjects for the hottest <self,inst,owner> tuple, down to 34.
Chris Toshok
@toshok
Jun 23 2015 23:30
i thought the overhead of switching between apis would be entirely exception translation
Travis Hance
@tjhance
Jun 23 2015 23:30
that’s a lot
Chris Toshok
@toshok
Jun 23 2015 23:30
guess I was wrong :)
Travis Hance
@tjhance
Jun 23 2015 23:30
so the extra thing being allocated is the object returned by compareInternal?
or what is it?
Chris Toshok
@toshok
Jun 23 2015 23:31
no, it was being allocated in compareInternal to actually do the comparison
Travis Hance
@tjhance
Jun 23 2015 23:31
why does PyObject_RichCompareBool not call compareInternal?
Chris Toshok
@toshok
Jun 23 2015 23:31
it was basically a throwaway BoxedWrapperObject that was allocated solely so we could call it
Travis Hance
@tjhance
Jun 23 2015 23:32
we optimize that sort of thing out in callattr (e.g., we don't construct a BoxedInstanceMethod when we do a.b())
Chris Toshok
@toshok
Jun 23 2015 23:32
right but inside our own builtins we can't
we’ve got other uses of compareInternal + nonzero too
Kevin Modzelewski
@kmod
Jun 23 2015 23:46
so the compare() case is a bit messy right now since it's half-migrated
compare() calls PyObject_RichCompare
but only if there isn't a rewrite
in which case it calls compareInternal
which has rewrite-ability
compareInternal should probably have the ability to rewrite to c slots if that makes sense
but I don't want to switch it to just calling the c slots without rewriting, since that will hurt the cases that we could actually rewrite
so the easier thing for now is just switch callers who can't rewrite to use PyObject_RichCompareBool
Kevin Modzelewski
@kmod
Jun 23 2015 23:54
I guess we could/should move the call to PyObject_RichCompare to compareInternal rather than in compare()