00:54:22  * seventhquit (Ping timeout: 245 seconds)
01:58:37  * bnoordhuisquit (Ping timeout: 256 seconds)
02:22:19  * seventhjoined
02:26:43  * seventhquit (Ping timeout: 246 seconds)
02:32:04  * C-Manquit (Quit: Connection reset by beer)
06:52:21  * rendarjoined
09:01:46  * xan_joined
09:03:58  * stamphoquit (Ping timeout: 252 seconds)
09:55:04  * abraxasjoined
10:02:20  * C-Manjoined
10:17:27  * stamphojoined
10:35:54  * stamphoquit (Ping timeout: 264 seconds)
10:49:06  * stamphojoined
11:03:55  * [[zzz]]joined
11:04:45  * Net147joined
11:07:19  * [[zz]]quit (Ping timeout: 246 seconds)
11:17:41  <CIA-70>jkummerow@chromium.org * r12583 /branches/bleeding_edge/ (52 files in 16 dirs):
11:17:41  <CIA-70>First commit of new tools/run-tests.py
11:17:41  <CIA-70>Review URL: https://codereview.chromium.org/10919265
11:17:41  <CIA-70>jkummerow@chromium.org * r12584 /branches/bleeding_edge/test/mjsunit/regress/regress-crbug-119926.js:
11:17:41  <CIA-70>Speed up test/mjsunit/regress/regress-crbug-119926
11:17:41  <CIA-70>Review URL: https://codereview.chromium.org/10958063
11:17:42  <CIA-70>jkummerow@chromium.org * r12585 /branches/bleeding_edge/test/mjsunit/d8-os.js:
11:17:42  <CIA-70>Speed up test/mjsunit/d8-os by reducing sleep times
11:17:43  <CIA-70>Review URL: https://codereview.chromium.org/10973003
11:17:43  <CIA-70>jkummerow@chromium.org * r12586 /branches/bleeding_edge/test/mjsunit/debug-multiple-breakpoints.js:
11:17:44  <CIA-70>Speed up test/mjsunit/debug-multiple-breakpoints
11:17:44  <CIA-70>Review URL: https://codereview.chromium.org/10961064
11:17:45  <CIA-70>jkummerow@chromium.org * r12587 /branches/bleeding_edge/test/mjsunit/greedy.js:
11:17:45  <CIA-70>Speed up test/mjsunit/greedy.js
11:17:46  <CIA-70>Review URL: https://codereview.chromium.org/10969062
11:17:46  <CIA-70>jkummerow@chromium.org * r12588 /branches/bleeding_edge/test/mjsunit/ (5 files):
11:18:04  <CIA-70>Speed up test/mjsunit/compiler/regress-or
11:18:04  <CIA-70>Review URL: https://codereview.chromium.org/10969063
11:18:04  <CIA-70>jkummerow@chromium.org * r12594 /branches/bleeding_edge/test/mjsunit/regress/regress-crbug-119926.js:
11:18:04  <CIA-70>Remove trailing whitespace
11:18:04  <CIA-70>R=mstarzinger@chromium.org
11:18:04  <CIA-70>Review URL: https://codereview.chromium.org/10969064
11:18:05  <CIA-70>jkummerow@chromium.org * r12595 /branches/bleeding_edge/test/mjsunit/ (mjsunit.status regress/regress-1969.js):
11:18:05  <CIA-70>Delete test/mjsunit/regress-1969.
11:18:06  <CIA-70>It was flaky, and its usefulness was doubtful.
11:18:06  <CIA-70>(1 lines omitted)
11:25:44  * bnoordhuisjoined
12:23:27  * TheJHjoined
13:05:09  * [[zzz]]changed nick to [[zz]]
13:30:31  <CIA-70>jkummerow@chromium.org * r12596 /branches/bleeding_edge/test/mjsunit/ (9 files):
13:30:31  <CIA-70>Split test/mjsunit/debug-stepout-scope into smaller chunks
13:30:31  <CIA-70>Review URL: https://codereview.chromium.org/10969061
13:30:32  <CIA-70>mstarzinger@chromium.org * r12597 /branches/bleeding_edge/src/heap.cc:
13:30:32  <CIA-70>Improve --trace-gc-verbose to show sum of all spaces.
13:30:32  <CIA-70>R=ulan@chromium.org
13:30:32  <CIA-70>Review URL: https://codereview.chromium.org/10974006
13:36:40  * abraxasquit (Remote host closed the connection)
15:21:12  * bradleymeckjoined
15:25:20  * Net147quit (Quit: HydraIRC -> http://www.hydrairc.com <- Organize your IRC)
15:37:55  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
15:51:01  <CIA-70>yangguo@chromium.org * r12598 /branches/bleeding_edge/src/ (json-parser.h objects.cc objects-inl.h objects.h):
15:51:01  <CIA-70>Fast path for symbol lookup in JSON.parse.
15:51:01  <CIA-70>R=verwaest@chromium.org
15:51:01  <CIA-70>BUG=
15:51:01  <CIA-70>Review URL: https://chromiumcodereview.appspot.com/10969069
15:51:02  <CIA-70>yangguo@chromium.org * r12599 /branches/bleeding_edge/src/json-parser.h:
15:51:03  <CIA-70>Fix failures caused by r12598.
15:51:03  <CIA-70>R=verwaest@chromium.org
15:51:04  <CIA-70>BUG=
15:51:04  <CIA-70>Review URL: https://chromiumcodereview.appspot.com/10958070
16:09:43  * bradleymeckquit (Quit: bradleymeck)
17:01:43  * xan_quit (Quit: leaving)
17:21:13  * bradleymeckjoined
18:45:52  * bnoordhuis_joined
18:48:24  * bnoordhuisquit (Ping timeout: 245 seconds)
18:48:25  * jamespagequit (*.net *.split)
18:48:25  * Alex_Gaynorquit (*.net *.split)
18:49:30  * jamespagejoined
18:49:50  * Alex_Gaynorjoined
18:53:54  * rendar_joined
18:55:14  <luite>is there a way to see the arguments a function was called with when it's deoptimized? i have some code that runs twice as slow with v8 as with ionmonkey and i'm trying to figure out why :)
18:56:01  * eoh|joined
18:57:38  * rendarquit (Read error: Connection reset by peer)
18:57:38  * eohquit (Ping timeout: 246 seconds)
18:57:39  * Alex_Gaynorquit (Ping timeout: 246 seconds)
18:57:39  * Deathzorquit (Ping timeout: 246 seconds)
18:58:16  * Deathzorjoined
18:59:25  * Alex_Gaynorjoined
19:02:15  * stalledquit (Ping timeout: 244 seconds)
19:05:47  * stalledjoined
19:14:27  * [[zz]]quit (Ping timeout: 274 seconds)
19:14:27  * stamphoquit (Ping timeout: 274 seconds)
19:14:28  * stamphojoined
19:14:28  * [[zz]]joined
19:22:16  <luite>wow (x === y)|0 is really slow compared to (x === y)?1:0
19:22:44  <luite>is there an even faster way?
19:33:43  * bradleymeckquit (Quit: bradleymeck)
19:35:20  <CIA-70>rossberg@chromium.org * r12600 /branches/bleeding_edge/ (src/messages.js src/parser.h test/mjsunit/limit-locals.js):
19:35:20  <CIA-70>Bump number of allowed variables per scope to 65535, to address GWT.
19:35:20  <CIA-70>R=jkummerow@chromium.org
19:35:20  <CIA-70>BUG=151625
19:35:20  <CIA-70>Review URL: https://codereview.chromium.org/10965063
19:35:21  <CIA-70>rossberg@chromium.org * r12601 /branches/3.13/ (4 files in 2 dirs):
19:35:21  <CIA-70>Merged r12600 into 3.13 branch.
19:35:21  <CIA-70>Bump number of allowed variables per scope to 65535, to address GWT.
19:35:22  <CIA-70>BUG=151625
19:35:22  <CIA-70>R=jkummerow@chromium.org
19:35:23  <CIA-70>Review URL: https://codereview.chromium.org/10973012
19:35:23  <CIA-70>rossberg@chromium.org * r12602 /tags/3.13.7.2: Tagging version 3.13.7.2
19:48:03  * bradleymeckjoined
19:51:43  <mraleph>luite: well you are doing bitwise on boolean values… nobody thinks that should be fast :-)
19:52:26  <mraleph>or in other words: Crankshaft does not like that
19:53:21  * jamespagequit (Ping timeout: 245 seconds)
19:55:42  * C-Manquit (Read error: Connection reset by peer)
19:56:29  * C-Manjoined
20:12:52  <luite>mraleph: yeah i noticed, i just needed a fast way to convert to ints, i assumed that it would recognize that the result would always be bool, and then inline a fast conversion. apparently not :)
20:14:11  <luite>but i guess it not really a common thing to do (i need to return a heap location for the result of a comparison, not a bool value, False and True are statically stored at heap locations 0 and 1)
20:15:28  * C-Manquit (Ping timeout: 241 seconds)
20:15:29  * bradleymeckquit (Ping timeout: 241 seconds)
20:15:29  * [[zz]]quit (Ping timeout: 241 seconds)
20:15:29  * stamphoquit (Ping timeout: 241 seconds)
20:15:29  * stamphojoined
20:16:12  * C-Manjoined
20:16:13  * [[zz]]joined
20:17:48  <luite>after fixing the |0 thing it's now only 25% slower than ionmonkey
20:20:25  <Alex_Gaynor>mraleph: why shouldn't bitwise arithmetic be fast on bools?
20:21:55  <mraleph>luite: now you have my attention. what are you actually measuring? it should not be slower than IonMonkey :-)
20:22:02  <luite>haha
20:22:07  <luite>i'm still optimizing
20:22:19  <mraleph>Alex_Gaynor: well it should be :-) just nobody went and did it.
20:22:19  <luite>it's code from a haskell->js compiler
20:22:30  <mraleph>mhm.
20:22:46  <mraleph>is it open source?
20:22:48  <luite>so not really easy to read
20:23:10  <mraleph>well I can read the compiler itself :-)
20:23:11  <luite>yeah but the new code generator i'm working on is not public yet
20:23:14  <mraleph>ok
20:23:31  <mraleph>please send me a mail when it'll be public: vegorov@google.com
20:24:00  <mraleph>if there are some corner cases where V8 is suffering I at least would like to materialize some issues from them :-)
20:24:06  <luite>it's extremely experimental so tricky to get running
20:24:32  <mraleph>well you can send selfcontained js output. that would work as well.
20:24:57  <Alex_Gaynor>mraleph: I'm curious why would anyone need to spend time optimizing it? Presumabley bool->int coercion just generates some op that widens the bits, and then int | 0 is an obvious noop (+ checking for valueOf or whatever that function is called).
20:24:59  <luite>it relies heavily on arrays (stack and heap global variables), the main loop is something like while(c !== done) { c = c(); }, arguments are passed in global variables r1...32 (yes i really want tco :) )
20:25:44  <mraleph>Alex_Gaynor: well it would work if boolean was a number, but in V8 it is a pointer to the object.
20:26:13  <Alex_Gaynor>mraleph: so it's a field read + widening :)
20:26:20  <Alex_Gaynor>which is really just one instruction on x86 I think
20:26:21  <mraleph>Alex_Gaynor: yeah that works.
20:26:27  <mraleph>yeah it is simple.
20:26:42  <Alex_Gaynor>So the missing operation is bool.toint() or similar?
20:27:16  <mraleph>yep.
20:27:39  <mraleph>I would rephrase it.
20:28:05  <mraleph>the design of the compiler pipeline in this place is a bit borked.
20:28:30  <mraleph>conversions do not exist as proper IR instructions.
20:28:58  <mraleph>translation layer just assumes that nobody would use boolean in a bitwise expression
20:29:07  <Alex_Gaynor>fun times
20:29:42  <mraleph>there is not such thing as boolean-to-int, only number-to-int.
20:30:05  <mraleph>it's either real number in a numeric operation or you are out of sweet spot :-)
20:30:27  <mraleph>this is why I always say that I want to rewrite V8 from scratch :-)
20:30:28  <luite>i've replaced the primitive operations in my compiler with the ?0:1 construct now, until you guys improve it :)
20:30:49  <mraleph>there are two many special cases accumulated over years in places where generic approach should be favored.
20:30:59  <Alex_Gaynor>mraleph: haha, I know the feeling I have a document on my desktop describing how I want to rewrite RPython from scratch
20:33:45  <mraleph>yeah IonMonkey is better then we with this… they have a real ToInt32 instruction in IR http://hg.mozilla.org/mozilla-central/file/4a9d494f4376/js/src/ion/MIR.h#l1666
20:35:23  <luite>hm the last change helped ionmonkey more than v8 :) https://gist.github.com/3778197
20:35:44  <luite>that's the benchmark, which runs in ~1.6s on v8, 1.2s on ionmonkeyt on my system
20:36:10  <mraleph>luite: thanks!
20:36:13  <luite>sorry for the ugliness :)
20:36:18  <mraleph>luite: np.
20:36:22  <mraleph>lovely Core
20:36:35  <luite>it has lots of redundant assignments since i don't have the dataflow analsys working yet
20:36:47  <luite>but i guess v8 would remove many of then anyway
20:36:51  <mraleph>n-queens, hohoho
20:37:28  <mraleph>let me try running it.
20:40:21  <luite>every haskell object is a function with 6 extra properties, i hope that's not a bad thing to do :)
20:40:42  <mraleph>luite: so how do I know if it works? if it printed at the end con[1] :: $hs_GHC.Types.I#_con_e -> (2680 :: double)?
20:40:47  <luite>yeah
20:40:50  <mraleph>ok
20:40:58  <luite>that means the reduced result is an Int with value 2680
20:41:18  <luite>the correct answer, number of solutions for an 11x11 field
20:41:55  <mraleph>one thing: I suggest not to log anything when measuring time. console.log is actually much slower on Chrome than on FF, last time I checked… I doubt that it dominates runtime, but still.
20:42:12  <luite>oh i use the v8 and ionmonkey console things
20:46:07  <mraleph>ok.
20:46:31  <luite>that part of the code runs much faster in v8 anyway :)
20:46:46  <mraleph>I briefly looked through IR for the hottest function, did not spot anything obviously bad… Need to take a deeper look later.
20:46:53  <luite>the garbage collector, which is a few loops through arrays
20:47:00  <luite>but it doesn't take much time compared to the rest
20:47:34  <luite>mraleph: ok, great, thanks
20:48:20  <mraleph>there are some LoadKeyedGeneric there, but without closer look it's hard to say if they are a genuine problem (e.g. you read out of bounds; v8 does not like that) or something else.
20:50:09  <luite>hmm, it shouldn't read anything out of bounds ever. out of bounds writes are probably more common, the stack should grow
20:58:35  <luite>do you ahve tips for reading deopt messages? output IR code with the checks somehow to see which failed?
21:00:59  * deavidquit (*.net *.split)
21:05:01  * deavidjoined
21:06:33  * jamespagejoined
21:06:33  * jamespagequit (Changing host)
21:06:33  * jamespagejoined
21:11:03  * rendar_quit
21:17:47  * luite_joined
21:18:04  <luite_>hm my code segfaults v8 now :(
21:18:20  * luitequit (Ping timeout: 240 seconds)
21:18:20  * Raynosquit (Ping timeout: 240 seconds)
21:18:35  * TheJHquit (Ping timeout: 256 seconds)