The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В ночных сборках Rust расширены возможности распараллеливания компиляции

11.11.2023 20:47

Во фронтэнде компилятора Rust, выполняющем такие задачи, как синтаксический анализ, проверка типов и анализ заимствований, реализована поддержка параллельного выполнения, позволяющего существенно сократить время компиляции. Распараллеливание уже доступно в ночных сборках Rust и включается при помощи опции "-Z threads=8". В стабильную ветку рассматриваемую возможность планируют включить в 2024 году.

Работа над сокращением времени компиляции в Rust ведётся уже несколько лет. За первые 10 месяцев 2023 года время компиляции сократилось в среднем на 13%, пиковое потребление памяти снизилось на 15%, а размер генерируемых файлов уменьшился на 7%. На данном этапе ускорение было достигнуто за счёт оптимизаций самого компилятора. После этого разработчики перешли к работе над ускорением при помощи распараллеливания операций во время компиляции.

До сих пор распараллеливание в Rust обеспечивалось в основном на уровне процессов, например, пакетный менеджер Cargo может запускать несколько процессов rustc для одновременной компиляции нескольких пакетов. Поддержка распараллеливания также присутствует на стороне бэкенда, выполняющего операции, связанные с генерацией кода - бэкенд Rust может генерировать код частями, которые в дальнейшем LLVM может обрабатывать параллельно. Фронтэнд же до сих пор мог обрабатывать исходный код только в однопоточном режиме.

Для поддержки распараллеливания фронтэнд переведён на использование библиотеки Rayon и значительно переработан, например, многие его части теперь синхронизируются с помощью мьютексов и блокировок чтения/записи, а в коде используются атомарные типы. При тестировании производительности новая распараллеливаемая реализация могла выполнять компиляцию до 2% медленнее при работе в однопоточном режиме (-Z threads=1), но когда потоков больше одного скорость значительно возрастала. Например, при установке 8 потоков (-Z threads=8) в некоторых ситуациях время компиляции удавалось сократить на 50%.

При этом результат сильно зависит от настроек окружения и компилируемого кода - для очень маленьких программ, которые и так компилируются быстро, компиляция в многопоточном режиме может выполняться медленнее. Кроме того, потребление памяти в многопоточном режиме может значительно возрастать, например, в тестах наблюдался рост потребления памяти до 35%.

  1. Главная ссылка к новости (https://blog.rust-lang.org/202...)
  2. OpenNews: Проект NGINX опубликовал инструментарий для разработки модулей на языке Rust
  3. OpenNews: Google переписал на языке Rust прошивку pvmfm, используемую в Android
  4. OpenNews: Открытие кода Rust-компилятора Ferrocene
  5. OpenNews: Выпуск языка программирования Rust 1.73
  6. OpenNews: JetBrains представил IDE RustRover и прекратил разработку открытого плагина intellij-rust
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60095-rust
Ключевые слова: rust, compile, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (79) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 23:05, 11/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    это получается я смогу быстрее компилять фаерфокс?
     
     
  • 2.6, Аноним (6), 23:12, 11/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там у огнелисы лишь небольшие куски на расте, поэтому даже медленнее получиться.
     
     
  • 3.7, worldmind (?), 23:21, 11/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Стоит запустить cloc перед тем как комментировать
     
     
  • 4.67, Аноним (67), 17:56, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты запустил сам-то? Какие результаты? ff на с++ и js написан - шах и мат.
     
  • 3.14, НяшМяш (ok), 00:10, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Санта-Барбара "онаним газифицирует лужу" серия 1337
    https://openhub.net/p/firefox/analyses/latest/languages_summary
     
     
  • 4.18, фнон (?), 00:39, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    ого, это получается что в следующем (возможно в 25м) году Раст обгонит Сишку
    Неплохо, весьма неплохо!
     
     
  • 5.76, Аноним (76), 07:24, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Последние пару лет Раст и Сишка соревновались только в том кого из них первым выкинут из проекта.
     
  • 4.20, Алкоголизм (?), 01:01, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Б-же, 4 ляма строк на HTML, даже больше, чем на С. И после этого некоторые продолжают утверждать, что HTML не язык программирования, а я не могу являться сертифицированным HTML-программистом.

    А если серьёзно, откуда так много? Весь интерфейс лисы описан на html/js?

     
     
  • 5.25, Аноним (25), 02:36, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    «Вы говорите что HTML невозможно программировать. По-моему вы просто жутко наелись конфет…» — Денис Попов
     
  • 5.33, вымя (?), 05:28, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А если серьёзно, откуда так много? Весь интерфейс лисы описан на html/js?

    Да. XUL мёртв, но подходы его живы.

    Хотя я уверен, что до половины от этого занимает монструозный about:newtab с нескучными списками самых посещаемых сайтов на react.js.

     
  • 5.34, Смузихлёб (ok), 06:52, 12/11/2023 Скрыто ботом-модератором     [к модератору]
  • –2 +/
     
  • 5.68, Аноним (67), 17:59, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А если серьёзно, откуда так много? Весь интерфейс лисы описан на html/js?

    Не только интерфейс, но и многая внутренняя логика. Чего удивительного? Ты посмотри сколько занимает в процентном соотношении код на lua или vimscript в neovim, или код на elisp в emacs.

     
  • 4.41, Axel (??), 10:10, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зачем там BrainFuck?
     
     
  • 5.61, фнон (?), 15:59, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чтоб тебе стало инетресно и ты сломал мозг))
     
  • 5.66, Аноним (67), 17:55, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно это некорректные данные от систем, которые определяют тип файла.
     
  • 4.65, Аноним (67), 17:54, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    11% - это много? Потом идет python, будет говорить что ff на питоне? Или ты сразу встал в защитную позу из-за того, что кто-то сказал что тебе не нравится?
     
     
  • 5.78, Аноним (76), 07:33, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Учитывая, что код на Python форматирован без скобок и в целом более компактный и высокоуровневый, можно смело говорить, что Firefox скорее написан на Python, чем на Rust. Не говоря уже о Javascript.
     

  • 1.2, Аноним (2), 23:07, 11/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну а как вы хотели?
     
  • 1.3, Аноним (6), 23:08, 11/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Остаётся этот самый бекэнд на Раст переписать. Зиг по слухам уже слезает с ллвмной иглы.
     
     
  • 2.11, Аноним (11), 23:35, 11/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Совсем не по слухам, давно стоит чёткая цель

    https://github.com/ziglang/zig/issues/16270

     
  • 2.39, фнон (?), 08:55, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не очень понятно зачем Т е можно потратить N сотен человеко-часов, а можно за... большой текст свёрнут, показать
     
     
  • 3.42, Советский инженер (ok), 10:16, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    судя по тикету, они не хотят зависеть от LLVM-ных библиотек.
    но это не мешает им использовать бинарники LLVM
     
  • 3.52, Terminator_T1000_РоботСлизь (?), 12:30, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Цель скорее имиджевая. Раст декларируется как замена дырявым Си/Си++, а под копотом втихаря у себя юзает "ллвмное сишное поделие". Более того, Раст не гнушается пользоваться сишной либси в недрах своей стдлибы. Не к лицу, какие-то "двойные стандарты". Попахивает ханжеством и лицемерием.
     
     
  • 4.53, фнон (?), 12:56, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Извини, но твое сообщение выглядит как набор пафосных штампов.

    Никто втихаря ничего не юзает - о том что раст собирается ллвм'ом могут не знать только домохозяйки (и то не все)) - любой человек которые решил его установить, прочтет документацию.
    По поводу либСИ - уже были попытки переписать (steed), думаю к этому еще вернутся.

    В любом случае добавление раст-кода к си-коду уже делает код лучше (хотя бы будет меньше use-after-free).

     
     
  • 5.75, Аноним (76), 07:20, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Добавление раст-кода к си-коду делает только необходимым поддерживать два языка вместо одного. Никакой код лучше от Раста автоматически не становится.
     
     
  • 6.85, Аноним (85), 13:57, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Можно утверждать с полной уверенностью, что становится хуже. Потому что ломается линковка, появляется зависимость от шланга и его стека (в том числе, от плюсовых либ), во многих случаях появляются случайные труднодиагностируемые зависания (и особенно это касается менее популярных платформ). Так что, если видишь растофанатика, смело плюй ему в лицо, он глупый и хочет тебе навредить.
     
     
  • 7.92, Советский инженер (ok), 18:52, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    пойди это librsvg расскажи.
    все вы такие умеые и умелые в комментах языком чесать. а вот когда касается дела - то пшик.
     
  • 4.55, Аноним (55), 13:58, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но двойные они только у опеннетных Военов Супротив Раста, сидящих тут с вендочки... большой текст свёрнут, показать
     
     
  • 5.84, Серб (ok), 13:40, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Совсем евангилисты раста обленились?

    Где тут сказано, что штатный интерфейс?

    Где тут сказано что никто не может сделать библиотеку для работы с системными вызовами?

    Бери, делай, работай. Поддерживать придется самому - это да.
    И код поддержки разных архитектур и ядер придется писать самому - это то же да.


    И да, как раз с этим у раста большие проблемы. Из-за заточенности на безопасности условная компиляция сложна в реализации. Из-за своеобразного взгляда на ООП такие реализации требуют мультиплексирования одних и тех же участков кода.

     
     
  • 6.86, Аноним (55), 16:31, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Совсем Воены овоенились - сами опять что-то придумали, сами оспорили И слушать ... большой текст свёрнут, показать
     
     
  • 7.87, Серб (ok), 16:48, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь дай пример кода, где функции на разных архитектурах в качестве параметров принимают разные структуры. И как реализуется работа с двумя разными структурами двух разных архитектур одним кодом...

    Очень будем посмотреть!

     
     
  • 8.88, Аноним (55), 17:32, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https github com jasonwhite syscalls tree main src ... текст свёрнут, показать
     
     
  • 9.89, Серб (ok), 18:01, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чутку глянул Это вот прям сахарок https github com jasonwhite syscalls blob ... текст свёрнут, показать
     
  • 9.91, Серб (ok), 18:16, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так где там разные структуры Вызов системного вызова по номеру и передача парам... текст свёрнут, показать
     
     
  • 10.93, Аноним (55), 20:49, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Папа, где море c Сам что-то придумал, сам потребовал опровергнуть истинны... большой текст свёрнут, показать
     
     
  • 11.94, Аноним (94), 21:16, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Забавно Так где разные структуры то Где один код обрабатывающий разные структу... текст свёрнут, показать
     
     
  • 12.95, Аноним (55), 21:53, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Забавно, пошли очередные это не считаица, это тоже, а покажи мне диво-дивное, ч... большой текст свёрнут, показать
     
     
  • 13.99, Аноним (99), 11:22, 14/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Изначально речь и шла про невозможность одним кодом разные структуры обрабатыват... текст свёрнут, показать
     
     
  • 14.100, Аноним (55), 22:26, 14/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Изначально речь шла о И да, как раз с этим у раста большие проблемы Из-за зато... большой текст свёрнут, показать
     
     
  • 15.101, Аноним (99), 02:31, 15/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 3.54, Аноним (54), 13:00, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Не очень понятно 'зачем'?

    зачем независимость ? внезапно чтобы не зависеть от прихотей левой пятки трансгендера

     
     
  • 4.60, янонимус (?), 15:56, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А он не может написать хороший код?
    Может ты не сможешь им пользоваться? Как это у вас называется, "зашкварно"?
    Или скрепы разогнуться?
     
     
  • 5.64, Аноним (64), 17:41, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А он не может написать хороший код ?

    пусть хоть волшебный код будет - кто думает о будущем не подсядет на вендорлок, поматросил и бросил в таких случаях лучшая стратегия

     
  • 5.77, Аноним (76), 07:27, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так эти трансгендеры код не пишут, они максимум на маркдауне в CoC контрибутят.
     
  • 3.80, Аноним (76), 07:47, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы весь тулчейн Zig был написан на компактном и быстром Zig и не тянул за собой тонны легаси.
     
     
  • 4.82, Советский инженер (ok), 09:46, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а может Zig такой компактный и быстрый как раз за счет использования LLVM?
    такие простые мысли тебя не посещали?
     

  • 1.5, Павел Отредиез (ok), 23:09, 11/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    :) надо быстрее в своп ложиться...
     
  • 1.8, Аноним (8), 23:21, 11/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Кроме того, потребление памяти в многопоточном режиме может значительно возрастать, например, в тестах наблюдался рост потребления памяти до 35%.

    Возрастать по сравнению с многопроцессностью? Не верю.

     
     
  • 2.15, Tron is Whistling (?), 00:10, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вполне может. Если там насовали лок на каждый указатель и используются обильные мелкие структуры - 35% - это ещё не предел.
     
  • 2.31, morphe (?), 05:16, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Многопроцессность не отменяется, как и раньше каждый крейт компилируется в отдельном процессе, однако теперь каждый из этих процессов может использовать несколько потоков при компиляции (При кодогенерации оно и так использовало многопоточность llvm)
     
     
  • 3.43, Аноним (43), 10:18, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Надеюсь, додумаются всё в 1 процесс засунуть и параллелить только одними потоками.
     
     
  • 4.69, morphe (?), 19:31, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Надеюсь, додумаются всё в 1 процесс засунуть и параллелить только одними потоками.

    А какой смысл?

     
     
  • 5.72, Аноним (72), 01:08, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну что ты как маленький? Чтобы потребители Коры Дуба™ были счастливы.
     

  • 1.17, Аноним (17), 00:18, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Собаки лают, караван идёт...
     
     
  • 2.21, Аноним (21), 01:02, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Собаки распараллеливают - караван идет

    8 потоков и на 50% быстрее. Каждый поток добавляет 6%... Питон, вроде, "параллельнее" будет.

     
     
  • 3.23, Павел Отредиез (ok), 01:26, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Они ещё не познали всю силу фрагментирующего дефрагментатора.
     
     
  • 4.24, Павел Отредиез (ok), 01:45, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У меня и козырь припасён. А как насчёт дефрагментирующего фрагментатора?

    Всё братья, простите грешника, спаааать!

     
  • 2.79, Аноним (76), 07:38, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Собаки лают, а все как писали на Си и С++, так и пишут.
     

  • 1.27, Аноним (27), 03:04, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Лучше бы сборку из GCC завезли.  Go можно собрать из GCC, а сабж - нет.
     
     
  • 2.32, Аноним (32), 05:25, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не переживайте. Люди этим занимаются.
     
  • 2.44, Аноним (43), 10:20, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    go-gcc не собирает многие приложения. А м6огие собранные - крашатся.
     
     
  • 3.45, Аноним (85), 10:28, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Учитывая, что на расте ничего не написано, то хватит и сборки немногого. Главное, что не придётся тащить этот мерзкий тулчейн (а шланг и вовсе компилируется вечность).
     
     
  • 4.48, Советский инженер (ok), 11:52, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >расте ничего не написано
    >не придётся тащить этот мерзкий тулчейн

    так если ничего не написано, то зачем таскаешь?
    мазохист?

     
     
  • 5.51, Аноним (85), 12:11, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Firefox, pyca/cryptography, librsvg. Ни одной другой причины нет.
     

  • 1.35, Аноним (35), 07:27, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сборка больших проектов и так задействует все ядра, так как производится в несколько процессов. А для небольших проектов время компиляции - явно не бутылочное горлышко.

    Если кто еще не понял, для чего это все делается, то - чтобы ускорить искусственные хелловорлды, впечатлить CEO, добавить круто выглядящие строчки в резюме и освоить деньги спонсоров. Собственно, весь раст как язык был изначально создан с такими целями.

     
     
  • 2.74, Аноним (76), 07:17, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эффективным менеджерам не нужен быстрый и эффективный язык, им нужно нечто с помощью чего можно бесконечно доить проект переписываниями и фиксами. Вот они и проталкивают Раст, специально спроектированный для этого.
     

  • 1.40, glad_valakas (?), 09:50, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    а в дневных билдах хрома и фаерфокса распараллелено уже все что можно.
    только жрать меньше они не стали.
    еще раз для непонятливых: ловкая утилизация системных ресурсов не является оптимизацией производительности.
     
  • 1.46, ИмяХ (ok), 10:47, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Но, погодите-ка, ведь раст изначально разрабатывался с поддержкой многопоточности "из коробки", как так получается, что многопоточная компиляция появляется только сейчас, спустя 15 лет с начала его разработки?
     
     
  • 2.47, фнон (?), 11:06, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты не путай многопоточное исполнение и компиляцию
    Компилятор может вообще быть на совершенно другом языке (и потом быть переписан на свой же язык, но не всегда)
    Раст начинал с окалма, ГнуСИ с волосатого паскаля.
     
     
  • 3.58, Аноним (58), 14:57, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А он и не путает. Он спрашивает, как так получилось, что сами сапожники остались без сапог.
     
     
  • 4.59, фнон (?), 15:04, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А они собирались делать себе сапоги? Или сам придумал)?
    Насколько я помню историю то выбор ллвм был почти сразу.
    Это отличный способ получить кучу профита из коробки и не придумывать велосипеды без сильной необходимости.
     
  • 4.97, burjui (ok), 22:59, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Интересен другой вопрос: а как так получилось, что лучшие разработчики на планете собрались на этом ресурсе и разучились читать?
     
  • 2.50, Аноним (55), 12:04, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Но, погодите-ка, ведь раст изначально разрабатывался с поддержкой многопоточности "из
    > коробки", как так получается, что многопоточная компиляция появляется только сейчас,

    А зачем "домохозяки", очевидно считающие что можно было просто сделать "запусти_много_потоков(синтактический_анализ_сорса)" интересуются?


     
  • 2.96, burjui (ok), 22:57, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Параллельная компиляция в rustc есть уже давно (этап генерации кода), просто сейчас дело дошло до распараллеливания фронтенда. Очевидно, проблемы решаются по мере возникновения и по важности. А как с параллельной компиляцией обстоят дела у других компиляторов, позвольте узнать?
     

  • 1.63, Аноним (67), 16:07, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где конкретные цифры по проектам? Ну к примеру насколько сам компилятор стал быстрее собираться? Что это маркетинговые байки
     
     
  • 2.70, фнон (?), 19:50, 12/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если перейти по ссылке в статье в блог - то там можно найти ссыль на гитхаб
    https://github.com/rust-lang/compiler-team/issues/681
    там есть примеры изменения времени компиляции разных либ (напр Serde, hyper, regex и тд)

    Спойлер: ускорилось от 11 до 47%, в среднем 30%
    Under 8 cores and 8 threads, the parallel front end can reduce the clean build (cargo build with -Z threads=8 option) time by about 30% on average.

     

  • 1.73, Аноним (76), 07:12, 13/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    "для очень маленьких программ, которые и так компилируются быстро, компиляция в многопоточном режиме может выполняться медленнее" - то есть общая скорость компиляции хелоуворлдов растишек в итоге только уменьшилась.
     
     
  • 2.90, нах. (?), 18:10, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не переживай за них так. На самом деле скорость компиляции не изменилась, потому что определяется скоростью скачивания миллиона крейтов от которых зависит их хеловрот.

     
  • 2.98, burjui (ok), 23:03, 13/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    На целых 2%. Возможно, ты слышал о таком понятии, как "компромисс". Это такая штука, которую приходится реализовывать примерно в 95% решаемых задач в реальном мире.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру