Ostatnio zasugerowany został mi pewien eksperyment. Chodziło o porównanie kilku komputerów pod względem jednego zadania obliczeniowego. Długo zastanawiałem się nad konkretnym zadaniem, aż wreszcie wpadłem przypadkiem na pewien pomysł.
Chciałbym znaleźć zadanie, które jednocześnie pozwoli na dość dobre porównanie wielu komputerów, ale i pokaże czytelnikom tego bloga zawiłości związane z obliczeniami wykonywanymi na komputerze.

Cel zadania

Archiwum Klango jest dość spore. Postanowiłem więc je nieco skompresować. W tym celu zdecydowałem się na konwersję całego forum głosowego z MP3 96kbps (oryginał) do Opusa 32kbps. Zapewnia to relatywnie niewielki spadek jakości zważywszy na używane przez Klangowiczów mikrofony, a zmniejszy rozmiar całości z 46 do 15 GB.
Napisałem więc do tego prosty skrypt w Rubym i go uruchomiłem. Kiedy po czterech godzinach zadanie tylko raczkowało, zrozumiałem, że miałem tu zdecydowanie błędne podejście.

Z czego składa się konwersja audio

Konwersja audio z MP3 do Opusa składa się zasadniczo z dwóch faz. W pierwszej audio musi być zdekodowane z formatu MP3 do zapisu PCM, który następnie zrozumie enkoder, zamieniając go na Opusa. Nie jest możliwa bezpośrednia zmiana jednego formatu na drugi, bo stosują one zupełnie inne algorytmy.

Dekodowanie

Dekodowanie MP3 jest stosunkowo łatwym zadaniem. To między innymi prostota była jedną z poszukiwanych cech kodeka audio, pamiętajcie, że MP3 pochodzi z roku 1993, celując w różne wieże, później odtwarzacze przenośne itp. W tamtych czasach sprzęt nie cechował się współczesną mocą obliczeniową, tak więc poszukiwano rozwiązań, przy których odtworzenie formatu będzie tak mało wymagające, jak to tylko możliwe, kosztem jakości.
Jedną z cech, którymi miał się wyróżniać ten format, jest możliwość rozpoczęcia dekodowania od danego momentu, bez dekodowania całego pliku. W tym celu enkoder buduje pewną bazę informacji, które pozwalają później dekodować konkretne, wybrane fragmenty. Umożliwia to podzielenie zadania dekodowania pliku MP3 między wiele jednostek, np. mając 8 komputerów możemy zdekodować ten sam plik 8 razy szybciej.

Enkodowanie

Zakodowanie audio jest procesem dużo trudniejszym od jego odczytania. Wynika to z koncepcji dotyczącej formatów audio, w której plik powstaje raz, za to odtwarzany razy może być i tysiąc. Można więc ciężar obliczeniowy przenosić na producenta. Tak też na początku istnienia stratnej kompresji audio pliki w formatach typu MP3 potrafiły być przygotowywane wielokrotnie dłużej niż same trwały, za to odczytywane niemal w czasie rzeczywistym.
Opus, jak większość formatów stratnych, dzieli się na tak zwane ramki. Każda ramka to maleńki fragment pliku, np. 20ms. Enkoder pobiera taką ramkę z pliku źródłowego i ją analizuje. Następnie, zależnie od jej zawartości, dobierany jest odpowiedni sposób kompresji.
Przykładowo, jeśli nasze 20ms to 20ms ciszy, zamiast zapisywać informację: "cisza, cisza, cisza, cisza, cisza" (i tak 960 razy), idealny kodek mógłby napisać po prostu "To tylko cisza". W praktyce z wyjątkiem sytuacji wygenerowanych programowo, istnienie idealnej ciszy jest niemal niespotykane.
Enkoder musi więc się zastanowić nad dynamiką dźwięku, tym, co ucho wychwyci lepiej, a co gorzej. W tym celu potrzebuje informacji o tym, co było wcześniej, nie może dojść do sytuacji, gdy co chwilę dźwięk zaczyna brzmieć inaczej, bo enkoder uznał, że na czym innym oszczędzi.
W rezultacie enkodowanie jest procesem ciągłym. Nie można jednocześnie kodować pliku w kilku miejscach, zawsze przed kolejnym fragmentem trzeba zapisać poprzedni. W rezultacie, gdybyśmy mieli 8 takich samych komputerów, czas kodowania jednego pliku do formatu Opus byłby taki sam, jak gdybyśmy użyli tylko jednego komputera.
W powyższym przykładzie użyłem pewnego uproszczenia. Proces kodowania audio jest częściowo wątkowalny, to znaczy można pewne operacje wykonywać jednocześnie, np. jeden komputer mógłby analizować plik, drugi kompresować, a trzeci umieszczać w kontenerze OGG. Jako jednak, że w tym wypadku analiza stanowi jakieś 90 procent czasu, moglibyśmy ugrać na tym tylko 10 procent, czyli używając trzech komputerów, z kompresji trwającej pół godziny nie zrobimy 10 minut, a 27 minut.

Komputery to rdzenie

W powyższym przykładzie dzieliłem pracę między kilka komputerów. Dziś jednak zdecydowana większość procesorów to jednostki wielordzeniowe. Oznacza to, że potrafią one pracować jednocześnie nad kilkoma zadaniami.
Najlepiej wyobrazić sobie je jako wiele połączonych z sobą mniejszych procesorków. Tak więc, skoro przykładowo dekodować audio można w kilku miejscach na raz, ten sam procesor posiadający 8 rdzeni zrobi to 4 razy szybciej od jednostki posiadającej tylko 2 rdzenie.

Co więc zrobiłem źle?

Jak już pokazałem, dekodowanie audio jest procesem wielokrotnie szybszym od zapisu. W praktyce dekoder tworzył zapis PCM dużo szybciej, niż enkoder go odczytywał. Komputer wielordzeniowy nie miał więc niemal żadnej przewagi nad jednostką posiadającą rdzeń tylko jeden.
Nie jest możliwe ugranie żadnego znacznego przyspieszenia kompresji audio na wielu rdzeniach (tylko od ok. 5 procent do 15 procent zależnie od formatu). Nic nie stoi jednak na przeszkodzie, by kompresować w tym czasie wiele plików audio. Jeśli kompresujemy pliki o długości minuty, a rdzeni mamy na przykład 4, możemy albo w tej minucie skompresować tylko jeden plik, albo cztery na raz. Ale nie możemy skompresować jednego pliku w 15 sekund.

Przy okazji powstał znakomity test

Na potrzeby testu wydzieliłem tylko angielskie forum głosowe. To 9,69 GB danych, czyli ok. 241 godzin nagrań, co jednak ważniejsze, składających się z małych plików, łącznie tych plików jest 14535. Zawartość tych plików jest różna: prezentacje, notki, recytacje, muzyka, raz na mikrofonie wbudowanym, raz studyjnym. Czyli piękny przekrój wszystkiego.
Następnie wykonałem na trzech komputerach dwa testy. Pierwszy test polegał na uruchomieniu kompresji sekwencyjnie, jedną po drugiej. W podejściu drugim kompresowałem tyle nagrań na raz, iloma rdzeniami logicznymi dysponował procesor.

Test ma pewną słabość

Celowo użyłem zewnętrznego dysku SSD, by zmniejszyć wpływ samego nośnika na kompresję. Opisując jednak działanie enkodera, posłużyłem się pewnym uproszczeniem, przedstawiając cały proces jako zadanie dla procesora.
W praktyce, choć może się to wydawać paradoksem, w kompresji audio dość aktywnie wspomaga procesor układ graficzny, który dużo lepiej jest dostosowany do pracy na dużych danych, wyliczania sum kontrolnych, kompresji itp.
Nie jest to wpływ decydujący, szacuję go na kilka procent, jednak trzeba o sprawie pamiętać.

Dość gadania, czas na dane.

Platforma testowa

Komputery biorące udział w teście to:
1. Dell XPS 15 9550
Procesor Intel Core I7-6700HQ, 8 rdzeni logicznych, 3,5GHz.
2. MacBook Pro 13 2017
Procesor Intel Core I7-7560U, 4 rdzenie logiczne, 4,0GHz.
3. Dell XPS 15 9500
Procesor Intel Core I7-10750H, 12 rdzeni logicznych, 5,0GHz.

Przebieg sekwencyjny, jedno po drugim

Najszybciej z zadaniem poradził sobie mój nowy Dell XPS 9500, osiągając czas 6 godzin i 47 minut. Drugi był MacBook z czasem 7 godzin i 41 minut. Najniższe miejsce zajął XPS 9550, czas tutaj wyniósł 8 godzin i 3 minuty.
Jak warto tu zauważyć, MacBook teoretycznie posiadał gorszy procesor od XPS-a 9550, procesor kategorii U, czyli energooszczędnej. Miał mniej rdzeni, mniej pamięci podręcznej.
Jako jednak, że zadanie większościowo wymagało tylko jednego rdzenia, o wyniku decydowała niemal wyłącznie częstotliwość pracy i to dlatego MacBook przebił teoretycznie lepszego Della.

Przebieg równoległy, na raz tyle nagrań, ile rdzeni

Ponownie pierwsze miejsce osiągnął Dell XPS 9500, czas wyniósł 47 minut. Miejsce drugie należy do starszego XPS 9550, który dopiął swego w godzinę i 31 minut. MacBook sprawował się najgorzej, a cała kompresja zajęła mu aż 2 godziny i 42 minuty.
Jak widać, tutaj jednak zaważyła właśnie wielordzeniowość. XPS 9550, choć posiadający nieco wolniejszy procesor od MacBooka pod względem częstotliwości, właśnie dzięki ośmiu miast czterech rdzeni poradził sobie w czasie niemal dwukrotnie mniejszym.

A wnioski? Nie takie rdzenie piękne, jak je malują.

Wielordzeniowość procesora jest zagadnieniem bardzo złożonym. W tym wypadku podziałała na moją korzyść. Istnieją jednak dwa przypadki, w których by tak nie było.

Po pierwsze, gdybym miał kompresować tylko jeden, bardzo długi plik.

W tym wypadku mój nowy laptop okazał się najszybszy, ale mając wybrać między MacBookiem a poprzednim XPS-em, musiałbym wybrać komputer z Jabłuszkiem i to mimo faktu, że w teście drugim był niemal dwukrotnie wolniejszy.

Po drugie, gdybym nie miał odpowiedniego oprogramowania.

Pisanie aplikacji z myślą o procesorach wielordzeniowych jest zagadnieniem bardzo trudnym. Dzielenie aplikacji na równoległe wątki wymaga od programisty rozważenia sposobu zarządzania pamięcią czy wymianą danych. Nie wspominając o tym, że nawet jeśli jakiś problem da się podzielić na części, najpierw sprawę trzeba głęboko przemyśleć i wykombinować, jak to zrobić.
W rezultacie jestem przekonany, że wiele dostępnych na rynku narzędzi (nawet tych popularnych) do dzisiejszego mojego zadania podeszłoby w sekwencyjny sposób, czyli program miast kompresować dane od 47 minut, czyniłby to niemal 7 godzin.
Należy więc pamiętać, że naprawdę dla większości użytkowników lepiej wybrać 6/8 rdzeniowy procesor o lepszym taktowaniu, niż 24-rdzeniowy o gorszym. Bardzo niewiele zadań uda się podzielić na tak wiele części. A nawet jeśli się uda, mało który program weźmie to pod uwagę. I niestety nie zanosi się na to, by coś w tej kwestii miało się zmienić.

9 uwag do wpisu “Kontrtest i doskonały przykład na to, jak to jest z tymi wieloma rdzeniami i kiedy to jest fajne

  1. Ciekaw jestem jakby wypadły stacjonarki w tym teście, bo tam procek niby bardziej żre prąd. Inna rzecz, że np. u mnie cpu ma już swoje lata, bo to zaledwie czwarta generacja. Jeśli masz to w jakiejś formie, której nie trzeba kompilować, uruchamiać piętnastu programów no i jeśli chciałbyś się podzielić to chętnie sprawdziłbym jak to u mnie wygląda. Sprawdzilibyśmy czy faktycznie te procki laptopowe wolniejsze są, chociaż oczywiście u mnie coskolwiek starszy ten układ.

  2. warto dodać, że taktowanie procesora taktowaniu nie równe, nawet przy identycznych wartościach zegara. Taktowania procesora można porównywać tylko przy procesorach tego samego producenta i tej samej generacji.

  3. Najlepszą jakość w stosunku do rozmiaru obecnie ma właśnie Opus, zwłaszcza przy niskich bitrate.
    Ma jednak kilka wad. Najważniejszą jest, niestety, dość niewielkie wsparcie.
    Druga to ograniczenie próbkowania, które w wypadku profesjonalnej obróbki może ten format wykluczyć. Opus obsługuje tylko próbkowanie 16-bit 48kHz. Oznacza to, że jest to doskonały format do zachowywania audio przy jak najlepszej jakości w jak najmniejszym formacie, ale tylko wtedy, gdy to audio nie ma być dalej obrabiane.

    Formatem gorszym jakościowo od Opusa, ale o większych możliwościach edycyjnych, jest AAC.

  4. i tak mp3 wymiata, co prawda jest gorszy od AAC i opusa, ale popularość robi swoje. No i, dobre mp3 256 kbps jest i tak nie do odróżnienia od oryginału

  5. Z tym "nie do odróżnienia" bym uważał. 😉
    Wszystko zależy od sprzętu, słuchacza i nagrania. Jakaś mowa czy piosenka w stylu obecnych, pewnie fakt.
    Ale im bardziej nagranie złożone, panoramiczne i dopracowane, tym trudniej je dobrze skompresować. Więc, tak, da się znaleźć przykłady, gdy jest odróżnialne nawet bez wielkiego doświadczenia.
    Inna sprawa, że w większości zastosowań MP3@128 spokojnie wystarczy.

  6. powiem tak. Realizator, inżynier dźwięku raczej rozpozna. Ale widziałem testy, w których osoba, która uważa się za audiofila, bynajmniej może nie ma w tym temacie jakiegoś wielkiego wykształcenia, ale jednak się na tym zna, testowała jedno nagranie we flacu i mp3 128. I to ten człowiek sam wybierał nagranie, żeby nie było wątpliwości, że je dobrze zna i wyłapie każde niuanse. Fakt, że użyłem dość dobrego kodeka, lepszego niż lame. Test, no cóż, wypadł jak można się spodziewać. A i tak test był robiony źle, bo osoba wiedziała, czego słucha, której wersji, wiec autosugestia, ale i tak nie pomogła w odróżnieniu. No do tego dobry sprzęt, drogi sprzęt był w użyciu. Chociaż wiadomo, znam mp3 128, które już będzie się gotować. Ale sporo zależy też od użytego kodeka.

  7. Sporo zależy od kodeka, ale przede wszystkim właśnie nagrania, karty dźwiękowej itp. Są na Eltenie mądrzejsi ode mnie, którzy lepiej to wyjaśnią. 😉

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *