Opcje zaawansowane nigdy nie będą przyjazne

Wiecie, że ten blog ma już 4 lata? Tak się śmiesznie złożyło, że założyłem go 11 listopada 2016, a więc razem z dniem Niepodległości, świętuję co roku taki mały jubileusz. Myślę, że z racji na tę rocznicę, należy coś napisać.

Obok mnie stoi komputer stacjonarny, na którym instaluje się system Windows 10. I przy okazji wspomniałem dawne czasy.

Ja uwielbiałem instalację Windowsa XP. Przyznać tu należy, że nigdy nie wypracowałem idealnej metody jego stawiania bezwzrokowego. Można użyć instalacji nienadzorowanej, ale to masa roboty. Można użyć 16-bitowego SCR, ale wymagany jest syntezator sprzętowy. Ostatecznie najlepszym rozwiązaniem wymyślonym przeze mnie było podłączanie swojego laptopa do portu RS232 komputera docelowego, odpalanie na nim scr, na swoim laptopie zaś Puttego i po prostu pozwalanie NVDA odczytywać komunikaty. Ale, umówmy się, nie było to jakoś wybitnie dobre rozwiązanie.
Mimo to instalacja XP była procesem niezwykle… klimatycznym, zawsze ją tak odczuwałem. Wciskanie klawiszy na klawiaturze w celu akceptowania licencji (F8 zdaje się), wybór dysku literą C, no miało to coś w sobie. Sam proces był wtedy podzielony na wiele etapów, a w trakcie instalacji pojawiały się pokazy i prezentacje innowacyjnego, nowoczesnego systemu Windows XP. Nie do przecenienia jest też muzyczka słyszana podczas pierwszej konfiguracji, choć usłyszenie jej było sporym wyczynem, gdyż prawdopodobieństwo, że Windows XP posiada sterowniki do naszej karty dźwiękowej, wynosiło jakoś z 1 na 100.

W ogóle Windows XP był dla mnie ostatnim systemem, przy którym w kontakcie z komputerem odczuwało się tę informatyczną magię. Potem wyszedł Windows 7, moim zdaniem system bardzo dobry, ale już obnażony z tej atmosfery nowości i tajemniczości, już zbyt próbował być przyjazny dla użytkownika, zbyt wiele robił w tle.

No i teraz mamy Windowsa 10. W trakcie instalacji widzimy okna o treści "Mamy teraz pewną ważną konfigurację do wykonania", musimy się męczyć, by nie zakładać konta Microsoft i w ogóle cały proces wygląda mi jak wielki wstęp do "szpiegowania by Microsoft", miast stawiania systemu operacyjnego.
Zastanawiam się, dlaczego Microsoft zdecydował się na sprawienie, by instalacja wyglądała, jakby przed komputerem siedział szary użytkownik, który w dodatku ma chyba jakieś problemy z głową, a jego wiedza informatyczna wynosiła mniej niż zero. Z doświadczenia wiem, że i tak nigdy przeciętny użytkownik nie odważy się stawiać tego systemu samemu, chociażbym mu i dopłacił.
Informatyka próbuje udawać prostą i przyjazną, ale to, co w 2005 roku było dla większości ludzi czarną magią, czarną magią pozostało. I prawdopodobnie będzie tak już zawsze.
Microsoft i inne firmy, udając przyjazne instalatory i kreatory, zamieniając "Bluescreena" na ekran ze smutną buźką, usuwając lub ukrywając narzędzia diagnostyczne, tylko utrudniają informatykom życie i sprawiają, że czują się oni traktowani jak idioci. A problemów i tak to nie rozwiązało, nie rozwiązuje i nigdy nie rozwiąże.

10 pytań przyszłych programistów

Nie, nie chodzi mi o kolejny z tysięcy poradnik o tym, jak nauczyć się Rubiego w 5 minut (nie da się nauczyć Rubiego w 5 minut) albo jak zostać programistą w tydzień (nie da się zostać programistą w tydzień). Zauważyłem jednak w naszym środowisku, tak Eltenowym jak poza-Eltenowym, pewną ciekawą tendencję, którą sprowadzę do twierdzenia "umiem programować". I fajnie, ale… No właśnie, ale.
Nie wiem, czy to stereotyp niewidomego informatyka, czy też fakt, że wymusza się na nas nieco większą wiedzę o zawiłościach komputerowych w stosunku do przeciętnego użytkownika widzącego, czy też inne czynniki, ale świadomość komputerowa bywa dość spora. Pewna garstka z nas, bo jednak grupa ta nie jest bardzo liczna, zaczyna myśleć o nauce programowania. I w tym momencie dzieje się coś dziwnego.
Mamy więc ludzi, którzy naprawdę zdobyli jakąś wiedzę, ale na tym się skończyło, bo albo mają wspaniałe teorie rewolucji świata, które nikną w zderzeniu z rzeczywistością, albo poświęcają pięć lat na wspaniały projekt, który jakoś nigdy nie doczekuje się światła dziennego, albo wciąż czekają na wenę/inspirację/motywację, te jakoś jednak nie przychodzą. I w rezultacie, gdy myślę o niewidomych programistach, prawdziwych programistach, na myśli mam tylko kilka nazwisk.
Pomyślałem sobie więc, że napiszę serię artykułów (ha ha ha, naprawdę wierzycie, że będę miał wenę na pisanie kolejnych), które poświęcę temu, jak zacząć swoją przygodę z programowaniem. Nie chcę, by był to kolejny tutorial w stylu "najpierw naucz się C", ale garść konkretnych porad wynikłych z mojej obserwacji tematu.

Nie mam jeszcze tyle doświadczenia w branży programowania, ile bym chciał. Z wyjątkiem jednak Grzegorza Złotowicza, chyba na Eltenie styczność z tematem miałem największą. Mam za sobą i duży projekt (tu Elten), i kilka mniejszych, także różne zlecenia płatne i współprace nad kodem. I w oparciu o to nasuwa się mi kilka wniosków.
Od razu uczulam, że wpis może być zbyt techniczny, nie przestraszcie się tego. Zakładam jednak, że jako osoby tematem zainteresowane, wiecie już, co to jest C++, innymi słowy to nie jest wpis dla osób, które nie mają o temacie zielonego pojęcia, tu wymagane jest przynajmniej seledynowe. 🙂
Na początek chciałbym odpowiedzieć na 10 najczęstszych pytań, które albo się gdzieś po forach zadaje, albo w domyśle ma się na myśli, albo które mi na myśl przychodzą. Przy założeniu, że pojawią się jakieś komentarze, a mi pomysł z głowy nie wyparuje, w następnym wpisie chciałbym odpowiedzieć na wasze uwagi i skupić się na dziesięciu najczęściej popełnianych na początku błędach.
Dobra, spróbujmy.

1. Czy programista musi być dobry z matematyki?

To pytanie staje się niemal tak nudne, jak szablonowe "How are you", ale wciąż jest kwestią sporów. Kwestią zupełnie dziwną o tyle, że odpowiedź jest po prostu oczywista. Przykro mi, ale tak.
Wiem, że pojawią się pewnie osoby, które zaczną argumentować, że to bzdura, że one sobie radzą, że… Nie, programista musi dobrze sobie radzić z matmą. I nie chodzi tu nawet o rozwiązywanie układów równań różniczkowych, choć na pewnym poziomie zagadnienia np. teorii sygnałów i taka zdolność się przyda. Chodzi jednak o pewną wyobraźnię.
Nie jest ważne, czy programować będziecie w C, czy w Pythonie, na jakim poziomie złożoności i w jakiej branży, elementy logiki, systemu binarnego, obliczeń i oszacowań po prostu okażą się w waszym wypadku niezbędne. Na pewno traficie czasem na potrzebę oszacowania złożoności danego algorytmu albo podzielenia zadania na wątki. Nie ma rady, komputery są na matematyce zbudowane i od matematyki nie uciekną.
Oczywiście pytaniem innym jest, co znaczy "bycie dobrym z matematyki". Znam osoby, które miały z matury rozszerzonej z matematyki naprawdę wyniki średnie, a rozwiązywały od ręki takie zadania, nad którymi ja musiałbym posiedzieć przynajmniej kilka godzin. Znam też osoby, które uzyskiwały świetne wyniki z testów, ale kiedy stawały przed prawdziwym obliczeniem (nie schematycznym zadaniem ze szkoły), pojawiał się problem.
Ale matematyka jako taka jest w programowaniu niezbędna.

2. Od jakiego języka zacząć?

Od jakiegokolwiek, naprawdę. Najbardziej bawi mnie sytuacja, gdy dana osoba zamiast zabrać się do nauki, spędza pół roku na rozważaniu za i przeciw różnych technik, zaczyna jedno i zaraz przerywa, coś tam napisze w języku A, by przejść na B, C i D.
Jedyne ważne jest to, by był to język mainstreamowy, najlepiej należący do najpopularniejszych. Wg portalu Toward’s Data Science, w roku 2020 najpopularniejsze języki to, w kolejności, JavaScript, Python, Java, Go, TypeScript, C++, Ruby, PHP, C# i C. W tej mainstreamowości chodzi o to, by łatwo było znaleźć poradniki i przykłady danego języka, a nie męczyć się z szukaniem odpowiedzi, jak napisać coś w języku znanym przez trzydziestu ludzi w Polsce.
Jako programiści i tak będziecie musieli w praktyce poznać przynajmniej kilka języków biegle, a znośnie właściwie ze 10-20. Będzie jeszcze czas na wybranie tych ulubionych, tym czasem zastanawianie się, co wolicie na samym początku, początek ten tylko oddala.
Są kłótnie i spory, czy lepiej zaczynać od języków strukturalnych czy obiektowych, poznać najpierw podstawy, czy zrobić od razu coś dużego i do podstaw wrócić. Szkół jest tyle, że i tak nie zadowolicie wszystkich, więc spróbujcie po prostu zadowolić siebie.

3. Ile muszę się uczyć przed napisaniem pierwszego programu?

Jak najmniej, bo to pisząc się uczy. I nie ma na to innego sposobu. Nigdy nie poznacie programowania tak naprawdę, jeśli nie wydacie pierwszego, drugiego, dziesiątego projektu. Jeśli spojrzycie na swój kod z przed trzech lat i nie powiecie sobie "Jaki głupek to pisał?", to znaczy tylko tyle, że niczego się nie nauczyliście.
Fakt, dobrze jest rozplanować pracę, ale nie stworzycie dobrego planu bez doświadczenia. W programowaniu są różne wzorce projektowe, struktury danych, rozwiązania i biblioteki. Ale nie ma żadnego poradnika, który dokładnie wam wyjaśni, jakie rozwiązanie pasuje do jakiego problemu.
Po pierwsze dlatego, że taka książka miałaby z milion stron, a po drugie, że to także od waszego indywidualnego stylu będzie zależało.

4. A ten pierwszy program, to co to ma być?

Coś małego, użytecznego, ale prostego. Często słyszę o programistach (choć akurat widzących), których gubią nadmierne ambicje co do pierwszego projektu.
Jeśli zaczniecie od pisania na przykład nowego edytora dokumentów PDF albo klienta Facebooka, to raczej daleko nie zajdziecie. A przecież są inne, małe zadania, które można sobie uprościć.
I co, że na początek program będzie pisany w konsoli? Ważne, by działał.
Jeśli macie komu, pokażcie kod, bądźcie otwarci na sugestie. A potem napiszcie coś nowego. I nowego. Z biegiem czasu przyjdzie czas i na interfejs graficzny, i większe wyzwania.

5. Z innej bajki, jaki edytor na początek?

A nawet niech będzie to i Notatnik. To nieśmiertelne rozwiązanie, które będzie wam towarzyszyło do szybkiego szkicowania już na zawsze. O nowym edytorze czas pomyśleć wtedy, gdy pojawi się taka potrzeba. Na początek macie się nauczyć programowania, a nie obsługi złożonych narzędzi.
A jeśli wam jednak mimo wszystko od razu zależy na profesjonalnym wyglądzie albo już tego następnego narzędzia szukacie, to ja zdradzę, że pracuję w Visual Studio Code oraz Vimie.

6. Czego jeszcze trzeba się nauczyć, prócz języka programowania?

To dość złożone zagadnienie. Generalnie zanim sięgniecie głębiej do istoty tematu, naprawdę uznajcie, że coś umiecie. Analiza złożonych przypadków bez ogólnego pojęcia w temacie jest jak uczenie się gramatyki języka bez słówek.
Nie odkładajcie tego jednak też zbyt daleko. Pewne wzorce, struktury i pomysły w programowaniu powstawały przez lata nie w celu utrudnienia, ale uproszczenia wam życia. I nauczenie się poprawnej implementacji gotowych rozwiązań nie tylko wam uprości pracę, ale i sprawi, że będzie ona czytelniejsza dla innych.
Z drugiej strony nic na siłę. Często widuję kody początkujących programistów, które są tak na siłę budowane wedle wzorców projektowych, że wyglądają jak jakieś przykłady encyklopedyczne, a nie gotowe aplikacje, a ich czytelność, miast zyskiwać, traci. To po prostu kwestia wprawy, kiedy coś się przyda, a kiedy trzeba machnąć na to ręką.
Jak już wydacie kilka projektów z GUI, na pewno polecam zapoznanie się z tematem najpopularniejszych szablonów aplikacji (MVC, MVVM, MVP), jak również z najważniejszymi wzorcami projektowymi i strukturami danych. Gorąco też polecam książkę pt. "Programowanie współbieżne i rozproszone" autorstwa panów Zbigniewa Weis oraz Tadeusza Gruźlewskiego, która w moim wypadku była bardzo ważnym podręcznikiem dobrych praktyk algorytmicznych.

7. Kiedy używać tych klas, interfejsów?

Dość często zauważam, że osoby uczące się programowania, nie do końca łapią się w tym, kiedy stosować które narzędzia. Dostajemy więc aplikacje napisane np. w C++ zawierające 80 funkcji i ani jednej klasy, z jakimiś dziwnymi zmiennymi albo, najgorsza praktyka z możliwych, tablicami, w których elementy o danym indeksie oznaczają dany zasób, ale schemat tworzenia ich występuje naturalnie tylko w głowie twórcy.
Czasami jest to zachowanie korzystne, ale w zdecydowanej większości przypadków nie. Dlatego warto eksperymentować z nowo poznawanymi elementami programowania obiektowego lub strukturalnego. Wszystko się jakoś samo poukłada, kiedy zauważycie, co pomaga, a co nie.

8. Ile plików ma mieć mój program?

To jest generalnie ciekawe zagadnienie i nie ma na nie dobrej odpowiedzi. Zależy to od ilości plików, pomysłu na organizację kodu i preferencji twórcy. Czasem wygodniej jest mieć pliki giganty, czasem lepiej mieć dużo karłów.
Na pewno jednak należy unikać dwóch skrajnych sytuacji, gdy program ma 10 plików po 10 linijek albo jeden plik zawierający linijek 38520. Generalnie na początku najlepszą praktyką jest dzielenie programu wg zastosowania.
Jeśli piszę więc kalkulator, jeden plik może odpowiadać za interfejs graficzny, drugi za obliczenia, a trzeci za przekazywanie informacji między jednym a drugim. I tak, to jest klasyczny przykład schematu MVC typu 2, mówiłem, że szablony i wzorce są przydatne.

9. Optymalizować, czy nie optymalizować?

Oto jest pytanie!
Współcześnie bardzo się zaciera granica między tym, kiedy kod lepiej optymalizować, a kiedy dbać o jego czytelność. W czasach, kiedy platforma Dotnet używa wirtualnej maszyny do wykonywania kodu, naprawdę sprawa staje się złożona.
Z jednej strony, kiedy mamy za zadanie posortowanie gigantycznej listy, na pewno będziemy zastanawiać się nad najlepszym algorytmem. Zwłaszcza, gdy w grę wchodzi przycinanie się programu.
Z drugiej strony mamy na przykład wybór większej wartości. Załóżmy, że mamy dwie liczby i zastanawiamy się, która z nich jest większa. Pokażę to na przykładzie zmiennych a i b, chcemy w zmiennej x zapisać większą z nich.
Najprościej zrobić to tak:
Jeśli a jest większe od b, zapisz x równe a,
w przeciwnym wypadku zapisz x równe b.
W języku C++:
if(a>b) x=a;
else x=b;
Czy można zrobić to wydajniej? Oczywiście!
Zapiszemy, że x jest równe różnicy a oraz wartości powstałej z iloczynu bitowego różnicy a i b oraz różnicy a i b przesuniętej bitowo o rozmiar w prawo.
x = a – ((a-b) & ((a-b) >> sizeof(x)*8-1));
Gratuluję! Właśnie stworzyliśmy wspaniale wydajny kod! Wydajny w każdym razie dla komputera, bo jak za tydzień będziemy go czytać, spędzimy na pewno dobrych kilka sekund zastanawiając się, jak to ma działać, co robić i obiecując sobie, że od tej pory będziemy programować tylko na trzeźwo.
Dla jasności, są sytuacje, gdy takie sztuczki naprawdę się przydadzą. Jeśli dysponujemy ograniczoną pamięcią lub mocą obliczeniową, bez nich się nie obędziemy. A to nie jest aż tak nieprawdopodobne, wszak mikrokontrolery są wszędzie, a rzadko który przekracza 4kB pamięci RAM i 16MHz.
Ale po pierwsze, wtedy stosuje się makra, a po drugie… Uznajmy, początkujący programiści nie piszą oprogramowania dla mikrokontrolerów.

10. Jak się ćwiczyć w programowaniu?

To chyba najważniejsza sprawa. Programowanie to przede wszystkim gra wyobraźni. Trzeba się nauczyć algorytmicznego myślenia, odruchowego rozwiązywania kłopotów.
Wiele jest żartów o programistach, które jednak doskonale to lustrują. Ja przytoczę dwa.
Pierwszy z nich: Jak zająć programistę? Dać mu kartkę z napisem:
Przeczytaj poniższą linijkę.
Przeczytaj powyższą linijkę.
Drugi natomiast: Żona do męża programisty:
– Kup chleb, a jak będą jajka, kup 10.
Nasz programista wchodzi więc do sklepu i pyta: "Są jajka"?
– Są – odpowiada ekspedientka.
– To poproszę dziesięć chlebów.
Komputer to taka maszyna, która robi tylko i dokładnie to, co jej każemy. A początkujący programiści mają taką skłonność do myślenia po ludzku, nie zaś po komputerowemu. I z tego wynika masa błędów.
Z drugiej strony doświadczeni programiści mają skłonność odwrotną i… też bywa ciekawie.
Na koniec pozostawiam was z zagadką logiczną, którą powinno się zadawać na pierwszych zajęciach z programowania, a jakoś się tego nie robi.
Jasiu dostał pięć jabłek i zjadł dwa. Ile jabłek ma Jasiu?
Zapraszam do odpowiadania w komentarzach.

Ufff, przebrnęliśmy przez to. Wiem, że wpis był nieco chaotyczny, ale mam nadzieję, że dla kogoś będzie jakąś tam podpowiedzią.
Zapraszam do zadawania wszelkich waszych pytań w komentarzach, spróbuję na nie odpowiedzieć, a będą one tylko motywacją do napisania jednak tego następnego wpisu.
Jeśli będę widział zainteresowanie, następnym razem omówię 10 grzechów głównych początkujących programistów na Eltena i Eltenowiczów przykładzie. 🙂

Z pozdrowieniami,
Dawid Pieper
Chociaż raczej powinienem napisać
446177696420506965706572

Kontrtest i doskonały przykład na to, jak to jest z tymi wieloma rdzeniami i kiedy to jest fajne

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ć.