View source for Tworzenie klas pochodnych: port programu SciMark2

''Grzegorz Kraszewski''
----
<small>Ten artykuł w innych językach: [[MUI Subclassing Tutorial: SciMark2 Port|angielski]]</small>

==Program SciMark2==
Często poradniki i przewodniki programowania zanudzają czytelników bezużytecznymi teoretycznimi przykładami. W tym przewodniku przeportujemy na MorphOS-a konkretny program, dodając mu interfejs graficzny w MUI. Naszą ofiarą padnie [http://math.nist.gov/scimark2/index.html SciMark 2]. SciMark2 to jeden z wielu programów mierzących wydajność procesora i pamięci. Aby je zmierzyć SciMark2 przeprowadza serię testów opartych na typowych obliczeniach naukowych, takich jak szybka transformata Fouriera, dekompozycja macierzy na macierze LU, mnożenie macierzy rzadkich i tak dalej. Program został pierwotnie w języku Java w celu porównywania wydajności maszyn wirtualnych tego języka. Następnie przepisano go w języku C (a także w wielu innych językach programowania). Kod źródłowy w C jest dostępny na [http://math.nist.gov/scimark2/download_c.html stronie domowej] projektu.

Kod źródłowy używa wyłącznie standardowych funkcji ANSI C, więc kompiluje się "od ręki" na MorphOS-ie po uruchomieniu znajdującego się w archiwum ''Makefile''. Trzeba jedynie zmienić linię ''$CC = cc'' na ''$CC = gcc'', bo tę ostatnią nazwę nosi standardowy kompilator w naszym systemie. Rezultatem kompilacji jest typowa konsolowa aplikacja. Oto przykładowe wyniki działania SciMarka2 na Pegasosie 2 z procesorem G4:


[[File: scimark_cli_noopt.png|center]]


Wyniki są niezbyt zachwycające. Bierze się to z faktu, że ''Makefile'' nie włącza w kompilatorze żadnych optymalizacji. Najprościej jest dodać linię ''$CFLAGS = -O3'' pod ''$CC = gcc''. Warto też zlinkować program z biblioteką ''libnix'' (linkowana statycznie biblioteka emulująca środowisko uniksowe, patrz [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C.2B.2B_Libraries|Standard C and C++ Libraries]]) dodając ''-noixemul'' do ''CFLAGS'' i ''LDFLAGS''. Po ponownej kompilacji i uruchomieniu wyniki ulegają znaczącej poprawie (program skompilowano kompilatorem GCC 4.4.4 z oficjalnego SDK):


[[File: scimark_cli_opt.png|center]]


To doświadczenie pokazuje jak bardzo ważne jest korzystanie z optymalizacji kodu, zwłaszcza w programach wykonujących dużo obliczeń. Zoptymalizowan kod jest '''ponad 4 razy szybszy'''!


==Przegląd kodu==
Oryginalny kod źródłowy jest logicznie podzielony na moduły. Pięć plików: ''FFT.c'', ''LU.c'', ''MonteCarlo.c'', ''SOR.c'' i ''SparseCompRow.c'' zawiera pojedyncze testy obliczeniowe. Pliki ''array.c'' i ''Random.c'' zawierają funkcje pomocnicze używane w testach. W plik ''Stopwatch.c'' z kolei znajdują się procedury pomiaru czasu. Plik ''scimark2.c'' zawiera funkcję ''main()'' i tekstowy interfejs programu.

Planowany interfejs graficzny powinien pozwalać użytkownikowi na uruchomienie każdego testu oddzielnie, albo wszystkich po kolei. Program posiada też opcję ''-large'', która zwiększa rozmiary danych dla poszczególnych testów tak, że nie mieszczą się w pamięci podręcznej procesora. Dobrą zasadą przy portowaniu programów jest ograniczenie modyfikacji oryginalnych plików do minimum. Dzięki temu znacznie ułatwiona jest aktualizacja portu, kiedy ukaże się nowa wersja oryginału. W przypadku SciMarka wystarczy zastąpić tylko jeden plik, mianowicie ''scimark2.c''. W zaawansowanym porcie możnaby też zastąpić ''Stopwatch.c'' kodem bezpośrednio używającym ''timer.device'', co zwiększyłoby dokładność pomiaru czasu. To zagadnienie jednakże nie mieści się w zakresie tematycznym artykułu.

Bliższe przyjrzenie się plikowi ''scimark2.c'' ujawnia, że zawiera on obiekt ''Random'' (jest to struktura zdefiniowana w pliku ''Random.h''), który jest używany przez wszystkie 5 testów. W oryginalnym kodzie jest on tworzony funkcją ''new_Random_seed()'' na początku programu i usuwany funkcją ''delete_Random()'' na jego końcu. Najlepszym miejscem na ten obiekt w zMUI-fikowanej wersji są dane obiektu aplikacji. Wtedy można go zainicjalizować w konstruktorze aplikacji (metoda ''OM_NEW()'') a usunąć w destruktorze (metoda ''OM_DISPOSE()''). Te dwie metody należy więc w klasie pochodnej od ''Application'' przeciążyć.


==Projekt intrerfejsu graficznego==
[[File:scimark_gui.png|left]] Nie ma oczywiście "jedynie słusznego" projektu GUI dla SciMarka. Prosty projekt, używający ograniczonej ilości klas MUI, pokazany jest na ilustracji po lewej. Mamy tam 5 przycisków do uruchamiania poszczególnych testów i szósty do automatycznego wykonania wszystkich po kolei. Wszystkie te przyciski są obiektami klasy ''Text''. Po prawej znajdują się gadżety wyświetlające wyniki testów. One również są klasy ''Text'', mają jedynie inny zestaw atrybutów. Przycisk "Large Data", oczywiście również klasy ''Text'', jest przyciskiem dwustanowym. O dziwo pasek stanu na dole nie jest klasy ''Text'' ale klasy ''Gauge'', dzięki czemu będzie można w nim wyświetlać postęp wykonywania testów w czasie wykonywania całego zestawu. Poziome paski oddzielające pojedyncze testy od testu zbiorczego są instancjami klasy ''Rectangle''. Do tego mamy trzy niewidoczne obiekty klasy ''Group''. Pierwszy to grupa pionowa będąca głównym obiektem okna. Ma ona dwie podgrupy. Górna to grupa tablicowa o dwóch kolumnach, w której znajdują się przyciski testów i pola wyników. Grupa dolna, będąca grupą poziomą, zawiera przycisk "Large Data" i pasek stanu.

Najprościej zacząć tworzenie GUI kopiując po prostu [["Hello world!" w MUI|przykład]] "HelloWorld". Nowe obiekty dodajemy wewnątrz funkcji ''build_gui()''. [http://krashan.ppa.pl/morphzone_tutorials/scimark2_mui.c Zmodyfikowany przykład] jest gotowy do skompilowania i uruchomienia. Oczywiście nie jest to kompletny program, a jedynie model interfejsu graficznego.

W kodzie można zauważyć, że funkcja ''build_gui()'' nie zawiera w sobie całego kodu tworzącego interfejs. Kod dla niektórych obiektów został przeniesiony do oddzielnych funkcji wywoływanych z głównego wywołania funkcji ''MUI_NewObject()''. Podzielenie funkcji tworzącej GUI na fragmenty ma szereg zalet:
* Większa czytelność kodu i prostsze wprowadzanie zmian. Pojedyncze wywołanie ''MUI_NewObject()'' staje się szybko bardzo długie w miarę rozbudowy interfejsu. Edycja tak dużej funkcji rozciągającej się na kilka ekranów edytora jest niewygodna. Dodawanie i usuwanie obiektów staje się koszmarem, nawet jeżeli wcięcia w kodzie są stosowane konsewentnie. Z drugiej strony taka funkcja może mieć 10 i więcej poziomów wcięć, co również czyni ją trudną w czytaniu.
* Zmniejszenie wielkości kodu. Zamiast powtarzać bardzo podobny kod wiele razy, na przykład przyciski różniące się jedynie etykietami, można wywołać podprogram z tekstem etykiety jako parametrem. 
* Debugowanie. Bywa, że MUI odmawia stworzenia obiektu aplikacji z powodu jakiegoś błędnego taga albo jego wartości. Jeżeli główne wywołanie ''MUI_NewObject()'', tworzące obiekt aplikacji, jest podzielone na szereg mniejszych funkcji, łatwo wyizolować błąd wstawiając kilka ''Printf()''-ów w tychże funkcjach.


==Metody i atrybuty==
Zaprojektowany właśnie intefrejs graficzny do SciMarka definiuje 6 akcji, jakie można wykonać w tym programie. Mamy pięć akcji polegających na wykonaniu pojedynczego testu, oraz szóstą, która wykonuje wszystkie testy po kolei i oblicza łączny wynik. Akcje te będą bezpośrednio odpowiadały metodom klasy utworzonej z klasy ''Application''. GUI określa nam także jeden atrybut, związany z przyciskiem ''LargeData''. Przypomnę, że określa on rozmiary danych dla testów. Ponieważ metody nie wymagają żadnych parametrów, nie ma potrzeby definiowania ich struktur. Jakikolwiek atrybut może być używany jako wartość początkowa konstruktora, może być ustawialny (wymaga [[Przeciążanie metody OM_SET()|przeciążenia metody OM_SET()]]), może też być odczytywalny (wymaga [[Przeciążanie metody OM_GET()|przeciążenia metody OM_GET()]]). Nasz nowy atrybut, nazwany ''APPA_LargeData'', wymaga jedynie możliwości ustawiania. W konstruktorze możemy go domyślnie ustawić na ''FALSE'', ponieważ na starcie programu przycisk "LargeData" jest wyłączony. Możliwość odczytu wartości atrybutu nie jest potrzebna, bo jest on odczytywany wyłącznie wenątrz klasy aplikacji, można więc bezpośrednio odwołać się do odpowiedniego pola danych obiektu.

Pisząc program warto umieszczać każdą klasę w oddzielnym pliku. Ułatwia to utrzymanie modułowości kodu, pozwala również na [[Rzut oka na BOOPSI#Klasy|ukrycie danych prywatnych klasy]]. Pociąga to sa sobą konieczność napisania ''makefile'', ale oryginalny kod SciMarka również składa się z kilku pilków, więc tak, czy inaczej, jest to nieuniknione. Stosując się do przedstawionych powyżej wskazówek projektowych można napisać [http://krashan.ppa.pl/morphzone_tutorials/scimark2_application.h plik nagłówkowy] klasy i jej [http://krashan.ppa.pl/morphzone_tutorials/scimark2_application.c kod]. Klasa w tej postaci nadal nic nie robi, po prostu zawiera puste metody akcji programu i przeciąża metody ''[[Przeciążanie metody OM_SET()|OM_SET()]]'', ''[[Przeciążanie konstruktorów|OM_NEW()]]'' i ''[[Przeciążanie destruktorów|OM_DISPOSE()]]''. Pisanie takiego szkieletu klasy jest nudną mechaniczną pracą, więc można ją zwalić na komputer. W istocie, przykładowy kod został wygenerowany narzędziem  [http://downloads.morphzone.org/find.php?find=chocolatecastle ChocolateCastle]. Niestety ChocolateCastle jest wciąż w wersji beta, więc kilka drobnych poprawek trzeba było wprowadzić ręcznie.

Następnym krokiem w projektowaniu programu jest połączenie metod i atrybutów z elementami interfejsu graficznego używając [[Programowanie sterowane zdarzeniami, notyfikacje#Notyfikacje w MUI|notyfikacji]]. Notyfikacje można ustawiać dopiero gdy zarówno źródło jak i cel notyfikacji są istniejącymi obiektami. W kodzie SciMarka są one ustawiane po wykonaniu funkcji ''build_gui()''. Wszystkie przyciski testów mają bardzo podobne notyfikacje, dlatego tutaj pokazana jest tylko jedna:

 DoMethod(findobj(OBJ_BUTTON_FFT, App), MUIM_Notify, MUIA_Pressed, FALSE,
  App, 1, APPM_FastFourierTransform);

Przycisk "Large Data" ma notyfikację ustawiającą odpowiadający mu atrybut:

 DoMethod(findobj(OBJ_BUTTON_LDATA, App), MUIM_Notify, MUIA_Selected, MUIV_EveryTime,
  App, 3, MUIM_Set, APPA_LargeData, MUIV_TriggerValue);

Obiekty źródłowe notyfikacji są [[Wyszukiwanie obiektów w drzewie|dynamicznie wyszukiwane]] w drzewie obiektów aplikacji (makro ''findobj()''). Zaoszczędza to potrzeby definiowania dla nich globalnych wskaźników.


==Implementacja metod==
Pięć metod, które zawierają główną funkcjonalność SciMarka, jest do siebie bardzo podobnych. Dlatego zacytowano tu tylko jedną, wykonującą test szybkiej transformaty Fouriera:

 IPTR ApplicationFastFourierTransform(Class *cl, Object *obj)
 {
   struct ApplicationData *d = INST_DATA(cl, obj);
   double result;
   LONG fft_size;
 
   if (d->LargeData) fft_size = LG_FFT_SIZE;
   else fft_size = FFT_SIZE;
 
   SetAttrs(findobj(OBJ_STATUS_BAR, obj),
     MUIA_Gauge_InfoText, (LONG)"Performing Fast Fourier Transform test...",
     MUIA_Gauge_Current, 0,
   TAG_END);
 
   set(findobj(OBJ_RESULT_FFT, obj), MUIA_Text_Contents, "");
   set(obj, MUIA_Application_Sleep, TRUE);
   result = kernel_measureFFT(fft_size, RESOLUTION_DEFAULT, d->R);
   NewRawDoFmt("%.2f MFlops (N = %ld)", RAWFMTFUNC_STRING, d->Buf, result, fft_size);
   set(findobj(OBJ_RESULT_FFT, obj), MUIA_Text_Contents, d->Buf);
   set(obj, MUIA_Application_Sleep, FALSE);
   set(findobj(OBJ_STATUS_BAR, obj), MUIA_Gauge_InfoText, "Ready.");
   return 0;
 }

Metoda używa [[Locating Objects in the Object Tree|dynamicznego wyszukiwania obiektów]] w celu uzyskania dostępu do obiektów MUI.

Pierwszym krokiem jest ustalenie rozmiaru danych dla testu, zgodnie z wartością pola ''d->LargeData''. Pole to jest aktualizowane przy zmianie atrybutu ''APPA_LargeData'', który z kolei jest powiązany notyfikacją z przyciskiem "Large Data". Następnie jest kasowana zawartość paska stanu i wpisywana jest tam informacja dla użytkownika o wykonującym się teście. Pole wyniku testu jest również czyszczone.

Z kolei aplikacja wprowadzana jest w stan zajętości (ang. ''busy''). Należy to czynić zasze, gdy aplikacja może nie reagować na poczynania użytkownika dłużej niż, powiedzmy, pół sekundy. Ustawienie atrybutu ''MUIA_Application_Sleep'' na wartość ''TRUE'' blokuje GUI i wyświetla "zajęty" wskaźnik myszy gdy okno programu jest aktywne. Oczywiście generalnie lepszym wyjściem byłoby uruchomienie testu w podprocesie, ale w teście wydajności nie ma to większego sensu. Tak czy inaczej użytkownik musi zaczekać na wykonanie testu zanim uruchomi kolejny. Jedynym problemem z punktu widzenia użytkownika jest to, że nie da się przerwać testu w trakcie jego wykonywania. Dla prostoty kodu pozostawiono ten problem nierozwiązany. Uruchamiając test mocy procesora oczekujemy, że obciąży on komputer całkowicie, kilka sekund zablokowania GUI programu nie jest w tym przypadku problemem. 

Następna linia kodu uruchamia właściwy test, wywołując funkcję ''kernel_measureFFT()'' z oryginalnego kodu SciMarka. Po zakończeniu testu otrzymany rezultat jest formatowany z użyciem funkcji ''NewRawDoFmt()''. Jest to funkcja systemowa z ''exec.library''. Użyta ze stałą ''RAWFMTFUNC_STRING'' działa tak samo jak standardowy ''sprintf()''. Do formatowania zastosowano bufor o stałej długości 128 bajtów, więcej od rzeczywistej możliwej długości tekstu, ale warto zawsze zostawić margines bezpieczeństwa. Sformatowany tekst wyświetlany jest w polu rezultatu testu. Następnie aplikacja jest "budzona z uśpienia" a tekst na pasku stanu jest zmieniany na "Ready."

Metoda ''APPM_AllBenchmarks()'' jest znacznie dłuższa, dlatego jej kod nie został zamieszczony w artykule. Metoda ta wywołuje kolejno wszystkie 5 testów, gromadząc ich wyniki w tablicy. Po każdym wykonanym teście aktualizowany jest pasek postępu. Na zakończenie wyliczany jest łączny wynik testów i wyświetlany w polu wyników.


==Gotowy port programu==
[http://krashan.ppa.pl/morphzone_tutorials/scimark2_mui.lha Kompletny kod źródłowy SciMarka2 w wersji MUI]

Program można skompilować wydając polecenie ''make'' w katalogu z kodem źródłowym.