От сюда следует, что поставленная гипотеза, полностью подтверждается, более сложная архитектура упрощает разработку
Если более сложная архитектура упрощает разработку, то, по идее, на разработку должно быть затрачено меньше времени, не так ли? Но по вашим данным получается как раз наоборот - более простая архитектура требует меньше времени, а следовательно - упрощает разработку. Не ясно, почему у вас именно такой вывод.
Да, действительно. Судя по всему уровень оптимизации влияет (если opt-level = 0 поставить в release конфигурации, то символ возвращается). Правда почему тут функция была заинлайнена между крйтами несмотря на выключенный lto я не уверен.
Лично я не пробовал, но случаем задание RUSTFLAGS="-C prefer-dynamic=yes" при сборке не заставит линковать std динамически, таким образом сильно снижая размер каждой динлибы?
Так-то отсутствие стабильного abi не мешает собрать и динлибу, и её пользователя одинаковой версией компилятора, не сходя до C abi.
ewext к слову в том же репозитории, но является отдельной от noita-proxy вещью и собирается под другой таргет (windows x32), а вызывается из lua, так что там кроме C abi вариантов нет, да.
Кроме самого проекта там ещё около 600 зависимостей, сборка которых тоже в эти 2 минуты включена. Не Qt конечно, но достаточно зависимостей, чтобы интерфейс и прочее было.
ewext к слову тоже на rust, и использует C ABI для ffi, конечно.
У стабильного ABI есть ещё и минусы - например, шанс застрять с неоптимальной реализацией хэшмапы.
Также... а зачем все эти трудности с переносом инкрементальных билдов, когда с нуля всё собирается за минуты? Вот только что проверил на одном из своих гуишных проектов (тык), в дебаге с нуля собирается на моей машине за 56 секунд, а в релизе - за 2 минуты. Неиллюзорный шанс потратить на скачивание готовых бинарников вручную больше, чем на такую сборку.
Ну а какая разница, что именно они там делают - главное чтобы на входе им был TokenStream, и на выходе тоже был TokenStream.
Также - откуда информация, что создаётся по отдельному процессу на макрос? Макросы собираются в динамическую библиотеку, после чего функции из них вызываются компилятором.
Ну и третье - а какое решение по вашему лучше? В С++ нет аналогичного макросам механизма, максимально близкое - это вызывать системой сборки скрипты, которые генерируют исходники. И не думаю, что этот подход лучше макросов.
станет станет, потому что компилятор будет знать что происходит и это сильно упростит инкрементальную сборку
Как вообще компилятор может знать меньше о том, что происходит в макросах, которые он сам же и вызывает, по сравнению с генерацией кода вне макроса? А с инкрементальной компиляцией всё и так просто - макросы считаются чистыми функциями, запускаются снова только когда код в пределах крейта изменился.
Форвард декларации невероятно ускоряют сборку, отрицать это сложно...
Не собирать вообще крайне редко получается. Например, если есть темплейты - то уже не всё получится в динлибу сложить. А если хочется опции компиляции поменять или под какую-то другую платформу собрать проект, то всё ещё придётся собирать самому.
Да и то, максимум на один раз меньше собирать библиотеку придётся, дальше всё равно инкрементальная компиляция будет работать и значительно снизит количество работы.
К слову, иногда и в rust можно выделить код в dll, например, это делает bevy, чтобы снизить количество времени, проводимое в линковке в дебаг сборках.
А что предлагаете вместо макросов использовать? "вызывать непонятно что в отдельных процессах" как часть скриптов сборки? Так быстрее не станет.
Форвард декларации это крайне неудобно, Да и очень сомневаюсь что это хоть как-то ускоряет компиляцию. Особенно учитывая, что модули в C++ всё как-то не доходят, а инклуд всех этих тысяч строк форвард деклараций на каждый файл исходников явно не ускоряет процесс. Precompiled headers конечно несколько помогают, но это решение, ИМХО, так себе.
А что, отсутствие стабильного ABI как-то влияет на время сборки? Если что, нестабильное оно только между релизами компилятора, в пределах одного релиза оно вполне стабильное и возможны как инкрементальная сборка, так и динамические библиотеки без перехода в C ABI. Так делает тот же bevy для ускорения повторной сборки.
ИМХО: Если использовать NAT ради защиты - то с практически тем же успехом можно кабель до провайдера ради безопасности перерезать. Как по мне, такого рода "безопасность" сыграла довольно злую шутку - если бы не она, вполне возможно, что IoT не был бы настолько знаменито дырявыми - ведь зачем среднему производителю тратиться на хоть какую-то безопасность, если подключение к камере извне крайне маловероятно?
Потребляется он потому, что программист так написал. Чтобы не потреблялся, надо передавать по ссылке. Кроме мутабельной ссылки есть ещё и иммутабельная:
Если честно, настройки rustfmt никогда особо не менял, так что не уверен.
Если опция на nightly, то с этим особо ничего не сделать. Впрочем, не обязательно весь крейт переводить на nightly, можно вызывать rustfmt вот так:
cargo +nightly fmt
По части цепочек функций - форматтер предпочитает записывать в одну строку, пока она не становится слишком длинной. Опция chain_width вроде похожа на правду.
Ну вот в расте уже "умные люди" договорились о стандарте, и большинство всё устраивает.
А что, писать #![allow(non_snake_case)] один раз на крейт (а не в каждом файле, как вы пишете), уже слишком несвободно? А добавить "-A non_snake_case" в rustflags в глобальный cargo config?
Так и в C# этот "навязанный стиль" есть. Вот представьте, что на C# кто-то решил использовать snake_case для имён переменных и скобочки на той же строке оставлять, вы бы не были... несколько несогласны с данным человеком? Особенно если вам с его кодом придётся работать?
Оно то, возможно, и так, но численного подтверждения этому тезису в статье нет.
Если более сложная архитектура упрощает разработку, то, по идее, на разработку должно быть затрачено меньше времени, не так ли? Но по вашим данным получается как раз наоборот - более простая архитектура требует меньше времени, а следовательно - упрощает разработку.
Не ясно, почему у вас именно такой вывод.
Да, действительно. Судя по всему уровень оптимизации влияет (если opt-level = 0 поставить в release конфигурации, то символ возвращается). Правда почему тут функция была заинлайнена между крйтами несмотря на выключенный lto я не уверен.
Хм, вроде как функция есть, последняя строка:
Единственное - я убрал всё, кроме варианта с dylib, потому что иначе не собирается, и я пока не разбирался, почему.
Лично я не пробовал, но случаем задание
RUSTFLAGS="-C prefer-dynamic=yes"при сборке не заставит линковать std динамически, таким образом сильно снижая размер каждой динлибы?Так-то отсутствие стабильного abi не мешает собрать и динлибу, и её пользователя одинаковой версией компилятора, не сходя до C abi.
ewext к слову в том же репозитории, но является отдельной от noita-proxy вещью и собирается под другой таргет (windows x32), а вызывается из lua, так что там кроме C abi вариантов нет, да.
К слову, даже не зная, о каком макросе вы конкретно говорите, есть разница между
и вызовом компилятором макроса в том же процессе, который уже запускает отдельный процесс.
Кроме самого проекта там ещё около 600 зависимостей, сборка которых тоже в эти 2 минуты включена. Не Qt конечно, но достаточно зависимостей, чтобы интерфейс и прочее было.
ewext к слову тоже на rust, и использует C ABI для ffi, конечно.
Вы бы ссылку скинули, искать макрос по названию без названия крейта, в котором он находится... ну такое.
У стабильного ABI есть ещё и минусы - например, шанс застрять с неоптимальной реализацией хэшмапы.
Также... а зачем все эти трудности с переносом инкрементальных билдов, когда с нуля всё собирается за минуты? Вот только что проверил на одном из своих гуишных проектов (тык), в дебаге с нуля собирается на моей машине за 56 секунд, а в релизе - за 2 минуты. Неиллюзорный шанс потратить на скачивание готовых бинарников вручную больше, чем на такую сборку.
Ну а какая разница, что именно они там делают - главное чтобы на входе им был TokenStream, и на выходе тоже был TokenStream.
Также - откуда информация, что создаётся по отдельному процессу на макрос? Макросы собираются в динамическую библиотеку, после чего функции из них вызываются компилятором.
Ну и третье - а какое решение по вашему лучше? В С++ нет аналогичного макросам механизма, максимально близкое - это вызывать системой сборки скрипты, которые генерируют исходники. И не думаю, что этот подход лучше макросов.
Как вообще компилятор может знать меньше о том, что происходит в макросах, которые он сам же и вызывает, по сравнению с генерацией кода вне макроса? А с инкрементальной компиляцией всё и так просто - макросы считаются чистыми функциями, запускаются снова только когда код в пределах крейта изменился.
Не собирать вообще крайне редко получается. Например, если есть темплейты - то уже не всё получится в динлибу сложить. А если хочется опции компиляции поменять или под какую-то другую платформу собрать проект, то всё ещё придётся собирать самому.
Да и то, максимум на один раз меньше собирать библиотеку придётся, дальше всё равно инкрементальная компиляция будет работать и значительно снизит количество работы.
К слову, иногда и в rust можно выделить код в dll, например, это делает bevy, чтобы снизить количество времени, проводимое в линковке в дебаг сборках.
А что предлагаете вместо макросов использовать? "вызывать непонятно что в отдельных процессах" как часть скриптов сборки? Так быстрее не станет.
Форвард декларации это крайне неудобно, Да и очень сомневаюсь что это хоть как-то ускоряет компиляцию. Особенно учитывая, что модули в C++ всё как-то не доходят, а инклуд всех этих тысяч строк форвард деклараций на каждый файл исходников явно не ускоряет процесс. Precompiled headers конечно несколько помогают, но это решение, ИМХО, так себе.
А что, отсутствие стабильного ABI как-то влияет на время сборки? Если что, нестабильное оно только между релизами компилятора, в пределах одного релиза оно вполне стабильное и возможны как инкрементальная сборка, так и динамические библиотеки без перехода в C ABI. Так делает тот же bevy для ускорения повторной сборки.
Это если роутер в свою очередь не находится за NAT провайдера, и тут как повезёт. Мне вот не повезло, у меня Symmetric (проверил с помощью pystun).
ИМХО: Если использовать NAT ради защиты - то с практически тем же успехом можно кабель до провайдера ради безопасности перерезать. Как по мне, такого рода "безопасность" сыграла довольно злую шутку - если бы не она, вполне возможно, что IoT не был бы настолько знаменито дырявыми - ведь зачем среднему производителю тратиться на хоть какую-то безопасность, если подключение к камере извне крайне маловероятно?
Потребляется он потому, что программист так написал. Чтобы не потреблялся, надо передавать по ссылке. Кроме мутабельной ссылки есть ещё и иммутабельная:
Если честно, настройки rustfmt никогда особо не менял, так что не уверен.
Если опция на nightly, то с этим особо ничего не сделать. Впрочем, не обязательно весь крейт переводить на nightly, можно вызывать rustfmt вот так:
По части цепочек функций - форматтер предпочитает записывать в одну строку, пока она не становится слишком длинной. Опция chain_width вроде похожа на правду.
Ну вот в расте уже "умные люди" договорились о стандарте, и большинство всё устраивает.
А что, писать
#![allow(non_snake_case)]один раз на крейт (а не в каждом файле, как вы пишете), уже слишком несвободно? А добавить "-A non_snake_case" в rustflags в глобальный cargo config?Так и в C# этот "навязанный стиль" есть. Вот представьте, что на C# кто-то решил использовать snake_case для имён переменных и скобочки на той же строке оставлять, вы бы не были... несколько несогласны с данным человеком? Особенно если вам с его кодом придётся работать?