Maciej[cc] » C++

Co jest nie tak z C++

maciej — Mon, 23 Dec 2019 08:22:02 +0000

Czasami mam wrażenie, że podczas rozwoju C++ coś poszło nie tak i język z wersji na wersję stał się nieczytelnym potworkiem, któremu coraz bliżej do Perla z czytelnością. Pomijając wskaźniki i zarządzanie pamięcią, spójrzmy na taki przykład: lista (wskaźników) funkcji, które mają być wywołane po podaniu określonych parametrów programu, z dodatkową listą pomocniczych parametrów i tekstem pomocy. Docelowo ma pozwolić na takie wywołanie aplikacji w następujący sposób:

./aplikacja --moje-id 1234 --email ja@domena.pl zamow pizze

Wspomniana lista ma trzymać polecenia typu “zamów pizze”, wymagane dla nich opcje (z --) oraz funkcje/metodę, która to obsłuży, oczywiście ze swoimi parametrami. Plus help text. W C++:

std::vector<std::tuple<std::vector<std::string> , void(*)(DApp *, std::vector<std::string>) , std::vector<std::string> , std::string > > command_mappings;
...
tuple<vector<string>, void (*)(DApp *, std::vector<string> ), vector<string>, string > p(vector<string>{"zamow", "pizze"}, handler, vector<string>{"moje-id", "email"}, "Zamawia pizze na niby");
command_mappings.push_back(p);

Wiem, można to przerobić na klasę/strukturę i będzie miejscami czytelniej. Wiem też, że można użyć gotowych struktur do obsłużenia tego, ale wyszło jak wyszło.

W Pythonie:

command_mappings = []
...
command_mappings.append(['zamow', 'pizze'], handler, ["moje-id", "email"], "Zamawia pizze na niby")

Może to trochę jak porówninie Elektrycznego Malucha z Fordem Escortem. Niby lata produkcji te same i oba mają strefę zgniotu kończącą się na silniku, ale jednak technologia i przeznaczenie inne. W pythonie, jak długo programuje, takie kwiatki nie wychodziły w miarę rozwijania kodu, nawet po latach. Kod zawsze wyglądał dość czytelnie i działał wolno. W C++ na odwrót :) A może po prostu PEBKAC.

Wesołych Świąt!

Jak zrobić to samo nieco szybciej – organizacja danych w pamięci

maciej — Fri, 24 Nov 2017 14:52:01 +0000

Krótko na temat tego, czy ten sam algorytm może działać szybciej. Tak! Proste testy, które udało mi się zrobić pokazują wzrost prędkości o ok. 30% przy odpowiednim czarowaniu z danymi, bez ingerencji w sam algorytm.

Skoro nie ruszamy O(n) ani algorytmy, to o czym mowa? O cache procesora i cache instrukcji. Weźmy na przykład ukochanego przez niektórych akademików Quick Sorta. Ze swoim O(n log n) działa szybciej niż Buble Sort z O(n*n). Ale czy na pewno? Na uczelni za to ostatnie pytanie można dostać 2.0 i zostać oddelegowanym na ten sam rok, tylko rok później :)

L1, L2, L3, ram i swap

Większość programistów powinna kojarzyć czym jest cache procesora, ram i swap (lub plik wymiany w znienawidzonych przeze mnie okienkach). Większość też kojarzy jak różni się prędkość zapisu do poszczególnych pamięci, albo chociaż wie, że im bardziej w prawo w tej liście, tym wolniej. Natomiast mało który programista zapytany jak skorzystać z cache procesora będzie wiedział jak to się robi. “Gdzieś kiedyś na studiach było, ale dawno i pewnie się pozmieniało, no i pewnie java/python/js zoptymalizuje za mnie”.

A gdyby ktoś Ci powiedział, że układając odpowiednio dane w pamięci możesz przyspieszyć swój kod? No może kosztem jego czytelności.

L1 i RAM tak samo jak RAM i Swap

Korzystanie ze swapu jest dla większości oczywiste – gdy coś się nie mieści w RAM’ie, to wędruje na dysk. Podobnie jest z cache każdego poziomu. Jeśli procesor nie jest w stanie pomieścić przetwarzanych danych w cache, to wymienia jego zawartość na nowe, aktualnie potrzebne dane z RAM’u. I tak jak ze swap’em, dzieje się to nie pojedynczych bajtach, ale całych blokach danych.

Gdybyś miał zrobić program, który nie zmieści się w ramie, to prawdopodobnie zaprojektowałbyś dostęp do pamięci tak, aby jak najmniej skakać po pamięci i powodować wymianę stron z dysku. Podobnie możesz zrobić z przetwarzaniem danych i trzymaniem ich w cache. Efekt nie jest tak zauważalny jak przy swapowaniu, które dosłownie zabija wydajność, ale porównując da się zobaczyć sporą różnicę, nawet 30%.

Zróbmy przykład!

Zacznijmy od prostego przykładu – zróbmy z dwóch czarno białych zdjęć jedno, będące średnią jasności. Na przykład:

char image1[width*height];
char image2[width*height];

// Load images

char image_diff[width*height];

for (int x = 0; x < width; x++) {
 for (int y = 0; y < height; y++) {
 image_diff[y*width + x] = (image1[y*width + x] + image1[y*width + x]) / 2
 }
}

Na pierwszy rzut oka kodu nie da się zbytnio zoptymalizować. Jeśli tylko dane są ułożone kolumnami (tj. cała pierwsza kolumna, później cała druga itd.), to nie będziemy odczuwać zbyt dużego efektu przeładowywania cache i program zadziała.

Jeśli natomiast dane w obrazkach są ułożone wierszami, to już tutaj tracimy cały zysk z cache (które jest ładowane przez procesor transparentnie dla programisty). Dane pierwszego i drugiego piksela leżą w obszarach na tyle oddalonych od siebie, że konieczne jest przeładowanie zawartości cache, co spowolni nasz program do prędkości działania RAM’u.

Co jeszcze zoptymalizować?

Wydaje się, że takie ułożenie to wszystko, na co możemy się porwać, aby było szybciej. Ale nie – jest jeszcze jedna możliwość. Każda iteracja powyższej pętli odwołuje się do trzech różnych obszarów RAM’u. Pierwsze dwa to obrazki źródłowe, natomiast trzeci to obrazek z wynikiem.

Możemy tak ułożyć nasze dane, aby wszystkie trzy obszary przepleść pomiędzy sobą. Dzięki temu kod programu będzie generował żądanie pobrania bloku danych do cache 3 razy częściej, ale tylko w jednym miejscu kodu i tylko jednego (zamiast oryginalnych trzech). W przetwarzaniu potokowym, w które wyposażona jest teraz większość procesorów spowoduje to, że informacja o konieczności pobrania strony pojawia się dość szybko i jest realizowana, gdy pozostała część procesora jeszcze ma co robić.

char images[width*height*3];

// Load images...

for (int i = 0; i < width*height; i++) {
 images[i*3] = (images[i*3 + 1] + images[i*3 + 2])/2;
}

W sumie ilość tzw. cache miss w L1, gdy potrzebny obszar pamięci nie jest w cache jest taka sama, ale docelowo zawartość cache L2 (lub niższych) pozwala wczytać te dane trochę szybciej i w praktyce ten sam algorytm wykonuje się ze znaczącą różnicą. W testach na Core2Duo, przy przetwarzaniu 20M bajtów było to około 30%.

Wracając do naszego akademickiego przykładu Buble Sort vs. Quick Sort – w przypadku dużych dysproporcji w prędkościach przetwarzania danych i ilości tych danych, lepsza złożoność może być “zjedzona” przez ilość cache-miss generowanych przez Quick Sort, względem Buble Sort idącego prosto przez pamięć, bez skoków. Prawdopodobnie nie będzie to częsty przypadek, ale też należy mieć go na uwadze :)

Pozostają jeszcze kwestie takie jak instruction cache i przewidywanie skoków w procesorze, ale do tego odsyłam do wujka google.

Zanim zmierzysz 64ns

Przy testach warto też wziąć pod uwagę optymalizacje kompilatorów. Gcc widząc pętle, z której wyników nikt później nie korzysta (pierwsza, wolniejsza wersja kodu) potrafi ją całkowicie wyciąć z binarnego kodu. Z taką wydajnością wtedy ciężko walczyć :)

Libsodium – kryptografia w łatwiejszym wydaniu

maciej — Fri, 21 Jul 2017 21:45:40 +0000

Już kilka razy potrzebowałem użyć kryptografii do jakiegoś zadania. Zwykle przychodził z “pomocą” potworek o nazwie openssl, za pomocą którego można było wyczarować cuda. Problemem była jedynie składnia, którą trudno zapamiętać, bo “potworek” jest szyty na miarę profesjonalnych zastosowań.

API “potworka” jest jeszcze bardziej pokręcone i wymaga ogromnej wiedzy, już na sam początek, co dla niewprawionych w bojach z kryptografią może być i tak bardzo dużym wyzwaniem.

Niedawno, szukając jakiejś alternatywy dla wołania zewnętrznego polecenia openssl albo gpg, dla projektu libdinemic udało mi się znaleźć bibliotekę Sodium, która jest następcą innego, ponoć podobnego narzędzia NaCl. Biblioteka ta pozwala w bardzo przyjemny sposób ogarnąć podstawowe zadania związane z kryptografią:

Podpisy cyfrowe – generujące kawałek danych potwierdzający, że właściciel prywatnego klucza coś napisał
Szyfrowanie symetryczne – pozwalające zamienić ciąg ważnych dla nas danych w (prawie) bezużyteczne śmieci, możliwe do odszyfrowania jedynie po podaniu hasła
Szyfrowanie asymetryczne – pozwalające zaszyfrowanie komuś danych posiadając jedynie jego publiczny, znany wszystkim klucz. Dzięki temu tylko ta osoba ta może odszyfrować, korzystając z prywatnej części klucza
Funkcje skrótu SHA2
… i kilka innych fajnych narzędzi związanych z bezpieczeństwem

Jak się za to zabrać?

Będziesz potrzebował samą bibliotekę, jej pliki nagłówkowe, kompilator i edytor tekstu:

sudo apt-get install libsodium-dev gcc gedit

Aby skompilować coś, co zachwile stworzysz, dodaj opcję -lsodium do kompilatora:

gcc -o program -lsodium program.c

…lub skorzystaj z gotowego narzędzia typu make, qmake albo cmake.

Klucz prywatny i publiczny – po co to

Zanim przejdziemy do kolejnych kroków – kilka zdań o kryptografii asymetrycznej. Jak źle by to nie było omówione na studiach, warto wiedzieć co ona daje i wierzyć, że jeszcze nikt z NSA nie złamał jej zabezpieczeń (albo i nie wierzyć). W dużym uproszczeniu, kryptografia asymetryczna bazuje na parach kluczy (liczb), z których jedna, prywatna, to zwykle duża losowa liczba. W niektórych algorytmach musi to być liczba pierwsza. Druga liczba, publiczna jest obliczana na podstawie tej pierwszej, prywatnej.

Generowanie drugiej liczny jest wykonywane w taki sposób, aby operacja odwrotna była bardzo żmudna i długotrwała. Dobrym porównaniem jest mieszanie farbek. Jeśli znasz proporcje (Twój klucz prywatny), to możesz szybko wymieszać podstawowe kolory i otrzymać identyfikujący Cię kolor. Każda wiadomość pomaziana Twoim kolorem będzie automatycznie oznaczona jako nadana przez Ciebie, bo tylko Ty potrafisz zrobić taki kolor. Jeśli natomiast ktoś chciałby podrobić Twój kolor, to musiałby próbować różnych zestawień barw, co trwało by znacznie dłużej. Podobnie miało to miejsce z tajną recepturą KFC. Wszyscy próbowali ją podrabiać, ale do czasu jej wycieku oryginalny smak, bazujący na proporcjach kilkunastu przypraw pozostawał tylko w KFC.

O ile kolory czy proporcje przypraw można by próbować dość łatwo odtworzyć, bo nie ma aż tylu możliwości, to obliczenie prywatnego klucza kryptograficznego (proporcji przypraw) na podstawie klucza publicznego (smaku) może trwać zwykle latami na pojedynczym komputerze. Dla tego jest to uznawane za bezpieczny środek komunikacji, a dodatkowo daje możliwość udostępnienia wszystkim czegoś (smaku, koloru, publicznego klucza), który może zweryfikować czy to my lub umożliwić zaszyfrowanie nam wiadomości, którą odczytamy tylko my.

Podpisy cyfrowe

Pierwszym zadaniem z libsodium było dla mnie zakodowanie modułu umożliwiającego generowanie podpisów cyfrowych w libdinemic. Miało to uwierzytelnić każdą zmianę wykonywaną w rozproszonej bazie dla wielu hostów, bez korzystania z blokad i tym podobnych mechanizmów. W zamian miały być wykorzystane właśnie podpisy cyfrowe – tylko osoba posiadająca klucz prywatny przypisany do obiektu w bazie może go zaktualizować.

Jak wygenerować taki podpis za pomocą libsodium? Potrzebujemy wiadomość (update stanu bazy) oraz parę kluczy, prywatny i publiczny. Klucze można wygenerować jedną funkcją:

#include <sodium.h>
...

unsigned char sign_secret_key[crypto_sign_SECRETKEYBYTES];
unsigned char sign_public_key[crypto_sign_PUBLICKEYBYTES];

crypto_sign_keypair(sign_public_key, sign_secret_key);

crypto_sign_keypair zapisze do podanych zmiennych klucz prywatny (losowy ciąg danych) i odpowiadający mu klucz publiczny. Libsodium używa do tego algorytmów opartych o krzywe eliptyczne, przez co klucze są znacznie krótsze od tych znanych z RSA. Mając dwa klucze możemy wygenerować wiadomość i podpisać ją cyfrowo naszym prywatnym kluczem:

unsigned char sig[crypto_sign_BYTES];
unsigned char message[] = "Ala ma kota a kot ma Ale";

crypto_sign_detached(sig,
 NULL,
 message,
 strlen(message),
 sign_secret_key);

Podpis cyfrowy będzie zapisany do zmiennej sig, która ma stałą, określoną przez crypto_sign_BYTES długość.

W ten sposób możemy rozpowszechnić nasz publiczny klucz, za pomocą którego inne osoby lub programy będą mogły potwierdzić autentyczność naszej wiadomości. Aby zweryfikować podpisany ciąg znaków wystarczy sprawdzić:

char sig[crypto_sign_BYTES];
unsigned char *message;

sig = ... //pobieramy podpis
message = ... //pobieramy wiadomość

if (crypto_sign_verify_detached(sig,
 message,
 strlen(message),
 sign_public_key) != 0) {
 // To jest fałszywy podpis!
} else {
 // Podpis się zgadza
}

Szyfrowanie danych

Szyfrowanie danych z libsodium wygląda podobnie, aczkolwiek wymaga użycia innego zestawu funkcji i algorytmów. Po pierwsze musimy wygenerować inny zestaw kluczy za pomocą innej funkcji – crpto_box_keypair:

unsigned char encryption_secret_key[crypto_box_SECRETKEYBYTES];
unsigned char encryption_public_key[crypto_box_PUBLICKEYBYTES];

crypto_box_keypair(encryption_public_key, encryption_secret_key);

Następnie możemy rozpowszechnić publiczny klucz. Szyfrowanie działa trochę inaczej – tutaj do wygenerowania danych nadawcy potrzebny jest publiczny klucz. Dzięki temu tylko odbiorca może odszyfrować swoją wiadomość. Odwrotnie było w przypadku podpisów – tylko nadawca mógł się podpisać pod wiadomością, a zweryfikować mógł ktokolwiek, używając jego klucza publicznego.

Do zaszyfrowania wiadomości będziemy potrzebowali dodatkowego obszaru pamięci, do którego libsodium zapisze zaszyfrowane dane:

unsigned char message[] = "Ala ma kota a kot nie ma Ali";
unsigned char *encrypted_message = new unsigned char[strlen(message) + crypto_box_SEALBYTES];

crypto_box_seal(encrypted_message,
 message,
 strlen(message),
 encryption_public_key);
// Wysylamy wiadomosc w swiat

Odbiorca wiadomości może ją odszyfrować posiadając swój prywatny klucz:

// Odebranie wiadomosci
...

unsigned char *decrypted_message = new unsigned char[encrypted_message_length];
int rc = crypto_box_seal_open(decrypted_message,
 encrypted_message,
 encrypted_message_length,
 encryption_public_key,
 encryption_secret_key);

if (rc != 0) {
 // nie udalo sie odszyfrowac wiadomosci
} else {
 // Mamy wiadomosc!
}

Do powyższych przykładów należy podejść czysto edukacyjnie i zwrócić uwagę zwłaszcza na funkcje strlen, które w przypadku danych binarnych mogą zwrócić niepoprawne wartości.