Cat
ааааа
Anonymous
Alexander
В Rust есть аналог iterate из Haskell?
Alexander
Бесконечный список необязателен. 😂
Berkus
ну в расте есть и бесконечные списки
Berkus
и аналог iterate думаю найдется, что он делает-то?
Alexander
Мне нужно функцию (замыкание) f применить k раз к начальному значению, а потом результату.
Alexander
f(f(...f(x)...))
Αλεχ
(0..k).fold(..)?
Alexander
Вариант. Спасибо!
Маjко
Маjко
Есть линка?)
Cat
видимо это https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086/14
Alexander
А как в Rust принято замерять время выполнения? В Haskell есть +RTS -s например. А тут просто time prog?
(((Sergey(not seresha))
Ну да
(((Sergey(not seresha))
Я о другом не слышал
(((Sergey(not seresha))
Можно внутри ещё разницу смотреть
Αλεχ
вроде есть cargo bench
Anonymous
вроде есть cargo bench
cargo bench есть только в nightly на текущий момент.
Лубинец, теперь доволен?
Αλεχ
cargo bench есть только в nightly на текущий момент.
Лубинец, теперь доволен?
а бывает не найтли?о_0о_0о_0о_0о_0о_0о_0о_0о_0о_0о_0
Anonymous
а бывает не найтли?о_0о_0о_0о_0о_0о_0о_0о_0о_0о_0о_0
Надеюсь, когда-нибудь будет и в стабильной ветке.
(((Sergey(not seresha))
Интересно как там у больших
(((Sergey(not seresha))
У которых все в продакшене
(((Sergey(not seresha))
Стейбл поди
(((Sergey(not seresha))
Ну у меня везде найтли
(((Sergey(not seresha))
И последняя
Anonymous
не знаю
(((Sergey(not seresha))
Тебя к расту не пускают?
Anonymous
я в общем говорю
сейчас бы работать программистом 🤢
Маjко
Я имел в виду карго бенч
А я имею в виду что и в стейбле можно бенчить, проблема то только в том что extern test в ночнике
Anonymous
А я имею в виду что и в стейбле можно бенчить, проблема то только в том что extern test в ночнике
Окей, исправил, кто не понял, теперь яснее, что я пояснял сообщение про каргобенч?
Berkus
Vladimir
cargo bench есть только в nightly на текущий момент.
Лубинец, теперь доволен?
Да не ток в найтли он есть
Vladimir
В найтли есть интернал крейт test который по дефолту для бенчей используется, но можно делать кастомные бенчи, юзая либы criterion-rs например, и он позволяет запускать под cargo bench кастомные бенчи
Alexander
По сути для stable есть criterion и bencher, которые на вид практически один в один как test::bencher из Найтли.
𝙽𝚒𝚌𝚔
https://thetechsolo.wordpress.com/2016/08/28/scaling-to-thousands-of-threads/
Блокирующий IO быстрее NIO примерно на 25%, а с NPTL вы можете иметь сотни тысяч потоков.
𝙽𝚒𝚌𝚔
Подробнее в презентации Пола Тимы здесь http://www.slideshare.net/e456/tyma-paulmultithreaded1
Safort
Подробнее в презентации Пола Тимы здесь http://www.slideshare.net/e456/tyma-paulmultithreaded1
По ссылке 404 Not Found.
𝙽𝚒𝚌𝚔
это слайдшаре, РКН в помощь
Cat
А каким боком это к расту?
(По первой ссылке ничего про раст, вторую не смотрел, но на превью жаба)
𝙽𝚒𝚌𝚔
Речь шла о неблокирующем IO в том числе в расте. Есть стереотип, что nio==быстро, что не совсем соответствует действительности.
𝙽𝚒𝚌𝚔
tymaPaulMultithreaded.pdf
𝙽𝚒𝚌𝚔
𝙽𝚒𝚌𝚔
Для тех, кто не может открыть эту презентацию на слайдшаре, я закачал пдфку.
Маjко
Речь шла о неблокирующем IO в том числе в расте. Есть стереотип, что nio==быстро, что не совсем соответствует действительности.
Бенчи в студию и тогда поговорим, лол
𝙽𝚒𝚌𝚔
В статье есть бенчи. Ну и товарищу Tyma можно верить.
Kerrigan:
> мне одному кажется, что делать асинхронный фреймворк, который для полноценного использования предлагает создавать по треду на запрос, это какой-то лол?
Если брать потоки из пула, то это нормальный подход.
Маjко
В статье есть бенчи. Ну и товарищу Tyma можно верить.
Kerrigan:
> мне одному кажется, что делать асинхронный фреймворк, который для полноценного использования предлагает создавать по треду на запрос, это какой-то лол?
Если брать потоки из пула, то это нормальный подход.
Там бенч как я понял на одном потоке приведен с одним клиентом
Маjко
Пока что все бенчи явно показывают что тот же HTTP на nio гораздо быстрее блокирующего io с потоком на каждого клиента
Маjко
techempower в помощь
Маjко
Товарищ tyma нашел какой-то корнер-кейс и на основе его делает далекоидущие общие выводы
𝙽𝚒𝚌𝚔
Товарищ tyma делал malinator, самый что ни на есть настоящий пример использования.
Маjко
Джава -- тоже корнер-кейс.
Кроме того, странно видеть заявления вида "все думают, что неблокирующее IO быстрее, но никто не бенчил" когда есть techempower.
Маjко
Alexander
А я признаться со скепсисом к победе асинк отношусь тоже. По сути в процы и системы долго вгоняли и оптимизировали мультрединг, а тут типа ручное кручение контента в проге взяло и победило. Ну хз, конечно может, но не на 100% уверен в этом.
Маjко
Маjко
Ну на 10k линукс даже не вспотеет
Маjко
ulimits в помощь
Маjко
Ну твой код же, объем выделения на стеке тоже ты контролируешь
Маjко
Ну так то да, асинк на N потоках-воркерах как сейчас в токио -- идеальный вариант по перформансу
Маjко
А как же эрланг
𝙽𝚒𝚌𝚔
Я бы сказал наоборот, как только сервис выходит за рамки перекладывания из одной очереди в другую и появляется какая-то обработка сообщений, модель с пулом потоков выигрывает совершенно. Опыт ноды как пример отлично демонстрирует, что событийная модель далеко не универсальна.
Alexander
Ну так то да, асинк на N потоках-воркерах как сейчас в токио -- идеальный вариант по перформансу
Я в идеальном мире видел бы что ос научилась какие-то лёгкие треды, и по факту на выходе получится тоже самое.
Маjко
Я бы сказал наоборот, как только сервис выходит за рамки перекладывания из одной очереди в другую и появляется какая-то обработка сообщений, модель с пулом потоков выигрывает совершенно. Опыт ноды как пример отлично демонстрирует, что событийная модель далеко не универсальна.
Это вопрос архитектуры сервиса, а не модели IO.
Ты и с токио можешь завести пулы потоков и делать пайплайны обработки.
Alexander
+ ещё запускать будет не только одну программу в асинк. А, так сейчас же почти так и есть :)
Маjко
Alexander
Так о чем и речь же в статье вроде как - долой мелкие пулы 100к пул делай - переключение контента не скажется (теоретически, судя по статье )
Маjко
Железо дешевое, программисты дорогие, все дела
Alexander
Признаться хз, у нас в проде 2.5тб рам :)
Маjко
Вот там уже как раз встает проблема с плотностью оборудования, они не могут вечно горизонтально масштабировать говнокод
Alexander
Одно.