RSS

8, 16 i 32 bity

Liczba odsłon: 48

Gdy coraz odważniej mówiono o zbliżającej się premierze Windows 95, łamy czasopism zaczęły zajmować przewidywania, o ile to 32-bitowe aplikacje będą szybsze od swoich 16-bitowych odpowiedników. Przetwarzanie dwukrotnie większej ilości danych w każdym kroku miało się przełożyć na wyraźnie większe tempo pracy.

Jak wiadomo, efekt nie był taki dobry. 32-bitowa architektura systemu zawsze niesie ze sobą balast większych wymagań co do pamięci operacyjnej. Przechowywanie 32-bitowych liczb i adresów znacząco zwiększa rozmiar każdej struktury programu — czasem bez wyraźnego zysku.

Okazało się też, że nie wszędzie 32-bitowy kod oznacza wydajność. Gdy program operuje na zestawie 8-bitowych próbek danych, zwiększenie pojemności rejestrów nie daje absolutnie nic — chyba, że sprytny programista zmieści kilka zmiennych w jednym rejestrze mikroprocesora. Niestety, popularna architektura x86 znacząco to utrudnia, dając bezpośredni dostęp tylko do dwóch z czterech 8-bitowych ćwiartek 32-bitowych rejestrów.

Zapomnij więc, że 32 bity automatycznie przyspieszą każdy program. Dobrze zoptymalizowany kod 8- lub 16-bitowy będzie szybszy i oszczędniejszy — szczególnie, jeśli wykorzysta większe możliwości dawane przez procesor. Te z kolei nie wymagają czasem nawet wsparcia ze strony systemu operacyjnego, o czym najlepiej wiedzą programiści, którzy pisali 32-bitowe programy działające w trybie rzeczywistym 16-bitowego DOSu.


Teza tego tekstu ma potwierdzenie w następnych zmianach architektur procesorów zgodnych x86, okazuje się że procesory te mogą być szybsze ale wcale nie dlatego że są ileś tam bitowe (teraz zapożycza się coraz więcej cech procesorów z superkomputerów itp.)