00:02:20  * C-Manquit (Quit: Connection reset by beer)
00:37:41  * carifquit (Quit: Ex-Chat)
01:36:22  * abraxasjoined
01:53:02  * carifjoined
01:58:05  * c4miloquit (Remote host closed the connection)
01:59:41  * c4milojoined
02:07:33  * carifquit (Quit: Ex-Chat)
04:18:02  * carifjoined
04:54:52  * c4miloquit (Remote host closed the connection)
05:51:06  * carifquit (Quit: Ex-Chat)
08:27:58  * muellijoined
08:41:10  * cha0squit (Ping timeout: 246 seconds)
08:43:01  * cha0sjoined
08:43:01  * cha0squit (Changing host)
08:43:01  * cha0sjoined
08:51:47  * bnoordhuisjoined
08:53:47  * C-Manjoined
10:54:28  * carifjoined
10:58:52  * solublejoined
10:59:05  * solublepart
10:59:26  * solublejoined
12:48:04  * stalledquit (Read error: Connection reset by peer)
12:55:21  * stalledjoined
12:55:57  * [[zz]]quit (Ping timeout: 240 seconds)
13:10:01  * [[zz]]joined
14:47:16  * solublequit (Ping timeout: 246 seconds)
14:51:48  * c4milojoined
15:10:04  * bnoordhuisquit (Ping timeout: 264 seconds)
15:10:06  * c4miloquit (Remote host closed the connection)
15:18:03  * spolujoined
15:27:40  * jmar777joined
15:31:37  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
15:35:44  * muelliquit (Remote host closed the connection)
16:15:17  * bnoordhuisjoined
16:19:35  * bnoordhuisquit (Ping timeout: 245 seconds)
16:19:36  * stalledquit (Ping timeout: 260 seconds)
16:23:23  * [[zz]]quit (Ping timeout: 240 seconds)
16:32:39  * stalledjoined
16:37:14  * bnoordhuisjoined
16:38:15  * [[zz]]joined
16:42:42  * c4milojoined
17:24:34  * c4miloquit (Remote host closed the connection)
17:37:12  * spoluquit (Ping timeout: 268 seconds)
18:26:06  * c4milojoined
19:02:34  * rickytaylor26_changed nick to ricky26
19:28:11  * c4miloquit (Remote host closed the connection)
19:36:41  * c4milojoined
19:38:50  * mralephjoined
19:39:39  * _bgajoined
19:39:46  <_bga>here
19:41:40  <mraleph>hi
19:41:44  <_bga>mraleph anyway i guess that checking overflow after each op is too expensive
19:41:52  <mraleph>no, it is not
19:42:45  <_bga>i need benchmark :)
19:42:46  <mraleph>it can matters only on a very tight stuff, which never happens in reality. and it can be worked around by sprinkling enough |0 here and there.
19:43:08  <_bga>as in asm.js
19:43:14  <mraleph>CPUs are very good at predicting branches.
19:43:18  <mraleph>as in normal javascript
19:43:56  <mraleph>but yes reasoning is the same as in asm.js
19:44:32  <mraleph>except that you don't need no asm.js --- ability to eliminate overflow checks here and there just follows from the pure JS spec
19:45:07  <mraleph>regarding your case with for (var i = x; i < y; i += z)
19:45:59  <mraleph>usually if range for x and y is unknown you would have an overflow check on i += z.
19:46:18  <mraleph>the code would look like add eax, ebx; jc ->deopt;
19:46:32  <mraleph>not very tragic cost, really.
19:46:50  <_bga>so v8 eliminates overflow check if i have explicit | 0
19:47:16  <mraleph>i = (i + z) | 0 should have no overflow check.
19:49:44  <mraleph>in case of z = 1 quite often you can actually derive that i would not overflow because you usually already know that x and y are int32 (or int31 even) and thus i + 1 will never overflow. it can go at most to y, which is bounded.
19:49:58  <mraleph>and the case of z = 1 is quite common.
19:50:00  <_bga>mraleph and. Is Math.floor(x) casts int x to double?
19:50:43  <mraleph>back in the day in V8 math.floor only supported double to int behaviour for Math.floor
19:51:01  <mraleph>in optimized code I mean
19:51:38  <mraleph>so in optimized code x was expected to be double and the result was expected to be int.
19:51:53  <mraleph>if you did Math.floor on smth that did not fit into int you get deoptimization
19:52:12  <mraleph>if you did Math.floor on something that is known to be an int32 than Math.floor just goes away
19:52:29  <mraleph>optimizer would replace Math.floor(x) with x if x is int32.
19:52:44  <mraleph>cause that makes perfect sense not to do redundant stuff :-)
19:53:20  <mraleph>[I can switch to Russian if you prefer, _bga]
19:53:31  <_bga>i just want robust way to cast int to double. Will benchmark tomorrow
19:54:07  <mraleph>I am not sure what you mean by robust way to cast in to double.
19:54:23  <mraleph>VM prefers to have representation that is most beneficial for the given value.
19:54:28  <_bga>i fear thats x - eps + eps just will transformed to x
19:54:48  <mraleph>unlikely, as it is not equivalent.
19:55:04  <mraleph>-0 - eps + eps is 0
19:55:06  <mraleph>not -0
19:55:20  <_bga>so it will work
19:55:21  <_bga>ok
19:55:43  <mraleph>should work
19:55:45  <_bga>is v8 uses 64 bits as SM now?
19:55:54  <mraleph>no
19:56:39  <mraleph>actually if x is known to be integer to optimizer than optimizer could turn x - eps + eps to x but I am pretty sure V8 would.
19:56:57  <_bga>so each double will be pointer deref
19:56:59  <_bga>:/
19:58:11  <bnoordhuis>v8 can sometimes unbox them
19:58:22  <bnoordhuis>maybe not as often as one would like
20:00:39  <mraleph>_bga no
20:00:53  <mraleph>doubles that are in the optimized code are unboxed
20:01:10  <mraleph>bnoordhuis: often enough for majority of computations
20:01:31  <bnoordhuis>mraleph: i was half tongue-in-cheek there :)
20:01:32  <mraleph>now even fields use mutable boxes, so situation is almost golden
20:01:34  <_bga>m. or i can have code, optimized for ints, or - for doubles
20:01:55  <bnoordhuis>we had an issue recently where c++ code that used to return an int now returns a double
20:02:01  <bnoordhuis>and the gc went crazy
20:02:08  <mraleph>oh yeah that is one of the issues left to address.
20:02:12  <mraleph>can be fixed still
20:02:29  <bnoordhuis>oh? if you tell me how and if it's not too much work, i'll have a go at it
20:02:55  <mraleph>_bga: code will be optimized for the most wide type needed to contain your values, if we are talking about optimizer.
20:04:29  <mraleph>bnoordhuis: actually the way I know requires quite a bit of work, requires splitting each optimized code object into two parts: one that does unboxing of inputs and reboxing of the result and the other that does work. and then you connect things to the working part directly from other optimized code objects
20:04:56  <mraleph>it's the same approach functional language compilers use to avoid boxing
20:05:00  <_bga>assuming thats modern cpus are 64bit - i guess thats forcing computation in pure doubles make code faster in v8
20:05:02  <mraleph>(thunks in their case)
20:05:10  <mraleph>(aka worker/wrapper transformation)
20:05:17  <mraleph>no :-)
20:05:59  <mraleph>SSE units while speedy have somewhat higher latency and other issues.
20:06:08  <bnoordhuis>mraleph: ah, okay. that doesn't sound like something i could get done in a day or two
20:06:25  <mraleph>yeah, I guess it would take a couple of months to get it right :-/
21:38:07  * mraleph1joined
21:38:52  * mralephquit (Read error: Connection reset by peer)
21:51:33  * bnoordhuisquit (Ping timeout: 240 seconds)
21:51:54  * seventhjoined
21:58:47  * jmar777quit (Remote host closed the connection)
22:07:36  * bnoordhuisjoined
22:29:06  * juanjosanchezjoined
22:31:06  * c4miloquit (Remote host closed the connection)
22:31:28  * RT|Chatzillajoined
23:01:20  * c4milojoined
23:25:36  * seventhquit (Ping timeout: 240 seconds)
23:51:56  * C-Manquit (Quit: Connection reset by beer)