Pisze aplikację w której operuję na obrazkach, kod przed optymalizacja ręczną (tylko /O2) generował 8FPSów, po dokonaniu optymalizacji ręcznej doszedłem do 50FPSów (włączone /O2) z tym że tak działało tylko dla P4 1.8Ghz, kiedy odpaliłem zoptymalizowaną wersję na i5 2.4Ghz uzyskałem marne 11FPSów(!!) czemu tak się dzieje? Jak mogę to poprawić? =/
Kompilator visual c++ 2012
0
0
Rozumiem że mamy zgadywać CO ten kod w ogóle robi albo jakie "optymalizacje" zastosowałeś?
Odpal to sobie z profilerem i zobacz co zjada tyle czasu. Darmowy profiler to na przykład gprof
0
tu nie chodzi o co ten kod robi tylko dla czego P4 jest szybsze od i5 tym bardziej że taktowanie P4 jest znacznie mniejsze niż i5. Optymalizacja ręczna polegała na wywaleniu operacji na liczbach zmiennoprzecinkowych i zastosowanie tylko typów int oraz long + proste przekształcenie obliczeń tak zeby wywlec do przeliczeń wstępnych jak najwięcej kodu. Tyle. Kompilacja pod P4 optymalizuje się świetnie, dla i5 praktycznie bez roznicy czy jest /O2 czy nie.
0
na float nie ma żadnej zmiany dla obu procesorów. Inty znacznie szybciej działają na P4 natomiast na i5 przyśpiesza ledwo co. Jezeli na float i5 nie działa szybciej, ani na intach nie działa szybciej to co to za syf? Z tego co wyczytałem to cała optymalizacja x86 jest o du*e rozbić dla i5...
0
Odpal profiler zamiast kombinować i gdybać.
0
nie, nic z nim nie robiłem. Jest jakiś zbiór wytycznych dla i5, jak należy pisać optymalny kod? Ewidentnie kompilatory sobie nie radzą, podobno zniknęło sporo instrukcji procesora które były dostępne w P4.
0
podobno zniknęło sporo instrukcji procesora które były dostępne w P4
Żartujesz sobie? Z biegiem lat do x86 dodawano masę rozszerzeń, instrukcji jest coraz więcej.
0
wiem jaka metoda jest "wolna", jej wywołanie zajmuje 0,02ms z tym że wywoływana jest 18432 dla bitmapy 1024x768. P4 sobie świetnie z nią radzi natomiast i5 jest fatalne. Metoda operuje na wycinku (w,h = w) bitmapy z pozycji (x,y), wycinki są bardzo małe liczba obliczeń wynosi w^4 na wycinek. Niestety nie da sie nic z tym więcej zrobić.
0
znalazłem taki cytat:
"My guess is that the developer of this program put it together with specific optimizations for the P4 (family 7 CPU). When Intel released the C2D, they went back to family 6 (and stayed there) which may mean that newer instructions sets introduced on the P4 are not being used. This way of detecting processor features is completely wrong and Intel makes this blatantly obvious if the programmer ever glanced at an x86 optimization guide from Intel."
0
nie, nic z nim nie robiłem. Jest jakiś zbiór wytycznych dla i5, jak należy pisać optymalny kod?
@deus poleciłby manuale Intela, ja polecam http://agner.org/optimize/ bo sam kiedyś z tego korzystałem.
0
dsadf napisał(a):
znalazłem taki cytat:
"My guess is that the developer of this program put it together with specific optimizations for the P4 (family 7 CPU). When Intel released the C2D, they went back to family 6 (and stayed there) which may mean that newer instructions sets introduced on the P4 are not being used. This way of detecting processor features is completely wrong and Intel makes this blatantly obvious if the programmer ever glanced at an x86 optimization guide from Intel."
Tutaj chodzi o detekcję procesora w oparciu o numer "Family", co jest błędne, bo one nie rosną tylko pomiędzy NetBurst a Core jest przeskok i to nie w spodziewaną stronę. Wg rzeczonego poradnika Intela jest to przeskok z 15 na 6. Chodzi o to, że jeżeli ktoś określa model procesora w oparciu o ten numer i na tej podstawie optymalizuje to robi to źle. Nie wydaje mi się, żeby to był Twój problem, to kwestia kompilatora a on raczej poprawnie wykrywa procesor.
1
Pentium 4 to bardzo specyficzna (i nieudana) linia procesorów, wiele specyficznych zasad optymalizacji działa zwyczajnie kiepsko na innych procesorach. Po Pentium III byłem "szczęśliwym" posiadaczem P4, procesora tak specyficznego, że na moim procesorze jeden algorytm chodził 2x szybciej niż drugi, na procesorze AMD kumpla (i nowszych Intelach) zazwyczaj pierwszy był minimalnie wolniejszy od drugiego. Bardzo ciężko powiedzieć coś konkretnego bez znajomości kodu i porównania specyfikacji rodzin.
0
w aplikacji dość intensywnie korzystam z cache(a raczej polegam na nim), widzę ze jeżeli zamienię operacje dostępu do pamięci na jakieś obliczenia to zyskuje drastyczny wzrost wydajności. Zastanawiam sie czy to nie wina hyper threading. Czy da się to jakoś obejść, nie licząc wyłączenia HT w bios? (niestety u mnie nie ma takiej opcji w bios więc nie jestem w stanie sprawdzić czy to ten problem na 100%)
0
może chodzi to o "cache miss" albo o predykcję skoków (branch prediction) i stąd pojawia się taka różnica.
Stawiam na predykcję skoków.
0
podobno zniknęło sporo instrukcji procesora które były dostępne w P4
Żartujesz sobie? Z biegiem lat do x86 dodawano masę rozszerzeń, instrukcji jest coraz więcej.
Zniknęło kilka śmieciowych instrukcji, jak AAA oraz kilka alternatywnych kodów istniejących instrukcji, ale tylko w trybie 64-bitowym.
Cięcia były po to, żeby zwolnić kody na prefiksy (tzw. RAX) wyznaczające nowe 64-bitowe rejestry.
Wszystkie te instrukcje jednak nadal są dostępne dla 32- i 16-bitowych programów, na tym samym procesorze.
z pretensjami do AMD, x64 to ich, nie Intela wynalazek.