Hacker News new | past | comments | ask | show | jobs | submit login

> this is pretty damning for ie9 js performance isn't it?

I think the whole point of the post is to poke fun at how Microsoft is cheating the benchmark and how it was caught. The part on the definition of Angles and that the "optimizer" should throw an exception it doesn't (most probably because it's not optimizing anything) is hilarious.




Mmm but this goes beyond cheating on the benchmark - that func(1,2) example is atrocious. You could (possibly) understand them having a direct match on the math-cordic benchmark to deliver a super-optimization, but they've also got general dead code removal wrong.


From what I see, it seems like they want to have a dead code remover for ie9 but don't know how to do it properly (because in the case of dynamic languages it is tricky). In the meantime, they have a wrong implementation that also detects a specific benchmark and cuts some corners with it. I could almost bet this has something to do with a performance evaluation being linked to a benchmark score.


The part on the definition of Angles and that the "optimizer" should throw an exception it doesn't (most probably because it's not optimizing anything) is hilarious.

What are you talking about? That code is getting optimized away into a no-op when it shouldn't be, which is why no exception is thrown. This means that

a. the optimization is definitely happening

b. it is unsound


Unsound in a very specific and suspicious way - yesterday it was pointed out adding a single, do-nothing, line to the middle of the function makes the "optimizer" fail.

I also think the "for beginners" in the title is somewhat directed towards whoever implemented the "optimizer".


Unsound in a very specific and suspicious way - yesterday it was pointed out adding a single, do-nothing, line to the middle of the function makes the "optimizer" fail.

That isn't unsoundness, that's incompleteness. An optimization being incomplete means that something that could be optimized isn't -- one being unsound means that something that shouldn't be optimized is. These terms come from mathematical logic.


Sorry. I am an engineer. I got it as "not solid", "wrong", "flaky". I appears all three apply perfectly to the optimizer at hand. Being it both unsound (as it optimizes too much of a benchmark) and incomplete (as it doesn't recognize the invalidity of the code being optimized - the Angles thing - and fails to optimize too much when a no-op is added) we could just be more concise and settle for "broken".


I think you're still mixing up what "unsound" means. If I say that applying an optimization is unsound, it means that if I apply that optimization, I can no longer guarantee that the resulting code is semantically equivalent to the original code.

Being incomplete means the code you generate is not as fast as possible. Being unsound means the code you generate may be wrong. We don't normally call an optimizer "broken" if it does not optimize something even though we can recognize the optimization could be applied - no optimizer does every conceivable thing. But generated code that is not semantically equivalent to what was given violates correctness.


I think the "Angles" removal demonstrates the optimization is unsound. The "optimized" code gives out a result when a correctly optimized one would give a ReferenceError. This optimizer ignores invalid code (that references a non-existent thing) and happily short-circuits it.

The only reason to trust this code to do other optimizations well is all the evidence it's targeted at one specific benchmark.


The "optimization" looks like a peephole replacement of a delimited range of tokens, rather than an actual optimization of a particular code pattern. I think it's a bit of a stretch to call it an optimization; it really is more of a hack.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: