Optymalizacja FFdecsa
FFdecsa to szybka implementacja algorytmu deszyfruj±cego CSA dla pakietów MPEG TS. Algorytm ten jest u¿ywany w telewizji cyfrowej DVB do szyfrowania obrazu video. Korzyst± z niego miêdzy innymi posiadacze kart DVB bez sprzêtowego dekodera, którzy u¿ywaj± VDR do ogl±dania telewizji satelitarnej.
Jak podaje autor, jego implementacja jest ponad 800% szybsza ni¿ najszybsza, któr± znalaz³. Wyja¶nia to nazwê programu, której skrót jest rowiniêty w jednym z pytañ w FAQ (do³±czonym do ¼róde³). Dziêki takiemu wzrostowi wydajno¶ci zyskujemy miêdzy innymi nastêpuj±ce w³a¶ciwo¶ci:
- deszyfracja strumienia 8Mb/s zabiera 5% czasu procesora zamiast 40%,
- deszyfracja ca³ego transpondera (z wszystkimi kana³ami lub z du¿ym strumieniem HDTV) nios±cego 38Mb/s zabiera 23% czasu procesora zamiast 190% (>100%, nie do odszyfrowania w czasie rzeczywistym),
- bardzo wolny procesor mo¿e odkodowaæ jeden kana³ bez problemów.
Autor zadba³ o dobr± dokumentacjê swojego programu. Warto przeczytaæ do³±czone do ¼róde³ plik README oraz dokumnety w katalogu docs. Dostarcz± nam one odpowiedzi na wiêkszo¶æ nasuwaj±cych siê pytañ ;)
Istniej± dwa sposoby optymalizacji FFdecsa. Przed kompilacj± mo¿emy wyedytowaæ plik Makefile, aby dostosowaæ flagi kompilatora. Podstawa to zmiana architektury procesora (-march). Drug± opcj± jest zmiana strategii grupowania bitowego. Ma to ogromny wp³yw na wydajno¶æ algorytmu, a nie jest trudne do wykonania. Wystarczy w pliku FFdecsa.c zmieniæ definicjê PARALLEL_MODE. Dostêpne warto¶ci, z których mo¿emy wybieraæ zdefiniowane s± w tym samym pliku nieco wy¿ej.
Aby uzyskaæ najlepsz± wydajno¶æ (oraz z ciekawo¶ci) skompilowa³em FFdecsa dla ka¿dego dostêpnego wariantu PARALLEL_MODE. Po kompilacji mo¿na wywo³aæ program FFdecsa_test, który przetestuje poprawno¶æ dekrypcji i oszacuje jej prêdko¶æ. Dla uzyskania lepszych rezultatów dobrze jest przeprowadziæ testy na bezczynnej maszynie i podwy¿szyæ priorytet zadania przy pomocy polecenia nice (alternatywnie mo¿na wywo³aæ 'make test'):
nice -n -19 ./FFdecsa_test
Dla procesora AMD Athlon XP 2000+ (1,67MHz) uzyska³em poni¿sze wyniki.
| PARALLEL_32_4CHAR | 6.79 Mbit/s | 4615.33 pkts/s |
| PARALLEL_32_4CHARA | 6.19 Mbit/s | 4211.85 pkts/s |
| PARALLEL_32_INT | 103.35 Mbit/s | 70216.50 pkts/s |
| PARALLEL_64_8CHAR | 7.95 Mbit/s | 5407.34 pkts/s |
| PARALLEL_64_8CHARA | 7.74 Mbit/s | 5258.37 pkts/s |
| PARALLEL_64_2INT | 36.58 Mbit/s | 24850.89 pkts/s |
| PARALLEL_64_LONG | 85.68 Mbit/s | 58208.91 pkts/s |
| PARALLEL_64_MMX | 132.96 Mbit/s | 90326.34 pkts/s |
| PARALLEL_128_16CHAR | 10.37 Mbit/s | 7050.85 pkts/s |
| PARALLEL_128_16CHARA | 4.54 Mbit/s | 3085.76 pkts/s |
| PARALLEL_128_4INT | 63.87 Mbit/s | 43391.91 pkts/s |
| PARALLEL_128_2LONG | 30.87 Mbit/s | 20975.88 pkts/s |
| PARALLEL_128_2MMX | 14.53 Mbit/s | 9874.25 pkts/s |
| PARALLEL_128_SSE | Naruszenie ochrony pamiêci | |
Najlepszym wyborem (podobnie jak u autora) jest tryb PARALLEL_64_MMX. Prawdopodobnie bêdzie tak w przypadku wiêkszo¶ci procesorów. Tryb PARALLEL_32_INT nie okaza³ siê wiele gorszym, a skoro jest bardziej przeno¶nym, czêsto mo¿e byæ lepszym wyborem (dlatego jest warto¶ci± domy¶ln±). PARALLEL_128_SSE spowodowa³ naruszenie ochrony pamiêci i w sumie nie bardzo wiem dlaczego (bug gcc? specyfika instrukcji sse w athlonie?). Polecam przeprowadzenie testów u siebie choæby dla kilku wyró¿niaj±cych siê trybów :D
5 komentarzy
Napisz komentarz