Lepsze wrogiem dobrego

Wcześniej czy później będziemy właścicielami 64-bitowego procesora i takiej platformy. Programiści jednak nie powinni ulegać emocjom i na gwałt zmieniać swoich narzędzi pracy na takie, które umożliwiają tworzenie 64-bitowych aplikacji. Przeniesienie każdego rodzaju programu na nową platformę zabierze sporo czasu. Rodzi się zatem pytanie, czy to się będzie opłacało? Na pewno nie wszystkim i raczej nie od razu.

Woda na młyn

Na zmiany sprzętowe najbardziej dynamicznie reagują twórcy gier komputerowych. Dzieje się tak, ponieważ engine’y graficzne co jakiś czas są pisane od nowa, aby łatwiej było wykorzystywać możliwości nowego sprzętu. Natomiast np. programy finansowe często zawierają fragmenty kodu powstałe nawet wiele lat temu. W wypadku gier główne zadania procesorów to obliczenia, które stosunkowo łatwo zoptymalizować, zamieniając kod 32-bitowy na 64-bitowy. Należy jednak pamiętać, że takie rozszerzenia, jak MMX, SSE, SSE2, SSE3 i 3DNow!, znane są od lat i umożliwiają wykonywanie operacji na rejestrach 64- i 128-bitowych, działając jednocześnie na wielu danych w trybie SIMD (Single Instruction, Multiple Data – pojedyncza instrukcja, wiele danych). Zatem nie ma sensu dostosowywać do 64 bitów kodu, który jest już zoptymalizowany np. pod kątem rozkazów MMX.

Na pewno jednak w grach 64 bity pomogą zwiększyć precyzję obliczeń bez straty wydajności i dzięki temu na ekranie zobaczymy np. dużo więcej szczegółów tworzonych światów 3D. Jednakże znacznie większy zysk osiągniemy poprzez umiejętne programowanie współbieżne uwzględniające procesory wielordzeniowe, niż przechodząc na 64 bity. Na dodatek, jeżeli się pospieszymy z przenosinami, grozi nam konieczność, jednoczesnego napisania i aktualizowania aplikacji w wersjach 64-bitowej oraz 32-bitowej (te drugie jeszcze przez kilka lat będą stosowane), co zdecydowanie zwiększy koszty.

Po co mi 64 bity?

Pyta o to zdecydowana większość programistów i podobnie mogą się zachować użytkownicy. W typowych aplikacjach biznesowych wydajność znajduje się na dalszym planie i nie ma większego wpływu na funkcjonalność oprogramowania. Ponadto 32-bitowe programy powstałe w takich językach, jak C# czy Java (a już tym bardziej w dowolnym języku skryptowym), w większości wypadków nie muszą być modyfikowane. Tłumaczeniem takich aplikacji na 64 bity zajmuje się system operacyjny lub warstwy pośredniczące, czyli np. .NET Framework, wirtualna maszyna Javy albo interpreter języka skryptowego.

Tylko spokojnie…

64 bity w procesorze same w sobie nie spowodują rewolucji. Zmiany w dotychczasowych aplikacjach w celu przystosowania ich do działania w nowym środowisku to czysto mechaniczna poprawka kodu. Oczywiście są fragmenty aplikacji, po zoptymalizowaniu których uzyskamy większą wydajność i precyzję działania, jednakże to tylko kosmetyka w samej implementacji w porównaniu ze zmianami, które należy wprowadzić, aby nasz program zadziałał znacznie wydajniej na procesorach HT (Hyper-Threading) lub wielordzeniowych. Takie modyfikacje będą się wiązały z zupełnie innym podejściem do tworzenia aplikacji już na poziomie projektowania jej architektury. Z całą pewnością dzięki nim znacznie lepiej da się wykorzystać moc drzemiącą w sprzęcie. MultiThreading, a nie 64 bity, to wyzwanie dla programistów na najbliższą dekadę, a z przepisaniem swojej aplikacji z 32 na 64 bity nie warto się spieszyć, gdyż użytkownicy mogą po prostu nie zauważyć zmiany na lepsze.

Więcej:bezcatnews