bs.mechanik::devBlog

Krótka przerwa

bs.mechanik@gmail.com (bs.mechanik) — Fri, 16 Oct 2009 23:12:00 +0000

Chciałbym z przykrością poinformować, że na okres kilku najbliższych miesięcy będę musiał wstrzymać to niezwykłe i interesujące zajęcie jakim jest blogowanie (sam proces nic nierobienia w tym względzie, praktykuję już od jakiegoś czasu). Powody jako takie są. Studia (ok, tu żartuję) a także kilka innych pomniejszych / powiększych spraw, które mimo wszystko są ważniejsze i bardziej czasochłonne. Myślę, że nikt się wiec nie obrazi. Obiecuję, że za jakiś czas pojawi się coś ciekawego, tak w ramach rekompensaty. Nie będę bawił się w ceregiele związane z usuwaniem bloga - niech sobie wisi w czeluściach internetu. A nuż/widelec coś/komuś się przyda - no w końcu kilka notek napisałem na trzeźwo. Na serio, to szkoda mi tych 1,22 z VAT, które wydałem na domenę. No koniec tego bezwładnego sypania literkami po ekranie. Do zobaczenia :)

Opera 10 oficjalnie wydana

bs.mechanik@gmail.com (bs.mechanik) — Tue, 01 Sep 2009 06:56:00 +0000

Opera Software zaprezentowała finalną wersję, dziesiątej odsłony swojej przeglądarki. Jak już widać było w wersjach beta i RC, zmianom uległ interfejs użytkownika - jest znacznie bardziej elastyczny i wygodniejszy w użyciu. Okienko "Speed dial" jest bardziej konfigurowalne (możliwość wyboru tła, określenie liczby wyświetlanych okienek). Możemy także schować główne menu, co daje nam jeszcze większą przestrzeń na wyświetlanie stron. Interesująca jest także możliwość zmiany położenia paska kart - można go umieścić choćby po lewej stronie, gdzie domyślnie wyświetlane są miniaturki stron.
Ciekawą funkcjonalnością jest także Opera Turbo. Pozwala ona na znacznie przyspieszenie ładowania stron (ale tylko w przypadku wolnych łączy), poprzez kompresję jej zawartości. Faktycznie, tracimy na jakości grafik, jednak nie zawsze jest to szczególnie istotna rzecz. Podobnie jak poprzednie beta wersje, przechodzi ona w 100% ostatni test ACID. Najważniejsze jednak, w porównaniu do poprzednich wersji (9.6x), znacznie poprawiono szybkość renderowania stron.
Download.

SSE w klasie - #2

bs.mechanik@gmail.com (bs.mechanik) — Tue, 11 Aug 2009 10:08:00 +0000

Po omówieniu podstaw związanych z programowaniem przy użyciu instrukcji SIMD, czas przedstawić nieco bardziej użyteczne informacje. Dzisiejszym daniem głównym więc, będzie niewielka (rozwijana w kolejnych częściach mini kursu) klasa czterowymiarowego wektora. Życzę smacznego i zapraszam do lektury :).

Na początku zaczniemy od przygotowania składników. Dziś zamiast wyrównanej do szesnastu bajtów tablicy typu float, skorzystamy ze struktury:

__declspec(align(16))
struct VectorData{
    float x,y,z,w;
};

Dla instrukcji SSE liczy się tak naprawdę odpowiednio przygotowany skrawek pamięci – w jaki sposób zostanie on zaalokowany (czy to będzie tablica czy struktura) zależy tylko od preferencji programisty.

Mając wszystko przygotowane, możemy przejść do przyrządzania dania głównego. Na pierwszy ogień pójdzie więc konstruktor domyślny, w którym to będziemy zerować współrzędne wektora.
Samo zerowanie jest oczywiście sprawą trywialną, choć początkowo może przysporzyć nieco problemów. Tradycyjnie, można to zrobić na dwa sposoby:

```
“manualne” przypisanie zer
```
skorzystanie z instrukcji memset (nagłówek cstring lub string.h)

Skorzystanie z memset powinno nieco przyśpieszyć tą prostą operację, ponieważ nie odwołujemy się do koprocesora, tylko operujemy danymi bezpośrednio w pamięci. Mimo iż w konstruktorze nie potrzebujemy wyjątkowej wydajności (jest on wykonywany zazwyczaj tylko raz), to jednak wykorzystamy trochę mocy :).

Otóż i niezwykle wyrafinowana treść naszej funkcji:

_asm{
    mov esi,this
    movaps xmm0,[esi]
    xorps xmm0,xmm0
    movaps [esi],xmm0
}

Jak widzimy, są tu dwie nowe rzeczy. Pojawił się wskaźnik this oraz instrukcja xorps.
Wskaźnik this używany jest by dostać się to struktury przechowującej wektor. Zadziała to jednak tylko wtedy gdy zmienna ta będzie pierwszym polem klasy. Wówczas adres na który wskazuje this jest równoznaczny z adresem owego pola.
W przeciwnym wypadku, pobranie adresu trzeba będzie wykonać “ręcznie”:

void *p = &m_vecData

_asm{
    mov esi,p
    //...
}

Cóż takiego robi instrukcja xorps? Jest to nic innego jak zwykły xor, w wersji dla SSE, działający na poszczególnych elementach naszego wektora. Wykonując tą operację na dwóch takich samych wektorach, zerujemy je. Jest to znacznie szybsze, niż “statyczne” przypisanie wartości zero do każdej ze współrzędnych. Mając konstruktor domyślny, możemy stworzyć konstruktor kopiujący oraz operator przypisania. Praktycznie rzecz ujmując będą to dwie identyczne funkcje. Ich działanie będzie się tylko ograniczać do kopiowania wartości pomiędzy rejestrami xmm. Spójrzmy więc jak to wygląda:

_asm{
    mov edi,vec
    mov esi,this

    movaps xmm0,[esi]
    movaps xmm1,[edi]

    movaps xmm0,xmm1

    movaps [esi],xmm0
}

Zakładam, że vec, to stała referencja na obiekt naszej klasy, przekazana do konstruktora kopiującego bądź operatora przypisania.
Działanie, jak już wspominałem, jest bardzo proste. Rejestry edi i esi przechowują wskaźniki na nasze obiekty, które następnie (za pomocą movaps) kopiowane są do odpowiednich rejestrów SSE – xmm0 dla naszego wektora oraz xmm1 dla wektora przekazanego w parametrze. Przypisanie wektorów to po prostu skopiowanie zawartości xmm1 do xmm0. Ostatnia instrukcja zapisuje wynik w this.

Na koniec omówimy sobie operator new i delete, ponieważ jak się okazuje, domyślne operatory nie będą kompatybilne z naszą klasą wektora.
W podstawowym ujęciu, instrukcje SSE dzielimy na dwie kategorie: operujące na wyrównanych i niewyrównanych danych. Gdy operujemy na danych niewyrównanych, działanie SSE jest nieco wolniejsze, ponieważ potrzeba więcej cykli by dostać się do odpowiedniej komórki pamięci. Przykładem tego typu instrukcji może być movups – jest to odpowiednik movaps (u – unaligned, a - aligned), tylko, że tablica lub struktura, do której chcemy uzyskać dostęp, nie musi być wyrównana do granicy szesnastu bajtów.

Cóż więc wspólnego mają z tym operatory new i delete? To, że przydzielają one niewyrównane do odpowiadającej nam wartości, kawałki pamięci. Należy zatem operatory te przeciążyć. Na szczęście jest to operacja równie trywialna, jak te, które zaprezentowałem powyżej. Jeden ze sposobów zrobienia tego, opisał Netrix, mi jednak udało się, znaleźć znacznie prostsze rozwiązanie. Okazuje się bowiem, że istnieją funkcje które robią to za nas: _aligned_malloc i _aligned_free. Zewnętrznie działają tak samo jak standardowe wersje malloc i free, więc ich użytkowanie nie powinno sprawiać większego problemu.

Implementację dodawania i odejmowania zostawiam jako zadanie domowe :). Instrukcje, które je wykonują omówiłem w poprzedniej części kursiku więc nie powinno to stanowić większego problemu.

W załączniku znajduje się kod do dzisiejszego kursiku. Dodałem także metodę zerującą wektor.

Najsławniejsi po polsku

bs.mechanik@gmail.com (bs.mechanik) — Wed, 05 Aug 2009 10:49:00 +0000

Przeglądając ostatnio serwisy z newsami dotyczącymi tematyki IT oraz ogólnie pojętego programowania, natrafiłem na dość interesującą informację. Powstał bowiem blog, którego autor postawił sobie za cel, tłumaczenie notek ze stron domowych takich sław jak Joel Spolsky lub Jeff Atwood. Jest to z pewnością bardzo ciekawa inicjatywa, szczególnie dla osób, które jeszcze z angielskim mają lekkie problemy :)

Adres strony: http://www.devblogi.pl.

Samsung yp-u1

bs.mechanik@gmail.com (bs.mechanik) — Sat, 23 May 2009 14:55:00 +0000

Dziś będzie trochę inna notka, nie nawiązująca zbyt wiele do programowania. Jak widać, znajduje się w kategorii krótka recenzja, lecz nie będę tu opisywał kolejnej, niezwykle fascynującej książki, z wciągającą fabułą i akcją. Chciałbym opisać niewielkie urządzenie, z którym miałem przyjemność spędzić ostatnie 3 lata. Nie jest to już więc sprzęt najnowszy, raczej ciężko go dziś kupić, jednak po tylu latach użytkowania chciałbym napisać kilka spostrzeżeń na temat tego niewielkiego odtwarzacza mp3.

Na początek kilka podstawowych danych technicznych:

wymiary: 25.6 x 87.4 x 13.6 mm
waga: 33g
zakres częstotliwości: 20Hz~20KHz
czas odtwarzania: 13h (wbudowany akumulator litowo-polimerowy)

Jak więc widać, jest to dość zgrabne i lekkie urządzenie. Dodatkowo bez problemów radzi sobie z formatami mp3 (także ze zmiennym bitrate) ogg, wma czy wav. Raz tylko zdarzył mi się plik, który podczas odtwarzania zawiesił odtwarzacz. Komunikacja z komputerem została rozwiązana standardowo: port USB 2.0, choć sposób chowania konektora jest nieco oryginalny (o tym później). Wyświetlacz jest cztero linijkowy, podświetlany w razie potrzeby na biało. Prezentowany tekst jest wyraźny i ostry. Nawet podczas przesuwania nie miga ani nie smuży, co często się zdarza w odtwarzaczach tego typu. Podświetlenie także nie pozostawia nic do życzenia – równomiernie rozłożone na całość ekranu.

Posiadana przeze mnie wersja miała 512MB (YP-U1X), lecz dostępna ilość miejsca do zapisu to 496MB.
Nawigacja po menu zostało zrobiona w sposób bardzo intuicyjny, szczególnie, że całość została przetłumaczona na język polski. Co ciekawe, “nieprzetłumaczalne” jest tylko “Settings” i “Language”, by po zmianie języka na koreański, bez problemów można było przywrócić stare ustawienia.
Główny ekran odtwarzania jest mocno konfigurowalny. Bez problemów można wyświetlić informacje na temat trybu odtwarzania, włączonego efektu dźwiękowego, bitrate (pliki ze zmiennym są oznaczane jako VBR), numeru pliku i poziomu baterii. Ciekawą opcją są dwa sposoby przewijania nazw utworów: poziomy i pionowy. Ten ostatni jest szczególnie przydatny, gdy nazwa piosenki jest dość długa by w krótkim czasie mogła zostać zaprezentowana w całości.
Nawigacja po drzewie plików też nie przysporzyła mi nigdy problemów – całość rozwiązana standardowo i intuicyjnie. Niektórym osobom nie podobał się sposób włączania i wyłączania odtwarzacza: kilku sekundowe przytrzymanie przycisku Play. Przyznam, że nigdy nie miałem problemów z przypadkowym wyłączeniem playera, tym bardziej, że czas reakcji jest dość szybki, a dodatkowo jest możliwość włączenia “brzęczyka” – dźwiękowe informowanie o wciśniętych przyciskach. Odtwarzacz obsługuje także własny typ playlist. Nie korzystałem z nich jednak nigdy; wolałem standardową, “folderową” kolejność utworów.
Dodatkową opcją jest nagrywanie dźwięku, lecz należy traktować to jako dodatek. Jakość nagrań jest bardzo zła, poza tym, zapisywane sa tylko w formacie wav.

Zewnętrznie urządzenie zostało wykonane dość estetycznie. Warto zauważyć, że, wbrew pozorom, jest to bardzo mocna konstrukcja. Nie raz zdarzyło mi się, że podczas wyciągania telefonu z kieszeni, wypadł mi także player – działa do dziś.

Wyżej wspominałem o ciekawym rozwiązaniu dotyczącym chowania wtyczki USB. Pierwszy raz spotkałem się z takim podejściem do problemu, by zamiast wysuwania, zastosować składanie – jest to ostatni (jeśli nie jedyny) model odtwarzacza mp3 Samsunga, który stosuje taki sposób. Niestety, po 3 latach intensywnego użytkowania (także często jako przenośna pamięć) rozwiązanie takie nie sprawdziło się. Jeśli przez pierwszy okres używania Yeepa nie było żadnych problemów, to teraz (zauważyłem to kilka miesięcy temu) urządzenie nie łączy się z komputerem w kilku warunkach. Przede wszystkim wejście USB nie może być zamontowane poziomo. Wówczas odtwarzacz opada (konektor się składa) i traci kontakt z komputerem – widać jakieś ruchome części odpowiedzialne za łączenie zostały uszkodzone.
Warto także zaznaczyć, że nie należy doprowadzać do zerowego stanu baterii. Często jest tak, że mimo informacji o niskim stanie akumulatora, po kilku chwilach odtwarzacz może zagrać jeszcze jeden, czy dwa utwory. Jest to jednak nie zalecane postępowanie. Ogólnie bateria sprawuje się dość dobrze – aktualnie trzyma od 6 do 8 godzin ciągłego odtwarzania muzyki. Warto zaznaczyć, że podświetlanie jest dość mocno “proądożerne” :)

Dołączone w zestawie słuchawki są wykonane solidnie i charakteryzują się dobrą jakością dźwięku podobnie jak sam odtwarzacz – nie jestem jednak znawcą i audiofilem, więc opinie będą na ten temat różne.

Podsumowując: YP-U1 to solidnie, proste w obsłudze, dobrze wykonane urządzenie nie pozbawione jednak kilku wad. Bez problemu zmieści sie w kieszeni i pozwoli posłuchać ulubionej muzyki w prawie każdych warunkach.

SSE w praktyce - #1

bs.mechanik@gmail.com (bs.mechanik) — Wed, 20 May 2009 07:57:00 +0000

Dziś postaram się przedstawić podstawowe operacje jakie możemy wykonać przy użyciu multimedialnych rozszerzeń procesora. Pokażę możliwość bezpośredniego wykorzystania assemblera, zaś w następnych notkach skupię się na wewnętrznych poleceniach kompilatora, specjalnie przygotowanych do obsługi SSE. Aby prezentowany kod mógł zostać uruchomiony potrzebny jest procesor klasy Intel Pentium III lub lepszy.
Więc do dzieła ;)

Jednak, jak to zwykle bywa, na początek jeszcze trochę teorii.
Programując przy użyciu SSE mamy do dyspozycji 8 dodatkowych, 128 bitowych rejestrów (w przypadku kodu dla procesorów 64 bitowych, liczba ta zwiększa sie do 16) - od xmm0 do xmm7. Wszystkie operacje, jakie będziemy chcieli wykonać przy użyciu omawianych tu instrukcji multimedialnych, będą operować właśnie na tych rejestrach. Jak już wiadomo, każdy z nich może przechować 4 wartości zmiennoprzecinkowe pojedynczej precyzji (float).

Na początek przygotujmy dane na których będziemy pracować: czteroelementowa, jednowymiarowa, wyrównana do 128 bitów tablica typu float – czyli nasz wektor.

__declspec(align(16)) float gVector4[4];

Zobaczmy na początek, w jaki sposób możemy dostać się do danych naszego wektora. Nie będziemy tego robić standardowo,
za pomocą operatora [ ] – posłużymy się do tego odpowiednimi instrukcjami SSE.
Pierwszą podstawową rzeczą, będzie skopiowanie zawartości komórki pamięci, gdzie znajduje się nasz wektor, do rejestru xmm.

_asm{
    lea esi,gVector4
    movaps xmm0,[esi]
    //wykonaj operacje...
    movaps [esi],xmm0
}

Pierwsza linijka odpowiada za pobranie adresu zmiennej gVector4 (dokładny opis działania instrukcji lea można znaleźć tu)
i skopiowanie go do rejestru esi (wskaźnik danych).
Następnie możemy zobaczyć już instrukcję z rodziny SSE – movaps. Odpowiada ona za kopiowanie zawartości rejestrów xmm
między sobą, a także pamięcią. W tym przypadku, zawartość komórki pamięci na który wskazuje rejestr esi, zostanie przesłana do rejestru xmm0.
Ostatnia instrukcja kopiuje zawartość rejestru xmm0 pod adres wskazywany przez esi – czyli do naszej zmiennej. Jak widać, mimo że jest to assembler, nie jest to takie trudne. Wygenerujmy więc nieco więcej bardziej praktycznego kodu.
Jak pewnie zważyliście, deklarowanie za każdym razem owej specyficznej tablicy z pewnością nie należy do specjalnie wygodnych.
Uprośćmy więc nieco ten proces:

typedef __declspec(align(16)) float AlignedVector4D[4];

Ten niewielki kawałek kodu, z pewnością pozytywnie wpłynie na czytelność kodu.
Poznajmy więc kilka podstawowych operacji: dodawanie, odejmowanie, mnożenie i dzielenie.
Na początek zdefiniujmy dwa wektory, na których będziemy wykonywać nasze operacje:

AlignedVector4D vec1 = {5.0,6.0,3.0,1.0};
AlignedVector4D vec2 = {2.5,3.0,1.5,0.5};

Za dodawanie odpowiada instrukcja addps. Przykład użycia:

_asm{
    lea esi,[vec1];
    lea edi,[vec2];

    movaps xmm0,[esi];
    movaps xmm1,[edi];

    addps xmm0,xmm1;

    movaps [esi],xmm0
}

Jak widać kod jest bardzo prosty. Dwie początkowe instrukcje odpowiadają za pobranie adresu zmiennych, następnie kopiujemy je
do rejestrów xmm0 oraz xmm1 by dodać je do siebie w następnej instrukcji. Wynik zapisywany jest do xmm0 które jest kopiowane
pod adres jaki wskazuje esi, czyli do zmiennej vec1.
Zauważmy, że obecność kopiowania do rejestru xmm1 nie jest konieczna – addps, podobnie jak movaps może pracować na jednym
operandzie znajdującym sie w pamięci operacyjnej:

_asm{
    lea esi,[vec1];
    lea edi,[vec2];

    movaps xmm0,[esi];
    addps xmm0,[edi];
    movaps [esi],xmm0
}

Pozostałe operacje wykonuje się analogicznie:
subps – odejmowanie
mulps – mnożenie
divps – dzielenie To byłoby na tyle. W kolejnych częściach poznamy trochę więcej interesujących rzeczy ;)

isabellFrame update

bs.mechanik@gmail.com (bs.mechanik) — Tue, 28 Apr 2009 23:03:00 +0000

Podczas prac nad silnikiem, zmieniłem kilka elementów Frameworka. Poprawiłem przede wszystkim dostęp do urządzeń wejścia (klawiatura i mysz). Dotychczas jedynym sposobem było podpięcie się pod rendering (metoda render klasy CBaseRenderer) i z tego miejsca pobieranie stosownych informacji. Teraz należy skorzystać z listenera (IInputListener).
Zmiany pojawiły się także w metodach pobierających informacje o systemie – są one wykonywane w bardziej stabilny sposób oraz mogą pobrać więcej danych.
Do działania aplikacji nie jest już konieczna klasa renderująca. Główną pętlę przeniosłem do CIsabellFramework. Także informacje o błędach są teraz bardziej kompletne: dodany został opis błędu oraz nazwa metody która go spowodowała.
Poprawiłem także kilka mniej znaczących uchybień.
W katalogu samples znajduje się sześć przykładowych aplikacji wykorzystujących określone funkcjonalności Frameworka.
Download.

Polimorfizm statyczny

bs.mechanik@gmail.com (bs.mechanik) — Thu, 23 Apr 2009 00:52:00 +0000

Główna metodą, dzięki której możemy zastosować polimorfizm to dziedziczenie, wraz z funkcjami (czysto) wirtualnymi. Jest to najbardziej intuicyjny sposób znany większości programistów. O tym, jak wygląda to od strony kompilatora, napisał swego czasu Xion w jednej ze swoich notek. Dziś jednak chciałbym się skupić na innej, rzadziej stosowanej, implementacji owej techniki.

Główną wadą polimorfizmu jest jego wydajność. Dziś, w czasach rozkwitu języków zarządzanych, nie jest to problem wyjątkowo dotkliwy, jednak w pewnych zastosowaniach, nawet tak niewielkie narzuty muszą być brane pod uwagę. Mowa tu oczywiście o dynamicznym wiązaniu metod, których klasa zostaje ustalona dopiero podczas wykonywania programu. Jak można obejść ten problem? Stosując szablony.

Przeanalizujmy prosty przykład: rysowanie i zarządzanie obiektami geometrycznymi.
Załóżmy, że chcemy przygotować klasę, która rysowałaby różnego rodzaju obiekty geometryczne: od punktów po wielokąty zdefiniowane przez użytkownika. Logicznym rozwiązaniem problemu, jest zastosowanie polimorfizmu.

Na początek, stwórzmy więc interfejs definiujący operacje jakie ma wykonywać owy obiekt:

class IGeometryObject{

    public:
        virtual void draw(void) = 0; //rysowanie obiektu na plotnie
        virtual void setColor(unsigned uColorType); //ustawia kolor obiektu

        virtual void create(void) = 0; //przydzielenie pamieci dla obiektu
        virtual void release(void) = 0; //zwolnienie zasobow obiektu
};

Jak widać, nie ma tu nic szczególnego – klika metod czysto wirtualnych. Stwórzmy teraz metody innej klasy, których zadaniem jest rysowanie takich obiektów:

class CGeometryDrawer{

    public:

        void drawObjectsList(const std::vector<IGeometryObject*> &vElems){
            for(unsigned i=0;i<vElems.size();i++)vElems[i]->draw();
        }

        void drawObject(IGeometryObject *pObject){pObject->draw();}
};

Główną zaletą takiego podejścia jest to, że kolekcja vElems może być heterogeniczna, czyli zawierać elementy różnych klas. Wystarczy tylko, że każda z nich będzie implementować interfejs IGeometryObject.

Był to więc przykład standardowego podejścia do problemu. Jak już wcześniej wspominałem, dla każdego wywołania jednej z wirtualnych metod interfejsu IGeometryObject musimy się liczyć z niewielkim narzutem, związanym z dynamicznym powiązaniem metody.

Czas na prezentację tytułowego sposobu. Podstawową różnicą będzie tu brak klasy, po której będzie obowiązek dziedziczenia – dzięki szablonom narzucimy odpowiedni interfejs wewnątrz metod:

class CGeometryDrawer{

    public:

        template <typename GeometryObject>
        void drawObjectsList(const std::vector<GeometryObject> &vElems){
            for(unsigned i=0;i<vElems.size();i++)vElems[i].draw();
        }

        template <typename GeometryObject>
        void drawObject(GeometryObject &object){object.draw();}
};

Jak widać, nowa wersja klasy rysującej korzysta z metod szablonowych. Metody te, definiując typ GeometryObject, narzucają dla niego obecność funkcji składowej draw. Dzięki temu, możemy przekazać obiekty dowolnych klas – istotne jest tylko to, by miały definicje draw. Ważne, by to metody były szablonowe, nie zaś cała klasa. W przeciwnym wypadku bylibyśmy ograniczeni tylko do obsługi typu przekazanego podczas definiowania obiektu klasy CGeometryDrawer.
Warto także zaznaczyć, że kolekcja vElems musi zawierać obiekty tego samego typu (homogeniczne). W przypadku polimorfizmu dynamicznego, dzięki zastosowaniu dziedziczenia, mogliśmy dodać do kolekcji, klasy różnych typów, w tym przypadku nie jest to jednak możliwe. Można co prawda, przekazać do metody drawObjectsList wektor wskaźników, ale wtedy funkcje składowe byłby wiązane dynamicznie, więc tracimy zyski związane ze statycznym wiązaniem.

Ogólnie rzecz ujmując polimorfizm dynamiczny można określić jako: powiązany i dynamiczny.

powiązany, ponieważ typy obiektów są zależne od innego typu (dziedziczenie po klasie bazowej, w tym przypadku interfejsie)
dynamiczny, bo klasa wywoływanej metody jest ustalana podczas działania programu.

Do jego podstawowych zalet można zaliczyć:

możliwość działania na kolekcjach heterogenicznych obiektów
metody korzystające z polimorfizmu mogą być dostarczane w postaci skompilowanej (lib lub dll)

Polimorfizm statyczny jest zaś niepowiązany i statyczny:

niepowiązany, bo klasy konkretne (niewirtualne) nie muszą być dziedziczone po określonym interfejsie lub innej klasie
statyczny – klasy metod są ustalane już na etapie kompilacji

Zalety:

większa wydajność
klasy konkretne nie muszą implementować całości określonego interfejsu, ponieważ wymagana jest znajomość tylko tych operacji które są rzeczywiście wywoływane w programie
istnieje możliwość stosowania typów podstawowych

afterparty…

bs.mechanik@gmail.com (bs.mechanik) — Wed, 25 Mar 2009 10:57:00 +0000

Zakończyła się juz coroczna Konferencja Inżynierii Gier Komputerowych. Był to mój pierwszy raz na tego typu spotkaniu i muszę przyznać, że pewnie nie ostatni. Niesamowita atmosfera i nowe znajomości to z pewnością podstawowe powody dla których warto tam się pojawić. Prezentacje, mimo, że nie wszystkie, były na wysokim poziomie, zaś smaczkiem był pokaz ewolucji renderera w grze NecroVision. Do najbardziej emocjonujących chwil, można z pewnością zaliczyć compo, w którym to nasza drużyna (Gwardia Grembosza), zajęła czwarte miejsce. Praca z pewnością nie była tak doskonała technicznie jak PsychoL, Rzeźników, jednak jej tworzenie przyniosło wiele radości. Brałem też udział w Konkursie IT, organizowanym przez Rega, choć tam juz było trochę trudniej, ze względu na dość szeroki wachlarz pytań i silną konkurencję.
Nie będę pisał szczegółowej relacji z przebiegu spotkania, bo uczynili to juz inni (patrz – linki blogów).
Pozdrowienia dla wszystkich uczestników i do zobaczenia za rok! :)

CPUID, czyli procesorze przedstaw się

bs.mechanik@gmail.com (bs.mechanik) — Fri, 13 Mar 2009 01:42:00 +0000

We wcześniejszych notkach pisałem o technologii SSE. Krótki opis, wsparcie ze strony kompilatora – czas więc na bardziej praktyczne podejście do tematu. W artykule tym skupię się jednak na działaniu instrukcji, która nie jest związana bezpośrednio z technologią SSE, a mianowicie na CPUID - proste, bezargumentowe polecenie, pozwalające uzyskać wiele przydatnych informacji na temat procesora.

Pisząc program korzystający z zestawu instrukcji SIMD, chcemy czasem zachować zgodność ze starszymi modelami procesorów, które nie wspomagają konkretnej wersji SSE lub 3DNow!. Wykorzystując także najnowsze wersje rozszerzeń multimedialnych (aktualnie jest to 4.1), musimy mieć na uwadze to, że wielu użytkowników nie posiada jeszcze procesorów, które je potrafią obsłużyć. Aby nie ograniczać liczby potencjalnych odbiorców, musimy więc zaopatrzyć się w metody, które wykonają stosowne obliczenia w sposób tradycyjny, lub za pomocą niższych wersji SSE. Problemem pozostaje oczywiście pobranie informacji o tym, jaki typ funkcji możemy wykonać na procesorze użytkownika. Rozwiązanie jest wbrew pozorom dość proste. Przyjrzyjmy się kilku z nich.

Jeśli interesuje nas lista podstawowych możliwości, możemy skorzystać z funkcji udostępnianych przez Windows Api: IsProcessorFeaturePresent i GetSystemInfo. Pierwsza z nich zwraca informacje o wersji obsługiwanych SSE (niestety, tylko do wersji trzeciej), MMX, 3DNow! a także garść innych danych (choćby dostępność Physical Address Extension). Kolejna z wymienionych funkcji, może być szczególnie przydatna, bo za jej pomocą można dowiedzieć się, ile fizycznych procesorów jest aktualnie zainstalowanych w systemie. Pobiera także dane dotyczące m.in. rozmiaru strony w pamięci operacyjnej.
Skorzystanie z powyższej funkcjonalności jest bardzo proste, zaś przykłady są na stronach ich dokumentacji, więc nie będę prezentował ich użycia.

Sprawdzanie jednak, czy procesor posiada obsługę MMX, w dzisiejszych czasach, nie jest już koniecznie wymagane – od ładnych kilku lat, należy to do standardowej funkcjonalności procesorów rodziny x86. Co jednak, gdy chcemy skorzystać z udogodnień SSE 4.1? Jego obsługa dziś nie jest jeszcze tak oczywista, podobnie jak SSSE 3. Tu z pomocą przychodzi nam assembler.
Instrukcja CPUID dostępna jest od rodziny procesorów Pentium i późniejszych Intel486. Nie wszystkie funkcje były wspomagane od razu, jednak od czasów Pentium 4, sytuacja nie zmieniła się zbyt mocno.
Ogólna idea działania jest bardzo prosta: do rejestru EAX przekazujemy numer funkcji (operacje jaką chcemy wykonać), wywołujemy instrukcję CPUID i dostajemy interesujące nas informacje w odpowiednich rejestrach. Na początek pobierzmy nazwę producenta – jest to 12 znakowy łańcuch, zapisany w 3 rejestrach:

 char szName[13];

_asm{
    mov eax,0x00000000;
    cpuid;
 
    mov DWORD PTR szName,ebx 
    mov DWORD PTR szName+4,edx 
    mov DWORD PTR szName+8,ecx
}

szName[12] = 0;
printf("%s\n",szName);

Na procesorach Intela zostanie wyświetlone: GenuineIntel, zaś AMD: AuthenticAMD.
Jak to działa? Bardzo prosto.
Pierwsza instrukcja mov zapisuje do rejestru EAX numer funkcji (w tym przypadku jest to funkcja o numerze 0). Następnie wywołujemy CPUID, które pobiera numer funkcji z rejestru EAX i wykonuje odpowiednią operacje. Funkcja, którą przekazaliśmy, zwraca wspomniany już identyfikator producenta procesora, w porcjach czterobajtowych, w rejestrach EBX, EDX, ECX. Aby dostać się do niego, przekazujemy do instrukcji mov wskaźnik na tablicę szName (warto przypomnieć, że nazwa tablicy jest jednocześnie wskaźnikiem jej początku) i nazwę konkretnego rejestru – ważne aby zastosować zaprezentowaną kolejność by dostać prawidłowo “poskładany” łańcuch. Pod przekazany adres tablicy kopiowana jest zawartość czterobajtowych rejestrów, więc, żeby uzupełnić tablicę, zwiększamy wskaźnik o ilość skopiowanych dotychczas danych (czyli właśnie 4 bajty) dla rejestrów EDX i ECX. Nie było to więc zbyt trudne zadanie. Dowiedzmy się więc, coś na temat SSE. Numer funkcji, za pomocą której dowiemy się o wspieranych przez procesor wersjach SSE, to 0x0000001, zaś interesujące nas informacje (czyli Standard Feature Flags) będą się znajdować w rejestrach EDX i ECX.

 unsigned s1, s2;

_asm{
    mov eax,0x00000001;
    cpuid;

    mov s1,edx;
    mov s2,ecx;
}

Zmienne s1 i s2 zostały wykorzystane tu jako wektory bitowe – każdy z 32 bitów przechowuje wartość 0 lub 1 (właściwość jest lub nie jest dostępna). W rejestrze EDX (więc u nas w zmiennej s1) przechowywane są informacje na temat dostępności MMX (bit 23), SSE (bit 25), SSE2 (bit 26). Czy jest obsługiwane SSE w wersji trzeciej dowiemy się sprawdzając bit zerowy zmiennej s2, SSSE3 bit 9 a SSE4.1 bit 19. Jak to zrobimy? Oczywiście posługując się operatorem >> (jego działanie i typowe zastosowanie opisał Xion, w swoim megatutorialu).
Ogólny schemat wygląda następująco:

((zmienna >> numer_bitu) & 1) ? printf("jest") : printf("nie ma");

Czyli, jeśli chcemy sprawdzić dostępność SSE2, piszemy:

((s1 >> 26) & 1 )? printf("jest\n") : printf("nie ma\n");

Dla bitu zerowego (SSE3), nie musimy wywoływać operatora >>.

Możemy także ubezpieczyć się, przed (czysto teoretyczną) sytuacją braku wsparcia dla CPUID. W takim przypadku, gdy spróbujemy wykonać tą instrukcję, wyrzucany jest wyjątek, zaś naszym zadaniem jest przechwycenie go.

__try{

    _asm{
        //...
        cpuid
        //...
    }

}
__except(EXCEPTION_EXECUTE_HANDLER) { 
    if (_exception_code() == STATUS_ILLEGAL_INSTRUCTION){
        printf("Instrukcja nie jest wspierana przez procesor. ");
    }
}

W tym przypadku mamy możliwość złapania wyjątku systemowego, a taki zostanie wyrzucony, jeśli spróbujemy użyć instrukcji nie wspieranej przez nasz procesor. Tak samo można zrobić dla instrukcji SIMD, jednak moim zdaniem nie jest to eleganckie. W przypadku CPUID, taki kod “opakowujący” jest użyty na wszelki wypadek i jego wykonanie jest praktycznie znikome, zaś dla SSE szanse te znacznie rosną i powinniśmy wykryć odpowiednie właściwości znacznie wcześniej.

Dokładny opis CPUID znajdziemy oczywiście w podręcznikach Intela, szczególnie w IA-32 Intel Architecture Software Developer’s Manual VOLUME 2A: Instruction Set Reference, A-M, stronach 3-179 do 3-208. Warto wspomnieć, że za pomocą tej instrukcji, możemy dowiedzieć się bardzo wielu niskopoziomowych szczegółów na temat procesora.

Istotna kolejność

bs.mechanik@gmail.com (bs.mechanik) — Wed, 25 Feb 2009 22:22:00 +0000

Dzięki operatorowi sizeof() możemy dowiedzieć się jaki jest rozmiar danego typu w bajtach. Standard świadomie nie określa odgórnych rozmiarów typów podstawowych, zostawiając to zależnym od platformy sprzętowej (opisane są tylko relacje wielkości pomiędzy typami). Mimo, że wszystkie produkowane dziś procesory operują na słowach 64 bitowych, to jednak znaczna większość użytkowników posiada 32 bitowe systemy operacyjne, dla których tworzony jest kod aplikacji.

Przypatrzmy się więc dwóm z pozoru identycznym strukturom:

struct A{
    short a1;
    int b1;
    short a2;
};
struct B{
    short a1
    short a2;
    int b1;
};

Mają służyć tylko jako przykład, więc nie są to wyjątkowo praktyczne typy. Jak widzimy obydwie struktury mają po dwa pola typu short i jedno typu int. Zróbmy teraz mały eksperyment i wyświetlmy rozmiary obu tych typów:

printf("%d %d\n",sizeof(A), sizeof(B));

Naszym oczom ukaże się dość zadziwiający widok, bo rozmiary typów A i B są różne, i wynoszą odpowiednio 12 i 8 bajtów (na procesorze z rodziny IA-32). Dość zaskakujące, nieprawdaż? Tylko z pozoru.
Zacznijmy więc od początku. Z prostego dodawania wynika, że obie te struktury powinny zajmować 8 bajtów (2+2+4). Pierwsza z nich jednak, zajmuje o 4 bajty więcej. W tym momencie przyda się podstawowa wiedza na temat działania procesora. Danymi, na których procesory 32 bitowe, pracują z największą wydajnością to właśnie 32 bity. Tyle wynosi rozmiar słowa i rejestrów ogólnego przeznaczenia. Wysłanie większej, lub mniejszej, ilości danych, jest realizowane wolniej, dlatego nie zawsze zaleca się ich używanie. Spójrzmy teraz na strukturę A. Aby efektywnie móc przesłać wartość jej pól do rejestrów, najlepiej zrobić to 32 bitowymi paczkami. Napotykamy jednak na problem. Wedle tej idei, zmienną b1 trzeba wysyłać 2 razy (po 16 bitów wraz z a1 i a2). Nie jest bezpieczne i poprawne rozwiązanie. W takim przypadku kompilatory stosują bardzo prostą sztuczkę: wyrównują zmienne do 32 bitów, co w tym przypadku oznacza, że a1 oraz a2 będą zajmować po 4 bajty. Na każdej z tych zmiennych zyskujemy dodatkowo po 2 bajty, więc zagadka została wyjaśniona. Dlaczego więc struktura B, zajmuje 8 bajtów? Decyduje o tym właśnie ułożenie zmiennych. W tym przypadku zmienne a1 i a2 można wysłać za pomocą jednego wywołania instrukcji mov, więc wyrównanie ich nie jest potrzebne.
Obrazowo można przedstawić to tak, że struktura (a zarazem i klasa) to pojemnik z 32 bitowymi (lub 64, w przypadku procesorów i systemów operacyjnych 64 bitowych) pudełkami, do których są kolejno dodawane zmienne. Jeśli dana zmienna nie zajmuje całego pudełka, a kolejna zmienna już nie mieści się do niego, wolne miejsce zostaje zapełnione – natura nie lubi próżni. :)

Kodowanie znaków, WinApi i Visual Studio

bs.mechanik@gmail.com (bs.mechanik) — Sun, 01 Feb 2009 23:14:00 +0000

Wielu początkujących programistów, po używaniu środowisk typu Dev-C++, przesiada się na Visual Studio. Mimo, że na początku może lekko przytłaczać, pakiet Microsoftu jest dość intuicyjnym narzędziem. Stworzenie aplikacji okienkowej w WinApi jest pewnie naszym pierwszym celem. Rozpoczynamy więc lekturę odpowiednich kursów, kopiujemy przykładowy kod i… Jak to zwykle bywa natrafiamy na problem. Okazuje się, że jego przyczyną jest błąd podobny do tego:

error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'char [12]' to 'LPCWSTR'

Błąd informuje nas o tym, że kompilator nie może zrzutować drugiego parametru funkcji CreateWindowEx z typu char na typ LPCWSTR. Przyjrzyjmy sie może czym jest LPCWSTR. Zaglądając do pliku WinNT.h (skąd wiem, że akurat tam? Wystarczy kliknąć prawym przyciskiem myszy na typ i wybrać: “Go to definition”) możemy odczytać:

typedef __nullterminated CONST WCHAR *LPCWSTR, *PCWSTR;

Jest to więc stała (#define CONST const) typu wchar_t (typedef wchar_t WCHAR) zakończona zerem (Microsoft wprowadził adnotacje do C++, jedną z nich jest właśnie __nullterminated – więcej informacji pod tym adresem).
Teraz przyjrzyjmy się bliżej naszej funkcji. Analiza błędu, przedstawionego nam przez IDE odkryje przed nami pewną ciekawostkę. Okazuje się bowiem, że nie wywoływaliśmy funkcji CreateWindowExW, zaprezentowanej w błędzie, tylko CreateWindowEx. W czym tkwi haczyk? Zobaczmy jak zadeklarowana jest owa funkcja:

#ifdef UNICODE
#define CreateWindowEx  CreateWindowExW
#else
#define CreateWindowEx  CreateWindowExA
#endif // !UNICODE

Tak. Oto całość. Jak na zwykłą deklaracje, kod wydaje się dość dziwny, jednak jego znaczenie jest dość proste. Na początku sprawdzane jest, czy została zdefiniowana stała preprocesora o nazwie UNICODE. Jeśli tak, każde wywołanie funkcji CreateWindowEx będzie zastępowane przez CreateWindowExW. W wypadku gdy stała nie jest zdefiniowana wywoływana będzie CreateWindowExA*. Tylko czym różnią się te funkcje z przyrostkami “A” i “W” ? Otóż jeśli funkcja ma postfix “W” oznacza to, że operuje na znakach Unicode, czyli wchar_t (LPCWSTR), zaś “A” oznacza zwykłe kodowanie ASCII (char).
Pozostaje jeszcze jedno pytanie. Skąd wiadomo, że stała UNICODE jest zdefiniowana i jak, w razie potrzeby, ją zdefiniować? Aby zapoznać się z pełną listą stałych wystarczy wejść we właściwości projektu, tam w element C++ (znajdujący się w Configuration Properties) a następnie w Command Line. Dla standardowego projektu Win32 możemy przeczytać następujące stałe: WIN32, DEBUG lub NDEBUG dla projektu Release, UNICODE oraz WINDOWS. Zmianę lub dodanie własnej stałej, wykonujemy poprzez Preprocesor Definitions elementu Preprocesor (dalej jesteśmy w C++). Tylko, że nie ma tam UNICODE, nawet jeśli stała ta jest zdefiniowana. Co należy zrobić by korzystać ze standardowego kodowania? Cóż, znów przyjdzie nam z pomocą okienko z właściwościami projektu. Klikamy na zakładkę General w Configuration Properties i tam Character Set ustawiamy na Not Set.
Klikamy na OK, rekompilujemy nasz projekt i możemy korzystać ze starego dobrego typu char.

*Warto wspomnieć o tym, że tak naprawdę kompilator nie wie, czym jest funkcja CreateWindowEx. Każde jej wywołanie, zostanie mechanicznie zastąpione jedną z dwóch wyżej wymienionych funkcji, jeszcze przed kompilacją – na tym ogólnie polega idea preprocesora tekstu w C++.

isabellFrame

bs.mechanik@gmail.com (bs.mechanik) — Fri, 09 Jan 2009 21:27:00 +0000

Jest to niewielki framework, ułatwiający tworzenie gier oraz aplikacji multimedialnych. Wykorzystuje Direct3D 9.0c
(wersja August 2008) oraz Direct Input 8.0. Napisany przy użyciu Microsoft Visual C++ 2008.

Zawiera:

podstawową obsługę zarządzania uprzędzeniem renderującym.
obsługę okna głównego aplikacji
pobieranie informacji o komputerze i systemie operacyjnym
sprawdzanie możliwości karty graficznej
obsługę wejścia (standardowe komunikaty Windows, Direct Input buforowany oraz niebuforowany)
obsługa błędów za pomocą stosu wyjątków

Jest to wersja 1.0 więc jest już stabilna, będę wdzięczny jednak za wszystkie informacje o błędach i nieprawidłowych zachowaniach. Dokumentacja zostanie opublikowana za jakiś czas.
Biblioteka jest darmowa do wszelakich zastosowań.

Download po tym adresem.
W paczce znajdują się nagłówki (katalog include), dwie wersje biblioteki (postfix “d” oznacza wersję debug, zaś “r” release ) oraz dwa przykłady wykorzystania frameworka (katalog tut).

Kompilator vs. inline assembler

bs.mechanik@gmail.com (bs.mechanik) — Mon, 05 Jan 2009 23:05:00 +0000

Optymalizacje niskopoziomowe, mimo że stosowane coraz rzadziej, nadal w wielu przypadkach, są jedynym wyjściem by przyśpieszyć działanie aplikacji. Z roku na rok jednak, kompilatory czynią dość znaczące postępy w automatycznym optymalizowaniu kodu i nie zawsze musimy uciekać się do drastycznych metod wstawek asemblerowych, które wbrew powszechnej opinii, nie są już zalecane. Przyjrzyjmy się jednak jednemu, specyficznemu przypadkowi: użycie SSE.
Mamy trzy możliwości do wyboru:

Optymalizacje stosowane przez kompilator (w opisywanym przypadku Visual Studio 2008).
Użycie wewnętrznych poleceń, tzw. intrinsic.
Bezpośrednie zastosowanie instrukcji SSE procesora.

Będziemy wykonywać operacje na wektorach, które będą reprezentowane przez zwykłą, wyrównaną do 16 bajtów (128 bitów) tablicą 4 wartości float:

__declspec(align(16)) float vector[4];

Pewnie wiele osób zastanawia się, skąd ta dziwna składnia tworzenia tablicy. Wyrównanie danych narzuca restrykcje dotyczące rozmiaru. Wyrównanie do 16 bajtów (czyli polecenie __declspec(align(16) ) informuje nas, że określona zmienna będzie zajmować dokładnie tyle. Przypomnijmy, że rejestry SSE są 128 bitowe i aby optymalnie wykonywać operacje musimy wysyłać dane do nich właśnie takimi, 128 bitowymi, paczkami. Aby porównać ze sobą wymienione wyżej trzy sposoby optymalizacji, zajrzymy do kodu wynikowego generowanego przez kompilator. Można to zrobić wchodząc we właściwości projektu (Project->Properties), następnie w zakładkę C++, Output Files i tam ustawić Aseembler Output na Assembly With Source Code. Będziemy porównywać podstawowe operacje typu przy zastosowaniu pierwszej wersji SSE, wektorem zaś będzie struktura:

struct Vector{
__declspec(align(16)) float data[4];
};

1. Optymalizacje kompilatora.

Jest to najprostszy sposób by użyć dodatkowej mocy procesora. Zaznaczamy kilka checkbox’ów, rekompilujemy projekt i dostajemy szybszy (przynajmniej w teorii) program. Zobaczmy jak sytuacja przedstawia się, gdy chcemy użyć SSE. Na początek przejdźmy do opcji projektu i tam C++ -> Code Generation -> Enable Enhanced Instruction Set ustawiamy na Streaming SIMD Extensions. Mając wszystko przygotowane, możemy przystąpić do pracy.

Posłużmy się prostą funkcją dodającą wektory:

void addVectors(Vector &v1,Vector &v2, Vector *pOut){
	pOut->data[0] = v1.data[0] + v2.data[0];
	pOut->data[1] = v1.data[1] + v2.data[1];
	pOut->data[2] = v1.data[2] + v2.data[2];
	pOut->data[3] = 1.0f;
}

Warto zauważyć, że element w, czyli ostatni, powinien być ustawiany na wartość 1.0f. Nie zastosowałem tutaj pętli, choć kompilator przy tak niewielkiej ilości iteracji i tak zastosowałby rozwinięcie.

Spójrzmy teraz na kod, który został wyprodukowany:

//; 8    :     pOut->data[0] = v1.data[0] + v2.data[0];
    mov    eax, DWORD PTR _v1$[ebp]
    fld    DWORD PTR [eax]
    mov    ecx, DWORD PTR _v2$[ebp]
    fadd    DWORD PTR [ecx]
    mov    edx, DWORD PTR _pOut$[ebp]
    fstp    DWORD PTR [edx]
//; 9    :     pOut->data[1] = v1.data[1] + v2.data[1];
    //dodawanie wartosci y
//; 10   :     pOut->data[2] = v1.data[2] + v2.data[2];
    //dodawanie wartosci z
//; 12   :     pOut->data[3] = 1.0f;
    mov    eax, DWORD PTR _pOut$[ebp]
    movss    xmm0, DWORD PTR __real@3f800000
    movss    DWORD PTR [eax+12], xmm0

Pominąłem tu prolog i epilog funkcji, bo nie są w tym momencie istotne. Nie ma także dodawania elementów y i z, ponieważ jest to realizowane w taki sam sposób jak dla elementu x. Zmieniane są tylko wartości rejestrów ecx dla instrukcji fadd (która odpowiada za dodawanie przez koprocesor FPU), oraz rejestru edx dla funkcji fstp odpowiednio o 4 (współrzędna x) i 8 (współrzędna y). Jak widać, samo dodawanie jest realizowane standardowo. Pierwszy raz instrukcja SSE jest użyta podczas przypisania elementu w (data[3]) – movss odpowiedzialna za ustawienie najniższej wartości rejestru na odpowiednią wartość.

Wnioski są bardzo proste: korzystanie z optymalizacji dostarczanych przez kompilator (w kontekście korzystania z SSE) nie dają zbyt wiele korzyści, a czasem nawet mogą zaszkodzić – powyższy kod nie uruchomi się na procesorach niższej klasy niż pentuim III – wszystko przez jedną instrukcję movss, która de facto, nie przyśpieszyła zauważalnie naszego kodu.

2. Wewnętrzne polecenia kompilatora.

Są to instrukcje, dzięki którym kompilator wie jak poprawnie użyć poleceń asemblera. By móc z nich skorzystać musimy dołączyć do projektu nagłówek xmmintrin.h, gdzie znajdują się wszystkie deklaracje funkcji i typów. Także i w tym przypadku wykorzystamy prostą funkcję dodającą dwa wektory:

void addVectors(Vector &v1,Vector &v2, Vector *pOut){
     _mm_store_ps(pOut->data,_mm_add_ps(*(__m128*)&v1.data,*(__m128*)&v2.data));
     pOut->data[3] = 1.0f;
}

Tak. Oto cała funkcja. Dodaje ona dwa wektory, więc funkcjonalnością jest ona identyczna z tą zaprezentowaną wcześniej. Na tym jednak kończą się podobieństwa. Jak widać sposób dodawania jest tutaj inny. Jest on wykonywany za pomocą funkcji _mm_add_ps, przyjmującej zmienne typu __m128 – by przekazać wyrównaną tablicę trzeba użyć rzutowania. Za pomocą _mm_store_ps zapisujemy wartość typu __m128, zwracaną przez _mm_add_ps, do tablicy. Zostaje jeszcze przypisanie wartości dla w. Tworząc własną klasę do zarządzania wektorami, można pominąć tę operację, dodając metodę dostępową zwracającą dla w zawsze 1.0f – wartość zapisana w ostatniej komórce będzie więc bez znaczenia.

Zobaczmy więc, co zostało ostatecznie wygenerowane:

    mov    eax, DWORD PTR _v2$[ebx]
    movaps    xmm0, XMMWORD PTR [eax]
    mov    ecx, DWORD PTR _v1$[ebx]
    movaps    xmm1, XMMWORD PTR [ecx]
    addps    xmm1, xmm0
    movaps    XMMWORD PTR $T20497[ebp], xmm1
    movaps    xmm0, XMMWORD PTR $T20497[ebp]
    mov    edx, DWORD PTR _pOut$[ebx]
    movaps    XMMWORD PTR [edx], xmm0
    mov    eax, DWORD PTR _pOut$[ebx]
    fld1
    fstp    DWORD PTR [eax+12]

Jak widać, kompilator utworzył znacznie mniej kodu. Pierwsze cztery linijki zapisują przekazane wektory do odpowiednich rejestrów SSE (xmm0, xmm1). Następnie addps dodaje te wektory (zwróćmy uwagę – jedno polecenie dodaje po cztery wartości dla każdego rejestru). Kolejne operacje dotyczą zapisania wyniku w przekazanej zmiennej, zaś trzy ostatnie przypisania wartości 1.0 dla ostatniej komórki tablicy. Tak utworzony kod jest zdecydowanie bardziej wydajny od poprzedniego. Widzimy tu zgodne z oczekiwaniami wykorzystanie instrukcji SSE (movaps, addps). Można zapisać to jeszcze lepiej?

3. Inline asembler

Została nam ostatnia opcja: bezpośrednia wstawka asemblerowa. Wbrew pozorom nie będzie to trudne zadanie – jak już wyżej było pokazane, dodawanie to zaledwie jedna instrukcja.

void addVectors(Vector &v1,Vector &v2, Vector *pOut){
    _asm{
        mov eax,v1;
        mov ecx,v2;
        movaps xmm0, [eax];
        addps xmm0,[ecx];

        mov eax, pOut;
        movaps [eax],xmm0;
    }
     pOut->data[3] = 1.0f;
}

Pierwsze dwie instrukcje przenoszą adresy (warto zauważyć, że wejściowe wektory przekazywane są przez referencje) danych na do odpowiednich rejestrów. Następnie movaps przenosi do rejestru xmm0, to co znajduje się pod adresem wskazywanym przez rejestr eax. Instrukcja addps dodaje zawartość rejestru xmm0 oraz miejsca w pamięci wskazywanego przez ecx. Ostatnie instrukcje zapisują wynik w wyjściowej zmiennej pOut.

Kod, który da nam kompilator, będzie praktycznie identyczny z tym znajdującym się wewnątrz bloku _asm{}. Dodatkowo dojdzie jeszcze ostatnie przypisanie dla data[3].

Jak widać okazaliśmy się lepsi od kompilatora. ;)

Co więc wybrać?

Pytanie nie jest taki proste. Nie zawsze bowiem, mamy chęć i czas by pisać kod w asemblerze – funkcje operujące na macierzach są zdecydowanie bardziej skomplikowane. Wyniki jakie dają metody z rodziny _mm* są wystarczająco zadawalające, jednak czasem można zaoszczędzić kilka instrukcji, pisząc niskopoziomowo. Dodatkowo funkcję lub metodę można oznaczyć jako inline lub __forceinline, dzięki temu ciało funkcji będzie wstawiane bezpośrednio w miejsce wywołania. Dzięki temu można uniknąć dodatkowego narzutu. Korzystanie z asemblera ma jednak jedną zasadniczą wadę. Funkcje napisane w taki sposób nie są w żadne sposób optymalizowane. Kompilator grzecznie wklei kod, który wcale nie będzie musiał być wykonywany. W takich przypadkach zdecydowanie bezpieczniej jest użyć intrinsic.

Ostatnim dylematem, może okazać sie potrzeba pisania własnych metod obsługi wektorów i macierzy. Jeśli korzystamy z DirectX, mamy tam do dyspozycji funkcje z rodziny D3DX, które (choć nie wszystkie) zostały odpowiednio już przygotowane – optymalizacja normalizacji wektorów lub mnożenia macierzy jest na prawdę dobrze wykonana.

Więcej mocy

bs.mechanik@gmail.com (bs.mechanik) — Fri, 05 Dec 2008 16:13:00 +0000

Współczesne gry są bardzo wymagającymi aplikacjami. Renderowanie dynamicznego, pełnego efektów, obrazu ze stałą prędkością co najmniej 30 FPS staje się coraz trudniejszym zadaniem, nawet dla obiektywnie mocnych komputerów. Dobra optymalizacja kodu jest podstawą do sprawnego i szybkiego działania programu. Mówiąc "optymalizacja" mamy zazwyczaj na myśli lepsze konstruowanie algorytmów lub wykorzystanie innych technik dążących do rozwiązania problemu. Czasem jednak, trzeba przejść "o jeden poziom niżej" - stworzyć kod, który jest bliżej określonego sprzętu. Najprościej sytuacja wygląda na konsolach. Tam developer ma z góry ustalona platformę na którą zostanie stworzona gra. Jest więc w stanie stworzyć takie funkcje, które będą działać maksymalnie szybko. Gorzej jest w przypadku PC. Jak powszechnie wiadomo: ilu graczy, tyle różnych konfiguracji. Istnieją jednak pewne ustalone standardy. W przypadku kart graficznych definiowane są one poprzez obsługę odpowiednich wersji DirectX lub OpenGL. Co prawda, różne rozwiązania sprzętowe sprawiają, że wydajność renderowania może być różna, jednak minimalne wymagania zostają ustalone. W kwestii programisty, zostaje odpowiednio wydajne wykorzystanie powyższych API. Wbrew pozorom, procesory także posiadają możliwości, które jesteśmy w stanie bezpośrednio wykorzystać. Mowa tutaj o dodatkowych rozszerzeniach multimedialnych. Są to specjalne instrukcje, dzięki którym możemy znacznie przyśpieszyć działanie naszej aplikacji:

MMX (Początkowo Intel, teraz także AMD)
3DNow! (AMD)
SSE(Początkowo tylko Intel, teraz także AAMD)

MMX. Jest to zestaw dodatkowych 57 instrukcji wykonujących operacje arytmetyczne i logiczne w technologii SIMD. SIMD (Single Instruction, Multiple Data) umożliwia nam dokonanie obliczeń za pomocą jednej instrukcji na grupie danych, spakowanych do jednego rejestru. Dzięki MMX programista mógł wykonywać równoległe obliczenia na maksymalnie dwóch, 32 bitowych zmiennych. Całość posiadała jednak, z dłuższej perspektywy, dość istotną wadę: Intel nie przeznaczył żadnych dodatkowych rejestrów dla MMX. Wszystkie operacje odbywały się na ośmiu 64 bitowych aliasach rejestrów FPU, co zmuszało koprocesor do przełączania kontekstów działania - w niektórych przypadkach kod MMX był wolniejszy od tego tradycyjnego.

3DNow! Była to odpowiedź AMD na MMX. Założenia są bardzo podobne to tych zastosowanych u konkurencji, aczkolwiek nie obeszło się bez pewnych różnic. Podstawową był typ danych na których mogły być wykonywane operacje: u AMD były to liczby zmiennoprzecinkowe pojedynczej precyzji. Poza tym, dla 3DNow! przygotowano tylko 21 instrukcji, jednak w kolejnych generacjach procesorów zestaw ten powiększał się.

SSE. Technologia z pozoru wydaje sie być podobna do wyżej zaprezentowanych, jednak wprowadzenie jej wraz z procesorami Pentium III było dość istoną ewolucją. Do dyspozycji programisty oddano osiem oddzielnych, 128 bitowych rejestrów, mogących przechować do czterych wartości zmiennoprzecinkowych pojedynczej precyzji. Dzięki temu wzorst wydajności jest zuważalny, szczególnie podczas wykonywania operacji wektorowych i macierzowych. Kolejne genereacje SSE dodają nowe instrukcje, dzięki czemu czesc operacji matematycznych (np. dot product), można wykonać za pomocą jednego wywołania instrukcji w assemblerze.

C++ 50 efektywnych sposobów na udoskonalenie Twoich programów

bs.mechanik@gmail.com (bs.mechanik) — Thu, 04 Dec 2008 23:10:00 +0000

Autor: Scott Meyers
Wydawnictwo: Helion

Jest to jedna z bardziej oryginalnych książek na temat programowania w C++, jaką miałem przyjemność czytać. Autor w sposób lekki i przystępny, tłumaczy dość zawiłe dla początkującego programisty, elementy języka. Tytułowymi "sposobami", są poszczególne rozdziały książki - dodatkowo pogrupowane w tematyczne bloki. Dowiemy się więc jak zarządzać pamięcią, poprawnie implementować konstruktory i destruktory, zapoznamy się z projektem i implementacją funkcji i klas, oraz poznamy kilka reguł projektowania obiektowego. Praktycznie rzecz biorąc, cała merytoryczna zawartość jest już przedstawiona w spisie treści - każdy rozdział to osobny "sposób". Książki nie należy traktować jako całości. Nie jest to kurs C++, który powoli wprowadza w tajniki języka. Każdy rozdział traktuje o osobnym zagadnieniu, choć w większości autor zaznacza, w którym miejscu książki poruszony został podobny temat. Poczucie humoru, oraz lekkość z jaką Scott Meyers tłumaczy kolejne zagadnienia, sprawia, że tą dość krótką książkę (244 strony) możemy przeczytać w jeden dzień. Wiedza jednak, warta będzie wydanych pieniędzy.

Zarządzanie pamięcią

bs.mechanik@gmail.com (bs.mechanik) — Thu, 04 Dec 2008 00:15:00 +0000

Szybkość przydziału pamięci na ładowane zasoby jest, wbrew pozorom, dość istotną kwestią działania niektórych aplikacji. Co prawda w grach, użytkownik zazwyczaj cierpliwie czeka, aż całość zostanie załadowana, jednak wydłużanie tego czasu może być mało pożądanym efektem. Warto zaznaczyć, że posiadacze konsol mogą być w nieco lepszej sytuacji. W przypadku tych urządzeń, jeśli średni czas ładowania określonej lokacji lub etapu, jest dłuższy, gra musi czymś zabawić czekającego gracza :). Aplikacjami codziennego użytku, w których wydajne zarządzanie i alokowanie pamięci jest ważne, są przeglądarki internetowe. Szybkość renderowania stron, przechodzenia pomiędzy zakładkami oraz zamykania programu, jest dość mocno uzależniona od kodu zarządzającego pamięcią.

Jest wiele sposobów dzięki którym możemy skrócić czas wyświetlania się komunikatu "Loading..." ;). Podstawową sprawą jest sposób zapisu danych na dysku. Powszechnie wiadomo, operacje na wielu małych plikach wykonują się dłużej, niż na jednym, im równoznacznym. Możemy więc stworzyć własny wirtualny system plików (VFS). Na czym on polega? Najczęściej spotykana implementacja takiego rozwiązania, to spakowane archiwa (rar, zip, 7z...). Jeden plik przechowuje w sobie dane wielu plików, które dodatkowo są spakowane. Najbardziej klasycznym przykładem, gry która korzysta z tego rozwiązania jest Quake 3. Zasoby gry były spakowane w oddzielne pliki *.pk, w których to dodatkowo zastosowano kompresję.

Podobnie sprawa ma się z pamięcią. Przydział kilkuset niewielkich porcji pamięci, jest znacznie mniej wydajny niż jednorazowe wywołanie funkcji przydzielającej pamięć dla większego bloku danych.
Dzięki operatorowi placement new, możliwe jest przydzielanie pamięci pod wskazany adres. Co nam to daje? Przydzielamy określony blok pamięci (ustalony z góry, lub obliczony) i posługując się wskaźnikiem na ową pamięć wywołujemy wyżej wspomniany placement new, który przydzieli zasoby pod określonym mu adresem. Następnie (po wcześniejszym rzutowaniu na char*), zwiększamy ten wskaźnik o rozmiar zablokowanego obiektu (operator sizeof()), by podczas kolejnego przydziału nie nadpisać istniejących danych. Dzięki temu dodawanie kolejnych obiektów będzie odbywało się znacznie mniejszym kosztem. Pamiętać należy tylko o tym, że wcześniej zaalokowana pamięć nie jest elastyczna - kiedyś się wyczerpie. Najlepiej, jeśli wcześniej posiadamy informacjie o ostatecznym rozmiarze ładowanych danych i dla niego przydzielimy pamięć.

Przedstawione sposoby, mimo, że bardzo proste, potrafią czasem dość znacząco przyśpieszyć działanie naszych superwydajnych aplikacji ;).

W następnych notkach postaram napisać coś o optymalizacji obliczeń matematycznych ;)

Visual Studio 2010

bs.mechanik@gmail.com (bs.mechanik) — Wed, 19 Nov 2008 16:53:00 +0000

Microsoft udostępnił wersję pre-release Visual Studio 2010. Do nowości zapowiadanych w tej wersji należały obsługa procesorów wielordzeniowych, co ma znacząco przyśpieszyć działanie pakietu, ulepszenie systemu pomocy, możliwoścc tworzenia programów dla Window 7, .Net Framework 4.0, a także wykorzystanie wielu monitorów, dzięki czemu konfort pracy będzie jeszcze wyższy. Poprawieniu miał ulec także systema autouzupełniania kodu intelliSense dla C++, które jak wiadomo, w poprzednich wersjach czasem działało niepoprawnie. Informacje o produkcie można znaleźć tu, zaś download możliwy jest pod tym adresem.

Joystick 2 Mouse

bs.mechanik@gmail.com (bs.mechanik) — Thu, 23 Oct 2008 20:50:00 +0000

Aplikacja, której nazwa jest w tylule niniejszej notki, jest bardzo użyteczna - potrafi oddać kursor myszy pod władzę podłączonego pada. Za pomocą wcześniej skonfigurowanych przycisków możemy poruszać kursorem. Niby nic nadzwyczajnego, jednak w pewnych sytuacjach bardzo praktyczne. Podstawowa zaleta, z punktu widzenia programisty gier, to możliwość przetestowania nowego rodzaju sterowania, bez konieczności implementacji obsługi pada. Wystarczy uruchomić Joystick 2 Mouse i już na wstępie podjąć decyzję o dodaniu nowej funkcjonalności. Oczywiście nie zawsze się to sprawdza, szczególnie gdy nasza gra nie jest sterowana za pomocą myszy :). Strona projektu: http://atzitznet.no-ip.org/Joy2Mouse3/

Zaplanowane zadania

bs.mechanik@gmail.com (bs.mechanik) — Tue, 14 Oct 2008 21:04:00 +0000

Tworzenie kodu źródłowego zazwyczaj odbywa się według określonego przez nas porządku. Wprowadzamy zmiany do istniejącej implementacji, dodajemy nową funkcjonalność... Całość pracy, mimo że podzielona na określone okresy czasu, musi zachować ciągłość. Jednak, jak to zazwyczaj bywa, najsłabszym ogniwem jest człowiek. Ile to razy zdarzyło się, że zapomnieliśmy poprawić działanie jakieś metody, której ostateczną implementację zostawilśmy na sam koniec? :) Przydatnym narzędziem są tzw. listy TODO - posortowana według priorytetu lista zadań, jakie należy wykonać w implementacji. Najprostszym tego typu rozwiązaniem może być zwykła kartka papieru lub plik txt. MS Visual Studio też oferuje dość proste, choć wystarczające rozwiazanie. Otwieramy menu View->Other Windows-> Task List. Pokazuje nam sie niewielkie okno. Dodawanie zadań dobywa się w dwojaki sposób: bezpośrednio w oknie zadań, lub jako komentarze w kodzie - wystarczy tylko wybrać opcję Comments lub User Tasks. Komentarze będące elementami listy zadan muszą zaczynać się od słowa TODO lub HACK. IDE natychmiast wykrywa taki komentarz, dodając go do listy. Mamy także informacje o numerze linii i nazwie pliku źródłowego. Niestety w przeciwieństwie do User Tasks nie możemy ustalać ich priorytetu. Jeśli wykonamy określone zadanie, zaznaczamy stojącego obok niego checkbox'a - misja wykonana :)

Fizyczność logiki

bs.mechanik@gmail.com (bs.mechanik) — Fri, 10 Oct 2008 22:21:00 +0000

Projektowanie kodu aplikacji jest z pewnością procesem niezwykle złożonym i pracochłonnym. Aplikacja cechująca się wysoka jakością, nie ogranicza się tylko do odpowiedniej funkcjonalności, stabilności i wydajności. Niezwykle ważną cechą jest także możliwość łatwej konserwacji a także ponownego użycia niektórych jej elementów. Oczywiście z pomocą przychodzi nam projektowanie zorientowane obiektowo. Podział kodu na logiczne części (klasy) i opisanie ich poziomu abstrakcji znacznie zwiększa czytelność projektu. Dodatkowo, do dyspozycji mamy też wyspecjalizowane narzędzia temu służące, jak np. UML.

Projekt programu może być dwojaki: logiczny lub fizyczny. Projekt logiczny opisuje problemy występujące na poziomie implementacji. Decyzja o tym, czy dany operator będzie członkiem klasy lub czy dana klasa powinna mieć konstruktor domyślny, zapada na etapie projektu logicznego. Projekt fizyczny zaś, określa zależności pomiędzy poszczególnymi komponentami programu. Wbrew pozorom, obydwa rodzaje są ze sobą ściśle powiązane i często nieświadomie projektujemy aplikacje od strony fizycznej.

Podstawowym elementem projektu fizycznego jest komponent, czyli spójna i niezależna jednostka będąca zazwyczaj klasą (lub zbiorem klas określonej funkcjonalności) zdefiniowaną w pliku nagłówkowym i zaimplementowaną w pliku cpp. Załóżmy, że tworzymy klasę przechowującą punkty na płaszczyźnie dwuwymiarowej. Klasa ta udostępnia pewną podstawową funkcjonalność (dodawanie, usuwanie,sortowanie punktów). Interesuje nas także możliwość przeglądania listy punktów, jednak przy wykorzystaniu iteratora. Tworzona przez nas klasa iteratora powinna znajdować się w tych samych plikach co główna klasa będąca kontenerem punktów. Fizycznie (a także logicznie) stanowią one jeden komponent udostępniający określoną z góry funkcjonalność (przechowywanie i przeglądanie danych).

Pomiędzy komponentami mogą występować określone relacje:

Jest
Używa-W-Interfejsie
Używa-W-Implementacji

Relacja Jest bezpośrednio wynika z dziedziczenia. Klasa A jest Klasą B, jeśli klasa A publicznie dziedziczy po klasie B. Używa-W-Interfejsie oznacza, że dany typ jest wykorzystywany w interfejsie danej klasy. Kiedy tak się dzieje? Gdy typ jest zwracany przez jedną z metod klasy, przyjmowany na liście argumentów lub znajduje się w sekcji prywatnej. Ogólnie rozróżnia się dwa przypadki tej zależności: pełna i z nazwy. Przypadek pierwszy, mówi o tym, że do kompilacji klasy wymagana jest znajomość całej definicji obiektu (dołączenie jej za pomocą #include). Jest to najczęściej spotykany przypadek. Zależność Tylko-Z-Nazwy jest wykorzystywana tam, gdzie mamy do czynienia ze wskaźnikami lub referencjami na obiekt. Wtedy potrzebujemy tylko nazwy obiektu - korzystamy z deklaracji wyprzedzającej. Ostatnia z relacji, czyli Używa-W-Implementacji, jak sama nazwa wskazuje, mówi o tym, że dany typ używany jest w implementacji funkcjonalności klasy. Wszystkie pliki nagłówkowe, niezbędne do kompilacji, należy dodać poleceniem #include w pliku cpp klasy (nie w pliku nagłówkowym). Odpowiednie wykorzystanie wyżej zaprezentowanych relacji pozwoli nam na bardziej przejrzyste zaprojektowanie naszej aplikacji, a także skrócenie czasu kompilacji lub nawet linkowania.

Opera 9.6

bs.mechanik@gmail.com (bs.mechanik) — Thu, 09 Oct 2008 18:31:00 +0000

Wczoraj, 8 października, Opera Software wypuściła finalną wersję, kolejnej generacji, swojej przeglądarki internetowej. Z podstawowych zmian o jakich należy wspomnieć to ulepszenia w kliencie pocztowym Opera Mail, polegające na dodaniu trybu "połączenia o niskiej przepustowości". Ciekawą funkcjonalnością jest także możliwość przejrzenia kanału informacyjnego RSS przed dodaniem go do Kanałów. Ciekawa jest także Opera Link, umożliwiająca zschynchronizowanie swojej przeglądarki z Operą zainstalowaną na innym komputerze - wystarczy zarejestrować się w serwisie my.opera.com i wybrać opcję z menu Plik->Synchronizuj Operę. Wybrane ustawienia zostaną zapisane na serwerach Opera Software. Tutaj możemy sciągnąć pakiet instalacyjny przeglądarki.

różności w kopiowaniu ;)

bs.mechanik@gmail.com (bs.mechanik) — Sun, 21 Sep 2008 18:26:00 +0000

Operacja dość często wykonywana podczas edycji tekstu (w tym także i kodu źródłowego), to kopiuj/wklej. Sekwencja stara, jak pojęcie "edytor tekstu", więc przez te kilka lat istnienia, powstało kilka rozwiazań, które rozbudowywują tą dość ubogą kolekcję - także w środowisku Visual Studio. Pierwsza ze znanych mi opcji to clipboard ring, czyli możliwość wklejenia kilku ostatnio kopiowanych fragmentów kodu. Użycie bardzo proste: Ctrl+Shift+Ins. Wielokrotne skorzystanie z tej kombinacji powoduje przeskok, do wcześniejszych fragmentów. Drugie udogodnienie jest bardziej wizualne. Otwieramy zakładkę Toolbox (View->Toolbox), zaznaczamy tekst i przenosimy go do Toolboxa. Tylko tyle ;) Wklejenie wiąże się z operacją odwrotną: "wyciągnięcie" fragmentu do edytowanego tekstu. Interesujące jest to, że możemy przechować w ten sposób więcej niż jeden fragment kodu, a znajdujące się tam dane pozostaja nawet po zamknięciu Visuala.

deklaracja a definicja

bs.mechanik@gmail.com (bs.mechanik) — Wed, 17 Sep 2008 21:54:00 +0000

Przeglądając fora internetowe lub kursy dotyczące programowania, wiele razy spotkałem się z błędnym używaniem pojęć "deklaracja" i "definicja". Autorzy powyższych tekstów często nie zwracali uwagi na drobne, aczkolwiek istotne szczegóły, różniące te dwa pojęcia. Jak wygląda to w praktyce? Deklaracja wprowadza do zakresu informacje dotyczące wyłącznie nazwy danego typu. W jednym zakresie może wystąpić kilka deklaracji określonej nazwy, jednak muszą być one indentyczne. Wyjątkiem są tutaj deklaracje metod i statycznych pól składowych klas - mogą wystąpić tylko raz. W wielu przypadkach, deklaracja jest jednocześnie definicją, wyłączając:

deklaracje wyprzedzające
prototypy funkcji
instrukcje typedef, tworzące alias dla istniejącego typu
deklaracje statycznych składowych klas
zmienne zadeklarowane z użyciem modyfikatora extern

wszystkiego najlepszego!

bs.mechanik@gmail.com (bs.mechanik) — Fri, 12 Sep 2008 16:53:00 +0000

Prawie każda grupa zawodowa ma dzień, w którym obchodzi swoje święto. Szczególnie popularne było to w czasach PRL, kiedy to urządzano wiece i pochody na których chwalono się najnowszymi osiągnięciami gospodarki. Te czasy jednak bezpowrotnie (miejmy nadzieje ;) ) minęły, jednak niektóre tradycje zachowały się do dziś. Górnik, hutnik, nauczyciel... To czemu nie programista? ;) Jak podaje Wikipedia dziś przypada nam dzień programisty - 256 dzień roku kalendarzowego. Życzę więc wszystkim świętującym udanych kodów i jak najmniej bugów!