Timestamps are in GMT/BST.
[07:56] ohumbel [5390f2dc@gateway/web/freenode/ip.83.144.242.220] has joined #jython
[08:02] Oti [5390f2dc@gateway/web/freenode/ip.83.144.242.220] has joined #jython
[08:58] Imek [~joe@host-195-188-251-108.reversezone.co.uk] has joined #jython
[09:27] lolsuper_ [~super_@unaffiliated/lolsuper-/x-9881387] has joined #jython
[09:56] Moo|businessday has changed nick to Moo|conf
[10:00] lolsuper_ [~super_@unaffiliated/lolsuper-/x-9881387] has quit [Ping timeout: 245 seconds]
[10:06] seberg [~sebastian@vpn-3034.gwdg.de] has joined #jython
[10:07] Imek [~joe@host-195-188-251-108.reversezone.co.uk] has quit [Quit: Good night, and have a pleasant tomorrow.]
[10:12] seberg [~sebastian@vpn-3034.gwdg.de] has quit [Ping timeout: 265 seconds]
[10:22] seberg [~sebastian@89.204.137.72] has joined #jython
[10:52] adiroiban [~adiroiban@h194-54-129-79.teleson.ro] has joined #jython
[11:11] Oti [5390f2dc@gateway/web/freenode/ip.83.144.242.220] has quit [Ping timeout: 265 seconds]
[12:23] juneau001 [~juneau@FESS-116326.dhcp.fnal.gov] has joined #jython
[12:28] seberg [~sebastian@89.204.137.72] has quit [Quit: Ex-Chat]
[12:33] shanka [~shashank@c-98-245-87-8.hsd1.co.comcast.net] has quit [Quit: Leaving.]
[13:07] sgithens [~sgithens@cpe-65-29-76-170.indy.res.rr.com] has quit [Ping timeout: 255 seconds]
[14:02] Oti [5390f2dc@gateway/web/freenode/ip.83.144.242.220] has joined #jython
[14:03] <Oti> the logbot is down - i need a few hours to fix it, sorry
[14:09] Moo|conf has changed nick to Moo|waitingforbe
[14:09] Moo|waitingforbe has changed nick to Moo|afternoon
[14:12] seberg [~sebastian@134.76.218.194] has joined #jython
[14:32] thobe [~Adium@66.46.247.40] has quit [Quit: Leaving.]
[14:40] jimbaker [~jbaker@71.16.235.2] has joined #jython
[14:47] adiroiban [~adiroiban@h194-54-129-79.teleson.ro] has quit [Ping timeout: 240 seconds]
[14:58] sgithens [~sgithens@149-166-134-137.dhcp-in.iupui.edu] has joined #jython
[15:05] jimbaker [~jbaker@71.16.235.2] has left #jython []
[15:06] jimbaker [~jbaker@71.16.235.2] has joined #jython
[15:12] skay [~skay@c-71-239-171-114.hsd1.il.comcast.net] has joined #jython
[15:29] skay [~skay@c-71-239-171-114.hsd1.il.comcast.net] has quit [Quit: skay]
[15:33] juneau001_ [~juneau@FESS-116326-2415106-dp.dhcp.fnal.gov] has joined #jython
[15:34] juneau001_ [~juneau@FESS-116326-2415106-dp.dhcp.fnal.gov] has quit [Client Quit]
[15:34] jimbaker [~jbaker@71.16.235.2] has quit [Quit: jimbaker]
[15:54] jimbaker [~jbaker@conference/ubuntudevelopersummit/x-gsnoounwbhtrzzem] has joined #jython
[16:30] skay [~skay@pat1.orbitz.net] has joined #jython
[16:36] shanka [~shashank@c-98-245-87-8.hsd1.co.comcast.net] has joined #jython
[16:43] <shanka> jimbaker: hi
[16:44] seberg [~sebastian@134.76.218.194] has quit [Quit: Ex-Chat]
[16:44] <shanka> jimbaker: the performance improvements that i sent your earlier is actually quite bogus. I'm starting to think about it again, i'll take another shot at it and send you the updated expectations
[16:45] <jimbaker> shanka: sounds good. what changes do you have in mind?
[16:45] <shanka> jimbaker: also i'll start touching the actual code and start implementing this logic
[16:46] <shanka> jimbaker: basically i was previously calling all of the 24 cases in a for loop. This is not what will happen in our compiler
[16:46] <shanka> for every iteration one of the 24 will be called
[16:47] <shanka> which means i need to use a random number generator inside the loop and call one in 24 cases in each iteration.
[16:47] <jimbaker> got it. a couple of other things to change: 1. use unique method code bodies in doWork; 2. increase the number of enums
[16:48] <shanka> jimbaker: ok sure
[16:48] <jimbaker> i suspect 24 cases is sufficient to spill into a table switch
[16:48] <jimbaker> but you can force it with a more realistic case
[16:49] <jimbaker> there's one other thing that's going on here, but will be harder to simulate
[16:49] <jimbaker> the basic problem that polymorphic instructions is trying to solve is keep code bodies small such that a chain of them will inline
[16:51] <jimbaker> but to simulate, you need to capture such aspects that 1) many bytecodes are quite compact and local - they manipulate the stack;
[16:52] <jimbaker> 2) others call into the runtime, but again, they might actually inline pretty well. of course we expect that to be the really the case once we get to indy
[16:52] <shanka> jimbaker: correct, so should i just trust and go ahead and change the PyByteCode; to see if we get improvements?
[16:54] lopex [lopex@chello089076044027.chello.pl] has joined #jython
[16:54] <shanka> then we'll know for sure if we are getting the improvements or not; after which we can take an appropriate call
[17:02] sgithens [~sgithens@149-166-134-137.dhcp-in.iupui.edu] has quit [Read error: Operation timed out]
[17:05] Moo|afternoon has changed nick to Moo|needforbeer
[17:11] enebo [~enebo@184-97-197-6.mpls.qwest.net] has joined #jython
[17:24] <jimbaker> shanka: sounds good to me
[17:26] <jimbaker> we have good evidence from JRuby that this polymorphic instruction strategy works. ola bini blogged about it (maybe it was their regex engine)
[17:26] <jimbaker> so the main thing is just to ensure we know how to implement
[17:27] <jimbaker> enebo: do you have a reference into JRuby that shanka could take a look at?
[17:28] <jimbaker> (shanka is a student of jeremysiek at the univ of colorado who is working with me to speed up jython performance)
[17:28] <enebo> jimbaker: you mean using polymorphic interface instead of big switch?
[17:28] <jimbaker> enebo: correct
[17:29] <enebo> ah. src/org/jruby/ast/*Node.java ... look at interpret() method (we start by calling interpret on RootNode and then it pings around)
[17:29] <jimbaker> enebo: thanks
[17:30] <enebo> The main reason it works out better than a big switch is the switch generally is a biggish method and the JVM does not optimize large methods
[17:30] <jimbaker> i put the code that shanka and i are discussing into the paste bin (http://pylonshq.com/pasties/699e85da090cb1d7b3e7861bf0437ead)
[17:30] <enebo> Consider probably half of that switch may never get hit
[17:31] <enebo> jimbaker: Actually that is pretty much how our parser works now
[17:31] <enebo> code-wise
[17:31] <jimbaker> we are trying to optimize the switch in this code: https://jython.svn.sourceforge.net/svnroot/jython/trunk/jython/src/org/python/core/PyBytecode.java
[17:32] <enebo> We post-process the generated Jay output to a collection and then store into an array and use state to get next production state
[17:33] <enebo> It was like 4 times faster then a switch which only contained one method call per switch statement
[17:33] <jimbaker> enebo: cool. we definitely have too much overhead in our ast phase, but it's not as critical as it is for jruby
[17:33] <enebo> yeah we had luck with these approaches. Let me know how it goes and if you discover anything else
[17:34] <jimbaker> enebo: sounds good. i think this will definitely help shanka
[17:34] <enebo> yeah our parsing if we warm up long enough will pass C Ruby but that is A LOT of parsing ;)
[17:34] <enebo> Like loading Rails framework 100 times
[17:34] <jimbaker> btw, the reason we are doing this is that we want to have support for a limited form of continuation passing semantics, as a fallback if type specialization fails
[17:35] <jimbaker> enebo: sounds like a great test! :P
[17:35] <jimbaker> jython is so much slower than cpython for parsing, we have to pay the tax of going through antlr
[17:36] <enebo> I've heard from someone that they upgraded to 3.1 and it has slowed down even more
[17:37] <jimbaker> but this is generally not a problem because my code these days is compiled in advance in python whether jython or cpython (this is the setup.py in a package)
[17:37] <jimbaker> s/my/most
[17:37] <jimbaker> (my code too, i guess ;) )
[17:37] <enebo> ah yeah that would be handy
[17:38] <shanka> enebo: thanks, i'm browsing through the git now, it's a great class design
[17:39] <jimbaker> enebo: we may end up normally running python bytecode for start/non hot-code if the type specialization works. to be seen!
[17:40] <jimbaker> are you still planning to execute asts going forward, or having a ruby bytecode vm?
[17:41] <enebo> jimbaker: We have a new system in org.jruby.compiler.ir
[17:41] <enebo> In fact I am making the debugging interpreter as we speak
[17:41] <enebo> I will be landing a pretty big changeset today or tomorrow
[17:41] <jimbaker> cool. is this the ssa approach?
[17:41] <enebo> The new IR is much more machine-like in nature
[17:42] <enebo> Instructions/Operands and the author is a Phd who wrote a Java optimizing compiler
[17:42] <enebo> SSA
[17:42] <jimbaker> ok. we should definitely take a look
[17:42] <jimbaker> we've been planning an alternative strategy of naive python to naive java compilation
[17:43] <enebo> The big pay off for us will be that we should end up generating less code for our Java bytecode we emit (plus a nice facility to inine method and closures)
[17:43] <enebo> It will take quite a bit of time to iron it out, but it is pretty amazing so far. Subbu ended doing all this gestalt style and studying the bytecode (our bytecode) to consider correctness
[17:44] <enebo> I have had to fix a number of things but far less than I thought. Most stuff was right on
[17:46] sgithens [~sgithens@adsl-76-252-55-59.dsl.ipltin.sbcglobal.net] has joined #jython
[17:47] <jimbaker> enebo: really want to see the performance here. the feedback i got from remi is that naive java code could get optimized better, and certainly he has good numbers for php-reboot
[17:47] <jimbaker> but... i don't know if he has good test workloads
[17:48] <enebo> jimbaker: yeah that is the rub. Performance is totally dependent on what you are benching against
[17:48] <enebo> I will say it should be fairly obvious in this case
[17:48] <enebo> It was for us in both the interpreter and in the parser (much more so in the parser)
[17:49] jgartman [~jgartman@66.194.163.210] has joined #jython
[17:54] <jimbaker> enebo: do you have a fairly standard set of real workload-derived benchmarks for ruby? we are planning to get jython into http://speed.pypy.org/, which runs the benchmarks that unladen swallow put together. probably the biggest contribution to python from unladen, they're derived from some internal work that was done at google
[17:55] <jimbaker> i think it's the sort of work that's hard and not celebrated. but so very useful
[17:56] jimbaker [~jbaker@conference/ubuntudevelopersummit/x-gsnoounwbhtrzzem] has quit [Quit: jimbaker]
[17:56] <enebo> jimbaker: We have tons of microbenchs but our larger ones are generally user-reported issues when we are slower then MRI. That in turn usually makes us create some microbenches once we figure out what is slow
[17:57] <enebo> we do really need a good benchmark to exercise the typical web 2.0 app. There is olioapp, but we have not really embraced it like we should
[18:12] == sgithens [~sgithens@adsl-76-252-55-59.dsl.ipltin.sbcglobal.net] has quit [Read error: Operation timed out]
[18:28] == Oti [5390f2dc@gateway/web/freenode/ip.83.144.242.220] has quit [Quit: Page closed]
[17:52] -anthony.freenode.net- *** Looking up your hostname...
[17:52] -anthony.freenode.net- *** Checking Ident
[17:52] -anthony.freenode.net- *** No Ident response
[17:52] -anthony.freenode.net- *** Couldn't look up your hostname
[17:52] [frigg VERSION]
[17:52] * JythonLogBot (~PircBot@74.50.59.201) has joined #jython
[17:52] * Topic is '[Jython 2.5.2 rc 2 at http://www.jython.org/ | This channel is logged: http://jython.extreme.st/irclogs/ | Please update the wiki: http://wiki.python.org/jython/ | Pastebin: http://pylonshq.com/pasties | IRC Channel: http://wiki.python.org/jython/IrcChannel | Jython Book: http://jythonbook.com | Podcast: http://www.jythonpodcast.com]'
[17:52] * Set by Oti!~ohumbel@adsl-84-226-37-89.adslplus.ch on Mon Oct 25 05:26:21 UTC 2010
[17:55] * fwierzbicki_ (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Quit: Ex-Chat)
[17:58] * fwierzbicki_ (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[17:58] * fwierzbicki_ (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Client Quit)
[18:03] * fwierzbicki_ (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[18:03] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Quit: Ex-Chat)
[18:05] * enebo (~enebo@216-250-174-225.static.iphouse.net) has joined #jython
[18:07] * jimbaker (~jbaker@71.16.235.2) has joined #jython
[18:07] * fwierzbicki_ is now known as fwierzbicki
[18:11] <enebo> jimbaker: Sorry I think I missed your last message to me
[18:11] <enebo> I noticed it when I reconnected but the restarted Colloquy because it was not reconnecting
[18:34] <jimbaker> enebo: sure, just curious if the ruby community has standardized on a set of benchmarks that are more useful than the typical XStone or whatever
[18:35] <jimbaker> this is what i'm referring to http://code.google.com/p/unladen-swallow/wiki/Benchmarks for python
[18:38] <enebo> jimbaker: Ruby impls generally all run the benchmarks shootout stuff, and evan (from rbx) has been trying to popularize a tiered set of benchmarks he has been using, but nothing standardized yet
[18:39] <jimbaker> enebo: right, i've seen the shootout, but they don't look very interesting. evan's bmarks probably are closer to unladen swallow's, based on your descr
[18:39] <enebo> yeah way too mathy for one
[18:39] <enebo> which is ok if you are doing that sort of thing, but they are all also pretty small and not too representative
[18:59] * lucian (~lucian@78-86-217-168.zone2.bethere.co.uk) has joined #jython
[19:01] <enebo> jimbaker: Your enum vs switch code you pasted earlier should probably not do IO for timings
[19:02] <enebo> Although if you redirect to /dev/null perhaps not as noisy
[19:02] <jimbaker> enebo: that's a very good point for shanka
[19:03] * juneau001 (~juneau@FESS-116326.dhcp.fnal.gov) Quit (Quit: Take care...)
[19:03] <enebo> The other comment since I am giving them is you may want to keep generating bigger and bigger switch vs enum to see the tipping point
[19:03] <enebo> At some point the switch still no longer compile to native and it will drop an order of magnitude in performance
[19:04] <shanka> enebo: good point, i'll try that
[19:04] <jimbaker> for me, it was just more important that shanka understood the basic approach of this process, which is to look at the enum to dispatch
[19:04] <jimbaker> because it seems too artificial anyway
[19:05] <enebo> yeah
[19:05] <jimbaker> PyBytecode actually has a complex relationship with the runtime, which will get more interesting once we put indy into place
[19:05] <jimbaker> at which point we would expect the lack of inlining to be even more pronounced
[19:06] <jimbaker> it's not a very good test, but when i ran PyBytecode vs using java bytecode on pystone, it was maybe 30% the speed. which seemed quite good
[19:08] <jimbaker> i would expect inlining to change this dynamic significantly
[19:08] <jimbaker> shanka: here's an interesting point
[19:12] * enebo (~enebo@216-250-174-225.static.iphouse.net) Quit (Quit: enebo)
[19:13] <shanka> jimbaker: I'm not sure i completely understand. which class generated the java byte code generated?
[19:14] <jimbaker> actually, i was just thinking about this some more. getattr/getglobal correspond somewhat to java reflection. we don't actually do that, but instead do our own resolution. indy is supposed to give the tools to work around that, but in something like the pbcvm, it's going to be what headius likes to describe as megamorphic
[19:14] <jimbaker> "anything can be called"
[19:15] <jimbaker> so that doesn't exactly make the callsite stable
[19:22] <jimbaker> shanka: just thinking out loud here. i think what this means is that the pbcvm won't inline w/ indy. which is fine. this is exactly what the #pypy devs realized, general interpreters are special
[19:22] <jimbaker> (although certain ones will work, such as a regex engine)
[19:23] <shanka> jimbaker: so you are thinking if the swith (to enums) is actually going to help
[19:24] <shanka> once indy kicks in that is
[19:24] <jimbaker> indy should not improve its performance. the enum refactoring will still be useful however
[19:25] <jimbaker> it should make it closer to existing java bytecode
[20:01] * juneau001 (~juneau@pool-72-69-211-49.chi01.dsl-w.verizon.net) has joined #jython
[20:13] * lucian (~lucian@78-86-217-168.zone2.bethere.co.uk) Quit (Remote host closed the connection)
[20:27] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Quit: Ex-Chat)
[20:30] * lucian (~lucian@78-86-217-168.zone2.bethere.co.uk) has joined #jython
[20:35] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[20:55] <Oti> the discussion from today should be logged now - sorry for the trouble
[21:03] * sgithens (~sgithens@149-166-11-27.dhcp-in.iupui.edu) Quit (Ping timeout: 272 seconds)
[21:17] <jimbaker> Oti: thanks. i asked shanka to make the leap of faith and do all of his performance work pretty much in the open. but it's certainly going to work out better, good discussion with enebo of course
[21:50] * skay (~skay@pat1.orbitz.net) Quit (Quit: skay)
[22:14] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 245 seconds)
[22:18] * shanka (~shashank@c-98-245-87-8.hsd1.co.comcast.net) Quit (Ping timeout: 272 seconds)
[22:19] * jgartman (~jgartman@66.194.163.210) Quit (Quit: Leaving)
[22:26] * intuition (~vaine0@69.84.253.197) Quit ()
[23:08] * skay (~skay@c-71-239-171-114.hsd1.il.comcast.net) has joined #jython
[23:55] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).