Comments 13
Что-то вы совсем очевидные вещи рассказываете.
Мне даже в голову не могло прийти начать джойнить потоки в том же проходе, в котором они создавались...
Первое апреля в этом году настало раньше положенного
Вроде так себя ведут итераторы в любом языке, где они настоящие, а не просто у массивов есть два метода map/filter возвращающих новый массив. Без ленивости будет аллокация памяти на полный размер массива на каждый шаг обработки.
Такая же ситуация как в Rust будет в Java, например.
Вот ленивый async есть не везде, а ленивые итераторы везде.
Думаю, минусов накидали в первую очередь за заголовок. В оригинале статья называется "Помогите, итераторы делают мой код медленнее!", и с такой постановкой становится понятней что это разбор тривиальной ошибки.
Да и сам перевод далеко не дословный, а с кучей дополнительных пояснений и воды.
Я из-за слишком серьёзного заголовка ожидал рассмотрение каких-то краевых случаев, где zero-cost abstractions оказываются не zero-cost. А внутри увидел совсем другое (я даже не могу сказать, что производительность именно ухудшилась, ибо время исполнения выросло в 10 раз, но и нагрузка на CPU уменьшилась в 10 раз).
Сама по себе статья полезная, но с "Помогите, итераторы делают мой код медленнее", у меня бы не было неоправдавшихся ожиданий от содержимого, я бы читал её именно как статью для новичков, а не понял это только в середине.
где zero-cost abstractions оказываются не zero-cost.
Т.е. везде? Вызов функции не гарантирует сохранения и обработку всех инвариантов.
Хотите zero-cost - юзайте макросы (кстате, в стандартной библиотеке так и поступают)
Объясните минуса? Я вот могу показать примеры, например, с банальным вызовом `.len()` из-за которого отключаются определённые оптимизации. Или же написать примеры кода, в котором на выходе из-за использования функций падение в производительности в 10+ раз.
zero-cost abstractions это маркетинг, он невозможен из-за природы работы оптимизатора.
А вам в ответ расскажут, как добавление вызова .len() ускоряет код, а добавление итератора ускоряет ещё сильнее https://habr.com/ru/companies/otus/articles/718012/
Мы говорим про zero-cost, это означает что для оптимизатора не должно быть разницы использовали ли мы абстракцию или нет.
При чём тут ускорение при добавление вызова .len() если разговор идёт об информации которая есть у оптимизатора (на проходах в которых она нужна) при использовании абстракций?
Например len не особо юзается в стандартной библиотеке, а вместо неё используется макрос, т.к. в определённых кейсах оптимизатор не может доказать что 2 вызова len ссылаются на одно значение.
В плане ускорения, конечно итераторы в расте могут быть быстрей чем пользовательский код, т.к. проблемы оптимизатора компенсируются вызовом `assume`, у другими механиками. Но речь немного о другом.
Если спавнить потоки std::thread::scope, когда не требуется нетривиальной обработки JoinHandle, то .join() будет происходить "автоматически", без явного вызова, который в вашем корректном примере с итераторами делал код многословнее
"Обколются своими курсами, а потом такие статьи пишут"
Как итераторы в Rust могут ухудшить производительность: разбираемся в проблеме