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

XPS 9500, pierwsze wrażenia

Mam ten komputer od nieco ponad 48 godzin. Czeka mnie jeszcze przynajmniej kilka tygodni – a najpewniej i miesięcy – zanim przetestuję go w każdym scenariuszu, odkryję ukryte wady i zalety. Jak jednak obiecałem, dziś recenzja związana z pierwszymi wrażeniami.

Specyfikacja techniczna

Procesor: Intel Core I7-10750H, 6 rdzeni, 12 wątków, 2,6GHz do 5,0GHz, 12MB Cache
RAM: 32GB DDR4 2933MHz
Grafika: Nvidia GeForce GTX 1650 Ti, 4GB GDDR6, 1350 do 1485 MHz, 128-bit
Rozdzielczość ekranu: 1920×1200 Px
Karta sieciowa: Killer Wi-Fi 6 AX1650S
Dysk: Kingston SA2000M8 1TB SSD NVMe PCI-E X4
Bateria: 6-cell 86WHr
Pozostałe moim zdaniem ważne: moduł TPM w wersji 2.0, czujniki HID V2, czytnik linii papilarnych Goodix

Dlaczego ten model?

O swoim przyszłym laptopie myślałem już od kilku miesięcy. I choć nie planowałem go kupować w tym roku, jak już wcześniej na blogu pisałem, badałem rynek w poszukiwaniu sprzętu, który za rok albo dwa stanie się moim nowym narzędziem pracy. A zadanie wcale nie jest proste, bo wymagania mam dość specyficzne.
Z jednej strony zależy mi na dobrych podzespołach, ale i baterii. Jakby nie dość było tu wzajemnych wykluczeń, dorzucam do pakietu jeszcze niewielki rozmiar. To wszystko sprawia, że możliwości pozostają bardzo niewielkie.
Moim poprzednim komputerem był Dell XPS 15 9550, do jego recenzji odsyłam ciekawych, dlaczego on. Jako, że był to zakup więcej niż satysfakcjonujący, najbardziej oczywistym wyborem było pozostanie przy serii. Co więcej, gdy wrzucicie w Google hasło "Best laptop for a software developer", pierwszy wynik od góry to strona na blogu creativebloq.com, gdzie zakupiony przeze mnie komputer na liście jest pierwszy. Postanowiłem jednak przeanalizować wszystkie proponowane tam komputery.
Pomijając MacBooki, nie ma tam niczego, co podzespołami równałoby się z XPS-em.
Pozostawał jeszcze dylemat co do wielkości laptopa – 15 czy 13 cali. I to była trudna kwestia, bo bardzo kusiła mnie mniejsza wersja, ze względu na jej mobilność.
Ostatecznie wybrałem XPS-a 15, choć tak naprawdę nigdy się nie przekonam, czy był to lepszy wybór. Najważniejsze argumenty, które tu zaważyły:
1. Większa, a co za tym idzie nieco wygodniejsza, klawiatura, choć na tą w trzynastkach nie można też nażekać,
2. Większa ilość złączy,
3. Ale przede wszystkim po prostu szybszy dysk.
Bo o ile procesor jest tam całkiem znośny, o tyle z przyczyn oszczędzania energii, XPS 13 9300 (tegoroczny) otrzymał słabszy dysk niż poprzednie modele 7390 i 9370. Benchmarki wskazują, że dysk ten osiąga niecałe 900MB/s prędkości odczytu, co w 2020 roku przy dyskach NVMe jest wynikiem mocno przeciętnym. Dla porównania, dysk z XPS 9370 (dwa lata starszego) osiąga 1600MB/s odczytu, prawie dwa razy więcej.

Dlaczego taka konfiguracja

Model ten sprzedawany jest w różnych konfiguracjach, dotyczących dysku, pamięci, procesora, baterii i ekranu. Dla mnie jednak od początku jasne było, co dokładnie chcę wybrać.
Po kolei. Można dostać ten komputer z procesorem I5, I7-10750H, I7-10875H oraz I9-10985H. Ja wybrałem opcję drugą.
Z testów wynika, że I5 jest procesorem ok. 37 procent słabszym. I9-10985H zaś tylko ok. 14 procent lepszym. Z czego to wynika i co oznacza?
Procesor I5 mógł się okazać dla mnie zbyt słaby, po prostu. Do tej pory pracowałem na I7-6700HQ, od którego I5 10 generacji pozostają wolniejsze. Oczywiste było dla mnie, że z I7 przesiądę się na I7. Dlaczego jednak nie model wyższy?
Dlatego, że uzysk jest niewielki. Dostajemy dwa rdzenie więcej i 4MB dodatkowej pamięci Cache. Nie zmienia się jednak ani bazowe, ani maksymalne taktowanie. Procesor 10875H jest zatem fajną opcją dla grafików i innych osób pracujących na wielu rdzeniach, ale w zastosowaniach, które wymagają do 6 rdzeni (m.in. programowaniu aplikacji desktopowych), różnice są prawie niezauważalne. Z jednym wyjątkiem, o ok. 10 procent krótszym czasem działania komputera na baterii. Decyzja wydawała się więc oczywista. I9 ma nieco większe taktowanie, ale skraca już bardzo zauważalnie czas pracy, a ja przyznam szczerze, że już dysponuję taką mocą obliczeniową, że z procesorem I9 musiałbym chyba przebranżowić się na hakera, by ją jakkolwiek wykorzystać. 🙂
Co do RAM-u, opcje to 8, 16, 32 oraz 64 GB. Ja wybrałem 32. Już z doświadczeń z XPS 9550 wiem, że 16 to krztynkę mało, ale nie mam zielonego pojęcia, na co mi by było aż 64.
Dysk? Tutaj gama to 256, 512, 1024 oraz 2048 GB. I ja znów po środku, wybrałem 1TB. Po prostu więcej mi nie trzeba, więc poco przepłacać?
Ekran to dwie opcje: full HD oraz dotykowy 4K. Chyba z perspektywy niewidomego oczywisty jest wybór opcji FHD, zwłaszcza, że 4K oznacza skrócenie czasu pracy nawet o 30 procent.
Skoro o czasie pracy mowa, ostatnia różnica to bateria. Mamy opcje 54 oraz 86 WHr, u mnie padło na propozycję nr 2.

Dotykając sprzętu

Byłem pewien, że komputer będzie podobny do poprzedniego XPS-a 15. XPS 13 9370, dwa lata młodszy od 9550, pozostaje do niego łudząco podobny. W tym roku jednak Dell zdecydował się na daleko idące zmiany. I o ile podobieństw nie brakuje i każdy kto widział jakiegoś Della XPS na pewno rozpozna, że to XPS, to jednak wiele się zmieniło.
Wymiary urządzenia to 344,4 x 230,3 x 18,0 mm. To ważne, bo Dell od kilku lat chwali się, że jego laptopy z serii XPS to najmniejsze urządzenia w stosunku do przekątnej ekranu na rynku: z XPS-em 15 wielkości 14-calowego notebooka i XPS-em 13 wielkości 12-calowego. I rzeczywiście mogę to potwierdzić, te laptopy są malutkie. Nie można jednak tego powiedzieć o wadze wynoszącej, zależnie od konfiguracji, od 1,8 do 2,05 kg. Dla porównania najnowszy MacBook Pro 16, o większym o cal ekranie, waży niecałe 2kg.
I masę tą po prostu czuć. Nie można jeszcze powiedzieć o tym komputerze, że jest ciężki, ale w porównaniu ze swoimi wymiarami, waga zaskakuje.
W stosunku do Della XPS 15 9550 zwiększyła się klawiatura. Już w poprzednim modelu mówiłem, że klawiatura to ogromny atut serii XPS, tym razem opinię i podtrzymuję, i pogłębiam, bo klawiatura jest jeszcze większa, z wyraźniejszymi odstępami i skokami klawiszy. Pisze się po prostu na niej bardzo przyjemnie.
Skoro o klawiaturze mowa, warto dodać, że XPS poszedł za trendem i przeniósł przycisk zasilania. Obecnie przycisk ten to po prostu górny prawy klawisz na klawiaturze, przy okazji z wbudowanym czytnikiem linii papilarnych. Przyzwyczaił mnie do tego MacBook, ale podejrzewam, że gdyby nie on, nie raz i nie dwa bym go omyłkowo wcisnął.
Jedyny poważny problem związany z klawiaturą to klawisze home i end. Nie pojmę, co strzeliło do łba inżynierom Della, by przypisać te klawisze do skrótów FN+F11 i FN+F12. No głupszej myśli dawno nie widziałem! I choć się już do tego przyzwyczajam, w pracy nad kodem nie jest to i nigdy nie będzie wygodne.
Powiększył się też touchpad, co pewnie z kolei dla wielu niewidomych będzie wadą. W tej chwili znaczna część palmrestu jest zajęta przez urządzenie wskazujące. Jeszcze nie zdarzyło mi się przypadkiem na nim czegoś kliknąć, ale umiem sobie wyobrazić, że wielu użytkownikom się to uda, bo albo nie mają nawyku trzymania rąk po bokach matrycy, albo po prostu mają dłonie nieco większe. Z drugiej strony tak duża przestrzeń gładzika jakby z automatu załącza mi myśl, że może czas powrócić do szeroko dyskutowanej na grupie NVDA w roku 2014 kwestii wykorzystania gestów jako skrótów nawigacyjnych dla czytnika.
Przy okazji kolejnych modeli XPS, Dell za każdym razem chwali się niewyobrażalnie cieniutkimi ramkami wokół wyświetlacza. Można odnieść wrażenie, że ekran trzyma się tu już chyba tylko na włosku. I tu wyobrażenia prześcignęły bardzo rzeczywistość. Jasne, ramki są cienkie, mają kilka milimetrów. Czytając jednak recenzje i zapowiedzi, spodziewałem się, że będą znacznie cieńsze, że ledwo co je wyczuję. Dobra, są cieńsze niż w XPS 15 9550, ale nie jakoś wybitnie, z jednym wyjątkiem ramki pod ekranem. W poprzednim modelu mieściła ona kamerę i mikrofon, co sprawiało, że była znacznie grubsza, kilka centymetrów. Tutaj także i górna, i dolna rama wyświetlacza są szerokości kilku milimetrów, dzięki czemu rozdzielczość pionowa ekranu wzrosła z 1080 do 1200 px przy zachowaniu tych samych wymiarów.

Dostępne złącza

18 mm wysokości, w tym 7,7 mm dolnej części zobowiązuje, ale zobowiązuje do czegoś, co pewnie będzie postrzegane tu jako wada. Mianowicie nie ma szans, by zmieścić pełnowymiarowe gniazda USB. Zrobiłem test, przykładając wtyczkę USB do obudowy. Jest po prostu od niej wyczuwalnie grubsza.
Mam tu mieszane uczucia. USB-C to standard lepszy, szybszy, bardziej uniwersalny. Tak się jednak złożyło, że dosłownie kilka tygodni temu bojowałem z wyborem laptopa dla kuzynki Julity i okazało się, że w segmencie niskiej półki cenowej, tylko pojedyncze modele dysponują choć jednym portem USB-C. Dążymy więc do sytuacji, gdy drogie sprzęty rezygnują z tradycyjnych portów USB, ale nigdy nie pozbędziemy się przejściówek, bo na próżno szukać nowoczesnych gniazd w tańszym sprzęcie. Jako kuriozum pozostawiam fakt, że MacBooki od kilku lat nie posiadają portów USB, jednak iPhone dołączany ma przewód USB – Lightning, a więc przejściówkę na USB-C, drogi użytkowniku, załatw sobie sam.
Pocieszyć może za to fakt, że w przeciwieństwie do Apple, Dell do swoich komputerów dołącza odpowiedni adapter. W pudełku z komputerem znajdziemy zatem kostkę z wysuwanym złączem USB-C, która posiada jedno tradycyjne gniazdo USB 3.1 i jedno gniazdo HDMI. I byłoby wspaniale, uważam jednak, że jedno USB to jeszcze za mało, takie gniazdka USB powinny być przynajmniej dwa. Ale nie psujmy wrażenia, mogli zawsze pójść wraz ze wspaniałym duchem Apple i nie dać przejściówki żadnej.
Z lewej strony, zaczynając od bliższej strony laptopa, znajdują się: dwa porty USB-C 3.2 ze wsparciem Thunderbold 3 oraz gniazdo klinowe.
Z prawej strony, zaczynając od strony użytkownika, znajdują się: jedno złącze USB-C 3.2, złącze kart pamięci SD, złącze Jack 4-polowe (słuchawki/mikrofon).
I to zasadniczo wszystko. Uważam, że wcale nie jest tych złączy za mało, pamiętać trzeba jednak o jednej pułapce. W tym komputerze zasilanie odbywa się poprzez port USB-C. O ile więc nie zakupimy osobnej, wcale nie aż tak taniej, stacji dokującej, do naszego użytku pozostają porty USB-C tylko dwa.

Pierwsze wrażenia

Pierwsze wrażenia bardzo pozytywne. Komputer bardzo szybki, ale i przy tym cichy. Podczas pracy nad Eltenem czy pisania tego wpisu ani razu nie usłyszałem budzącego się do życia wiatraczka, co akurat dla mnie zaletą jest ogromną, dźwięk pracującego chłodzenia potrafi mnie bowiem bardzo skutecznie rozpraszać.
Niestety, tu muszę nieco popsuć wrażenie. O ile nie jest łatwo zmusić ten komputer do uruchomienia radiatora, to kiedy już się to nam uda (np. podczas budowania NVDA), dźwięk jest dość piskliwy, problem, którego model 9550 nie miał. Nie jest to może bardzo głośny pisk znany z tańszych Inspironów, ale gdzieś tam te wysokie częstotliwości w tle pobrzmiewają, skutecznie irytując użytkownika.
Rzuca się też w oczy dość duża wnęka między ekranem a przednią częścią obudowy. To tam znajduje się jeden z wiatraczków. Dzięki takiej budowie, chłodzenie jest znacznie efektywniejsze, jednak ja nie mogę pozbyć się wizji całego kurzu w powietrzu trafiającego w tę przestrzeń. Coś czuję, choć to na razie tylko podejrzenia, że XPS 9500 będzie wymagał znacznie częstszego czyszczenia sprężonym powietrzem od modelu poprzedniego, by zachować tę kulturę pracy.
Jeśli chodzi o wydajność, pierwszym szokiem był, co ciekawe, Firefox. Od momentu wciśnięcia Entera na ikonie do załadowania przeglądarki i gotowości na wpisanie adresu mija jakieś ćwierć sekundy. Przyznam uczciwie, że mnie to kompletnie zamurowało i byłem przekonany, że przeglądarka gdzieś działa w tle, ale nie, nic z tych rzeczy.
A w reszcie spraw niech przemówi zegarek:
Czas (pełnego) startu Windowsa: 6,2 sekundy,
Czas instalacji Debiana: 2 minuty, 11 sekund,
Czas kopiowania pliku o pojemności 20GB z zewnętrznego dysku SSD USB-C: 11,3 sekundy,
Czas wybudzenia z hibernacji: 3,1 sekundy.

Co z baterią?

Nie wiem, jak szybko bateria będzie się zużywała. XPS 9550 cechował się jej bardzo dużą żywotnością, ale jak będzie tutaj? Poczekamy, zobaczymy.
Na razie zrobiłem test, odłączyłem zasilacz przy pełnej baterii i pracowałem, z założenia czekając aż Windows pokaże 10 procent. Były w tym oczywiście spore przerwy, ale tym lepiej symulowało to naturalne warunki. O godzinie 23:00, po dziewięciu godzinach, wciąż system wskazywał 38 procent. W tym momencie test przerwałem. 🙂 Dodam, że naładowanie baterii od 38 procent do 100 procent potrwało 97 minut.

Jeszcze za szybko na omówienie wydajności

Potestuję, zobaczę, uwierzę, opiszę. Jestem pewien, że wyniki będą dobre, pytanie brzmi, jak dobre. To nie jest laptop z niskiej półki cenowej, ja więc pozostanę wobec niego bardzo krytyczny. I powiem wam szczerze, że choć piszę tu dużo dobrego o tym sprzęcie, musimy pamiętać o poprzeczce, którą Dell postawił.
Skoro jest to sprzęt oficjalnie kierowany do programistów i grafików, skoro jest to model flagowy, po prostu musi być wybitnie dobry. To nie jest komputer przeceniony na wystawie w markecie, w którym pewne kompromisy można przyjąć.
I choć jestem na razie bardzo zadowolony i mam szczerą nadzieję, że tak pozostanie, każde inne odczucie na tym etapie byłoby po prostu rozczarowaniem zakończonym zwrotem towaru.

Notka posiadacza nowego sprzętu

Nie można krakać i czas, bym się tego nauczył. Pamiętacie, jak jeszcze kilka miesięcy temu przekonywałem, że po drobnym upgradzie laptop posłuży mi jeszcze z rok albo dwa? No cóż, los nie wybiera. Zaczynają się studia, a mój stary XPS 9550 krąży na drodze serwisowej.
W tej sytuacji byłem zmuszony do podjęcia decyzji, która mnie nie raduje, ale była konieczna, zakupiłem nowy komputer, z którego to piszę te słowa, mój poprzedni zaś, pod warunkiem succesful naprawy, dostanie mój brat, który studia zaczyna za rok.

Wybrany przeze mnie model to znów XPS, bo marka mnie zdecydowanie kupiła. Sprzęt tegoroczny. Za kilka dni, jak poużywam, napiszę jakąś szerszą recenzję, tym czasem zaś dla ciekawych:
Dell XPS 15 9500:
Procesor: Intel Core I7-10750H 2,6GHz do 5,0GHz;
Grafika: NVIDIA GeForce GTX 1650Ti 4GB GDDR6;
Pamięć: 32GB DDR4 @2933MHz;
Dysk: 1TB NVME M.2 SSD;
Sieć: Killer AX1650;
Ekran: 1920 x 1200 px;
Bateria: 86whr.

To chyba z najważniejszej specyfikacji tyle. I choć zakup przyprawiony nutką goryczy, po pierwszych 8 godzinach nie rozczarowuje.

Dysk, drugi upgrade XPS-a

Druga z trzech zaplanowanych przeze mnie aktualizacji Della XPS 15 9550 to, jak zapowiadałem przy okazji wymiany kości RAM, nowy dysk.
Dość długo zastanawiałem się nad modelem, ostatecznie zdecydowałem się na dysk Adata XPG SX8200 Pro. Ryzyko o tyle, że jest to moja pierwsza styczność z dyskami SSD Adaty.
Prawdopodobnie mój wybór padłby na Samsunga 970 Evo Pro, ale testy donoszą, że model ten ma ogromny problem z przegrzewaniem się, zwłaszcza w laptopach, a doniesień tych jest tak wiele, że coś musi być niestety na rzeczy.

Parametry dysku (wg specyfikacji)

Pojemność: 1TB (właściwie 953GB)
Interfejs: PCI-E x4 Gen3 NVMe,
Szybkość odczytu: 3500MB/s,
Szybkość zapisu: 3000MB/s,
Odczyt Losowy: 390000 IOPS,
Zapis Losowy: 380000 IOPS,
TBW: 640TB.

Zaletą tu niewątpliwie są duże szybkości odczytu i zapisu, o praktycznym aspekcie za moment. Także nie można nie wspomnieć o bardzo niskiej cenie, 700zł za tej klasy SSD to naprawdę nie jest dużo.
Zawodem pewnym są wartości operacji losowych, 400 tysięcy IOPS w porównaniu z 500-550 osiągalnymi przez Samsunga to parametry tylko nieco powyżej przeciętnej.
Także TBW 640TB przy pojemności 1TB jest daną, która na kolana nie powala. Z drugiej strony mówimy o naprawdę tanim dysku, a parametry i tak klasują go w randze, że tak to ujmę, topowej, na stan roku 2019 w teście Benchmarkowym był to piąty dysk pod względem osiągów, a porównywalny z modelami kosztującymi nawet dwa razy tyle.

Jak to wygląda

Dyski NVMe, jeśli ktoś nie wie, są małe… Jak, nie wiem, pendrive, z tych mniejszych. Ważą tyle co piórko i przypominają bardziej kartę do jakiegoś chipu niż dysk.
Adata przyszła w wielkim kartonie, w którym był nieco mniejszy karton, w którym było małe pudełeczko, w którym była folia z dwiema częściami wielkości karty bankowej. Jeden element to dysk, drugi to radiator.
Od razu chciałbym wyjaśnić małą niepewność. Zwykło się mówić na wiatraczek procesora radiator, błędnie. Wiatraczek to wiatraczek, a radiator to radiator. Radiator to odpowiednio wyprofilowany przedmiot, który usprawnia krążenie powietrza, chłodząc to, do czego go przykleimy lub na czym nałożymy. Nie jest jednak w żadnym sensie elektryczny, nie ma wiatraczka, chłodzi wyłącznie kształtem zapewniającym przepływ powietrza.
Dokumentacja podaje, że radiator dla tego dysku jest elementem opcjonalnym i, jeśli nie zmieści się w gnieździe M.2, należy pozostawić dysk bez niego. U mnie w laptopie się jednak zmieścił.

Odczucia

Generalnie wydaje się, że dysk Adaty lepiej od fabrycznej Toshiby dogaduje się z procesorem. To oczywiście uproszczenie, ale znacznie mniej wysiłku kosztuje komputer zapis losowy, marudziłem przed momentem, że 400 tysięcy IOPS to nie jest dużo, ale poprzedni dysk miał IOPS tysięcy 250, więc jest to poprawa o ponad 50 procent.
Nie policzyłem niestety czasu wymaganego na instalację Windowsa 10 na poprzednim dysku, na tym jednak instalacja od momentu pierwszego restartu do ukazania się okna konfiguracji trwała 7 minut i 47 sekund, wliczając ponowne rozruchy, wkrótce zaktualizuję wpis o dane dotyczące Debiana, bo jeszcze go nie postawiłem.

Kilka danych

Najpierw będzie technicznie, a potem praktycznie.
Testy wykonane dla 16GB w 5 rundach programem Crystal Disk Mark wskazują:
Odczyt sekwencyjny: 3377.18MB/s
Zapis sekwencyjny: 2825.27MB/s
Odczyt losowy (blok 1MB): 1355.54MB/s
Zapis losowy (blok 1MB): 1273.36MB/s
Odczyt losowy (blok 4kB): 52.48MB/s
Zapis losowy (blok 4kB): 131.61MB/s
Wyniki są śliczne, zwłaszcza parametry odczytu. Co zaskakujące, dla bloków po 4kB odczyt okazał się mniejszy od zapisu, być może wynika to z czasu lokalizacji komórki.

Testy praktyczne

W testach tych kopiowałem między partycjami NTFS plik lub pliki zapełnione zupełnie losowymi bajtami. Poniżej wyniki.

Jeden plik, 25GB:
Prędkość średnia: 1017MB/s,
Czas kopiowania: 25,17s.

25 plików, 1GB każdy:
Prędkość średnia: 1039MB/s,
Czas kopiowania: 24,64s.

25000 plików, 1MB każdy
Uwaga! Rozmiar nieco mniejszy od powyższych, 25000MB to nie 25GB. 🙂
Prędkość średnia: 211MB/s,
Czas kopiowania: 118,48s.

Warto dodać, że w czasie wszystkich przeprowadzanych testów maksymalna temperatura wyniosła 49 stopni Celsjusza, a temperatura średnia to 43 stopnie Celsjusza, dane z programu Crystal Disk Info.

Podsumowanie

Adata XPG SX8200 Pro to z pewnością jeden z najlepszych dysków SSD na rynku, a przy tym o cenie, nie umiem inaczej tego nazwać, w segmencie śmiesznie niskiej. Konkurencyjny Samsung 970 Evo o tej samej pojemności kosztuje 300zł więcej, zaś warto tu wspomnieć, że w benchmarkach modele te idą łeb w łeb.
Nie będę tu listował zalet i wad, bo dysk mam zbyt krótko, by je podać. Na pewno jednak z zakupu na razie jestem bardzo zadowolony.
Warto jednak tu wspomnieć o bardzo ważnym, a przemilczanym w reklamach i opisach produktu kompromisie – kompromisie, który z resztą dotyczy i Samsungów, i Toshib, i Adat, i Corsairów. Obecnie nie posiadamy technologii umieszczania w sensownej cenie produkcyjnej 1-bitowych komórek w dyskach o pojemnościach liczonych w terabajtach. Używamy zatem 3 bitów na komórkę, technologia TLC. Żeby zaś usprawnić odczyt, zapełniamy te komórki tylko jednym bitem, by zachowywały się, jak dyski SLC. Dzięki temu możemy mówić o tak wielkich odczytach i zapisach, jak tutaj.
I wszystko działa ładnie, jak długo mamy do dyspozycji wolne komórki. Z czasem jednak danych zapisujemy więcej i więcej, a wolnych komórek zaczyna ubywać. Wciąż możemy przeprowadzać optymalizację dysku, jeśli jednak o tym zapomnimy, jakoś na poziomie jednej trzeciej zapelnienia, dysk zauważalnie zwolni.
Regularnie optymalizując go możemy ten proces odsunąć w czasie, ale mniej-więcej przy zapełnieniu 75-80 procent, już żadne optymalizacje cudów nie zdziałają i po prostu dysk będzie 3-4 razy wolniejszy. Dlatego ja sam unikam zapełniania dysku w tym zakresie, ostatnie 20-30 procent miejsca zachowując na dane bardzo tymczasowe.