#pypy IRC log for Tuesday, 2011-10-25

aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) joined #pypy.00:00
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) left irc: Quit: Computer has gone to sleep.00:05
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) joined #pypy.00:10
fzzzy (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) joined #pypy.00:20
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) left irc: Quit: Computer has gone to sleep.00:20
fzzzy (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) left irc: Client Quit00:21
fzzzy (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) joined #pypy.00:21
etrepum_ (~bob@accessnat4.mochimedia.net) joined #pypy.00:30
tav (~tav@host-92-20-26-15.as13285.net) left irc: Ping timeout: 240 seconds00:32
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) joined #pypy.00:32
etrepum (~bob@accessnat4.mochimedia.net) left irc: Ping timeout: 255 seconds00:33
maxyz (~maxy@186.23.74.228) left irc: Ping timeout: 252 seconds00:33
etrepum_ (~bob@accessnat4.mochimedia.net) left irc: Ping timeout: 245 seconds00:34
dmalcolm (david@nat/redhat/x-aryquvcngwunikfv) left irc: Quit: Leaving00:34
maxyz (~maxy@186.23.74.228) joined #pypy.00:34
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) left irc: Client Quit00:36
fzzzy (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) left irc: Quit: fzzzy00:37
tav (~tav@host-2-99-72-126.as13285.net) joined #pypy.00:37
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) joined #pypy.00:47
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) left irc: Client Quit00:49
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/180300:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/24900:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/53700:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-64/builds/59000:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/106500:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-Ojit-no-jit-linux-x86-32/builds/77600:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-32/builds/140800:50
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/66900:50
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/24000:50
DasIch (~dasich@p4FFDFEA7.dip.t-dialin.net) left irc: Ping timeout: 256 seconds01:02
kenaan12alex_gaynor virtual-dicts 11912afce3954e 15/pypy/jit/metainterp/: it... all seems to work01:09
etrepum (~bob@75-101-96-144.dsl.static.sonic.net) joined #pypy.01:09
kenaan12alex_gaynor virtual-dicts 118cae4e3f42e9 15/pypy/jit/metainterp/optimizeopt/virtualstate.py: fix translation01:26
Remilia_Scarlet (~proton@124.131.64.28) joined #pypy.01:39
bbot23Success: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-32/builds/918 [12alex]01:44
Vorpal (~AnMaster@unaffiliated/anmaster) left irc: Ping timeout: 252 seconds01:44
Moku (~John@osbk-4d08744c.pool.mediaWays.net) joined #pypy.01:54
Guest28331 (~John@osbk-4db06492.pool.mediaWays.net) left irc: Ping timeout: 240 seconds01:54
Nick change: Moku -> Guest1255701:55
tilgovi (~randall@couchdb/developer/tilgovi) left irc: Ping timeout: 240 seconds01:56
DasIch (~dasich@p4FFDF277.dip.t-dialin.net) joined #pypy.02:06
Arfrever (~Arfrever@apache/committer/Arfrever) left irc: Quit: Ex+re02:12
fzzzy_ (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) joined #pypy.02:13
Remilia_Scarlet (~proton@124.131.64.28) left irc: Quit: leaving02:14
davisagli (~davisagli@davisagli.com) left irc: Excess Flood02:38
davisagli (~davisagli@davisagli.com) joined #pypy.02:39
crakdmirror (~crakdmirr@174.127.114.26) left irc: Quit: ZNC - http://znc.sourceforge.net02:40
Transformer (~Transform@ool-4a59e397.dyn.optonline.net) joined #pypy.02:45
Transformer (~Transform@ool-4a59e397.dyn.optonline.net) left irc: Excess Flood02:46
crakdmirror (~crakdmirr@174.127.114.26) joined #pypy.02:49
mcdonc (~mcdonc@cabana.palladion.com) left irc: Ping timeout: 258 seconds02:53
[mat^2] (~mathias@212.130.113.35) joined #pypy.02:55
mat^2 (~mathias@212.130.113.35) left irc: Ping timeout: 276 seconds02:55
lac_ (~quassel@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.02:55
lac (~quassel@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Ping timeout: 240 seconds02:56
canta (~canta@77-20-123-240-dynip.superkabel.de) joined #pypy.02:59
fzzzy_ (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) left irc: Quit: fzzzy_03:07
[mat^2] (~mathias@212.130.113.35) left irc: Ping timeout: 260 seconds03:13
mwhudson (~mwh@linaro/mwhudson) left irc: Ping timeout: 240 seconds03:16
bbot23Success: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/115 [12alex]03:19
davisagli (~davisagli@davisagli.com) left irc: Excess Flood03:46
davisagli (~davisagli@davisagli.com) joined #pypy.03:47
mitchellh (~mitchellh@c-71-202-125-40.hsd1.ca.comcast.net) joined #pypy.03:52
bogner (~bogner@2600:3c03::f03c:91ff:fedf:7ef4) left irc: Quit: Coyote finally caught me03:54
Transformer (~Transform@ool-4a59e397.dyn.optonline.net) joined #pypy.03:55
mcdonc (~mcdonc@cabana.palladion.com) joined #pypy.03:55
bogner (~bogner@li325-42.members.linode.com) joined #pypy.03:56
Transformer (~Transform@ool-4a59e397.dyn.optonline.net) left irc: Excess Flood03:56
mwhudson (~mwh@linaro/mwhudson) joined #pypy.03:58
tilgovi (~randall@c-98-210-155-124.hsd1.ca.comcast.net) joined #pypy.04:00
tilgovi (~randall@c-98-210-155-124.hsd1.ca.comcast.net) left irc: Changing host04:00
tilgovi (~randall@couchdb/developer/tilgovi) joined #pypy.04:00
mitchellh (~mitchellh@c-71-202-125-40.hsd1.ca.comcast.net) left irc: Quit: Computer has gone to sleep04:07
kenaan12alex_gaynor virtual-dicts 11fd60bd44e563 15/pypy/jit/metainterp/: next test that I need to pass.  for virtual dicts to be useful in python they need to work through opaq...04:12
Alex_GaynorAnyone feel like teaching a dog new tricks?04:15
Alex_Gaynorhakanardo: ping04:20
mitchellh (~mitchellh@c-71-202-125-40.hsd1.ca.comcast.net) joined #pypy.04:25
bbot24Failure: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/180304:25
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1804 [12alex, virtual-dicts]04:25
kushal (kdas@nat/redhat/x-icsdmhjdtzmcfdla) joined #pypy.04:29
kushal (kdas@nat/redhat/x-icsdmhjdtzmcfdla) left irc: Changing host04:29
kushal (kdas@fedora/kushal) joined #pypy.04:29
PiotrSikora (~none@nginx/adept/piotrsikora) left irc: Excess Flood04:33
tilgovi (~randall@couchdb/developer/tilgovi) left irc: Ping timeout: 252 seconds04:34
PiotrSikora (~none@nginx/adept/piotrsikora) joined #pypy.04:35
tilgovi (~randall@couchdb/developer/tilgovi) joined #pypy.04:40
kenaan12alex_gaynor virtual-dicts 1156876d48b184 15/pypy/jit/: replace cast_opaque_ptr resop, which never did anything except be used to mark its argument with mark_o...04:45
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/24904:51
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) joined #pypy.05:07
mat^2 (~mathias@212.130.113.35) joined #pypy.05:10
canta (~canta@77-20-123-240-dynip.superkabel.de) left irc: Ping timeout: 240 seconds05:13
kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Ping timeout: 240 seconds05:16
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-32/builds/140805:25
mat^2 (~mathias@212.130.113.35) left irc: 05:26
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-Ojit-no-jit-linux-x86-32/builds/77605:28
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-64/builds/59005:38
Alex_GaynorDoes anyone around understand why the final p61 = isn't folded by the frontend heapcache? http://paste.pocoo.org/show/497770/05:41
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/106505:43
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1066 [12alex, virtual-dicts]05:43
lmoura (~lmoura@186.215.206.130) left irc: Ping timeout: 245 seconds05:47
lmoura (~lmoura@186.215.206.130) joined #pypy.05:48
Ademan (~dan@adsl-71-141-242-47.dsl.snfc21.pacbell.net) joined #pypy.05:52
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/24005:54
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/53706:04
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/538 [12alex, virtual-dicts]06:04
hakanardoAlex_Gaynor: pong06:11
mvt (~mvantelli@87.213.45.85) joined #pypy.06:26
mitchellh (~mitchellh@c-71-202-125-40.hsd1.ca.comcast.net) left irc: Quit: Computer has gone to sleep06:33
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1066 [12alex, virtual-dicts]06:48
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/538 [12alex, virtual-dicts]06:59
JaRoel|4d (~jaroel|4d@office.fourdigits.nl) joined #pypy.07:03
Trundle (~andy@p578bfdcf.dip0.t-ipconnect.de) joined #pypy.07:13
Trundle (~andy@p578bfdcf.dip0.t-ipconnect.de) left irc: Changing host07:13
Trundle (~andy@python/site-packages/trundle) joined #pypy.07:13
antocuni (~antocuni@host152-120-dynamic.11-79-r.retail.telecomitalia.it) joined #pypy.07:37
kenaan12hager ppc-jit-backend 117c2f8272c677 15/pypy/jit/backend/ppc/ppcgen/: Implemented STRLEN, STRGETITEM, STRSETITEM.07:37
bivab (~david@fwstups.cs.uni-duesseldorf.de) joined #pypy.07:42
fijal (~fijal@78.9.163.32) joined #pypy.07:46
fijalmorning07:47
teknico (~quassel@88-149-209-131.dynamic.ngi.it) joined #pypy.07:57
amaury_ (~amaury_@74.125.57.34) joined #pypy.08:01
bbot24Failure: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/66908:04
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/670 [12alex, virtual-dicts]08:04
fijalAlex_Gaynor: had a busy day ;-)08:05
lucian_ (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.08:09
fijalAlex_Gaynor: is justin's branch ready to be merged?08:11
arigato (~arigo@fwstups.cs.uni-duesseldorf.de) joined #pypy.08:13
fijalarigato: morning08:14
arigatohi!08:14
Action: fijal ponders what he can measures lightweight-finalizers on08:15
fijalhttp://paste.pocoo.org/show/497810/08:17
fijal^^^ this is significantly faster08:17
stakkars_ (~tismer@89.204.153.112) joined #pypy.08:17
arigatogood :-)08:18
fijal60% faster08:18
bivab (~david@fwstups.cs.uni-duesseldorf.de) left irc: Remote host closed the connection08:18
bivab (~david@fwstups.cs.uni-duesseldorf.de) joined #pypy.08:18
fijal2.4 vs 3.8s08:18
arigatosuccess, I suppose08:18
fijalI suppose08:18
fijalbut it adds complexity for a corner case really08:18
fijalbut maybe a significant corner case08:18
arigatoah, digging into why rbigint is slow: it seems that the slow-down-compared-to-CPython-using-exactly-the-same-algo comes from two factors:08:19
fijalarigato: there is one more issue btw08:19
arigatoone is just general RPythonicity, the other is... "assert" statements08:19
fijalpffff08:19
fijalclear_all_weakrefs is not lightweight at all08:20
fijalhow can we make only the subclass calling clear_all_weakrefs?08:20
fijaland not have it in the base __del__?08:20
arigatothe bsae has a __del__ or not?08:20
fijalthe base has a __del__08:21
tilgovi (~randall@couchdb/developer/tilgovi) left irc: Ping timeout: 252 seconds08:21
lucian_ (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Read error: Connection reset by peer08:21
fijalcan't we put another del on UserObjectArrayWithDel08:21
fijalor however it is called08:21
fijalthat would call clear_all_weakrefs and the base __del__08:21
fijalsounds less error prone as well08:22
tlynn (~tlynn@cpc6-cmbg14-2-0-cust121.5-4.cable.virginmedia.com) joined #pypy.08:22
arigatosomething like that, yes08:22
fijalok08:22
arigatofeel free to reorganize a bit08:22
fijalok08:22
arigatothis part is waiting for a clean-up08:23
Action: fijal runs away scared08:23
arigatoit's delicate to get right :-(08:23
arigatobut with the right approach it would be better08:23
stakkars_ (~tismer@89.204.153.112) left irc: Quit: schnarch08:24
fijalarigato: it's still checking flags instead of keeping old objects with light finalizers list08:25
fijalbut I'm a bit pondering on what I can measure the impact08:25
fijalwould gcbench be good?08:25
arigatofijal: I suppose, but checking flags should not be costly if done "right"08:28
fijalok, but then why we keep a list of objects with finalizers instead of checking flags of everything?08:29
fijalor weakrefs08:29
arigatoweakrefs you need anyway, and finalizers too08:30
arigatobecause they both require you to do something more complicated elsewhere08:31
amaury (amaury_@nat/google/x-kzewsvakmaubjerj) joined #pypy.08:31
fijalok08:31
arigatobut I see the point08:31
fijalI see08:31
fijalyou could in theory gather the list on the fly08:31
fijalprobably not really interesting08:31
arigatono, how?08:31
arigatoif it involves making an extra pass over all objects, then it's terribly slow08:32
arigatoanyway, it's not like it's hard to keep a list of objects with lightweight finalizers08:33
amaury_ (~amaury_@74.125.57.34) left irc: Ping timeout: 240 seconds08:33
arigatoso feel free to do that instead, to get an extra X% of performance (for X probably smallish)08:33
fijalit's ok either way, I'm just pondering how to make it measurable08:34
fijalI'm not going to run around doing changes if I can't measure them08:34
fijalarigato: anyway, lightweight-finalizers is ready for the review as it is08:34
fijalI can improve what's lightweight independently08:35
arigatook08:35
arigatoer, is it?08:35
arigatowhat about clear_all_weakrefs?08:35
fijalthis means that some stuff that should be lightweight is not08:36
fijalbut it still works for other things08:36
fijallike W_Hash08:36
fijalif it belongs to the same branch then ok08:36
arigatowhy is W_Hash not calling  clear_all_weakrefs?...08:37
jonanin (~jonanin@24-183-50-140.dhcp.mdsn.wi.charter.com) left irc: Ping timeout: 252 seconds08:37
kenaan12fijal benchmarks 1105f934e964ab 15/savecpython.py: improve cpython saver08:37
fijalgood question :)08:38
fijalarigato: that's why we should do the calling automatically because we forget :)08:38
fijalok, I'll do the clear_all_weakrefs08:38
arigatowell that's why we should refactor the whole thing a bit more than I did last time... :-)08:39
fijalprecisely08:39
tlynn (~tlynn@cpc6-cmbg14-2-0-cust121.5-4.cable.virginmedia.com) left irc: Ping timeout: 240 seconds08:44
canta (~canta@77-20-123-240-dynip.superkabel.de) joined #pypy.08:48
fijalhttp://speed.pypy.org/comparison/?exe=1%2BL%2Bdefault%2C2%2B35%2C2%2B472&ben=1%2C34%2C27%2C2%2C25%2C3%2C4%2C5%2C22%2C6%2C39%2C7%2C8%2C23%2C24%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C35%2C36%2C37%2C38%2C16%2C28%2C30%2C32%2C29%2C33%2C31%2C17%2C18%2C19%2C20&env=1&hor=true&bas=2%2B472&chart=normal+bars08:49
fijal^^^ uploaded 2.7.2 numbers08:49
ojii (~ojii@40-34.60-188.cust.bluewin.ch) joined #pypy.08:49
fijalI broke the main speed.pypy.org though08:49
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.08:50
kenaan12fijal benchmarks 11354e7ef9ccde 15/savecpython.py: finish fighting08:50
kenaan12fijal benchmarks 119cd4b2c5429c 15/savecpython.py: clarify comment08:50
fijalso besides json (and translation which I did not have heart to run)08:50
fijal2.7 is not much faster than 2.608:50
luciancpython?08:54
kenaan12bivab arm-backend-2 1145d7621d2e2a 15/pypy/jit/backend/test/runner_test.py: extend call_assembler tests to check the fail_descr_number and ensure it is non-zero in the tests08:58
kenaan12bivab arm-backend-2 11f534b61e5913 15/: merge default08:58
kenaan12bivab arm-backend-2 11beae95ba795c 15/pypy/jit/backend/arm/assembler.py: there was a word missing here08:58
kenaan12bivab arm-backend-2 11744854db4b1c 15/pypy/jit/backend/arm/assembler.py: (arigo, bivab) refactor a bit and fix decode_inputargs when checking spilled floating point values08:58
kenaan12bivab arm-backend-2 11411d754b81a2 15/pypy/jit/backend/arm/: set the name of generated functions for floatint point operations08:58
kenaan12bivab arm-backend-2 111aeb2c211a8a 15/pypy/jit/backend/arm/opassembler.py: update comment08:58
kenaan12bivab arm-backend-2 11310898482c7b 15/: merge default08:58
kenaan12bivab arm-backend-2 116d558e62094e 15/pypy/jit/backend/arm/: implement getinteriorfield_gc and setinteriorfield_gc08:58
kenaan12bivab arm-backend-2 113bae2cc9ba15 15/pypy/jit/backend/arm/opassembler.py: add cast_ptr_to_int and cast_int_to_ptr08:58
kenaan12bivab arm-backend-2 118754b1a53808 15/pypy/jit/backend/arm/: add some asserts08:58
kenaan12bivab arm-backend-2 110dc87b084c4a 15/pypy/jit/backend/arm/: fix an error when setting and reading float fields from an object with a large offset08:58
kenaan12bivab arm-backend-2 110868f9fb2793 15/pypy/jit/backend/arm/regalloc.py: forgot to add these methods08:58
kenaan12bivab arm-backend-2 11f29ee3944161 15/pypy/jit/backend/arm/: implement merging of comparison operations with following guards08:58
kenaan12bivab arm-backend-2 117b6405557495 15/pypy/jit/backend/arm/: merge guards with cmp ops for floats08:58
voidspace (~voidspace@python/psf/voidspace) joined #pypy.08:58
G2P (~G2P@fw-asn1.ornis.com) joined #pypy.08:59
bbot24Failure: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1804 [12alex, virtual-dicts]09:01
kenaan12hager ppc-jit-backend 11ef1c13357210 15/pypy/jit/backend/: Implemented UNICODEGETITEM, UNICODESETITEM, UNICODELEN.09:16
Action: arigato sometimes wonder why x86 assembler doesn't have an instruction "clear memory from X to Y" that would use whatever is the most efficient way to do so on the CPU09:20
arigatoin particular, in an algo that does "stuff; clear mem; use mem" or "clear mem; stuff; use mem"09:22
arigatothe 2nd is probably a bit worse because the cleared memory might no longer be in caches09:22
arigatobut what about "stuff; use mem" in one thread, and "clear mem" on another CPU?09:23
arigatoI guess I have to measure09:23
antocuni (~antocuni@host152-120-dynamic.11-79-r.retail.telecomitalia.it) left irc: Ping timeout: 260 seconds09:25
cantawhy would you want memory to be cleared by the cpu?09:30
arigatobecause if the memory size is greater than the caches, you end up sending and reloading from main memory null bytes09:32
arigatowhereas with a small cache on the CPU it could remember that "page N" is fully zeroed, so it doesn't need to reload it09:32
kenaan12hager ppc-jit-backend 112aa87669180f 15/pypy/jit/backend/ppc/ppcgen/opassembler.py: Removed unnecessary operations in emit_unicodegetitem and emit_unicodesetitem.09:37
arigatook, on a modern laptop it makes no difference in real time, and uses 5% more CPU time, to use the multithreaded approach09:43
kenaan12hager ppc-jit-backend 1152d3d714f611 15/pypy/jit/backend/ppc/ppcgen/opassembler.py: Removed unnecessary operations from emit_strgetitem and emit_strsetitem.09:44
arigatowell less than 5%, but more than 2%09:44
arigatoin other words the time saved not doing the clearing on CPU 1 is lost sending stuff over to CPU 209:46
arigato(or in this case from CPU 2)09:46
arigatomakes me wonder if a simple non-multithreaded marksweep gc wouldn't be the best, with no write barrier and no moving09:47
arigatoah wait, you need a write barrier09:47
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) left irc: Quit: x___x09:48
lucianlinus had some interesting comments on caches and gcs09:49
arigatoyes?09:50
arigatomy problem right now is that I can think of 42 different approaches and have no clue which one is best...09:50
arigatomaybe I need to invest more time building general support functions09:51
arigatoso that they can be tried out more quickly09:51
lucianlinus's argument was that gcs were inherently bad with space locality, as opposed to reference counting09:53
lucianbut yeah, it's hard to find the best way, since it's not exactly known. especially with NUMA in the picture09:54
lucianhmm09:54
antocuni (~antocuni@host152-120-dynamic.11-79-r.retail.telecomitalia.it) joined #pypy.09:56
bbot24Failure: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/670 [12alex, virtual-dicts]10:05
witulski (~stupsi@134.99.16.23) joined #pypy.10:09
witulski (stupsi@134.99.16.23) left #pypy.10:10
kenaan12hager ppc-jit-backend 11be68ff457064 15/pypy/jit/backend/ppc/ppcgen/: Implemented SAME_AS operation.10:10
kenaan12bivab arm-backend-2 11fccb38718397 15/pypy/jit/backend/arm/assembler.py: add missing not_implemented implementation10:11
kenaan12bivab arm-backend-2 112df0dec0a518 15/pypy/jit/backend/arm/test/test_runner.py: fix test10:11
JaRoel|4d (~jaroel|4d@office.fourdigits.nl) left irc: Ping timeout: 258 seconds10:14
kenaan12cfbolz int-tag-untag-as-operations 110ed5fb78f4be 15/pypy/jit/metainterp/optimizeopt/: woops10:18
stakkars_ (~tismer@82.113.121.177) joined #pypy.10:27
derdon (~derdon@p5DE89ED9.dip.t-dialin.net) joined #pypy.10:28
jimbaker (~jbaker@canonical/jimbaker) left irc: Ping timeout: 256 seconds10:33
jimbaker (~jbaker@c-75-71-80-146.hsd1.co.comcast.net) joined #pypy.10:36
jimbaker (~jbaker@c-75-71-80-146.hsd1.co.comcast.net) left irc: Changing host10:36
jimbaker (~jbaker@canonical/jimbaker) joined #pypy.10:36
JaRoel|4d (~jaroel|4d@office.fourdigits.nl) joined #pypy.10:45
arigato (~arigo@fwstups.cs.uni-duesseldorf.de) left irc: Ping timeout: 244 seconds10:45
stakkars_ (~tismer@82.113.121.177) left irc: Ping timeout: 240 seconds10:45
khs (~khs@2001:700:300:2120:725a:b6ff:fee5:a44) joined #pypy.11:05
jacob22 (~jacob@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Quit: Konversation terminated!11:12
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) joined #pypy.11:14
jacob22 (~jacob@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.11:15
derdon (~derdon@p5DE89ED9.dip.t-dialin.net) left irc: Remote host closed the connection11:22
dgl (~dgl@109.86.165.231) joined #pypy.11:24
witulski (~stupsi@134.99.16.23) joined #pypy.11:28
lizardo (~lizardo@189.2.128.130) joined #pypy.11:31
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) left irc: Quit: x___x11:31
witulski (stupsi@134.99.16.23) left #pypy.11:31
lucian_ (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.11:33
arigato (~arigo@fwstups.cs.uni-duesseldorf.de) joined #pypy.11:33
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) joined #pypy.11:33
dgl (~dgl@109.86.165.231) left irc: Read error: Operation timed out11:33
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Ping timeout: 258 seconds11:34
lucian_ (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Remote host closed the connection11:51
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.11:55
khs (~khs@2001:700:300:2120:725a:b6ff:fee5:a44) left irc: Quit: Leaving11:57
CIA-2503arigo 07roundup * 10#907/Stacklets running out of memory on higher optimisation levels: It seems I need to have Stdlib.cvl and possibly others. How do I build them? * 14https://bugs.pypy.org/issue90711:59
ramusara (~ramusara@220.156.210.236.user.e-catv.ne.jp) joined #pypy.12:03
dgl (~dgl@109.86.165.231) joined #pypy.12:08
dgl (~dgl@109.86.165.231) left irc: Client Quit12:08
lac (~quassel@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.12:09
Gonsor (~quassel@p548A9C3F.dip0.t-ipconnect.de) joined #pypy.12:10
lac_ (~quassel@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Ping timeout: 276 seconds12:10
aboudreault (~alanb@osgeo/member/aboudreault) joined #pypy.12:11
kushal (kdas@fedora/kushal) left irc: Ping timeout: 258 seconds12:12
CIA-2503ltratt 07roundup * 10#907/Stacklets running out of memory on higher optimisation levels: 12:13
CIA-25The best option for you to test this problem will be to roll back to an older12:13
CIA-25commit, as a few other things have changed and expanded in the inte ... * 14https://bugs.pypy.org/issue90712:13
dgl (~dgl@109.86.165.231) joined #pypy.12:15
Taggnostr (~quassel@dyn57-215.yok.fi) left irc: Read error: Connection reset by peer12:18
Taggnostr (~quassel@dyn57-215.yok.fi) joined #pypy.12:23
fijalarigato: ping?12:24
santagada (~leonardo@201.86.242.147.dynamic.adsl.gvt.net.br) joined #pypy.12:28
gnuvince (~vince@ip-50-21-130-139.dsl.netrevolution.com) left irc: Read error: Operation timed out12:34
Vorpal (~AnMaster@unaffiliated/anmaster) joined #pypy.12:40
aat (~aat@cpe-72-225-174-173.nyc.res.rr.com) left irc: Quit: Computer has gone to sleep.12:44
fijalAlex_Gaynor: ping12:45
Gonsor (~quassel@p548A9C3F.dip0.t-ipconnect.de) left irc: Remote host closed the connection12:46
Rhy0lite (dje@nat/ibm/x-tzwteopzbvqrjzar) joined #pypy.12:55
fijalRhy0lite: hi13:00
Rhy0litehi, fijal13:00
Rhy0litegood afternoon13:00
fijal15:10, train to yuma leaves13:01
Rhy0litewhere are you?  Yuma, AZ?13:02
kenaan12hager ppc-jit-backend 1123ce29218564 15/: (arigo, hager): merge with branch arm-backend-213:06
exarkunisn't that a movie13:06
exarkun_15:10 Train To Yuma_13:06
fijaleven 2 movies13:07
tav (~tav@host-2-99-72-126.as13285.net) left irc: Ping timeout: 256 seconds13:09
arigatofijal: pong13:10
fijalarigato: eh, I kinda desperately need an explanation about clear_all_weakrefs13:10
arigatoyes?13:10
fijalbecause from what I can tell the __del__ on UserSubclassWithDel already calls it13:10
arigatoah right13:10
fijalbut if you don't have __del__ on a subclass it's not called13:11
fijalis it ok?13:11
fijalI have a test: http://paste.pocoo.org/show/497919/13:11
arigatoso it's not needed on W_Hash because W_Hash objects are not weakreferenceable13:11
fijaland I tried with __del__13:11
fijalarrays are weakreferencable13:11
arigatoah13:11
fijalbut I'm unable to provide a failing test13:11
fijalarigato: I would at the very least want to know the explanation why and how this should be called13:12
arigatoconfused: array.__del__ calls clear_all_weakrefs()13:12
fijalyes I know13:12
fijalthe question is can I remove it13:12
fijaland if not why not13:12
fijaland if not what's the failing test13:13
arigatoI think clear_all_weakrefs() is only about clearing the weakrefs before doing del'ish stuff13:13
arigatoso it is only needed if you do enough del'ish stuff13:13
arigatolike resurrecting the object13:14
fijaljust freeing the underlaying raw memory is ok?13:14
arigatoyes I think so13:14
arigatobecause normal instances don't have a del anyway13:14
arigatoso no place to call clear_all_weakrefs()13:15
fijaland if you have an applevel __del__ it would call clear_all_weakrefs early enough13:15
arigatoyes13:15
fijalok13:15
fijalso I just remove it then :)13:15
kushal (~kdas@fedora/kushal) joined #pypy.13:15
arigatonow why is there clear_all_weakrefs() in array....13:16
fijalfrom what you have told me before I understood you have to call it on each __del__ on a subclassable type13:16
arigatothis is seriously missing tests13:17
fijalI'm a bit unable to provide a test that would make a difference13:18
arigatoit needs a bit of chance13:18
fijalok13:19
fijalso you claim it's useful or not?13:19
arigatofor example if you don't call clear_all_weakrefs() in array, then it's fine, because at worst if you see the array after __del__ was called, you see an empty but valid array13:19
fijalhow can you even see that?13:20
arigatosimilarly, in module/_file, you see a closed but valid file13:20
fijalif you mean "in a weakref callback" then I don't think so13:20
fijalbecause you can't resurrect13:20
arigatoif you don't call clear_all_weakrefs(), then what occurs is:13:20
arigatox = ref(my_array)13:20
arigato[here my_array is __del__ed]13:21
arigatoa = x()13:21
fijalthen it's None13:21
arigatoif you don't call clear_all_weakrefs(), then a might not be None13:21
fijalbut it's None on cpython as well13:21
fijalpom pom pom13:21
fijal"might not be"?13:21
fijalbecause you did not reach gc.collect correctly?13:22
arigatouh? no13:22
arigatox = ref(my_array)13:22
arigatodel my_array13:22
arigatogc.collect()13:22
arigatoa = x()13:22
arigatoin this example, a will not be None13:22
arigatobut if you do two gc.collect(), then it will be None13:22
arigatosee?13:22
fijaland of course you can't simulate it on top of CPython?13:23
arigatowell no13:23
fijalno as in...13:23
arigatono13:23
arigatobasically our GCs don't clear the weakrefs to x before calling x.__del__13:24
fijalfor extra complexity this is no longer true for the case of lightweight finalizers...13:24
arigatoyes13:24
fijalok13:24
fijalso it's safe to remove :)13:24
arigatoit means that for lightweight finalizers you can ignore clear_all_weakrefs() completely, in summary13:25
fijalin the case your del is simple enough13:25
arigatoyes13:25
fijalwe should be slightly skeptical because we don't require GCs to implement lightweight finalizers13:26
arigato:-/  of course13:26
arigatothe whole issue is not completely well thought-out too13:26
arigatoe.g. what if you have a weakref to b, and a has a destructor, and there is a link a->b13:26
arigatoor b->a13:26
kenaan12hager ppc-jit-backend 11c00c0dca8cfc 15/pypy/jit/backend/ppc/ppcgen/ppc_assembler.py: (bivab, hager): fix interface access after merge13:26
fijalarigato: from what I can see if buffer is null you would explode13:27
fijalah no13:28
fijalwrong wrong, you set length to 013:28
arigatopossibly what we need is to define a precise policy that we would have to implement in the GCs13:29
fijalyes13:29
fijalwe have a lot of half-assed features13:29
fijalthat have unclear win13:29
arigatolike: if any object is only reachable from dead objects with finalizers, then of course it's kept alive, but all weakrefs to it are cleared13:29
fijallike malloc_nonmovable, array_resize etc.13:29
arigato:-)13:29
fijalI would like to experiment with pinning one day13:30
fijaland a different write barrier, but that's a mess13:30
arigatoand I'm busy playing with non-moving GCs13:30
fijalyes13:30
fijalso my plans are on hold a bit13:30
arigatobecause of me playing with non-moving GCs?13:31
fijalarigato: do you feel like reviewing lightweight-finalizers in the light of this discussion?13:31
fijalfor one, but also because I'm playing with other stuff ;-)13:31
kenaan12fijal default 119079d6cb7394 15/pypy/module/array/: (fijal, arigo) Remove call to clear_all_weakrefs with an explanation. A test that might potentially fail with -A if...13:32
kenaan12fijal default 11f5825eff38c3 15/pypy/jit/: merge default13:32
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Ping timeout: 240 seconds13:32
arigatostill a bit confused --- we didn't decide anything that would mean that lightweight-finalizers is fine, I think13:32
fijalyou mean with regard to clear_all_weakrefs or with what?13:33
arigatoyes13:33
fijalhttp://paste.pocoo.org/show/497927/13:33
fijalthose are all people that call it13:33
fijalit seems that you can just remove those calls13:33
fijalanyway, they already help W_Hash and now array13:33
fijaland numpy.array13:34
fijalarigato: or what precisely we think is not fine :)13:35
arigatobut it seems that removing those calls will have some possibly strange consequences in corner cases13:35
arigatoand we didn't decide to ignore it (I'm fine if we do it right now, but it needs at least one bug tracker entry, or something)13:35
fijalI'm fine with creating a bug tracker entry on which we'll decide what we require from GCs13:36
fijaland then look how they look like13:36
fijalbecause admitedly it's a mess right now13:36
arigato:-)13:36
fijalI don't think lightweight finalizers make things worse though13:37
fijalif anything they reduce the number of corner cases13:37
fijalbut that's not enough to not have a bug tracker issue13:37
Alex_Gaynorfijal: pong13:37
fijalAlex_Gaynor: what's the status of various numpy branches any clue?13:38
Alex_Gaynorfijal: nope, the only branches I know about ATM are mine13:38
fijaluh we should have a look13:38
Alex_Gaynoron that note, Does anyone by chance feel like reviewing virtual-dicts, I think it needs more tests, but suggestions on where to write tests would be nice.13:38
fijalwhat's multidim status?13:38
Alex_Gaynorfijal: barely started, I haven't seen that guy on IRC in a bit13:42
Alex_Gaynorfijal: btw someone should write a response to http://tech.dropbox.com/?p=8913:43
fijalyes13:43
fijalbut they did not provide a test case13:43
Alex_Gaynoryes, that's super stupid, I guess I'll leave a comment as such13:43
Alex_Gaynoroh someone else did, me likes it13:44
Alex_Gaynorclearly the best approach is two passes, one to sum the length, and the second to create a UnicodeBuilder and combine them13:44
Alex_Gaynorfijal: do you see why in http://paste.pocoo.org/show/497770/ the final p61 = getfield isn't remove by the frontend heapcache?13:45
arigatofijal: can you comment about the #XXX you added to rlib.rmmap?13:47
fijalarigato: yes, in general RPython level dels should not raise exceptions13:49
fijalwhile if we call os.close it checks the result value and raises OSError13:49
fijalthere is more than one thing that does it13:49
fijalwe should call the equivalent, but without checking the return code13:51
tav (~tav@host-92-20-11-103.as13285.net) joined #pypy.13:51
arigatoah ha13:53
arigatoindeed, it's what CPython does13:53
fijalI was staring at graphs13:53
whitelynx (~whitelynx@li117-47.members.linode.com) joined #pypy.13:53
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.13:54
arigatothere are some changes left over that you should revert, about raw_mem_attr_name13:54
fijaluh13:54
fijalindeed13:55
arigatoyou added op_track_alloc_stop(addr) to opimpl.py, but it's already in llinterp.py, so now it's defined in two places13:55
arigatoyou didn't fix all GCs, some of them are broken now I assume?13:57
fijalno, they just don't support light finalizers13:57
kenaan12fijal lightweight-finalizers 110554cbf80d3c 15/pypy/rpython/: remove traces of previous approach13:57
fijalI think13:58
arigatowhere is it written that they don't support them?  usually it's done with flags in the same file13:58
fijalif you don't do anything special, they're treated as normal finalizers13:58
arigatoah, then you need to rename a few arguments :-)13:58
fijalwhich ones?13:58
arigatolike malloc_fixedsize_clear(): I guess that "has_light_finalizer" really means "the_finalizer_is_light"13:59
fijalyes13:59
fijalsorry13:59
fijalwhich gcs I did not fix?13:59
arigatonone, sorry14:00
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Ping timeout: 240 seconds14:00
fijalanyway14:01
fijalrenaming is a good idea :)14:01
fijaluh14:02
kenaan12fijal lightweight-finalizers 11cde38a4297fc 15/pypy/rpython/memory/: rename argument to malloc_fixedsize_clear to reflect what it really means (it implies has_finalizer)14:02
fijalhm14:02
fijalso do I just remove op_track_alloc_stop from llinterp?14:02
fijalAlex_Gaynor: probably because it's an argument to some guard?14:03
fijaluh no14:03
Alex_Gaynorfijal: uh, and why can't you just reuse teh value from the previous setfield?14:03
fijalAlex_Gaynor: copystrcontent is kosher?14:04
Alex_Gaynorfijal: it should be, I don't know maybe it blows up caches14:04
Alex_Gaynorseems like a silly reason to do so :)14:04
arigatofijal: you missed the call to SemiSpaceGC.malloc_fixedsize_clear()14:06
kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #pypy.14:06
arigatoyou have to add the flag there too14:06
arigato(at some point we should clean this and pass a single integer containing flags, instead of N boolean variables)14:06
fijalwhere is it?14:07
arigatoin generation.py14:07
kenaan12alex_gaynor virtual-dicts 11ef72b02f3457 15/pypy/jit/: translation fixes for some tests, fix x86 tests14:07
arigatoin semispace.py:deal_with_objects_with_light_finalizers:14:08
arigatomissing self.objects_with_light_finalizers.delete()14:08
Action: fijal fixes14:09
fijalthis is AddressStack14:09
fijalnot AddressDict14:09
arigatoso?14:09
arigatothis part of the interface is the same14:09
Action: fijal looks14:10
arigatoalso, I would not mind if lightweight finalizers were a bit more explicit: at least we should be able to add an attribute that says "assert that this finalizer is lightweight"14:11
fijalok14:12
arigato(or a decorator)14:12
arigato(as you prefer)14:12
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1067 [12alex, virtual-dicts]14:13
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1805 [12alex, virtual-dicts]14:13
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/539 [12alex, virtual-dicts]14:13
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/671 [12alex, virtual-dicts]14:13
santagada (~leonardo@201.86.242.147.dynamic.adsl.gvt.net.br) left irc: Ping timeout: 240 seconds14:13
arigatoah, yes, you should probably have a list of old objects with lightweight finalizers, instead of checking the flag of all objects,14:13
fijalwell sure14:13
arigatobecause it requires going from the object's typeid to the typeinfo table14:13
fijalbut I would like to have a benchmark that shows this is a problem14:13
fijalas I said before14:14
arigatoso it's (slightly) more involved than I thought14:14
fijalwould gcbench do?14:14
arigatoyes, I think so14:14
arigatocheck that it does enough major collections14:14
fijalok14:15
arigatowhat I imagined was that you decide based on flags in the header14:15
arigatowhich you need to read anyway 3 lines ago14:15
kenaan12fijal lightweight-finalizers 11fadf05e6c02a 15/pypy/rpython/memory/gc/generation.py: a missed call14:16
fijalyes, I can add that as a flag in the header as well14:16
fijalwe do still have flags left14:16
arigatoyes, but it's probably better to just have a list14:16
arigatoand not really more complicated14:16
fijalyes, agreed14:16
fijalno, not at all14:16
fijalit's also easier because we don't have to inspect objects in 3 places14:16
fijalinstead we have 114:16
arigatoyes14:17
fijalwhat does the delete do?14:17
fijaland why do I need it?14:17
fijalah in semispace14:17
arigatoself.AddressStack() makes a new raw-malloced structure, so you must also delete another one somewhere, otherwise leak14:18
fijalyes yes14:18
fijalI thought you're talking about minimark where I have just one stack14:18
fijal(I don't have to create a new one)14:18
arigatoah, sorry14:18
fijalno, you said so :)14:19
kenaan12fijal lightweight-finalizers 1198da45c0aeb5 15/pypy/rpython/memory/gc/semispace.py: add a delete here14:19
stakkars_ (~tismer@p5DDB5E98.dip.t-dialin.net) joined #pypy.14:19
stakkars__ (~tismer@dslb-088-074-058-015.pools.arcor-ip.net) joined #pypy.14:19
stakkars (~tismer@p5DDB5E98.dip.t-dialin.net) left irc: Read error: Connection reset by peer14:20
Nick change: stakkars_ -> stakkars14:20
fijalon gcbench it's not measurable14:20
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.14:20
arigatotest_rclass.py should also be reverted14:20
arigatohow many major collections?14:21
Ademan (~dan@adsl-71-141-242-47.dsl.snfc21.pacbell.net) left irc: Quit: leaving14:21
fijalhttp://paste.pocoo.org/show/497952/14:21
fijalthis is measurable14:21
arigatoah :-)14:21
fijalwhat in test_rclass?14:22
kenaan12bivab arm-backend-2 11e9b9f641f506 15/pypy/jit/backend/arm/: add names to the functions generated to emit code in the assembler14:22
kenaan12bivab arm-backend-2 113c00e205750e 15/pypy/jit/backend/arm/: add functions to merge unary cmp operatios with guards14:22
arigatoall the changes?14:22
fijalhow do I create a diff of a single file between 2 branches?14:22
arigatoyou do this:14:23
arigatoin your branch:14:23
arigatohg merge default14:23
arigatohg diff -r default14:23
fijalah yes, I know that14:23
arigato(and then probably "hg up --clean" to cancel the hg merge)14:23
stakkars_ (~tismer@p5DDB5E98.dip.t-dialin.net) joined #pypy.14:24
fijalweeeeelll14:24
fijalthose changes remove assignment to an unused variable14:24
fijalI know it's irrelevant to the branch but well14:24
arigatoas you like --- but at least the "import" can be killed14:25
lucian_ (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.14:25
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Read error: Connection reset by peer14:25
mcdonc (~mcdonc@cabana.palladion.com) left irc: Ping timeout: 258 seconds14:25
fijalit's just that my emacs colors such stuff red :)14:25
kenaan12fijal lightweight-finalizers 11e916dec7191d 15/pypy/rpython/test/test_rclass.py: remove unused imports14:25
santagada (~leonardo@177.18.63.32) joined #pypy.14:25
arigatofijal: ah, also, FinalizerAnalyzer:14:27
stakkars__ (~tismer@dslb-088-074-058-015.pools.arcor-ip.net) left irc: Ping timeout: 244 seconds14:28
arigatoI think you should swap its meaning, with top_result() meaning "oups, I lost track" and bottom_result() meaning "ok so far"14:28
arigatothat's what the generic functions do14:28
arigatoe.g. if you have some strange indirect_call to an unknown graph, the generic code will return top_result()14:28
arigatoah oups, sorry14:29
fijalyes I was confused as well :)14:29
arigatook, it's already in the "correct" way :-)14:29
arigato"bottom" and "top" are too much "computer sciency" for us14:30
fijalyes14:31
arigatook, I just wrote here my comments, please make sure you didn't skip any :-)14:32
arigatothe branch looks fine otherwise14:32
fijalI've just finished the last one14:32
fijalthe list vs checking typeid one14:32
fijalso I would run some tests and then merge14:33
fijalah one more14:33
fijalyou didn't answer - do I just kill op_track_alloc_stop on the llinterp and be happy?14:33
arigatoprobably not14:33
arigatonote that it's not doing tracking14:33
fijalthat's a bit of a problem14:33
fijalonly if you write some kind of test though14:34
fijalso maybe not any more14:34
arigatowhy did you need to make it "canrun", but not the track_alloc_start?14:34
fijalI think those are leftovers from the previous approach really14:34
fijalwe don't have a test any more that directly manipulates low-level memory14:34
fijalso "fine" I guess to remove this support14:34
Nick change: lucian_ -> lucian14:35
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Quit: Leaving14:35
arigatook14:35
lucian__ (~lucian@93-97-174-114.zone5.bethere.co.uk) joined #pypy.14:35
Nick change: lucian__ -> lucian14:35
fijalarigato: if you want to look for some work targets, we loose on ai with cpython these days14:38
fijalah\14:38
fijalarigato: I have an idea about improving frames in case of call_assembler14:38
Alex_Gaynorarigato: there is something *too* computer sciency for us?14:40
Action: fijal booked his sprint ticket14:42
dgl (~dgl@109.86.165.231) left irc: Quit: Leaving...14:43
UnhelpfulSurely not, for you ivory-tower academics? ;)14:43
Alex_Gaynorfijal: pff, you were right, copystrcontent does indeed clear frontend heap caches14:43
fijalAlex_Gaynor: :)14:44
arigatoAlex_Gaynor: if you think pypy is anywhere near computer-sciency in style, you don't know computer science :-)14:44
kenaan12fijal extradoc 111fc0097464a4 15/sprintinfo/gothenburg-2011-2/people.txt: add myself14:44
fijalor pypy14:44
Alex_Gaynorarigato: all the computer scientists I know left academia to do real work :)14:44
arigato:-)14:44
fijaltests pass14:46
Action: fijal merges lightweight-finalizers14:46
arigato:-)14:47
fijalAlex_Gaynor: do you know the status of justin's branch?14:47
Alex_Gaynorfijal: his gc branch?14:47
Alex_Gaynorno idea14:47
Alex_GaynorI thought he said it was close though14:47
fijalyeah14:47
fijalit has implications with lightweight finalizers14:47
fijalsince if the stuff was malloced in the nursery, adding pressure makes no sense14:48
fijalso maybe we need to reorganize the interface a bit ;-)14:48
kenaan12fijal lightweight-finalizers 11d80d4e3f457a 15/pypy/rpython/lltypesystem/: remove track_alloc_stop support, not needed any more14:49
kenaan12fijal lightweight-finalizers 11e09c7b3e1296 15/pypy/rpython/memory/gc/minimark.py: Use a list instead of checking each time the type id data14:49
kenaan12fijal lightweight-finalizers 11630cc8b2cb4c 15/: close merged branch14:52
kenaan12fijal default 11b3d0ebe10a5d 15/pypy/: (fijal, arigo reviewing) Merge lightweight-finalizers branch. This branch adds a possitibility for a finalizer to b...14:52
fijaloops14:52
fijalI guess I forgot a decorator14:52
fijalAlex_Gaynor: so what's up with multidim arrays?14:58
matehat (~matehat@modemcable015.90-176-173.mc.videotron.ca) joined #pypy.15:05
Alex_Gaynorfijal: not much ATM15:06
fijalcan I finish it somehow?15:07
Alex_Gaynorfijal: tehre isn't a ton of progress, if you want to take it and finish it that would be good I think15:10
fijalI guess we can15:10
fijalif for nothing else, then for "yes we can" campaign15:10
ojii (~ojii@40-34.60-188.cust.bluewin.ch) left irc: Remote host closed the connection15:11
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/539 [12alex, virtual-dicts]15:12
fijalboom15:12
mvt (~mvantelli@87.213.45.85) left irc: Quit: Leaving15:12
ojii (~ojii@40-34.60-188.cust.bluewin.ch) joined #pypy.15:12
Alex_Gaynorfijal: any idea what could cause http://buildbot.pypy.org/summary/longrepr?testname=unmodified&builder=pypy-c-jit-linux-x86-64&build=539&mod=lib-python.2.7.test.test_xrange ?  I'm seeing it on my virtual-dict branch15:13
fijalyou mean anything other than a bug in the backend?15:13
Alex_Gaynorfijal: yes, like some API I implemented wrong on my virtual or resume data or some such15:14
fijalAlex_Gaynor: I know how to fix that though15:14
Alex_Gaynorfijal: fix what?  a KeyError?15:14
fijaladd set/getinteriorfield to test_zrandom15:14
fijaland fix the bug there15:14
fijalfeel like doing it?15:15
Alex_GaynorI gotta go to class in a minute, so not ATM :)15:15
Alex_Gaynorfijal: btw, I think we generate resume data for zeroing a field on a virtual, that's a bit stupid no?15:15
fijalafter class15:15
Alex_Gaynorfijal: maybe, I also need to teach frontend heapcache about strcopycontent, and I don't know anything about test_zrandom anyways15:17
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1067 [12alex, virtual-dicts]15:18
arigatoyes, adding new operations to test_random is a good idea generally speaking15:18
Alex_Gaynorarigato: do you have an idea about resume data for zeroing fields on virtuals?15:19
arigatoyes, it's likely that indeed you are right15:19
arigatowe should assume that upon resuming, we start with zero-killed structures, so that we don't have to specify it again15:20
arigatozero-filled15:20
Alex_Gaynorwe could even branch on if gc_ll_descr.malloc_zerofilled15:20
Alex_GaynorI guess that's a useful optimization, especially for virtual-dicts, which hvae tons of fields but usually only a few are set15:20
arigatoit's probably even better to really assume it's zero-filled, and fill it if necessary15:21
arigatogood point15:21
amaury (amaury_@nat/google/x-kzewsvakmaubjerj) left irc: Remote host closed the connection15:21
Alex_Gaynorpff, my branch doesn't seem to work with app-level dicts yet for some reason15:21
Action: Alex_Gaynor -> class15:22
mcdonc (~mcdonc@cabana.palladion.com) joined #pypy.15:25
aleksi (~aleksi@85.235.191.82) joined #pypy.15:28
fijalAlex_Gaynor: this is probably a bug in the implementation somehow, seriously add it to test_zrandom15:30
fijaleven if it's a pain15:30
fijalI can do it if you don't like the idea15:30
dmalcolm (david@nat/redhat/x-lgpbojqechtdfhst) joined #pypy.15:31
arigatofijal: ah, you talked about call_assembler earlier15:31
fijalarigato: yes15:31
arigatoI also have ideas for it15:31
fijalok :)15:31
fijalmy goal would be to reduce amount of stuff we store on frame before finish()15:32
fijalbecause we can pass a flag "did frame escape"15:32
arigatoah, what I have in mind is unrelated then: it's about reducing the amount of stuff we pass *into* the call15:33
fijalrelated, but not15:34
arigato:-)15:34
arigatoso far we stupidly pass every virtualizable2 field of the frame twice:15:35
fijalyes15:35
arigatoin the frame itself, and as argument15:35
Action: fijal is kinda amazed how zen pypy is15:35
fijalit does not seem to be ever finishable15:35
arigato:-)15:36
arigatoI think the sanest is to pass it only on the frame, and keep the number of arguments down15:36
arigatoit would mean that all our call_assembler have a known number of arguments, too15:36
arigatoso it would speed up the normal calls to execute_token() too15:37
kushal (~kdas@fedora/kushal) left irc: Quit: This computer has gone to sleep15:38
arigatoin fact set_future_value_xx() and execute_token() are probably not needed any more,15:38
arigatoand instead we just need an execute_token(looptoken, *args)15:38
arigatoand the machine code backends can be simplified to not make two entry points everywhere15:41
arigatoinstead they can have just the version that accepts arguments15:41
arigatonot the version that reads them out of "set_future_value" storage15:41
arigato...I only need a reasonable name for that branch now :-)15:43
JaRoel|4d (~jaroel|4d@office.fourdigits.nl) left irc: Remote host closed the connection15:44
fijalexecute_assembler goes where?15:44
fijalalways to the entry bridge or to the normal loop as well?15:44
arigatocall_assembler?15:45
fijalyes15:45
arigatoto the entry bridge15:45
fijalsorry15:45
fijalalways?15:45
arigatoI think so15:45
fijalI think not15:45
arigatoah15:45
fijalthen it would be utter nonsense15:46
fijalsince entry bridges have fixed number of args15:46
fijalI claim it goes to the loop as well15:46
Action: fijal checks15:46
arigatoit seems to go only on "jit_cell_at_key()"15:47
lambacck (~chris@d24-150-124-118.home.cgocable.net) joined #pypy.15:48
arigatowhich has a method get_entry_loop_token()15:48
arigatoso unless the naming is not correct any more15:48
arigatothen it goes to an entry bridge15:48
fijalah ok15:48
fijalbut then it only unpacks the virtualizable it does not have virtuals right?15:48
arigatoyes15:48
fijalok15:48
fijalthen it's indeed nonsense15:49
arigatoyes yes, there is code that takes the red args + the virtualizable stuff15:49
kkris (~kris@93-82-44-187.adsl.highway.telekom.at) joined #pypy.15:49
fijalhm15:49
arigatobut the virtualizable stuff is always the same as what is found on the frame15:49
fijalI *think* the original idea was that we don't have to store it on the frame in the first place15:49
arigatoyes15:49
arigatobut anyway we do it too15:50
fijalyes15:50
arigatoand the original idea would not really work anyway because we can't pass virtuals15:50
fijalmaybe we can think about a way to do it though?15:50
arigatothat's a bit hard, but also it would not really invalidate the simplification I'm doing now15:51
Action: fijal cooked himself a fairly disgusting dinner15:51
arigatobecause what I'm going to assume is that on execute_token() we have a known number of args15:51
fijalok15:51
fijaljust don't make it any harder :)15:51
fijalwhat I had in mind was a step in the other direction15:51
arigatobut generating CALL_ASSEMBLERs with different signatures should be possible later15:52
arigatoyes?15:52
lucian (~lucian@93-97-174-114.zone5.bethere.co.uk) left irc: Ping timeout: 256 seconds15:53
Trundle (~andy@python/site-packages/trundle) left irc: Remote host closed the connection15:54
fijalby the time we do CALL_ASSEMBLER we generally know whether the frame escaped or not15:54
fijalso we can mark it as "not escaped"15:54
fijaland on the lower level the optimizer can be smarter because it does know the frame did not escape15:55
fijalmaybe causing a retrace15:55
arigatoah15:55
fijalwe do lots of nonsense just because it might have escaped15:55
fijalbut it usually does not and by the time we call it we know it15:56
arigatoI think even that we should not reach CALL_ASSEMBLER if the frame escaped, bcause a GUARD_NOT_FORCED would trigger15:57
fijaleven better :)15:57
Gonsor (~quassel@134.76.63.190) joined #pypy.15:57
mitchellh (~mitchellh@c-71-202-125-40.hsd1.ca.comcast.net) joined #pypy.15:57
fijaleven from the interpreter the frame escaped only if a couple of things were called15:57
fijalit doesn't escape "just because"15:57
fijalso we can keep a flag on frame "did it escape?"15:57
fijaladmittedly it's very hand-wavy15:57
arigatoit's a bit annoying, it seems to require us to compile two versions of everything15:58
fijalno15:58
fijalbecause we usually don't call the JIT if stuff escaped anyway15:58
arigatoah15:58
mitchellh (~mitchellh@c-71-202-125-40.hsd1.ca.comcast.net) left irc: Client Quit15:58
arigatoI see15:58
fijalgood:)15:58
arigatoyou want a flag on the PyFrame class15:59
fijalyes15:59
arigatoseems to make sense15:59
fijalit's obviously not as good idea in general, for any interpreter15:59
fijalbut in practice it's good enough for python and virtualrefs are an obscure python-only hack anyway15:59
arigatowell so far we just generate GUARD_NOT_FORCED everywhere too15:59
arigatowe can even use the same fields checked by GUARD_NOT_FORCED, instead of adding our own16:00
fijalah16:00
fijalit's possible to do the same trick for GUARD_NOT_FORCED as for GUARD_NOT_INVALIDATED16:01
fijalyou just have to carefully patch the assembler back ;-)16:01
Action: fijal hides his evil grin16:01
arigatoah sorry, I meant GUARD_NOT_INVALIDATED everywhere16:01
fijalno, I think you meant GUARD_NOT_FORCED16:01
fijalthe one about virtualizables right?16:01
arigatoer yes :-)16:01
fijalGUARD_NOT_INVALIDATED is about quasi immutable hints16:01
arigatoyes, I'm confusing the two now .-)16:02
fijalok16:02
fijalbut indeed, we already have necessary mechanisms I think16:02
fijalon virtualrefs16:02
arigatothis should not be about virtualrefs, though16:02
fijalno no no16:03
fijalbut virtualrefs already keep track of which stuff has escaped16:03
fijalI think16:03
fijalI might be wrong though16:03
fijalarigato: do I make any sense?16:03
arigatoyes, mostly :-)16:03
fijalgood :)16:04
fijalI was merely trying to poke some neurons in your head since I only *think* it's possible16:04
arigatoyes, I also *think* it is16:04
arigatobasically you would do the equivalent of GUARD_NOT_FORCED manually just before calling execute_token()16:04
arigatoand also just before tracing16:05
fijalyes16:05
arigatobut what about generators?16:05
fijalas in their frames escape?16:07
arigatoyes, we need to sort out what occurs with app-level generators16:07
fijalyou can have a hint like one we had for inlining16:07
fijalif the code is generators, do what we have now16:07
fijalotherwise optimize slightly better16:08
fijala bit of a mess, but still you don't need two copies of everything16:08
asmeurer (~asmeurer@dhcp-baca-230.resnet.nmt.edu) joined #pypy.16:11
kenaan12fijal default 119d13b202cb4b 15/pypy/: Provide a hint that can be specified as a decorator - @rgc.is_light_finalizer16:11
fijalwe should come back to the idea of light virtualizables btw ;-)16:11
fijalprecisely for generators16:11
fijalwhere you copy a virtualizable stack -> heap but without forcing it16:12
Action: arigato -> away16:14
G2P (~G2P@fw-asn1.ornis.com) left irc: Quit: Leaving.16:15
arigato (~arigo@fwstups.cs.uni-duesseldorf.de) left irc: Quit: See you16:18
bivab_ (~david@fwstups.cs.uni-duesseldorf.de) joined #pypy.16:23
bivab_ (~david@fwstups.cs.uni-duesseldorf.de) left irc: Client Quit16:23
kushal (~kdas@114.143.161.251) joined #pypy.16:24
kushal (~kdas@114.143.161.251) left irc: Changing host16:24
kushal (~kdas@fedora/kushal) joined #pypy.16:24
bivab (~david@fwstups.cs.uni-duesseldorf.de) left irc: Read error: Operation timed out16:25
exarkunhttp://speed.pypy.org/ :/16:26
fijalexarkun: yes, a bug16:26
fijalI poked miquel and it'll be fixed16:26
fijalhopefully tonight16:26
Ibison_ (~Ibison@c-83-233-136-34.cust.bredband2.com) joined #pypy.16:30
k_bx (~k_bx@94.244.19.62) joined #pypy.16:32
MjrTom (MjrTom@azureus/MjrTom) left #pypy.16:38
aleksi (~aleksi@85.235.191.82) left irc: Remote host closed the connection16:44
ojiifijal, what i was talking about in #epio: https://gist.github.com/131349316:50
ojiiusing the code from here: https://github.com/ojii/gitstats.ep.io16:51
kenaan12fijal default 112612cae35357 15/lib-python/modified-2.7/urllib2.py: I swear I did that change before - remove the incorrect usage of close introduced by chance when experimenting with...16:51
fijalwhat's dulwich?16:52
ojiipure-python git implementation16:52
fijalojii: why does it compile C if it's pure python?16:52
ojiioh should mention, the first argument to run.py should be a path to a git repository16:53
ojiifijal, o.O?16:53
fijalyes, that's precisely what I mean16:53
ojii"Dulwich is a pure-Python implementation of the Git file formats and protocols."16:53
ojiifrom their website16:53
fijalI don't want to care *which* git repository is good enough16:53
ojiithe hell?16:53
fijalwell, that's a lie16:53
ojiiheh "Dulwich has been tested on CPython 2.X where >= 4 and on recent versions of pypy."16:53
fijalmaybe it works on pypy16:53
fijalfirst it should not compile C extensions on pypy16:54
Nick change: Guest98764 -> Arach16:54
fijalwhat's dateutil?16:54
ojiiaha "All functionality is available in pure Python, but (optional)      C extensions are also available for better performance."16:54
ojiidateutil are utilities for datetime16:54
ojiiusing the 'loop over all months between those two dates' helper16:54
fijalhow do I install dateutil?16:54
ojiipip install -r requirements doesn't work?16:55
ojiiit's called 'python-dateutil' on pypi16:55
fijalso what did you use for your git repo?16:55
ojiidjango-cms repo16:55
ojiihttps://github.com/divio/django-cms16:55
fijalok16:56
fijalif I remove the optional C extension it goes 2x faster16:57
fijalfor example16:57
fzzzy (~donovan@nat/mozilla/x-cvyhclmvhexdyqkg) joined #pypy.16:58
ojiiinteresting16:58
fijalojii: complain and tell them to remove compilation on pypy and then make python version better optimized16:58
fijalwell, it's known16:58
ojiihow did you do that?16:58
fijalrm <some-path>/*.so16:58
ojiiah16:58
ojiismart16:58
fijalnot a very advanced way admittedly16:58
fijalI should charge by an hour ;-)16:58
ojiiheh16:59
ojiirm'ing them removed a second from runtime16:59
ojiiI'll just start doing this with everything. Removing random files to speed up my computer :D17:00
fijal:]17:00
matehat (~matehat@modemcable015.90-176-173.mc.videotron.ca) left irc: Quit: Leaving...17:01
tilgovi (~randall@c-98-210-155-124.hsd1.ca.comcast.net) joined #pypy.17:02
tilgovi (~randall@c-98-210-155-124.hsd1.ca.comcast.net) left irc: Changing host17:02
tilgovi (~randall@couchdb/developer/tilgovi) joined #pypy.17:02
mtigas (~Adium@users.spokesman.com) joined #pypy.17:03
ojiifijal, https://bugs.launchpad.net/dulwich/+bug/88154617:03
ojiiit is still massively slower than python 2.7 though17:03
fijalless massively so, no?17:03
ojiiyes17:03
ojiiit's only twice as slow now17:03
ojiiinstead of 4 times as slow17:03
fijalremember we're fighting now with a C extension ;-)17:04
fijalbut yes, not good enough17:04
ojiiit's weird, for some reason i've yet to write code that runs faster under pypy than 'normal python', maybe my code is just too weird/bad :D17:05
fijalwell, in this particular example it uses pure python vs C extensions17:05
fijaland there is another obscure reason17:06
fijalwhich is that structseq is written badly in pypy17:06
ojiiah of course, i had an idea it would be that17:07
teknico (~quassel@88-149-209-131.dynamic.ngi.it) left irc: Remote host closed the connection17:07
fijaland stuff like this :)17:09
fijalno pypy does not win for everything17:09
fijalbut has a much better curve than cpython17:09
fijal;-)17:09
kushal (kdas@fedora/kushal) left #pypy ("Leaving").17:09
ojiibut i want pypy to be that magical silver bullet that makes all the things faster17:10
fijalI know17:10
fijalwe'll get there17:11
fijal;-)17:11
ronnyojii: fyi i just made a commit to dulwich disabling the extensions on pypy, should be accepted soon17:14
ojiironny, nice17:14
ojiiwow launchpad is confusing17:17
ronnyyes17:18
ojiianyway i'll need to grab a beer, when i come back this is super fast, right? :D17:19
ojii (~ojii@40-34.60-188.cust.bluewin.ch) left irc: Remote host closed the connection17:23
jerryluc (~Havar@bl252a.studby.ntnu.no) left irc: Read error: Connection reset by peer17:28
mitchellh (~mitchellh@c-69-181-107-107.hsd1.ca.comcast.net) joined #pypy.17:29
ramusara (~ramusara@220.156.210.236.user.e-catv.ne.jp) left irc: Quit: Leaving...17:34
mitchellh (~mitchellh@c-69-181-107-107.hsd1.ca.comcast.net) left irc: Quit: Computer has gone to sleep17:38
fijalAlex_Gaynor: mess....17:44
bbot24Failure: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1805 [12alex, virtual-dicts]17:48
CIA-2503fijal 07roundup * 10#921/_structseq is a slow mess: [new] http://paste.pocoo.org/show/498047/ is 2x slower under pypy than cpython * 14https://bugs.pypy.org/issue92117:50
fijalok, "for later"17:50
arigato (~arigo@82.113.121.195) joined #pypy.17:57
Alex_Gaynorfijal: what is?17:57
Alex_Gaynorfijal: btw do you feel like doing test_zrandom?17:58
fijalI can I guess, it's me who introduced problems17:58
fijalAlex_Gaynor: structseq is a mess17:59
Alex_Gaynorfijal: well, I still think it might be a bug in my virtuals, since it doesn't error on trunk, but yes please do write the test :)17:59
fijalok, so numpy-comparisons is by far unfinished17:59
fijalhttp://paste.pocoo.org/show/498055/18:00
fijalan example18:00
Alex_Gaynorfijal: one thing at a tiem18:00
voidspace (~voidspace@python/psf/voidspace) left irc: Quit: voidspace18:00
fijalyes right18:00
fijalI was just looking, since snus-mumrik did new checkins I believe18:00
fijalwe should start looking into numpy tests I believe18:01
voidspace (~voidspace@python/psf/voidspace) joined #pypy.18:02
fijalAlex_Gaynor: but make structseq nicer18:06
Alex_Gaynorfijal: first virtual dicts for me18:06
antocuni (~antocuni@host152-120-dynamic.11-79-r.retail.telecomitalia.it) left irc: Ping timeout: 260 seconds18:08
santagada (leonardo@177.18.63.32) left #pypy.18:11
Trundle (~andy@python/site-packages/trundle) joined #pypy.18:11
pjenveystructseq is a subclass of tuple in 3.318:12
pjenveycould skipping ahead to that change maybe do enough for structseq's speed?18:13
fzzzy (~donovan@nat/mozilla/x-cvyhclmvhexdyqkg) left irc: Quit: fzzzy18:15
fzzzy (~donovan@nat/mozilla/x-qqdmamnpfemtujsl) joined #pypy.18:16
pjenveyit's just basically a namedtuple impl right, why did it not totally consolidate with namedtuple, i don't know18:17
ronnypjenvey: names and indexes dont map propperly with structseq 18:20
ronnypjenvey: in particular differen ways to access give different types for some backward compatibility things18:21
rekamso (~textual@67.51.82.66) joined #pypy.18:23
kenaan12alex_gaynor virtual-dicts 11d58706c7bdb6 15/pypy/jit/metainterp/: make the heapcache a bit smarter about how stuff escaped18:23
fijalit's not like we have arrays of pointers in test_random either18:24
kenaan12alex_gaynor virtual-dicts 11c1dbbe1bd86e 15/pypy/jit/metainterp/: add a unittest for the previous commit18:26
Alex_Gaynorfijal: I suppose the conclusion is we should add them18:27
Action: Alex_Gaynor teaches the frontend heapcache random tricks18:27
kenaan12alex_gaynor virtual-dicts 11d876b901547e 15/: merged default18:28
fijalAlex_Gaynor: how about the other kind of heapcache18:28
fijalthe optimizeopt one?18:28
Alex_Gaynorfijal: it already knows these tricks :)18:28
fijalincluding copystrcontent?18:28
Alex_GaynorI haven't taught it copystrcontent yet18:29
Alex_GaynorI just taught it that if you put a virtual inside a virtual array then the box doesn't escape until either it or the array escapes18:29
Alex_Gaynorthis is useful since tons of stuff "escapes" to locals_Stack in python18:30
mabbikeel (~mabbikeel@cpc4-duns7-2-0-cust218.9-3.cable.virginmedia.com) joined #pypy.18:31
CIA-2503agaynor 07roundup * 10#921/_structseq is a slow mess: 18:31
CIA-25[chatting] I guess it'd be nice if this was a more unittest type thing, without needing18:31
CIA-25random IO. Can we write a benchmark that just construct ... * 14https://bugs.pypy.org/issue92118:31
fijalAlex_Gaynor: yop we can18:32
fijalit was just faster that way18:32
Alex_Gaynorfijal: put it on the TODO list ;)18:32
CIA-2503afa 07roundup * 10#921/_structseq is a slow mess: os.stat_result((None,) * 10) * 14https://bugs.pypy.org/issue92118:42
Alex_Gaynorfijal: hehe, amaury is smarter than us18:42
fijal:]18:43
arigatofijal: arrays of pointers in test_random: that's not too important18:47
arigatobecause for a low-level backend, that's the same as array of integers18:47
fijalok18:47
arigatosimilarly, you should add arrays of structs containing a few ints of various sizes, but not pointers18:47
amaury_ (~amaury_@46-127-23-192.dynamic.hispeed.ch) joined #pypy.18:48
arigatobah, I may give up already on the branch "jit-simplify-backendintf"18:49
Alex_Gaynorwhat branch was that?18:49
kenaan12arigo jit-simplify-backendintf 1126419ef5e993 15/: A branch to simplify the backend interface, killing set_future_value_xx().18:51
kenaan12arigo jit-simplify-backendintf 116e1590cee5e1 15/pypy/jit/backend/: Change the interface and fix the llgraph backend.18:51
arigato^^^ for reference18:51
Alex_Gaynorah18:51
arigatoI don't know what to do in the one case in which the front-end calls a loop that's not an entry bridge18:51
arigatoit's after tracing, when it has traced one iteration18:53
arigatoah, maybe I can instead abort18:53
arigatoand let it reach the loop normally later18:53
arigatoit would kill a bit more code18:53
kenaan12arigo default 119a4ee13149cd 15/pypy/jit/backend/llsupport/test/test_gc.py: Make this test closer to what was intended.18:55
bbot24Failure: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/671 [12alex, virtual-dicts]18:56
tilgovi (~randall@couchdb/developer/tilgovi) left irc: Ping timeout: 240 seconds18:57
amaury_FYI, I don't plan to work alone in the py3k branch anymore18:58
arigatoamaury_: that's fine, there are people that are supposed to be paid for it :-)18:58
amaury_indeed18:58
arigatowe're probably going to quick-start it at the Gothenburg sprint18:59
amaury_very good18:59
amaury_the py3k branch probably needs some review, otherwise it seems to be a good start19:00
arigatook19:00
amaury_the most disturbing changes are already in: unicode identifiers, and open=io.open19:01
amaury_and yet the CPython test suite runs correctly for many files19:02
arigatoon py.py, or translated already?19:03
amaury_translated19:03
amaury_I had to remove _rawffi and cpyext19:03
amaury_because they segfault during translation19:03
amaury_(both pypy-c and python2.6)19:04
Alex_Gaynorpff, 30 minutes translating just to find out I'm missing some frontend op which is needed :/19:04
arigatowow19:04
amaury_probably a misguided call to ll2ctypes19:04
amaury_ccharp on a unicode string19:04
arigatoAlex_Gaynor: which one?19:05
Alex_Gaynorarigato: I haven't a clue, I just know that http://paste.pocoo.org/show/498087/ still generates a CALL for the dict lookup19:05
arigato:-/19:07
arigatoif you can't find it out, try the example on pypyjit.py19:07
Alex_Gaynorthat'd be the smart idea19:08
arigatoyou can also use the (Linux-only) backend/x86/tool/viewcode.py19:08
arigatoit should be able to map the address of the called function back to its name19:09
Alex_GaynorI don't need that, this problem is evident at the resop level19:09
arigatoah19:09
fijalamaury_: I don't think anyone expected you to work on py3k branch at all :)19:12
fijalif you ask me19:12
fijalarigato: gdb is useful as well :)19:12
fijalviewcode does not always work, gdb always19:13
Alex_Gaynorgdb isn't quite useful for why the frontend optimizer missed something19:14
fijalI hate test_zrandom19:14
kenaan12edelsoh ppc-jit-backend 11d4c1290fd460 15/pypy/jit/backend/ppc/ppcgen/opassembler.py: More PPC64 support for arraylen_gc, setarrayitem_gc, getarrayitem_gc19:14
mwhudson (~mwh@linaro/mwhudson) left irc: Ping timeout: 252 seconds19:16
k_bx (~k_bx@94.244.19.62) left irc: Remote host closed the connection19:16
amaury_fijal: It's probably a way for me to compensate for my absence from the sprints19:18
fijalamaury_: I'm not that judgmental19:19
tilgovi (~randall@75.101.111.78) joined #pypy.19:20
tilgovi (~randall@75.101.111.78) left irc: Changing host19:20
tilgovi (~randall@couchdb/developer/tilgovi) joined #pypy.19:20
bgola (~bgola@c95185bc.virtua.com.br) left irc: Ping timeout: 260 seconds19:21
bgola (~bgola@c95185bc.virtua.com.br) joined #pypy.19:27
Rhy0lite (dje@nat/ibm/x-tzwteopzbvqrjzar) left irc: Quit: Leaving19:27
Alex_Gaynorarigato, fijal: you know what's screwing this up?  a ptr_eq.19:35
fijalAlex_Gaynor: uh?19:35
fijalwhat's screwing what up?19:36
Alex_Gaynorfijal: it's causing the frame to "escape" in the frontend, which escapes the locals, which escapes the W_MultiDict, which esapes the rdict, whih auses something not to get unrolled19:36
fijalpfff19:37
fijalthe famous ptr_eq between frames?19:37
fijalnonstd_virtualizable or so?19:37
Alex_Gaynorfijal: yup19:37
Alex_Gaynorfijal: optimizeopt of course removes it becaues one is virtual and the other isn't19:37
arigatoah19:37
Alex_Gaynorit's easy to fix, but I have to go for a few minutes now :)19:37
ojii (~ojii@154-60.3-85.cust.bluewin.ch) joined #pypy.19:38
fijalarigato: http://paste.pocoo.org/show/498103/19:39
fijaldoes that make any sense to you?19:39
arigatoself._obj is seriously nonsense19:40
arigatoyou messed up a pointer vs what is being pointed to somewhere19:40
mabbikeel (~mabbikeel@cpc4-duns7-2-0-cust218.9-3.cable.virginmedia.com) left irc: Ping timeout: 258 seconds19:42
pjenveydid we ever have that more detailed discussion about how to best maintain py3k support?19:45
fijalpjenvey: nope19:45
fijalpjenvey: not really at least19:45
mabbikeel (~mabbikeel@cpc4-duns7-2-0-cust218.9-3.cable.virginmedia.com) joined #pypy.19:45
fijalmeh :/19:47
fijalarigato: test_random is a mess :/19:47
arigatoyup19:48
mwhudson (~mwh@linaro/mwhudson) joined #pypy.19:48
Ibison_ (~Ibison@c-83-233-136-34.cust.bredband2.com) left irc: Ping timeout: 240 seconds19:51
fijalarigato: how do I get stuff out of _opaque?19:53
arigatoin RPython code, or in tests?19:53
fijalin tests19:54
fijalin RPython code I can't without knowing type19:54
fijalwhat the fuck19:54
fijalarigato: operations look valid to me, feel like giving a go?19:55
arigatofijal: fwiw http://paste.pocoo.org/show/498103/ shows that the _ptr's _obj contains complete nonsense19:55
arigatoit contains another _ptr19:55
arigatowhich contains another _ptr etc.19:55
arigatountil after 50 times you eventually reach a real "struct"19:56
fijalit's a prebuilt thing that looks sane to me19:56
arigatowell, I'm just saying that it *is* complete nonsense for a _ptr's _obj to contain another _ptr19:57
fijalah19:57
fijalhow do we get prebuilt stuff passed to the backend?19:58
fijalas just an array of constants or we do stuff with them?19:58
arigatosorry, missing context19:58
Action: fijal as well19:59
fijalwe create there a list of prebuilt constants19:59
fijaldoes the backend to anything special with them?19:59
fijalor just takes a list?20:00
fijalor we just pass Consts there?20:00
fijalthat seems to be more likely20:01
fijalmaybe just llbackend does not deal that well with prebuilt arrays of structs20:01
Alex_Gaynorfijal: are you working on test_zrandom?20:04
fijal"working" is a bit too much to say20:04
Alex_Gaynorheh20:04
arigatowe create there a list of prebuilt constants => I don't know where "there" is20:04
arigatono, the backend isn't sent any list of prebuilt constants20:05
fijalarigato: the obj seems sane to me at the point of creation20:06
fijalbut then someone at the other end receives something broken20:06
fijali31 = getinteriorfield_gc(Const(* GCREF hidden), Const(0), descr=<Descr "9, 'i', 'f2', E">),20:06
fijalthis is how the operation looks like when printed20:06
fijal(Pdb++) subloop.operations[-4].getarg(0).value._obj.container20:07
fijal<array [ S5 {f0='\x02', f1='\xf5', f2=216L}, S5 {f0='+', f1='\x0e', f2=255L}, S5 {f0='\x07', f1='\xec', f2=2L}, S5 {f0='G', f1='\xda', f2=152L}, S5 {f0='\xe9', f1='\t', f2=195L}, S5 {f0='\xe9', f1='$', f2=19L}, S5 {f0='\x0b', f1='>', f2=249L}, S5 {f0='\x06', f1='\xee', f2=11L}, S5 {f0='U', f1='\xdb', f2=30L}, S5 {f0='\xe9', f1='\x0e', f2=239L}, S5 {f0='\xca', f1='\xed', f2=162L}, S5 {f0='\xfe', f1='\xe2', f2=6L}, (...), S5 {f0='\xfb', f1='\xeb', f2=9L}, S5 {f0='\20:07
fijalxfd', f1='\xf5', f2=7L}, S5 {f0='\x07', f1='\x0e', f2=250L}, S5 {f0='\xf6', f1='\xf3', f2=1L}, S5 {f0='\xdd', f1='\x05', f2=48L} ]>20:07
fijal(Pdb++) 20:07
mwhudson (~mwh@linaro/mwhudson) left irc: Ping timeout: 240 seconds20:07
fijallooks sane to me20:07
Alex_GaynorI lost track, are you claiming it's sane or broken?20:08
fijalthis one seems sane20:08
fijalbut then the llgraph backend gets something obscure20:08
kenaan12alex_gaynor virtual-dicts 116283d742ab74 15/pypy/jit/metainterp/test/test_ajit.py: fix a really emberassing typo20:10
mwhudson (~mwh@120.136.5.22) joined #pypy.20:12
mwhudson (~mwh@120.136.5.22) left irc: Changing host20:12
mwhudson (~mwh@linaro/mwhudson) joined #pypy.20:12
mabbikeel (~mabbikeel@cpc4-duns7-2-0-cust218.9-3.cable.virginmedia.com) left irc: Ping timeout: 240 seconds20:13
fijalyes, it's llgraph backend not dealing with PBCs that are arrays of structs :/20:15
fijalok20:17
fijalarigato: how do I check when it gets modified?20:17
fijal:/20:17
fijalit's ok when I pass it to llgraph backend20:17
fijalbut then it gets corrupted20:17
arigatollimpl.py should probably use the official interface of lltype, and not _obj20:17
fijal:/20:18
fijalit's a mess to fight with20:18
Alex_Gaynorlltype has an official interface? ;)20:18
arigatoI can't guess why it's corrupted, but the official interface wouldn't let you build such nonsense20:18
arigatoAlex_Gaynor: yes: don't use any '_attribute'20:19
fijalarigato: it's still ok at the moment when I call compile_add_ref_const20:20
Alex_Gaynor:)20:20
arigatoI can fix it if you want20:20
arigatowell, "fix"20:20
arigatobecause it's probably unrelated to what fijal is fighting20:21
fijalarigato: please, I'm 7 yaks away20:21
fijalcan I push my stuff?20:21
arigatosure20:21
kenaan12fijal default 11de02b302dd89 15/pypy/jit/backend/test/test_ll_random.py: progress towards get/set interiorfield in test_ll_random20:24
kenaan12fijal default 1113932f534c82 15/pypy/jit/backend/llsupport/test/test_gc.py: merge default20:24
fijalarigato: you can get it to crash by doing20:24
fijalpy.test test/test_ll_random.py -s -x --pdb --repeat 10000 --random-seed=685820:24
cantato translate the py3k branch just do "hg up -C py3k" and then translate like you would do usually? or is there anythin more specific?20:24
aboudreault (~alanb@osgeo/member/aboudreault) left irc: Quit: Leaving20:25
kenaan12edelsohn ppc-jit-backend 11c58fa0a4d970 15/pypy/jit/backend/ppc/ppcgen/opassembler.py: Add PPC64 support for strlen20:27
Action: arigato -> good night20:28
kenaan12arigo jit-simplify-backendintf 11cce408b68723 15/pypy/jit/metainterp/: Fix the front-end.  Some reduction in the total number of lines, but due to a change --- when trac...20:28
kenaan12arigo default 1189631bbf04fe 15/pypy/jit/backend/test/test_ll_random.py: Typo20:28
Alex_GaynorRhyolite: should the PPC backend maybe he using some inheritance, rather than if IS_PPC_32 everywhere?20:29
arigatocanta: yes, that should be it20:29
RhyoliteAlex_Gaynor: yes, but I have asked Sven and Carl about this multiple times20:29
cantaarigato: splendid, thanks20:29
Alex_Gaynorfijal, arigato: I claim victory! http://paste.pocoo.org/show/498149/ now generates http://paste.pocoo.org/show/498150/20:32
fijalcanta: it's very unfinished though20:32
kenaan12alex_gaynor virtual-dicts 118dfa8646de2c 15/pypy/jit/metainterp/heapcache.py: ptr_eq and ptr_ne don't escape things.20:32
cantafijal: I hope I can find something that i might be able to fix :)20:33
fijalcanta: cool20:34
Alex_Gaynorcanta: if you want a good beginner task, I think amaury_ hasn't done the conversion for dict.{items,keys,values} to return the views, instead of lists20:34
fijalAlex_Gaynor: a lot of debug_merge_points :)20:34
cantawhen there is a lot that could be fixed, the probabilty is much higher to find something that i am actually able to fix :p20:34
Alex_Gaynorfijal: somewhere we have "5 resops per bytecode" as a goal.  I claim we're doing good ;)20:35
fijalAlex_Gaynor: that's super cool btw20:37
Alex_Gaynorfijal: we have kinda good infrastructure :)20:38
mabbikeel (~mabbikeel@cpc4-duns7-2-0-cust218.9-3.cable.virginmedia.com) joined #pypy.20:38
amaury_canta: Also, support for sys.hash_info is needed to import decimal.py20:40
amaury_this one is even simpler20:42
fijalAlex_Gaynor: yop20:42
amaury_What is a resop?20:43
cantaTaking some notes for the mentioned tasks20:43
danchr (danchr@cl-848.chi-02.us.sixxs.net) left #pypy.20:43
danchr (~danchr@cl-848.chi-02.us.sixxs.net) joined #pypy.20:43
derdon (~derdon@pD9E1D174.dip.t-dialin.net) joined #pypy.20:43
Alex_Gaynoramaury_: they're the operations used in the JIT optimizers and backends20:45
fijalamaury_: ?20:45
amaury_like a jit opcode?20:46
Alex_Gaynoramaury_: basically20:46
arigatoamaury_: a resop is an operation in the traces produced by the JIT20:50
arigatoas opposed to a "jit opcode" which means an opcode that is used as input to the tracer20:51
arigato"resop" is the intermediate format used everywhere in the JIT, basically20:52
timonatora finalizer as relevant to "lightweight-finalizers" is a __del__ method in an applevel object?20:53
Alex_Gaynorno, it's an __del__ at interp level20:53
mabbikeel (~mabbikeel@cpc4-duns7-2-0-cust218.9-3.cable.virginmedia.com) left irc: Ping timeout: 260 seconds20:54
amaury_arigato: ok thanks20:54
fijalarigato: any idea?20:58
lizardo (~lizardo@189.2.128.130) left irc: Quit: Leaving20:58
timonatorah, ok21:00
timonatori think i should, rather than try to explode my brain with the separate-applevel-numpy branch merging, re-do the changes i made onto the "regular" micronumpy structure21:07
timonatorand do the renaming "instantaneously" when the amount of other numpy branches is 021:07
fijaltimonator: I don't think there is ever going to be such time21:07
fijaltimonator: what's wrong now?21:07
timonatori capitulate, my diff/merge-fu is not near strong enough to figure out what i did wrong21:08
timonatorif someone else did it, okay, that would be fine21:08
fijalwhy do you want to?21:08
Arfrever (~Arfrever@apache/committer/Arfrever) joined #pypy.21:09
kenaan12fijal releasegil-effectinfo 11ce357df2a5c2 15/pypy/jit/metainterp/test/test_ajit.py: Initial JIT test for the manifestation of this issue.21:10
kenaan12fijal default 11fc37961a668f 15/pypy/module/pypyjit/policy.py: look into mmap21:10
fijaltimonator: I can do it if you don't feel like it21:10
fijaltimonator: however, maybe add at least docstrings for things yuo've added?21:11
arigato (~arigo@82.113.121.195) left irc: Quit: See you21:11
timonatorsure, that i can definitely do21:12
fijaleh21:15
fijalAlex_Gaynor: if I change genexpr into list comprehensions in ai I speed it up 7x21:16
fijalwe have to do something, this is insane21:16
Alex_Gaynorfijal: this is set(...)?21:16
fijaland two others above21:16
fijalmaybe 6x21:16
Alex_Gaynorfijal: but they're all to set, or list, or some other function with intep leve loop?21:17
Alex_Gaynorfijal: also, wtf at ce357df2a5c2?  isn't that something we committed ages ago?21:17
fijaluh21:18
kenaan12alex_gaynor virtual-dicts 1190eed59807bd 15/pypy/jit/metainterp/: copy{str,unicode}content can't affect heap caches21:18
fijalthat was some irrelevant checkin laying on tannit21:18
Alex_Gaynorfijal: anyway, so the slowness are all interp level loops?21:18
fijal[x86/asm] not implemented operation (guard): instance_ptr_eq21:19
fijalAlex_Gaynor: hey you broke my tools21:19
fijalCRASH21:19
Alex_Gaynorfijal: pull, I fixed that ages ago21:19
fijalpuh21:19
fijaldid I translate in the middle of something then?21:19
Alex_Gaynorno idea?21:19
Alex_Gaynorfijal: about the slowness?21:20
kenaan12fijal releasegil-effectinfo 1148639d927f25 15/: close long abandoned branch21:20
Alex_Gaynorabandoned?  it was merged :)21:20
fijalwell whatever21:21
fijalok, I guess I gonna go sleep then21:21
fijalslightly worried about genexprs21:21
Alex_Gaynorfijal: can you please answer my question about the slowness?21:21
fijalwhat about the slowness?21:22
fijalyes, they're all to tuple or set why?21:22
Alex_Gaynorfijal: all the places genexprs are slow are where they're passed to a builtin function?21:22
fijalyes21:22
Alex_Gaynormove them to app level ;)21:22
fijalI'm not sure you can move list to applevel21:23
fijalor tuple21:23
Alex_Gaynoruh, tuple might be hard, but list shouldn't be, I don't think21:23
fijalwhy are multimethods so slow anyway21:24
fijalmeh, I should start removing more of them I guess21:25
Alex_Gaynordunno, change next() to not be a multimethod21:25
Alex_Gaynorthen it should be fine I guess21:25
mat^2 (~mathias@212.130.113.35) joined #pypy.21:26
Alex_Gaynorfijal: well, list.__init__ has to lookup GeneratorIterator.__next__ on each iteration21:26
fijalyes, that is silly21:26
Alex_Gaynorthat's python for you21:27
Alex_Gaynorthat's why we have a JIT that removes such things21:27
amaury_ (~amaury_@46-127-23-192.dynamic.hispeed.ch) left irc: Ping timeout: 240 seconds21:28
pjenveyneed moar app level21:32
Alex_Gaynorpjenvey: pretty much :)21:33
timonatorapp level ALL THE THINGS21:34
Alex_Gaynorthat too :D21:34
timonatorsomeone could shop cfb's terminator-head onto that haah picture21:34
timonator.o(i just made up an acronym for hyperbole and a half!)21:34
timonatorstill waiting for that book to come out :(21:35
tlynn (~tlynn@cpc6-cmbg14-2-0-cust121.5-4.cable.virginmedia.com) joined #pypy.21:37
ojii (~ojii@154-60.3-85.cust.bluewin.ch) left irc: Quit: Leaving21:46
bbot2Started: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/11621:50
bbot2Started: 15http://buildbot.pypy.org/builders/own-macosx-x86-32/builds/69221:50
bbot2Started: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-32/builds/91921:50
davisagli (~davisagli@davisagli.com) left irc: Excess Flood21:53
davisagli (~davisagli@davisagli.com) joined #pypy.21:53
davisagli (~davisagli@davisagli.com) left irc: Excess Flood21:54
davisagli (~davisagli@davisagli.com) joined #pypy.21:54
cantaIs it expected that cpython runs the tests much faster than pypy? (14 to 40 seconds in one example)21:57
Alex_Gaynorcanta: tests are usually a bad case for the JIT, because you tend to run a lto of code only a few times each21:58
exarkunis this in the FAQ yet? :)21:59
cantamakes sense, could have thought of that21:59
antocuni (~antocuni@host152-120-dynamic.11-79-r.retail.telecomitalia.it) joined #pypy.22:09
Nick change: TkTech -> TkTech|Train22:11
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) joined #pypy.22:13
k_bx (~k_bx@94.244.19.62) joined #pypy.22:13
fijalexarkun: no, feel like putting it there?22:14
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/540 [12alex, virtual-dicts]22:14
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1806 [12alex, virtual-dicts]22:14
bbot2Started: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/672 [12alex, virtual-dicts]22:14
bbot2Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1068 [12alex, virtual-dicts]22:14
aboudreault (~alanb@osgeo/member/aboudreault) joined #pypy.22:19
dmalcolm (david@nat/redhat/x-lgpbojqechtdfhst) left irc: Quit: Leaving22:22
Sho_ (~EHS1@kde/hein) joined #pypy.22:30
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) left irc: Quit: x___x22:34
davisagli (~davisagli@davisagli.com) left irc: Excess Flood22:35
davisagli (~davisagli@davisagli.com) joined #pypy.22:36
kkris (~kris@93-82-44-187.adsl.highway.telekom.at) left irc: Remote host closed the connection22:44
whitelynx (~whitelynx@li117-47.members.linode.com) left irc: Quit: Ex-Chat22:58
CIA-2503awsum 07roundup * 10#922/1.6 crashes with time.sleep(negative_number): [new] cpython just throws IOError: Invalid argument * 14https://bugs.pypy.org/issue92223:03
Transformer (~Transform@ool-4a59e397.dyn.optonline.net) joined #pypy.23:09
Transformer (Transform@ool-4a59e397.dyn.optonline.net) left #pypy.23:11
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/540 [12alex, virtual-dicts]23:17
Trundle (~andy@python/site-packages/trundle) left irc: Ping timeout: 248 seconds23:20
bbot24Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1068 [12alex, virtual-dicts]23:22
rekamso (~textual@67.51.82.66) left irc: Ping timeout: 260 seconds23:24
derdon (~derdon@pD9E1D174.dip.t-dialin.net) left irc: Remote host closed the connection23:29
bbot24Failure: 15http://buildbot.pypy.org/builders/own-macosx-x86-32/builds/69223:36
fzzzy (~donovan@nat/mozilla/x-qqdmamnpfemtujsl) left irc: Quit: fzzzy23:36
kvda (~kvda@124-149-101-221.dyn.iinet.net.au) joined #pypy.23:36
Gonsor (~quassel@134.76.63.190) left irc: Remote host closed the connection23:47
fzzzy (~donovan@76-198-130-19.lightspeed.mtvwca.sbcglobal.net) joined #pypy.23:53
Sho_ (~EHS1@kde/hein) left irc: Quit: Stop leaking memory like it's going out of fashion.23:56
Sho_ (~EHS1@kde/hein) joined #pypy.23:56
--- Wed Oct 26 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!