00:56
<Hixie>
hm, no abarth
00:56
<Hixie>
aha, he's in #webkit
07:16
<MikeSmith>
Hixie: http://www.whatwg.org/issues/data.html looks borked
07:17
<MikeSmith>
oh
16:00
<gsnedders>
Anyone around that understands __proto__ in SM?
16:10
<gsnedders>
Basically, anyone know what Object.prototype.__proto__ does?
16:11
<gsnedders>
I'm confused looking over the thread in es-discuss.
16:59
<asmodai>
Mmm
16:59
<asmodai>
I wonder why Opera mobile does not allow fingerpress on URL to have a copy URL popup option.
17:12
<gsnedders>
asmodai: What OS?
17:13
<asmodai>
Android 3
17:13
<asmodai>
Only got a Save As and Copy Text option when long pressing an URL leading to an apk (nightly firefox in this case)
17:16
<gsnedders>
Oh, you mean on a link?
17:17
<asmodai>
Aye
17:18
<asmodai>
Many cases where you might want to drop an URL into an evernote note or something like that
17:34
<TabAtkins_>
Argh, Transforms are *so* messed up.
17:34
<TabAtkins_>
I suspect largely because nobody ever finished the spec, but everyone implemented anyway.
17:35
<Ms2ger>
Sounds like something to blame Apple for
17:35
<AryehGregor>
TabAtkins_, :)
17:36
<AryehGregor>
TabAtkins_, on the other hand, it might get interesting if you resolved ems for computed value but not percentages . . .
17:36
AryehGregor
tries to think of an interesting case
17:36
<AryehGregor>
It's a corner case anyway, since there's no reason for anyone to specify transform: inherit, ever.
17:37
<AryehGregor>
We could probably change it so ems are resolved and no one would notice.
17:41
<Ms2ger>
AryehGregor, I think a well-written css3-box would be really nice, fwiw
17:42
AryehGregor
has never looked at css3-box
17:42
<Ms2ger>
Hey, it doesn't have a warning
17:42
<Ms2ger>
TabAtkins?
17:44
<bga>
w3c reminds me idef more and more
17:49
<annevk>
back
17:49
<annevk>
jetlagged
17:49
<TabAtkins_>
Ms2ger: Yes?
17:50
<TabAtkins_>
Oh, I see.
17:50
<TabAtkins_>
Huh, I wonder how that escaped my warning crusade.
17:50
<hober>
annevk: welcome back!
17:51
<annevk>
inbox >4000
17:51
<Ms2ger>
annevk, multipage HTML is broken
17:51
<annevk>
yeah, I read about that
17:51
<annevk>
is foolip away too?
17:51
<annevk>
or just didn't have the time
17:58
<TabAtkins_>
AryehGregor: Changing it to resolve ems would be great, yes.
18:05
<annevk>
MikeSmith: resolved bugs still don't go to www-dom I think
18:05
<annevk>
MikeSmith: the timeout given in my email (backed up by Art) has long since passed
18:05
<annevk>
MikeSmith: so I think we can go ahead with that now
18:11
<annevk>
Velmont: hey, have you ever played with gzip and XHR?
18:12
<annevk>
Velmont: should work fine no?
18:12
<AryehGregor>
Ms2ger or some Mozilla person: do reftests detect differences that aren't painted onto the screen? Like, they're outside the initial viewport?
18:12
<Ms2ger>
Don't think so
18:13
<AryehGregor>
I just found a reftest that seems to want to say matrix3d(1,0,0,0, 0,2,0,0, 0,0,3,0, 4,5,6,1) is the same as scale3d(1,2,3) translate3d(4px,5px,6px), which of course it's not, but the transformed div has no background and the text is off-screen, so I guess it's not surprising that it passes anyway.
18:13
<annevk>
"Responses must have the content-encodings automatically decoded."
18:13
<annevk>
so that should work fine
18:16
<AryehGregor>
. . . also, I just found a test that's precisely identical to its ref.
18:16
<Ms2ger>
<3
18:16
<AryehGregor>
I guess I should file bugs.
18:16
<Ms2ger>
Checked for silly things like BOMs?
18:17
<AryehGregor>
diff -u returned nothing.
18:17
<Ms2ger>
A bug it is, then, I guess
18:17
<AryehGregor>
diff -u layout/reftests/transform-3d/overflow-hidden-1{a,-ref}.html
18:17
AryehGregor
reports
18:17
<Ms2ger>
Hah
18:51
<AryehGregor>
Ms2ger, if I'm filing a bug that was introduced by another bug, the new bug I file should depend on the old bug, right? Not block it?
18:52
AryehGregor
always gets them confused
18:52
<Hixie>
MikeSmith: wfm now
18:52
<Ms2ger>
AryehGregor, block
18:52
<AryehGregor>
Okay.
18:55
<Hixie>
anyone have IE handy?
18:55
<AryehGregor>
Hixie, yes.
18:55
AryehGregor
is using Windows 8 Developer Preview in VirtualBox with IE10
18:56
<AryehGregor>
No need for licensing fees.
18:56
<Hixie>
can you load http://software.hixie.ch/utilities/js/live-dom-viewer/ and hit the download link
18:56
<AryehGregor>
Then what?
18:56
<Hixie>
and then hit set 0, check that option 0 is selected, then hit set 1, check that option 1 is selected, and then hit set null, and see what happens?
18:57
<AryehGregor>
When I hit "set 0", option 0 is selected. Then when I hit "set 1", option 1 is selected. Then when I hit "set null", option 0 is selected again.
18:57
<AryehGregor>
In IE10 Developer Preview.
18:57
<Hixie>
awesome, thanks
18:57
<Hixie>
and nothing is selected for set 2, right?
18:57
<AryehGregor>
Right.
18:57
<Hixie>
ok so the guy reporting this bug was just wrong, cool
18:57
<Hixie>
thanks
18:58
<Hixie>
it's so cool the way these days the specs all line up and actually describe obscure edge cases interoperably
18:59
<AryehGregor>
Well, the HTML/DOM type of specs, at least . . . CSS not so much, as I'm finding.
18:59
<Hixie>
:-(
19:02
<TabAtkins_>
Dude, you're explicitly dealing with specs that are shitty because they got dropped.
19:02
<TabAtkins_>
Stop generalizing, please. >_<
19:02
<dglazkov>
good morning, Whatwg!
19:02
<AryehGregor>
TabAtkins_, no, I definitely mean all CSS specs. At least all the ones to do with layout. Parsing and the cascade seems fine. But layout is horribly vague. It needs to be redefined algorithmically using precise hyperlinked definitions.
19:03
<AryehGregor>
We were just talking about how terms like "the element's box" are ambiguous in tons of cases.
19:03
<annevk>
oh hey Hixie, until when are you around?
19:03
<TabAtkins_>
Mm, that's true.
19:03
<Hixie>
woot, anne has returned!
19:04
<Hixie>
annevk: i'm at home with some virus or something
19:04
<annevk>
Hixie: planning on looking into that multipage issue, but food is getting near
19:04
<Hixie>
annevk: so on and off depending on when i'm feeling better and when i'm out cold in bed
19:04
<TabAtkins_>
A big problem there is that no one has written Box yet, and 2.1 is still overly vague.
19:04
<annevk>
Hixie: oh, good luck with that
19:04
<Hixie>
i'll be fine
19:04
<annevk>
Hixie: will take a look a little later (still going through email) and ping you again
19:04
<AryehGregor>
A big problem is that tons of different people are all writing different specs to bolt on features in different places and there's very little thought given to how they interact, because nothing is being done in a unified fashion.
19:04
<Hixie>
annevk: cool
19:05
<Hixie>
annevk: it looks like your end isn't fetching the spec
19:05
<Hixie>
annevk: at least, i don't get any hits for the spec when i ping your end
19:05
<annevk>
I use svn update
19:05
<Hixie>
oh
19:05
<Hixie>
hm
19:05
<Hixie>
might be my fault then
19:05
<Hixie>
maybe i'm no longer updating something
19:05
<Hixie>
let me check
19:06
<Hixie>
nope, looks like the repo is up to date
19:06
<Hixie>
both complete.html and index (though tehy're identical now of course)
19:07
<Hixie>
man, i really need to add a mail filter to send anything matching (to:public-webapps subject:charter) to trash
19:08
<annevk>
hmm a week out of date
19:12
<annevk>
oh, dreamhost was hacked, had to reset my password
19:12
<annevk>
they were hacked jan 21... spec stopped updating jan 24
19:12
<annevk>
hmm
19:15
<Hixie>
yeah i don't think the password change would have any effect
19:19
<annevk>
and I'm in
19:22
<annevk>
Hixie: fixed
19:23
<Hixie>
what was wrong?
19:23
<annevk>
Hixie: same problem as last time, svn cleanup was required
19:23
<Hixie>
weird
19:23
<annevk>
I put it in the cgi script now
19:23
<Hixie>
heh
19:23
<annevk>
not sure if that'll help
19:25
<Hixie>
annevk: any idea what's causing svn cleanup to be needed?
19:26
<annevk>
svn being locked while checking out maybe? not sure if that's possible, but it complaints about locking
19:26
<Hixie>
weird
19:31
<Ms2ger>
This is actually what *specs* do?
19:31
<annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12539#c11 is still not fixed
19:31
<annevk>
any idea jgraham ?
19:32
<Ms2ger>
Apparently the web wants isSameNode :(
19:32
<Ms2ger>
And GWT in particular
19:33
<Ms2ger>
annevk, ^
19:34
<annevk>
aah
19:34
<annevk>
sad
20:03
<annevk>
IE is shipping BlobBuilder?
20:03
<annevk>
I thought we were going to kill that? :(
20:05
<AryehGregor>
WTF -- transform-origin parses differently in standards and quirks mode?
20:05
<AryehGregor>
Interoperably?
20:07
<AryehGregor>
transform-origin: 100 100 is interpreted as transform-origin: 100px 100px in quirks mode, but not standards mode . . .
20:07
<AryehGregor>
Is this an across-the-board difference in CSS parsing? If so, is it specced somewhere?
20:07
<AryehGregor>
TabAtkins, ^^
20:07
<Philip`>
https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior ?
20:07
<Philip`>
("The CSS parser interprets unitless numbers as px")
20:08
<Philip`>
(Oh, I misread "specced" as "documented")
20:08
<AryehGregor>
Seems interoperable.
20:09
<AryehGregor>
This should probably be in Values and Units.
20:09
<Ms2ger>
Oh, and I think we parse color: 000000 in quirks
20:09
<Ms2ger>
Quirks mode doesn't exist in CSS, though
20:10
<AryehGregor>
So it's only for styles that are inline in an HTML document?
20:10
<bga>
css compressors will be happy to hear this
20:11
<bga>
Ms2ger and color: fff too?
20:11
<Ms2ger>
Dunno
20:11
<Ms2ger>
AryehGregor, is it? I'm not sure
20:11
AryehGregor
also doesn't
20:13
<AryehGregor>
data:text/html,<div style="background:00ff00; height:100;width:100"> displays a green box in IE/Chrome/Opera, but not Firefox.
20:14
<Ms2ger>
Hmm, attributes may go through another path
20:15
<AryehGregor>
Awesome.
20:21
<annevk>
I think they should all go through the same path
20:21
<annevk>
and I think we should define it
20:24
AryehGregor
just sent mail to www-style
20:28
<Ms2ger>
Hmm, ParseStyleAttribute does seem to check for quirks mode
20:30
<Ms2ger>
Seems like this should work...
20:32
<Ms2ger>
Aha
20:33
<Ms2ger>
AryehGregor, doesn't work for compound properties; color and background-color work
20:33
<AryehGregor>
Nice.
20:34
<Ms2ger>
Ah, and bz beat me to it
20:49
<annevk>
so data URL rules when fetching data URLs through an HTTP API
20:49
<annevk>
what would be the best place?
20:49
<annevk>
XMLHttpRequest for now?
21:10
<bga>
gwt users blame Ms2ger that he deleted isSameNode
21:12
<annevk>
I wonder why GWT uses isSameNode
21:34
<annevk>
so what's HTTP/2.0?
21:34
<annevk>
is it intended to be the new name for SPDY?
21:52
<jgraham>
I presume HTTP/2.0 will be where they take SPDY, make some backward-incompatible changes, and leave browsers with 3 protocols to implement
21:57
<annevk>
reminiscent of Kafka
22:00
<annevk>
<2400
22:00
<annevk>
(there was a lot of spam :( )
22:04
<hober>
jgraham: sounds familiar...
22:10
<gsnedders>
jgraham: I'm not sure SPDY has any legacy which prevents it from being dropped, though.
22:10
<annevk>
why is http://tools.ietf.org/html/draft-ietf-websec-origin not linked to http://tools.ietf.org/html/draft-abarth-origin ?
22:11
<gsnedders>
jgraham: Also Firefox already supports at least four already: HTTP, FTP, SPDY, and Gopher.
22:11
<hober>
annevk: and both should really point to http://tools.ietf.org/html/rfc6454
22:11
<abarth>
annevk: dunno. I think we'd need to ask someone at the IETF to add the links
22:12
<annevk>
hober: yeah, the former does, but I found the latter via Google :/
22:12
<hober>
annevk abarth: of course the ietf have always been so good about this sort of thing</sarcasm>
22:13
<abarth>
annevk: I can update the draft with a link if all else fails
22:15
<annevk>
abarth: I guess I'll ask Julian if I remember
22:20
<jgraham>
gsnedders: I don't think that FTP or Gopher are functionally equivalent to HTTP. I mean Opera support SMTP but it's hardly comparable
22:23
<annevk>
oh, by donating you become an EFF member?
22:24
<annevk>
I wonder if I could have avoided that somehow
22:26
<annevk>
should we add something to http://wiki.whatwg.org/wiki/MetaExtensions about emailing whatwg⊙wo for community review?
22:26
<annevk>
as optional step of course
22:35
<annevk>
only two sleeping spammers on the wiki since I left
22:35
<annevk>
good times
22:35
<asmodai>
Oh hey, it's anne!
22:40
<annevk>
"Obsolescence notices on old specifications, again" ooh
22:48
<annevk>
ooh, there's a subthread on www-archive with the same name
22:48
<annevk>
and no popcorn available
22:56
<jacobolus>
does anyone know what the right way is to unpack a javascript float? i.e. to figure out the exact bits of the internal number?
22:56
<jacobolus>
*internal representation
22:56
<gsnedders>
You mean get at the actual repr of it?
22:56
<jacobolus>
right
22:57
<gsnedders>
Um, there's no built-in way to do so.
22:57
<jacobolus>
sure. I'm just wondering what the best arithmetic to do is that won't introduce rounding errors or w/e
22:57
<gsnedders>
You can probably achieve it through Typed Arrays, actually.
22:57
<jacobolus>
gsnedders: yeah, but that doesn't help me in old browsers :)
22:57
<gsnedders>
Then it's less easy :)
22:58
<jacobolus>
gsnedders: and one thing I'm trying to do is test out the PRNGs behind Math.random(), just for my own edification
22:59
<gsnedders>
I guess you just need to calculate the needed exponent and mantissa yourself.
23:00
<jacobolus>
yeah. so in theory, if I have a number 0 < x < 1, repeatedly multiplying by 2 and sometimes subtracting 1 should avoid rounding problems, right?
23:01
<gsnedders>
I'm nowhere near awake enough to think in that level of detail :)
23:01
<jacobolus>
heh. boo
23:02
<jacobolus>
:)
23:02
<gsnedders>
Well, the exponent is such that you take log2, round-down.
23:03
<gsnedders>
IEEE754 means you need to deal with the exponent bias.
23:03
<gsnedders>
But then you should just be able to subtract Math.pow(2, exponent) from your value to get the mantissa, no?
23:04
<jacobolus>
that's what I would expect
23:05
<jacobolus>
but once I have the mantissa, that's still as a float. I should be able to pull out the bits w/ repeated [multiply by 2], [if > 1 then subtract 1] steps, right?
23:05
<gsnedders>
And both the exponent and mantissa can be expressed exactly (both are less than 2^53), and Math.pow(2, exponent) is guaranteed to have a representation possible.
23:05
<gsnedders>
jacobolus: Just x.toString(2)
23:06
<jacobolus>
gsnedders: oh! didn't realize that one.
23:07
<jacobolus>
gsnedders: I can just use x.toString(2) in general then
23:08
<gsnedders>
jacobolus: Doesn't get you the actual repr of the float, though
23:08
<jacobolus>
but it gives the exponent & mantissa
23:09
<gsnedders>
jacobolus: It shouldn't.
23:09
<gsnedders>
> (Math.pow(2, 51)+1.5).toString(2)
23:09
<gsnedders>
"1000000000000000000000000000000000000000000000000001.1"
23:09
<gsnedders>
For example
23:10
<jacobolus>
that looks correct...?
23:10
<gsnedders>
It's not the exponent and mantissa, though
23:10
<jacobolus>
well, the exponent is however far the . is to the right
23:11
<jacobolus>
and the mantissa is the value if we remove the . and strip leading 0s
23:11
<jacobolus>
and if I read the ieee 754 spec I could figure out precisely how the bits of that are arranged
23:11
<gsnedders>
jacobolus: That's not going to be in IEEE754 double format, though
23:12
<jacobolus>
what do you mean?
23:12
<gsnedders>
(where the mantissa has an implicit leading 1, effectively making it normalized)
23:12
<jacobolus>
sure
23:12
<gsnedders>
Or am I being stupid and half-asleep?
23:12
<gsnedders>
(This seems quite plausible)
23:12
<gsnedders>
(Seeming I am, in fact, half asleep)
23:12
<jacobolus>
gsnedders: what I'm saying is I can deterministically figure out the representation from that, I think
23:12
<gsnedders>
Right.
23:13
<jacobolus>
but in any event, it's good enough for my purposes here
23:13
<jacobolus>
gsnedders: interestingly, v8's Math.random() seems to only do 32 random bits?
23:13
<gsnedders>
jacobolus: No idea.
23:13
<jacobolus>
safari as well
23:14
<jacobolus>
in theory they could do 53 random bits, right?
23:14
<jacobolus>
for a number in (0, 1)
23:14
<gsnedders>
(0, 1]
23:15
<Philip`>
[0, 1)
23:15
<jacobolus>
is it (0, 1]? I was under the impression that they'd never produce 1.
23:15
<gsnedders>
No, I'm just getting my brackets the wrong way around.
23:15
<jacobolus>
gotcha
23:15
<gsnedders>
What Philip` said.
23:15
<Philip`>
0 <= x < 1, if you want the not incredibly confusing notation
23:15
<jacobolus>
:)
23:16
<jacobolus>
the notation is plenty readable to former math students :)
23:16
<jacobolus>
gsnedders: thanks for the toString(2) lead. I for whatever reason thought that only worked for integers
23:19
<Philip`>
I believe at least SpiderMonkey uses an RNG equivalent to lrand48(), which returns 31 bits, but then it gets two random ints and shifts and adds to get a random double
23:20
<Philip`>
I think one difficulty with Math.random() is that if you change it to a higher quality RNG, you lose on critical-for-marketing benchmarks
23:20
<jacobolus>
boo
23:20
<jacobolus>
prngs like MWC are pretty fast though
23:21
<zewt_>
integrate randomness quality into the benchmarks? heh
23:21
<jacobolus>
Philip`: but it's hard to imagine a case where actual calls to random() is the bottleneck. adding just a couple noop function calls seem to dramatically slow things down relative to calling random() bare
23:22
<zewt>
as long as you're not doing anything stupid (like touching /dev/random)
23:22
<jacobolus>
i.e. hard to imagine such cases in real code
23:22
<Philip`>
jacobolus: Never underestimate the ability of benchmark writers to write benchmarks whose bottleneck is nowhere like where they intended :-)
23:22
<jacobolus>
heh. fair enough
23:23
<Philip`>
(especially since the bottlenecks change after the benchmarks are written)
23:23
<jacobolus>
I guess what I mean is, doing `for (var i = 0, r = Math.random; i < 1e6; i++) { r(); };` seems like a relatively rare sort of occurrence
23:24
<jacobolus>
if there's a benchmark along those lines, maybe it should be scrapped :)
23:24
<zewt>
jacobolus: of course, a smart JIT would notice that Math.random() has no side-effects, and elide the whole damn thing :P
23:24
<gsnedders>
A lot of Peacekeeper comes down to little more than that.
23:25
<zewt>
c/c++ compilers definitely do that sort of thing
23:26
<zewt>
(no clue if JS engines do)
23:26
<zewt>
(guess it'd be easy enough to find out)
23:27
<gsnedders>
I *think* V8 and SM should, but in V8's case it needs to be detected as hot-code to get the optimization done!
23:27
<zewt>
chrome production doesn't, anyway
23:27
<zewt>
well, not when pasting into the console
23:27
<zewt>
gsnedders: of course, that's another problem with benchmarking JS :P
23:27
<zewt>
was: re: stating the obvious
23:28
<gsnedders>
zewt: It's optimization for hot-code should, at least. The problem is you have to run the non-optimized code first. :P
23:28
<gsnedders>
zewt: Well, it's a problem with any JITing language.
23:28
<zewt>
sticking it in a function and calling it a few times and it doesn't change, at least
23:28
<zewt>
gsnedders: well, I'm blaming the naive benchmarks, not JS
23:28
<gsnedders>
Try a few hundred :P
23:28
<jacobolus>
gsnedders: is commented peacekeeper code easily accessible someplace?
23:28
<gsnedders>
jacobolus: No.
23:28
<jacobolus>
their site is kind of a mess
23:29
<zewt>
shouldn't have to run an expensive function a few hundred times to get it to optimize :P not when calling the function takes over a second
23:29
<zewt>
(increased to 1e7 so I could see the runtime clearly)
23:29
<gsnedders>
jacobolus: The test frame just loads the same URL over and over again, and changes based on cookies :P
23:30
<jacobolus>
how can people take a 21st century benchmark seriously that doesn't clearly show & explain what it's doing?
23:30
<gsnedders>
Marketing.
23:31
<Philip`>
The perceived quality of a benchmark is entirely dependent on how pretty its graphs are
23:31
<Philip`>
(That's how I judge them, at least)
23:31
<jacobolus>
Philip`: well are there any good benchmarks with shitty graphs that need help?
23:32
<jacobolus>
I bet with a couple days effort it would be possible to make some damn pretty graphs
23:32
<jacobolus>
use canvas or SVG, and if they aren't supported, just "sorry, your browser is so obsolete we can't even show you results"
23:33
<gsnedders>
Kraken for example tests CSE quite heavily.
23:35
<gsnedders>
(for var i = 0; i < 1000; i++) { foo[i] = Math.abs(foo[i] >> 1); bar[i] = foo[i] >> 1; }
23:35
Philip`
knows too little to know of any good benchmarks
23:35
<gsnedders>
Is what you need to be quick on to be good on Kraken.
23:36
<jacobolus>
gsnedders: "CSE"?
23:36
<gsnedders>
jacobolus: common subexpression elimination
23:37
<jacobolus>
ah, I see
23:37
<gsnedders>
Also you need to be able to tell Math.abs is loop-invariant
23:37
<jacobolus>
gsnedders: with the idea there being that foo[i] >> 1 can't be eliminated because foo[i] changes after the first time?
23:38
<gsnedders>
jacobolus: Gah! No, switch the two statements in the block around.
23:38
<zewt>
understanding const functions is a pretty fundamental optimization anyway, i'd expect
23:38
<gsnedders>
(which means you have to be able to tell that Math.abs is the built-in pure one, and that foo[i] and bar[i] are data properties for all i)
23:39
<gsnedders>
(because if they are accessor properties for any i then they could have side-effects and mutate Math.abs)
23:39
<jacobolus>
sure
23:39
<zewt>
i'd expect engines to optimize for functions like that not being mutated, and have an exception path if anything ever does ("fuck, throw everything jitted away and give up because someone did something horrible")
23:41
<gsnedders>
Also if any are {valueOf:function(){return 1;}} because obv. you can do whatever in that function
23:41
<jacobolus>
are there any "how fast can the jit do when we throw horrible stuff" tests? those would be fun to write
23:41
<zewt>
and if someone creates benchmarks for performance when people do horrible things that break optimizations, they get shot in the head
23:41
<gsnedders>
zewt: Ah, but the point is you don't want the branch for the exception path in the hot code.
23:41
<gsnedders>
Oh, you mean just throwing out all generated code if something mutates such a thing?
23:41
<zewt>
gsnedders: the branch would happen on assignment, not on access
23:42
<zewt>
(putting aside how to do *that* efficiently)
23:42
<zewt>
right
23:42
<gsnedders>
zewt: That could be fun with OSR.
23:42
<zewt>
with who?
23:42
<gsnedders>
on-stack replacement
23:43
<gsnedders>
Imagine you have generated code that assumes a built-in is a built-in, and then you change the built-in.
23:43
<zewt>
right
23:43
<gsnedders>
Everything higher up on the stack has to cope with this change.
23:43
<zewt>
i'd think that would be an important assumption to be able to make
23:43
<zewt>
and cope with if someone is a jerk and violates it
23:43
<gsnedders>
So throwing away code isn't obviously always simple.
23:43
<zewt>
but not optimize for
23:43
<zewt>
heh, i wouldn't expect anything related to JIT to be simple :)
23:44
<zewt>
but yeah, it's definitely a tough problem
23:44
<zewt>
i'd expect the wins to be pretty significant, though
23:44
<gsnedders>
I mean, something like that example at first glance appears to be quite easy to optimize, until you start finding edge-cases that make optimization hard.
23:45
<gsnedders>
zewt: Eh, mostly only on benchmarks, though
23:45
<gsnedders>
Anyhow, time for me to vanish.
23:45
<zewt>
gsnedders: i don't know about that; it should allow general sets of constant-value folding
23:46
<zewt>
granted, many of which you can do by hand, but that's exactly what you shouldn't have to do with a good optimizer
23:46
<zewt>
heh, I think some C optimizers will optimize x = 0; for(int i = 0; i < n; ++i) x += i; to x = n*(n+1)/2
23:47
<zewt>
(which, to be sure, is an optimization only relevant to benchmarks)
23:53
<Philip`>
(I imagine it could be argued that those kinds of optimisations are actually somewhat useful, even though a human could perform the same transformation trivially, because dumb code will be generated via macros or templates and it's nice if the compiler can recognise the special cases instead of forcing the programmer to abandon their nice abstractions and optimise those cases by hand)
23:53
<zewt>
also, those optimizations tend to (though don't always) mirror more useful optimizations
23:54
<zewt>
eg. having enough information in a C compiler to notice common patterns (as opposed to, say, a dumb peephole match for a summation) is obviously a good thing
23:54
<zewt>
(no idea what level the above optimization is actually done at)