Tworzenie klas pochodnych: port programu SciMark2

From MorphOS Library

Grzegorz Kraszewski

Ten artykuł w innych językach: angielski

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:


Scimark cli noopt.png


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):


Scimark cli opt.png


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

Scimark gui.png
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 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.

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

Kompletny kod źródłowy SciMarka2 w wersji MUI

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

Retrieved from "https://library.morph.zone/index.php?title=Tworzenie_klas_pochodnych:_port_programu_SciMark2&oldid=1248"