Zamiast wielowątkowej kompilacji jednej paczki wolę stosować równoległą budowę wielu derywacji.

Jednym z powodów mojej niechęci do równoległej kompilacji jest losowa kolejność wpisów historii kompilacji, co utrudnia znajdywanie błędów. Równoczesna budowa wielu derywacji jest po prostu alternatywnym sposobem na wykorzystanie dostępnych zasobów obliczeniowych.

Podręcznik Guix definiuje dwie opcje dotyczące pracy równoległej.

ŹRÓDŁO --cores=n -c n Wykorzystuje n rdzeni procesora do budowy każdej derywacji; 0 oznacza tyle ile jest dostępnych.

ŹRÓDŁO --max-jobs=n -M n Pozwala na maksymalnie n równoległych budów. Domyślną wartością jest 1. Ustawienie 0 znaczy, że żadne budowy nie będą wykonywane lokalnie; zamiast tego, usługa zleci zdalne budowy lub po prostu zgłosi niepowodzenie.

DO ZROBIENIA Ustawienie --cores=1 już funkcjonuje w moich systemach. Działa dokładnie tak, jak jest to zdefiniowane. Ciekawe jest, że użycie jednego rdzenia odsłoniło błąd fazy testowania w jednej z paczek.

DO ZROBIENIA Jeśli liczba wątków kompilacji jest ograniczona do jednej, to logicznie nasuwa się ustawienie liczby jednoczesnych budów derywacji Guix na odpowiadającą liczbie dostępnych procesorów.

DO ZROBIENIA W praktyce najlepsze rozwiązania są połączeniem skrajności. Powinienem więc zaprogramować obie opcje tak, aby dynamicznie ustalały liczbę n. Skoro opcje są dwie, to optymalnym rozdziałem (tak jak największą powierzchnię względem obwodu ma kwadrat) jest ustawienie n równe pierwiastkowi kwadratowemu z liczby dostępnych procesorów. Musi to być jednak liczba całkowita, więc rozsądne jest wzięcie najbliższej wyższej liczby całkowitej. Liczba niższa doprowadzałaby do niepełnego wykorzystania zasobów.