Tworzenie klas pochodnych: port programu SciMark2
From MorphOS Library
Grzegorz Kraszewski
Ten artykuł w innych językach: angielski
Contents
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 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 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:
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 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):
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
Najprościej zacząć tworzenie GUI kopiując po prostu przykład "HelloWorld". Nowe obiekty dodajemy wewnątrz funkcji build_gui(). 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ążenia metody OM_SET()), może też być odczytywalny (wymaga 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 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ć plik nagłówkowy klasy i jej kod. Klasa w tej postaci nadal nic nie robi, po prostu zawiera puste metody akcji programu i przeciąża metody OM_SET(), OM_NEW() i 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 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 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ą 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 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.
The next line of code runs the benchmark, by calling kernel_measureFFT() function from the original SciMark code. After the benchmark is done, the result is formatted and displayed in the result field using NewRawDoFmt(), which is a low-level string formatting function from exec.library and with the RAWFMTFUNC_STRING constant, it works just like sprintf(). It uses a fixed buffer of 128 characters (which is much more than needed, but adds a safety margin) located in the object instance data. Unsleeping the application and setting the status bar text to "Ready." ends the method.
The APPM_AllBenchmarks() method code is longer so it is not repeated here. The method is very similar to the single benchmark method anyway. The difference is it runs all 5 tests accumulating their results in a table. It also updates the progress bar after every benchmark. Finally it calculates a mean score and displays it.
Final Port
The complete source of SciMark2 MUI port
The program may be built by running make in the source directory.