Michal Kawecki napisał(a):
> Masz oczywiście rację, programiści powinni robić co się da żeby z nowych
> zabawek wyciągnąć maksimum pożytku. Ale przejście na 64-bity jest
> nieuchronne, a wynika to po prostu z powoli kończącej się puli adresowej
> dla pamięci RAM. Dzisiejsze 4 GB to dla wielu za mało. A na dzień
Z tym się zgadzam.
I nie tyle ilość RAMu zaczyna być za mała, co - szybciej
chyba nawet - wirtualna przestrzeń adresowa. Coraz więcej
danych mapowanych z dysku w pamięci też musi się gdzieś
zmieścić bez kombinowania z przesuwającymi się oknami
dostępu. Bo co z tego, że w tej chwili w typowym systemie
32-bitowym aplikacja może mieć wirtualną przestrzeń
adresową rzędu setek terabajtów, skoro na raz ma dostęp
do 2 lub max 3 GiB danych :)
> dzisiejszy te "psedo 64-bitowce" to jedno wielkie rozczarowanie: system
> 64-bitowy wcale nie chodzi na tych procesorach szybciej, choć
Ale w związku z powyższym, nawet jeżeli tryb 64-bitowy
będzie działał tak samo jak 32-bitowy pod względem
wydajności, to zyski z większej ilości pamięci i większej
przestrzeni wirtualnej będą nie do przecenienia.
> teoretycznie powinien. A czasem jest wręcz przeciwnie, zwykły system
> 32-bitowy okazuje się wydajniejszy...
> (przy ograniczonych zasobach RAM)
Wiesz, jest całkiem sporo testów, gdzie jednak system
i aplikacje 64-bitowe są szybsze.
W końcu większości aplikacji wystarczą liczby 32-bitowe.
Same procesory też domyślnie operują na operandach 32-bitowych,
jest osobny prefiks do ich wydłużenia. Jedynie adresy są
uniwersalnie dłuższe o kawałek. W efekcie aplikacja 64-bitowa
powinna działać szybciej, bo ma 2x więcej rejestrów a kod się
wydłuża nieznacznie. I zazwyczaj testy oprogramowania open-
source działającego np. pod Linuksem wykazują, że faktycznie
rekompilacja daje kilka-kilkanaście procent przyspieszenia
czyli tyle, ile można się spodziewać.
-- |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""| | Radosław Sokół | http://www.grush.one.pl/ | | | Administrator, Politechnika Śląska | \................... Microsoft MVP ......................../Received on Thu Jan 18 13:50:06 2007
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 18 Jan 2007 - 13:51:18 MET