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
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.
Comments
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.