Comments 10
Гораздо интереснее было бы сравнить какой нибудь ввод вывод и заюзать в расте async. Я, если честно, ждал сравнения горутин и tokio
А почему версия Go такая старая (1.14.2 выпущена 2020-04-08)?
Программа на Rust показала намного большую производительность при вычислении членов возвратной последовательности, чем программа на Go: 367 млн. итераций в секунду против 44 млн. Обращаем внимание на этот факт, но не беремся делать из него глубокие выводы, поскольку сравнение производительности программ, написанных на этих языках, не входило в задачи исследования.
В следующей статье предлагаю сравнить прохождение одного и того же виража гоночным болидом на скорости 367 км/час и Ладой Приорой на скорости 44 км/час. Очень жду выводов о том, что Лада Приора прошла этот вираж намного ровнее, ни разу не выехав на встречную полосу, а гоночный болид ехал по какой-то совсем странной траектории.
Если длительность выполнения i-той задачи вычисляется как дельта между её стартом и финишем, то вычислять с этим показателем «стоимость конкуренции» совершенно неправильно, так как их время перекрывается из-за переключения задач.
И я не смотрел код, и не очень разбираюсь в этих языках, но похоже, что вы сраниваете лёгковесные потоки Go, которыми управляет и раскидывает по процессам системы сам Go; со спавнингом полноценных системных процессов в Rust, где ими управляет операционка, их не рекомендуется создавать много. Прошу знающих подтвердить или опровергнуть.
Да, именно так.
На самом деле сравнение не корректно. И все результаты фактически вытекают из этого.
Более корректно было бы сравнить горутины с async кодом, в идеале - наверное на голом tokio
Замечу, что tokio умеет запускать рутины в разных «физических» тредах, поэтому io-bound-ность не обязательно
crossbeam::scope- можно было и просто join использовать без внедрения лишних зависимостей.
Статья показалась мне наукоемкой, исследовательской и... весьма бесполезной. В духе отчета по НИОКР за госбабки.
Проблема автора в том, что он не в курсе, что бывают io-bound задачи и cpu-bound.
Go и его рантайм заточены под io-bound задачи (когда надо ждать пересылки данных), а в Rust существуют разные подходы в зависимости от задач - можно юзать async (std или tokio) для io-bound задач, и можно юзать хоть crossbeam хоть обычные потоки для cpu-bound задач.
И ещё момент - если хотелось придумать задачу с большим количеством вычислений, то можно было просто взять хэширование.
А это точно тестирование конкурентности? Так как аналогом горутин в расте это корутины, а не потоки. Golang хорошо в i/o, потому он и взлетел в сетевых приложениях. Rust же может и i/o bound и cpu bound. Для этого собственно и есть корутины и отдельно потоки.
Наблюдение за выполнением конкурирующих задач в Go и Rust