🚀 go-pugleaf

Tomasz Chmielewski presented the following explanation :
> http://digitizor.com/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/
>
> While Mozilla engineer Rob Sayre was benchmarking Firefox 4 with different 
> browsers, he noticed something with Internet Explorer 9 – Internet Explorer 9 
> was around 10 times faster than the other browsers in a particular test 
> (math-cordic) in the SunSpider benchmark. While Chrome and Opera scored took 
> around 10ms in that test, Internet Explorer 9 finished it it in about 1ms.
>
> Sayre investigated further by modifying the code for that test used in the 
> SunSpider Benchmark a bit. He made two variations of the test little bits of 
> codes to the original – one by adding a “true” and another by adding a 
> “return”. As these “true” and “return” in this context does not do anything 
> there should be minimal impact.
>
> 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.

-- 
Piotr Borkowski

On 18.11.2010 16:44, Piotr B. (pb2004) wrote:
> Tomasz Chmielewski presented the following explanation :
>> http://digitizor.com/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/
>>
>>
>> While Mozilla engineer Rob Sayre was benchmarking Firefox 4 with
>> different browsers, he noticed something with Internet Explorer 9 –
>> Internet Explorer 9 was around 10 times faster than the other browsers
>> in a particular test (math-cordic) in the SunSpider benchmark. While
>> Chrome and Opera scored took around 10ms in that test, Internet
>> Explorer 9 finished it it in about 1ms.
>>
>> Sayre investigated further by modifying the code for that test used in
>> the SunSpider Benchmark a bit. He made two variations of the test
>> little bits of codes to the original – one by adding a “true” and
>> another by adding a “return”. As these “true” and “return” in this
>> context does not do anything there should be minimal impact.
>>
>> 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.

Ba, rowniez madrzejsi robiacy analize tego nie slyszeli o dead code 
elimination robiacym eliminacje skomplikowanego kodu, a wywalajacym sie 
na banalnej modyfikacji tegoz.


-- 
Tomasz Chmielewski
http://wpkg.org

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.

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>
= AC Universe.:JumpTheGun:. =  85.14.221.102:27960  
= Urban Terror TDM Server = no snipers, no camping,
no spam voting, no console noise...  just pure fun.

Tomasz Chmielewski formulated the question :
> On 18.11.2010 16:44, Piotr B. (pb2004) wrote:
>> Tomasz Chmielewski presented the following explanation :
>>> http://digitizor.com/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/
>>>
>>>
>>> While Mozilla engineer Rob Sayre was benchmarking Firefox 4 with
>>> different browsers, he noticed something with Internet Explorer 9 –
>>> Internet Explorer 9 was around 10 times faster than the other browsers
>>> in a particular test (math-cordic) in the SunSpider benchmark. While
>>> Chrome and Opera scored took around 10ms in that test, Internet
>>> Explorer 9 finished it it in about 1ms.
>>>
>>> Sayre investigated further by modifying the code for that test used in
>>> the SunSpider Benchmark a bit. He made two variations of the test
>>> little bits of codes to the original – one by adding a “true” and
>>> another by adding a “return”. As these “true” and “return” in this
>>> context does not do anything there should be minimal impact.
>>>
>>> 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.
>
> Ba, rowniez madrzejsi robiacy analize tego nie slyszeli o dead code 
> elimination robiacym eliminacje skomplikowanego kodu, a wywalajacym sie na 
> banalnej modyfikacji tegoz.

To już wyszła finalna wersja IE9, że oczekujesz że wszystkie błędy zostały 
naprawione?

-- 
Piotr Borkowski

Grzegorz Staniak formulated the question :
> 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]. Co do dwudziestokrotnej 
różnicy to jest ledwie 19ms (zmian z 1ms na 20ms) więc tak się nie 
podniecaj. ;-)

1. http://news.ycombinator.com/item?id=1913368
2. 
http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/

-- 
Piotr Borkowski

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.

> 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. Ty chcesz na poważnie dowodzić, że w przeciwieństwie do IE 
Chrome i Opera nie optymalizują kodu JS?

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>
= AC Universe.:JumpTheGun:. =  85.14.221.102:27960  
= Urban Terror TDM Server = no snipers, no camping,
no spam voting, no console noise...  just pure fun.

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

On Nov 18, 7:53 pm, Grzegorz Staniak <gstan...@gmail.com> wrote:
> On 18.11.2010, Piotr B <p_borkow...@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

Z mikrooptymalizacja kodu to właśnie jest tak, że raz działa,  raz nie
działa, i czasami nie bardzo wiadomo dlaczego. Rozumiem, że sam nie
programujesz zawodowo więc się z tym nie spotkałeś, ale ja mam z tym
do czynienia na codzień, i zapewniam Cię, że takie analizy jak Twoja
są OKDR.

Dowodem na oszustwo w IE9 byłoby, gdyby zmiana nazwy funkcji wpływała
na jej czas wykonania. na przykład.

RW

In the darkest hour on Thu, 18 Nov 2010 16:44:15 +0100,
Piotr B <p_borkowski@nospamgazeta.pl> screamed:
>> 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.
>

Od kiedy dołożenie "return;" wyłącza dce?

-- 
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:239B ]
[ 21:07:40 user up 12627 days,  9:02,  1 user, load average: 0.50, 0.38, 0.12 ]

 I refuse to answer that question on the grounds that I don't know the answer.

Artur M. Piwko was thinking very hard :
> In the darkest hour on Thu, 18 Nov 2010 16:44:15 +0100,
> Piotr B <p_borkowski@nospamgazeta.pl> screamed:
>>> 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.
>> 
>
> Od kiedy dołożenie "return;" wyłącza dce?

Niepełna z błędami implementacja.

-- 
Piotr Borkowski

In the darkest hour on Sun, 21 Nov 2010 14:33:54 +0100,
Piotr B <p_borkowski@nospamgazeta.pl> screamed:
>>>> 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.
>>
>> Od kiedy dołożenie "return;" wyłącza dce?
>
> Niepełna z błędami implementacja.
>

To jedyna logiczna w tym przypadku wersja oficjalna. Ja jej nie kupuję.

-- 
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:218B ]
[ 17:01:56 user up 12628 days,  4:56,  1 user, load average: 0.63, 0.50, 0.06 ]

                      Sacred cows make the best hamburger

Artur M. Piwko pretended :
> In the darkest hour on Sun, 21 Nov 2010 14:33:54 +0100,
> Piotr B <p_borkowski@nospamgazeta.pl> screamed:
>>>>> 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.
>>> 
>>> Od kiedy dołożenie "return;" wyłącza dce?
>> 
>> Niepełna z błędami implementacja.
>> 
>
> To jedyna logiczna w tym przypadku wersja oficjalna. Ja jej nie kupuję.

Ale co nie kupujesz? Developer Mozilli opisał luki implementacji DCE w IE9.

-- 
Piotr Borkowski

In the darkest hour on Sun, 21 Nov 2010 18:42:22 +0100,
Piotr B <p_borkowski@nospamgazeta.pl> screamed:
>>>>>> 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.
>>>> 
>>>> Od kiedy dołożenie "return;" wyłącza dce?
>>> 
>>> Niepełna z błędami implementacja.
>>
>> To jedyna logiczna w tym przypadku wersja oficjalna. Ja jej nie kupuję.
>
> Ale co nie kupujesz? Developer Mozilli opisał luki implementacji DCE w IE9.
>

Jak napisałem wyżej. Wersji oficjalnej MS.

-- 
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:221B ]
[ 08:02:37 user up 12629 days, 19:57,  1 user, load average: 0.75, 0.61, 0.02 ]

                   You still need the last file you removed.

On Nov 22, 7:03 am, "Artur M. Piwko" <milusi.pysiac...@buziaczek.pl>
wrote:
> In the darkest hour on Sun, 21 Nov 2010 18:42:22 +0100,
> Piotr B <p_borkow...@nospamgazeta.pl> screamed:
>
> >>>>>> 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.
>
> >>>> Od kiedy dołożenie "return;" wyłącza dce?
>
> >>> Niepełna z błędami implementacja.
>
> >> To jedyna logiczna w tym przypadku wersja oficjalna. Ja jej nie kupuję.
>
> > Ale co nie kupujesz? Developer Mozilli opisał luki implementacji DCE w IE9.
>
> Jak napisałem wyżej. Wersji oficjalnej MS.

Zapewne dlatego, ze to wersja oficjalna MS ;-)

RW