Dlaczego optymalizacja GCC spowalnia STL algorithms?

Question

Cześć.

Czytając to można zauważyć, że bez optymalizacja szybkość wykonywania każdej operacji w przypadku STL jest za każdym razem szybsza od SOI czy ranges, jednak gdy w przypadku GCC użyjemy optymalizacji (choćby 1 poziomu, to szybkość diametralnie się zwiększa i wygrywają zewnętrzne biblioteki (choć ranges chyba jest w standardzie, ale dziwnie to wygląda). Dlaczego ta zmiana jest na złe, choć jest to optymalizacja, a autora to nie dziwi (tak, jakby tak właśnie powinno być)? 

 

Comments

Gdzie widzisz że spowalnia? Ja na oko widzę że optymalizacja wszędzie pomaga, tylko w niektórych przypadkach jedna biblioteka zyskuje bardziej niż inna.

---

"ratio CPU time / Noop time
Lower is faster"

---

@Hiskiel chodzi Ci o różnice pomiędzy O2 i O3 na pierwszych dwóch wykresach czy o to, że słupki są nagle wyższe (przynajmniej tak bym to dosłownie rozumiał sugerując się tylko tytułem)? Spróbuj wytłumaczyć o co chodzi na konkretnym przykładzie.

---

Nie rozumiem, czego nie rozumiecie.. Są pokazane 4 wykresy z każdych algorytmów dla GCC - z optymalizacją 0,1,2 i 3. Bez optymalizacji słupek pokazujący szybkość dla STL jest najmniejszy, za to z optymalizacją słupki nagle rosną i STL nagle wykonuje się kilka razy wolniej. Spójrz tylko na podlinkowany artykuł.

---

@Hiskiel porównaj wartości na przedziałkach.

---

Nie było tematu, dzięki.

---

Ok każdy może się pomylić. Tak na marginesie dodam, że czasami O2 może być trochę szybsze od O3, Skuteczność optymalizacji jest zależna od procesora. Niektóre instrukcje mogą być dla jednych bardziej skuteczne, a inne mniej. Zazwyczaj twórcy kompilatorów starają się znaleźć złoty środek, ale nie można dogodzić każdemu.