Jakie są rozmiary LParam i WParam w win64?
Czyżby wpram ma 32 bity, a Lparam 64?
To byłby w zasadzie powrót do 16-bitowej wersji windows, czyli win16, bo tam tak było:
Lparam jako far wskaźnik - 32 bity, a ten wparam to integer - 16 bit.
0
0
http://blogs.msdn.com/b/oldnewthing/archive/2011/06/29/10181137.aspx
Nie wiem co to znaczy, ale tutaj wygląda na to że jest dobrze opisane.
Szczególnie pierwsze zdanie : The integral types WPARAM, LPARAM, and LRESULT are 32 bits wide on 32-bit systems and 64 bits wide on 64-bit systems.
0
WPARAM jest unsigned long long
LPARAM jest long long
0
Myślałem że ten wparam to int.
A współrzędne przy grafice jakie są: pozostaje 32 bit, czy też aż 64?
Chodzi mi głównie o te struktury POINT, które figurują w Polygon, Polyline, PolyBezier, itd.
Trochę przesada używać tu 64bity, a pewnie tak jest;
koordynaty na ekranie, czy wydruku: -trylion do trylion... głupota - marnotrawstwo ramu.
0
To ma być dokumentacja?
Nieczytelne dziadostwo.
Już prędzej znalazłbym to wprost w tym wintypes.h
Jest dostępna jakaś inna wersja tej dokumentacji - w innym formacie?
0
- jeśli masz 64-bitowy system i kompilator, to dlaczego nie zrobisz
cout << sizeof(WPARAM)i będziesz wiedział. - a jeśli nie masz, to właściwie na co ci ta wiedza? ;-)
-
POINTto są dwa pola 32-bitowe ze znakiem niezależnie od architektury. - nie wiem czemu się czepiasz dokumentacji: jest dobra. nie wspaniała, ale dobra. kiedyś co prawda była lepsza nawigacja, ale treść generalnie od zawsze ta sama. tę samą dokumentację można też mieć offline, jako help do Visual Studio.
0
Azarien napisał(a):
- jeśli masz 64-bitowy system i kompilator, to dlaczego nie zrobisz
cout << sizeof(WPARAM)i będziesz wiedział.
Nie robiłem programów na 64.
Azarien napisał(a):
- a jeśli nie masz, to właściwie na co ci ta wiedza?
Po to żeby oszacować koszty przerobienia gotowej aplikacji 32 na 64.
Azarien napisał(a):
POINTto są dwa pola 32-bitowe ze znakiem niezależnie od architektury.
w win16 koordynaty są 16 bitowe, więc zależy.
Azarien napisał(a):
- nie wiem czemu się czepiasz dokumentacji: jest dobra. nie wspaniała, ale dobra. kiedyś co prawda była lepsza nawigacja, ale treść generalnie od zawsze ta sama. tę samą dokumentację można też mieć offline, jako help do Visual Studio.
Mam SDK, ale sprzed kilku lat i tam dokumentacja jest przejrzysta, czytelna i pełna, zwięzła i szybka - momentalna.
Tego jest chyba tylko ze 100 MB, i do tego razem z dokumentacją: OpenGL, DirectX, GDI+ i kilku innych.
To coś w Vis Studio, co nazywasz helpem, ma się do tego jak... śmietnisko miejskie w dzielnicy biedoty w Bangladeszu w porównaniu do laboratorium w CERN.
0
Po to żeby oszacować koszty przerobienia gotowej aplikacji 32 na 64.
Koszty niewielkie. Trzeba dopilnować by program nigdzie nie zakładał, że w incie zmieści się wskaźnik.
W prawidłowo napisanym kodzie zmian nie trzeba wcale albo trzeba bardzo mało (np.GetWindowLongzamienić naGetWindowLongPtr, pamiętać że taki DialogProc ma zwracaćINT_PTRa nieBOOL). Po przeróbkach kod się będzie kompilował zarówno w trybie 64- jak i 32-bitowym.
Mam SDK, ale sprzed kilku lat i tam dokumentacja jest przejrzysta, czytelna i pełna, zwięzła i szybka - momentalna.
Być może, ale niestety – przestarzała. Kodu napisanego zgodnie z aktualną dokumentacją nie trzeba przerabiać do 64 bitów, bo będzie kompatybilny.
PS. dokumentacja może ci się nie podoba, ale naprawdę tam wszystko jest:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb427430(v=vs.85).aspx/html
0
Azarien napisał(a):
W prawidłowo napisanym kodzie zmian nie trzeba wcale albo trzeba bardzo mało (np.
GetWindowLongzamienić naGetWindowLongPtr, pamiętać że taki DialogProc ma zwracaćINT_PTRa nieBOOL). Po przeróbkach kod się będzie kompilował zarówno w trybie 64- jak i 32-bitowym.
No to sobie pisz takie 'prawidłowe', a potem się pewnie okaże że 64 będą wolniejsze... tak z 3 razy, a w tym .net z 25 razy, bo to widać po programach.
Być może, ale niestety – przestarzała. Kodu napisanego zgodnie z aktualną dokumentacją nie trzeba przerabiać do 64 bitów, bo będzie kompatybilny.
Nie ma tam jeszcze nic przestarzałego, tylko brakuje wersji do 64.
To jest chyba do XP, a potem praktycznie nic nie zrobili - co by mnie interesowało.
PS. dokumentacja może ci się nie podoba, ale naprawdę tam wszystko jest:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb427430(v=vs.85).aspx/html
Dobry przykład. Właśnie tak wygląd ta dokumentacja:
puste, rozwleczone - ogólnikowe i bezprzedmiotowe wodolejstwo niemal na każdej stronie.
Mnie takie autoreklamy Microsoft nie interesują.
To jest robota hurtowa - pewnie oni tam płacą autorom tej dokumentacji 1$ za kb, i stąd takie efekty.
0
No to sobie pisz takie 'prawidłowe', a potem się pewnie okaże że 64 będą wolniejsze... tak z 3 razy
Nie wiesz, o czym piszesz.
Mam SDK, ale sprzed kilku lat i tam dokumentacja jest przejrzysta, czytelna i pełna, zwięzła i szybka - momentalna.
Czy to nie jest przypadkiem dokumentacja z C++ Buildera?
0
Wersje 64 bitowe programów przerabianych tak wprost - przekompilowanych tylko z 32 są wolniejsze,
z powodu dłuższych danych, pewnie głównie wskaźników i operacji na stosie.
Niektóre instrukcje trwają tam dłużej, np. dzielenie 64 bitowych liczb wymaga więcej cykli niż dla 32 bitowych.
Może na dobrym kompilatorze byłoby inaczej, ale takich chyba nie ma i raczej już nie będzie.
Epoka optymalizacji kompilatorów zakończyła się jakiś czas temu, a teraz jest masówka - wystarczy zajrzeć w ten produkowany kod i to widać.
Czy to nie jest przypadkiem dokumentacja z C++ Buildera?
Nie, to jest SKD z MS.
Builder ma swoje dokumentacje - głównie do tego vcl, a nie do funkcji i struktur windowsa.
No, ale sprawdziłem ten nowszy SDK z VS i tam nawet dobrze jest.
Gdy wchodzimy prosto w MSDN z przeglądarki, wtedy trafiam się zwykle w ten reklamiarski kit.
0
Wersje 64 bitowe programów przerabianych tak wprost - przekompilowanych tylko z 32 są wolniejsze, z powodu dłuższych danych, pewnie głównie wskaźników i operacji na stosie.
A masz na to jakieś dowody, źródła, wyniki pomiarów?
Poza tym, jeśli nie masz konkretnego powodu by kompilować program jako 64-bitowy to po prostu tego nie rób, zapomnij o problemie, zaparz sobie herbatkę…
Gdy wchodzimy prosto w MSDN z przeglądarki, wtedy trafiam się zwykle w ten reklamiarski kit.
Jak zamierzasz marudzić to rób to w dziale Flame.
0
Wersje 64 bitowe programów przerabianych tak wprost - przekompilowanych tylko z 32 są wolniejsze, z powodu dłuższych danych, pewnie głównie wskaźników i operacji na stosie.
Jakich danych? Jedyne co tam tak naprawdę w sposób istotny się zmienia to wielkość wskaźnika, i nie sądzę, żeby większy wskaźnik miał wpływ na ogólną szybkość działania aplikacji.
Niektóre instrukcje trwają tam dłużej, np. dzielenie 64 bitowych liczb wymaga więcej cykli niż dla 32 bitowych.
Nie wiem jak tam z tymi cyklami jest - nie chce mi się tego teraz sprawdzać - ale jakie to ma znaczenie? Przecież jeśli jest coś do podzielenia czy pomnożenia, to i tak musi być wykonane, niezależnie na którą platformę kompilowana jest aplikacja. Ewentualny narzut jest zapewne pomijalnie mały, zatem pisanie, że kod po przekompilowaniu na 64-bity będzie 3x wolniejszy, jest absurdalne i raczej nie świadczy o dobrej znajomości tematu
Builder ma swoje dokumentacje - głównie do tego vcl, a nie do funkcji i struktur windowsa.
Miał też dokumentację WinAPI, która w sumie była tylko wycinkiem tego, co oferowało PSDK microsoftu. No ale nieważne...
0
Builder ma swoje dokumentacje - głównie do tego vcl, a nie do funkcji i struktur windowsa.
Visual też. Nazywają się ogólnie msdn i jako, że ważą dziesiątki milionów bajtów to panowie z MS nie udostępniają ich offline. Zrobili zamiast tego narzędzie do ściągnięcia tylko tego co uznasz za potrzebne.
Niektóre instrukcje trwają tam dłużej, np. dzielenie 64 bitowych liczb wymaga więcej cykli niż dla 32 bitowych.
Nie mam pojęcia skąd wziąłes informacje o wolniejszym dzieleniu i nie chce mi się przeszukiwać dokumentacji intela, żeby to sprawdzić. Dla uproszczenia założę, że to prawda.
Dzieląc na procesorach x64 możemy bez utraty wydajnośći używać double zamiast float (mieści się w jednym rejestrze koprocesora - x86 musiał kombinować). Float może być wydajniejsze jedynie jeśli operujemy jednocześnie na więcej niż 16 zmiennych (bo tyle wchodzi na stos SSEx64) - sprytny kompilator zamiast operować na pamięci może do jednego rejestru wrzucić 2 floaty (zostawiając conajmniej 2 rejestry na operacje - w procesorach x32 masz tych rejestrów (dla floatów) 8). Jeśli na procesorze x64 operujemy na float'ach kompilator (nie jestem pewien, czy nie zostało to w jakiś sposób poprawione - stąd czas przeszły) zamieniał float na double, operował na double, konwertował z powrotem na float i zapisywał do pamięci. Pytanie brzmii kiedy opłaca się wrzucać do jednego rejestru 2 floaty. Potrzeba dodatkowych operacji na wyłuskanie połowy rejestru. Także na potrzeby dyskusji uznajmy, że żaden kompilator tego nie zrobi, bo to jest be, wolniejsze niż x32 i w ogóle bez sensu.
Stanęliśmy na tym, że dzielenie FLOATÓW(!) na x32 faktycznie jest wolniejsze, bo następuje podwójna konwersja. Należy jednak pamiętać, że konwersja ta ma miejsce tylko w momencie wczytania zmiennej z pamięci i zapisania jej do pamięci. Dla przykładu:
float zmienna = 0;
for(int i = 0; i < 10; ++i)
{
zmienna += 0.1f;
}
W tym kodzie konwersja następuje 2 razy. Czy to faktycznie daje chociażby o połowe wolniejsze rezultaty? Ile razy w swoim programie wykonujesz dzielenie? A gratis masz 2 razy więcej rejestrów procesora (do których masz błyskawiczny dostęp), co pozwala przyspieszyć wszystkie obliczenia. Zresztą co ja się rozpisuję - pewnie i tak mi nie uwierzysz.
Wyniki benchmarka z 2005 roku wykonanego w Performance Test 6:
TEST: CPU - Integer Math
PT6 64bit, Win2003 64bit, Result = 193.3
PT6 32bit, Win2003 64bit, Result = 92.9
PT6 32bit, WinXP 32bit, Result = 92.9TEST: CPU - Find Prime Numbers
PT6 64bit, Win2003 64bit, Result = 217.7
PT6 32bit, Win2003 64bit, Result = 158.2
PT6 32bit, WinXP 32bit, Result = 157.9TEST: CPU - Data compression
PT6 64bit, Win2003 64bit, Result = 2584.6
PT6 32bit, Win2003 64bit, Result = 2578.6
PT6 32bit, WinXP 32bit, Result = 2582.77
źródło: http://www.passmark.com/forum/showthread.php?261-Comparing-64bit-and-32bit-CPU-benchmark-results
Jeśli chcesz mogę rozpisać program do testów tylko i wyłącznie dzielenia (zaprojektowany na x32), żebyś mógł przetestować go na swoim x64 i opublikować wyniki.
nie sądzę, żeby większy wskaźnik miał wpływ na ogólną szybkość działania aplikacji.
A dlaczego miałby mieć? Po prostu jest wrzucany do większego rejestru procesora.
0
0x666 napisał(a):
Jakich danych? Jedyne co tam tak naprawdę w sposób istotny się zmienia to wielkość wskaźnika, i nie sądzę, żeby większy wskaźnik miał wpływ na ogólną szybkość działania aplikacji.
Samo to może istotnie obniżyć wydajność podczas manipulacji na złożonych i dużych strukturach -
listy wskaźników, różne drzewa, sieci, itp.; jest tego pełno w stl.
W programikach do wyświetlania 'Hello babe i'm win 64!' lub obrazków, nie będzie oczywiście dużej różnicy,
no ale w obliczeniach numerycznych, symulacjach procesów fizycznych, w problemach optymalizacji, może być już istotny spadek szybkości.
Nie wiem jak tam z tymi cyklami jest - nie chce mi się tego teraz sprawdzać - ale jakie to ma znaczenie? Przecież jeśli jest coś do podzielenia czy pomnożenia, to i tak musi być wykonane, niezależnie na którą platformę kompilowana jest aplikacja. Ewentualny narzut jest zapewne pomijalnie mały, zatem pisanie, że kod po przekompilowaniu na 64-bity będzie 3x wolniejszy, jest absurdalne i raczej nie świadczy o dobrej znajomości tematu
Złożone operacje trwają zwykle proporcjonalnie do n^2, n - liczba bitów argumentów.
No, ale konstruktorzy o tym wiedzą, więc próbują to redukować, i zwykle jest trochę lepiej,
co można właśnie wykorzystać do przyspieszania algorytmów, które liczą na krótszych danych.
Po prostym przekompilowaniu będzie zazwyczaj odwrotnie: to co było 32 jest teraz 64 tyle że z wyzerowaną górną połową,
co nie ma tu znaczenia, więc jedzie wolniej.
Albo i odwrotnie: kod 32 bitowy, który obliczał na 64 bitowych, lub dłuższych, liczbach jeszcze zwolni
po bezpośrednim przekompilowaniu na 64, ale po zaprogramowaniu całego algorytmu od nowa
na 64 bitowy procesor będzie już zasuwał znacznie szybciej.
0x666 napisał(a):
Builder ma swoje dokumentacje - głównie do tego vcl, a nie do funkcji i struktur windowsa.
Miał też dokumentację WinAPI, która w sumie była tylko wycinkiem tego, co oferowało PSDK microsoftu. No ale nieważne...
Kiedyś był tam dołączany fragment SDK, a teraz to nie wiem co tam jest... pewnie nic.
0
Złożone operacje trwają zwykle proporcjonalnie do n^2, n - liczba bitów argumentów.
To dlaczego procesor x64 pozwala na operacje na większych liczbach? Według Twojego rozumowania moglibyśmy pracować na procesorach x1, które mają 1024 rejestry (ilość bitów w rejestrach wychodzi taka sama jak przy procesorach x64) i nie zauważylibyśmy różnicy w wydajności. Przecież nie liczy się liczba cyklów maszynowych tylko ilość bitów na których operujemy. BA! Przecież to by było o wiele szybsze! Żeby zapisać jakąś liczbę pobieralibyśmy dokładnie tyle bitów ile potrzebujemy. Chcemy powiększyć liczbę poza zasięg tych bitów, które już wzieliśmy? Żaden problem! Bierzemy jeszcze jeden rejestr. To nic, że kod asm wyglądałby tak samo czytelnie jak kod maszynowy. Przecież od tego jest C++. Ale za to wydajność wzrosłaby o kilkaset procent. Przecież wyrównanie pamięci i rozmiaru, a także rejestry x64 to jakiś bezcelowy wymysł.
No, ale konstruktorzy o tym wiedzą, więc próbują to redukować, i zwykle jest trochę lepiej,
co można właśnie wykorzystać do przyspieszania algorytmów, które liczą na krótszych danych.
0
Samo to może istotnie obniżyć wydajność podczas manipulacji na złożonych i dużych strukturach - listy wskaźników, różne drzewa, sieci, itp.; jest tego pełno w stl.
Idąc tym tokiem rozumowania, procesory 16-bitowe powinny być wydajniejsze od 32-bitowych ;)
no ale w obliczeniach numerycznych, symulacjach procesów fizycznych, w problemach optymalizacji, może być już istotny spadek szybkości.
Mało prawdopodobne. Przypominam, że cały czas mowa o kodzie napisanym w C.
0
Azarien napisał(a):
A masz na to jakieś dowody, źródła, wyniki pomiarów?
Masz dowody: Księżyca nie ma w dzień, bo go nie widzisz, a c jest stałe bo światło zawsze widać.
0
0x666 napisał(a):
Idąc tym tokiem rozumowania, procesory 16-bitowe powinny być wydajniejsze od 32-bitowych ;)
Tam było inaczej: adresy były i tak 32 bits, bo na 64KB danych niedaleko zajedziesz.
Programy 16 bitowe zwykle szybciej chodzą na starych windowsach, ale to inna sprawa.
no ale w obliczeniach numerycznych, symulacjach procesów fizycznych, w problemach optymalizacji, może być już istotny spadek szybkości.
Mało prawdopodobne. Przypominam, że cały czas mowa o kodzie napisanym w C.</quote>
Pewne.
0
no ale w obliczeniach numerycznych, symulacjach procesów fizycznych, w problemach optymalizacji, może być już istotny spadek szybkości.
Mało prawdopodobne. Przypominam, że cały czas mowa o kodzie napisanym w C.
Pewne.
Nieprawda! - taki sam argument.
0
Używając 64 bitowych instrukcji mnożenie 32bitowych liczb można przyspieszyć 4x razy.
A gdy zrobimy wg zaleceń dzieciaków z MS, czyli ciachniemy jeden - jakiś tam przenośny kody, wtedy będzie tak:
a = b*c,
i tu mnożymy 32 albo 64, co nie ma znaczenia, bo mnożenie trwa tyle samo na 64,
no ale tu dojdą pewne straty na ładowanie dwa razy większych danych do rejestrów z ram,
zwłaszcza gdy mamy tego dużo, i na 64 będzie wolniej, ale niewiele.
Ale przy dzieleniu będzie już prawie 4 razy wolniej.
0
Liczy się czas dostępu, a nie ilość odczytywanych danych DDR 2 ma magistralę 64bit. Wiesz co to znaczy?
0
wader napisał(a)
Programy 16 bitowe zwykle szybciej chodzą na starych windowsach, ale to inna sprawa.
Starego Windowsa masz na starym komputerze, więc nie ma co porównywać.
Ola Nordmann napisał(a)
Nazywają się ogólnie msdn i jako, że ważą dziesiątki milionów bajtów to panowie z MS nie udostępniają ich offline. Zrobili zamiast tego narzędzie do ściągnięcia tylko tego co uznasz za potrzebne.
Coś się plączesz. Skoro można ściągnąć (zarówno spod Visual Studio jak i osobnym narzędziem) to znaczy że udostępniają.
Dzieląc na procesorach x64 możemy bez utraty wydajnośći używać double zamiast float (mieści się w jednym rejestrze koprocesora - x86 musiał kombinować
Rejestry koprocesora x87 mają 80 bitów, więc spokojnie się zarówno float i double mieszczą. Nie rozumiem o jakich kombinacjach mówisz.
@wader: pokaż ten kod, który ci chodzi 3x wolniej pod x64. Bo albo tylko bezsensownie hejcisz, albo masz konkretny problem: a wtedy zapewniam, jest on w twoim kodzie, a nie w procesorze.
0
Ola Nordmann napisał(a):
Złożone operacje trwają zwykle proporcjonalnie do n^2, n - liczba bitów argumentów.
To dlaczego procesor x64 pozwala na operacje na większych liczbach? Według Twojego rozumowania moglibyśmy pracować na procesorach x1, które mają 1024 rejestry (ilość bitów w rejestrach wychodzi taka sama jak przy procesorach x64) i nie zauważylibyśmy różnicy w wydajności. Przecież nie liczy się liczba cyklów maszynowych tylko ilość bitów na których operujemy. BA! Przecież to by było o wiele szybsze! Żeby zapisać jakąś liczbę pobieralibyśmy dokładnie tyle bitów ile potrzebujemy. Chcemy powiększyć liczbę poza zasięg tych bitów, które już wzieliśmy? Żaden problem! Bierzemy jeszcze jeden rejestr. To nic, że kod asm wyglądałby tak samo czytelnie jak kod maszynowy. Przecież od tego jest C++. Ale za to wydajność wzrosłaby o kilkaset procent. Przecież wyrównanie pamięci i rozmiaru, a także rejestry x64 to jakiś bezcelowy wymysł.
I w zasadzie tak jest - dużo rejestrów przyspiesza obliczenia, i tylko dzięki temu te przekompilowywane żywcem przenośnie kody nie chodzą drastycznie wolniej, lecz prawie tak samo, czyli tu jest zero zysku z 64 bitowej maszyny.
W tym przypadku te 2 razy większe rejestry degradują, ale jest ich 2 razy więcej co kompensuje straty i jest to samo: +/- 5%.
A w przypadku kodu dedykowanego jest tak: + 200% + rozrzut też +/-200%.
0
@Azarien
msdn w Visualu:
Może nie konkretnie się wyraziłem - taki skrót myślowy. Chciałem napisać, że nie udostępniają ich z instalacją VS.
double/float, rejestry koprocesora:
No tak - dałem ciała. Teraz nie rozumiem swoich benchmarków. Coś musi leżeć na konwersjach, albo SIMD jest winowajcą. ;)
Dobrze, że takie Azarieny są na forum to jak człowiek zostanie zjechany z pozoru niewinnym pytaniem to się nauczy na błędach :D
0
No tak - dałem ciała. Teraz nie rozumiem swoich benchmarków. Coś musi leżeć na konwersjach, albo SIMD jest winowajcą.
Zauważ że pod x86 domyślnie operuje się na FPU, a pod x86-64 na SSE2.
Jednak oba zestawy instrukcji, wbrew temu co się czasem pisze, są dostępne na obydwu architekturach.
Jest jednak różnica między ilością dostępnych rejestrów SSE2 w trybie 32- i 64-bitowym.
SSE2 jest generalnie szybsze od FPU na obu.
Nie robiłem jednak testów jak to się ma do konwersji float/double.
0
Azarien napisał(a):
No tak - dałem ciała. Teraz nie rozumiem swoich benchmarków. Coś musi leżeć na konwersjach, albo SIMD jest winowajcą.
Zauważ że pod x86 domyślnie operuje się na FPU, a pod x86-64 na SSE2.
Jednak oba zestawy instrukcji, wbrew temu co się czasem pisze, są dostępne na obydwu architekturach.
Jest jednak różnica między ilością dostępnych rejestrów SSE2 w trybie 32- i 64-bitowym.
SSE2 jest generalnie szybsze od FPU na obu.
W SSE nie ma: sin, cos, arctan, log, i wielu innych, więc FPU i tak jest używany na 64;
Chyba że MS liczą te funkcje teraz ręcznie na sse - metodą Newtona.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910%28v=vs.85%29.aspx
0
kompilator VC++ nie używa FPU pod x64, więc tak, funkcje te są liczone „ręcznie”
Pewnie w libach są nadal instrukcje FPU, więc kompilator nie ma tu nic do roboty.
Inaczej te funkcje przestępne z math byłby strasznie wolne na win64.
0
Pewnie w libach są nadal instrukcje FPU, więc kompilator nie ma tu nic do roboty.
Nie, w libach nie ma instrukcji FPU. Tak, sprawdzałem. I nie, nie są wcale strasznie wolne.
Przecież FPU też liczy funkcje tymi (lub podobnymi) metodami. I jak się okazuje, nie jest w tym wcale tak zawrotnie szybkie...
Jest jeszcze "gorzej": Visual 2012 generuje kod dla SSE2 również pod x86. Można przełączyć na FPU (będzie wolniej!) ale domyślnie jest SSE2.
I tak, sinusy są wtedy liczone w pętli metodą jakąś-tam.
I tak, program wymaga procesora z obsługą SSE2.
0
Azarien napisał(a):
Pewnie w libach są nadal instrukcje FPU, więc kompilator nie ma tu nic do roboty.
Nie, w libach nie ma instrukcji FPU. Tak, sprawdzałem. I nie, nie są wcale strasznie wolne.Przecież FPU też liczy funkcje tymi (lub podobnymi) metodami. I jak się okazuje, nie jest w tym wcale tak zawrotnie szybkie...
Podobnymi ale hardwerowo, co robi różnicę.
FPU oblicza sin tak w 50 do 100 taktów, i do tego masz tu pełne 64 bity precyzji long double, nie double - 53 bity prec.
Wątpię żeby można było szybciej to obliczyć softem, czyli za pomocą mnożeń i dodawań, ewentualnie jeszcze: sqrt i div, ale te raczej nie wchodzą w grę - za wolne.
Jest jeszcze "gorzej": Visual 2012 generuje kod dla SSE2 również pod x86. Można przełączyć na FPU (będzie wolniej!) ale domyślnie jest SSE2.
I tak, sinusy są wtedy liczone w pętli metodą jakąś-tam.
I tak, program wymaga procesora z obsługą SSE2.</quote>
Ale możesz sobie używać spokojnie obj, czyli lib z kodem FPU.
Byłby problem z przenoszeniem parametrów, ale można to przeskoczyć.
tradycyjnie floaty były zwaracane na st0, a teraz chyba w xmm0;
i podobnie z argumentami: dawnie były na stosie, a win64 w xmm.
Zatem tak należałoby robić:
;double sin(double x)
mov tmp, xmm0; // x = tmp
;--------- stara - oryginalna wersja sin(x)
fld tmp
fsin
;ret ; to jest dalej
;------- koniec oryginału
fstp tmp
mov xmm0, tmp
ret