🚀 go-pugleaf

Grzegorz Staniak explained on 11/18/2010 :
> On 18.11.2010, Piotr B <p_borkowski@nospamgazeta.pl> wroted:
>
>>>>> The result though is startling – Internet Explorer 9 took around
>>>>> 20 times longer with the two new tests compared with the original.
>>>>> While the original took only 1ms in my laptop, the other two took
>>>>> around 20ms each.
>>>> 
>>>> Kolejny który nie słyszał o dead code elimination.
>>> 
>>> Chyba sobie jaja robisz. _Dwudziestokrotna_ różnica czasu wykonania 
>>> przez dodanie jednego właśnie nic nie robiącego "true" czy "return"? 
>>> Wolne żarty.
>> 
>> Dodanie return powoduje ten sam efekt co DCE[1]. Dodanie true, zmiana 
>> operatorów lub pętli, które jeszcze nie są w DCE zaimplementowane powoduje 
>> po prostu nie zadziałanie tej optymalizacji[2].
>
> Sorki, ale bzdurzysz. To byłaby optymalizacja, gdyby nie działała 
> w tym jednym bardzo ograniczonym przypadku. Ten cały cheald sprawdził 
> przecież analogiczne przypadki i ma rację pisząc:
>
>     It would be good code analysis if it applied in the general case.
>     That was my initial assumption too - that IE is doing the right
>     thing - but the fact that it fails to apply this same analysis in
>     other cases where the same conditions apply (no external scope
>     modified, no returns, etc) makes it feel awfully suspiciously like
>     it's cheating on the analysis of that function in particular.
>
> http://news.ycombinator.com/item?id=1915322
>
> Niestety, same twoje deklaracje to trochę za mało, żeby podważyć
> jego wnioski. Chcesz bronić honoru Microsoftu? Pokaż w jakich innych
> przypadkach działa ta sugerowana optymalizacja.
>

Ty czytałeś całą dyskusję? Masz tam przykłady modyfikacji kodu na których 
działa DCE, a nawet przykład innej funkcji na której przy jednym zapisie 
działa a przy innym nie.
http://news.ycombinator.com/item?id=1913497
http://news.ycombinator.com/item?id=1913527
http://news.ycombinator.com/item?id=1915380

Poza tym programiście Mozilli chyba wierzysz jak pisze że testowali: 
Regarding fragility, our investigations have shown that you can only use 
the operators -, +, ++, <<, +=, -=, and if(<). For example if you change 
this comparison inside math-cordic:
 if (TargetAngle > CurrAngle) { to
 if (TargetAngle <= CurrAngle) { then IE9 will no longer eliminate the 
code.

Więc akurat moje stwierdzenie okazuje się prawdziwe że po prostu DCE jest 
jeszcze bardzo zabugowane i nie w pełni zaimplementowane. Co nie jest 
dziwnym bo to jest beta 1.

>> Co do dwudziestokrotnej różnicy to jest ledwie 19ms (zmian z 1ms
>> na 20ms) więc tak się nie podniecaj. ;-)
>
> A jakież niby znaczenie ma sumaryczny czas? Istotna jest właśnie 
> wielkość różnicy między przypadkiem z "pustym return", a przypadkiem
> "zoptymalizowanym" -- praktycznie nieistniejąca w innych implementacjach
> JavaScriptu.

Widocznie inne implementacje nie usuwają martwego kodu dlatego nie ma 
różnicy. W przypadku IE9 bez return cała pętla for jest usunięta, zaś po 
dodaniu return za pętlą for DCE nie działa. Po prostu bug w implementacji 
DCE.

> Ty chcesz na poważnie dowodzić, że w przeciwieństwie do IE 
> Chrome i Opera nie optymalizują kodu JS?

Jeden z linków który podawałem dowodzi tego że nie korzystają w tym 
przypadku z DCE:

„In fact, if we just kill that for loop all together:
  --- tests/sunspider-0.9.1/math-cordic.js        2010-11-17 
00:55:29.000000000 -0700
  +++ tests/sunspider-0.9.1-deadcode/math-cordic.js       2010-11-17 
01:16:36.000000000 -0700
  @@ -62,20 +62,6 @@

       TargetAngle = FIXED(28.027);
       CurrAngle = 0;
  -    for (Step = 0; Step < 12; Step++) {
  - *snip for brevity*
  -    }
   }

We get the following times:

  Chrome: 8.9ms
      IE: 10.6ms”

Po ręcznym usunięciu pętli czas się zrównuje i widać na którym kawałku kodu 
DCE działa w której przeglądarce.

-- 
Piotr Borkowski