W frontendzie kompilatora Rust, kt\u00f3ry wykonuje takie zadania, jak analiza sk\u0142adniowa, sprawdzanie typ\u00f3w i analiza po\u017cyczek, zaimplementowano wsparcie dla wsp\u00f3\u0142bie\u017cnego wykonywania, co pozwala na znaczne skr\u00f3cenie czasu kompilacji. Rozdzielanie zada\u0144 jest ju\u017c dost\u0119pne w nocnych wersjach Rust i w\u0142\u0105cza si\u0119 za pomoc\u0105 opcji «-Z threads=8». W stabilnej ga\u0142\u0119zi planuje si\u0119 wprowadzenie tej funkcji w 2024 roku. <\/p>\n
Prace nad skracaniem czasu kompilacji w Rust trwaj\u0105 ju\u017c od kilku lat. W ci\u0105gu pierwszych 10 miesi\u0119cy 2023 roku \u015bredni czas kompilacji skr\u00f3ci\u0142 si\u0119 o 13%, szczytowe wykorzystanie pami\u0119ci zmniejszy\u0142o si\u0119 o 15%, a rozmiar generowanych plik\u00f3w zmniejszy\u0142 si\u0119 o 7%. Na tym etapie przyspieszenie zosta\u0142o osi\u0105gni\u0119te dzi\u0119ki optymalizacjom samego kompilatora. Nast\u0119pnie deweloperzy przeszli do prac nad przyspieszeniem poprzez r\u00f3wnoleg\u0142e wykonywanie operacji podczas kompilacji. <\/p>\n
Do tej pory parallelizacja w Rust by\u0142a g\u0142\u00f3wnie realizowana na poziomie proces\u00f3w, na przyk\u0142ad mened\u017cer pakiet\u00f3w Cargo mo\u017ce uruchamia\u0107 kilka proces\u00f3w rustc do jednoczesnej kompilacji kilku pakiet\u00f3w. Wsparcie dla r\u00f3wnoleg\u0142ego przetwarzania jest r\u00f3wnie\u017c obecne po stronie backendu, kt\u00f3ry wykonuje operacje zwi\u0105zane z generowaniem kodu \u2014 backend Rust mo\u017ce generowa\u0107 kod w cz\u0119\u015bciach, kt\u00f3re nast\u0119pnie LLVM mo\u017ce przetwarza\u0107 r\u00f3wnolegle. Frontend m\u00f3g\u0142 do tej pory przetwarza\u0107 kod \u017ar\u00f3d\u0142owy tylko w trybie jednow\u0105tkowym. <\/p>\n
Aby wspiera\u0107 r\u00f3wnoleg\u0142e przetwarzanie, frontend zosta\u0142 przekszta\u0142cony w korzystaniu z biblioteki Rayon i znacznie przerobiony; na przyk\u0142ad wiele jego cz\u0119\u015bci synchronizowanych jest teraz za pomoc\u0105 mutex\u00f3w i blokad do odczytu\/zapisu, a w kodzie u\u017cywane s\u0105 typy atomowe. Podczas test\u00f3w wydajno\u015bci nowa r\u00f3wnoleg\u0142a implementacja mog\u0142a wykonywa\u0107 kompilacj\u0119 do 2% wolniej w trybie jednow\u0105tkowym (-Z threads=1), ale przy wi\u0119cej ni\u017c jednym w\u0105tku pr\u0119dko\u015b\u0107 znacznie wzrasta\u0142a. Na przyk\u0142ad przy ustawieniu 8 w\u0105tk\u00f3w (-Z threads=8) w niekt\u00f3rych sytuacjach czas kompilacji uda\u0142o si\u0119 skr\u00f3ci\u0107 o 50%. <\/p>\n
Jednak\u017ce wynik w du\u017cej mierze zale\u017cy od ustawie\u0144 \u015brodowiska i kompilowanego kodu \u2014 dla bardzo ma\u0142ych program\u00f3w, kt\u00f3re i tak kompiluj\u0105 si\u0119 szybko, kompilacja w trybie wielow\u0105tkowym mo\u017ce przebiega\u0107 wolniej. Ponadto, zu\u017cycie pami\u0119ci w trybie wielow\u0105tkowym mo\u017ce znacznie wzrosn\u0105\u0107, na przyk\u0142ad w testach zaobserwowano wzrost zu\u017cycia pami\u0119ci o 35%. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"