All streams
Search
Write a publication
Pull to refresh
195
0
Михаил @mikhanoid

ИММ УрО РАН

Send message

Есть такая функция https://docs.rs/futures/0.3.5/futures/future/fn.join_all.html Отличие в том, в какие очереди эти задачи будут записаны, и как эти очереди будут обработаны. Соответственно, могут быть иными и объёмы необходимой памяти. join_all, например, кучу Box создаёт.

Парадигма с promise/future везде примерно одинаковая. Что помешало автору на других языках сохранить futures в массив и точно так же их потом последовательно дождаться? Или почему он в программе на Rust не воспользовался join_all?

Можно. Но ресурсов это потребляет заведомо меньше.

Важно, как именно всё выполняется. В реализации на Tokio сначала все таймеры записываются в список ожидания, а потом цикл с await проверяет каждый таймер на срабатывание, сравнивая текущее время с тем, что записано в списке ожидания. Естественно, все таймеры окажутся сработавшими, когда сработает первый await в цикле. И общее время работы составит 10 секунд.

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

Поэтому прямое сравнение таких вариантов кода не имеет смысла. Это не означает, что при корректном сравнении Tokio и Rust не будут выигрывать у JS. Но нужно измерять примерно одно и то же, а не выполнять для сравнения на одной из систем заведомо более сложный алгоритм.

Зачем же так недооценивать умы 19-го века? Они до квантовой механики додумались и дифференциальной геометрии. Из-за феномена "цифровой деменции" да и вообще деградации науки, как социального института, не уверен, что современные учёные смогли бы до таких вершин мысли подняться. Кто знает, что в 19 веке смогли бы извлечь из мобильного телефона?

Вот едут учёные изучать реликтовые племена (условно) Амазонки. И что? У них всё оборудование с протоколами самоуничтожения? Зачем это нужно?

Это просто прекрасно: сравнивать последовательный await задач с waitall. GPT - программирование, не приходя в сознание, - сегодня в тестах, завтра в production!

Будут ли у конечных пользователей деньги, после того, как их погонят с работы под лозунгом "ИИ может лучше!"? Ставка на ИИ с экономической точки зрения странная, потому что сокращает платёжеспособный спрос.

Это так не работает. Кодирование инструкций для CISC может потребовать больше байтов для эквивалентной программы, даже если самих инструкций нужно меньше.

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

Спасибо за статью, но возник следующий глупый вопрос. Вот есть огромные затраты на продвижение, которые надо окупать. Кроме того, чтобы пришёл инвестор, игры должны обладать определённой структурой, разработчики и художники ограничены в своём творчестве, во времени. Игры превращаются в скучный штампованный ширпотреб. И так далее, и тому подобное, и прочие негативные последствия.

Спрашивается: а зачем всё это? Если разработчикам достаётся малая доля денежного потока, то почему бы не перестать ставить целью завоевать аудиторию в миллионы пользователей? По идее, не нужно же заработать все деньги мира, а нужно заработать достаточно, чтобы содержать своё домохозяйство (скажем так), и иметь ресурсы для развития игры.

Не разумнее ли в этом случае просто привлечь меньше игроков, но более интересным продуктом? В итоге сработает сарафанное радио, аудитория появится. Почему это не работает? Ну, с большими корпорациями понятно, конечно, они все больны болезнью Паркинсона на разных стадиях. Но для небольших команд, кажется, стратегия "мы хотим завоевать весь мир" не особо разумна.

Есть не правильное и не неправильное :)

Может, проблема в следующем? Если они говорят, что GPT-4 разработала новый яд, никто не сможет это проверить, ведь, они скажут, что этические нормы не позволяют открыть им формулу. Если они скажут, что разработали лекарство, придётся предъявить результат, а не просто "впечатления учёного".

Длина - это интеграл вдоль кривой. Интегрирование по лесенке не является интегрированием вдоль дуги окружности, потому что в таком интеграле необходимо брать расстояния между точками, которые попадают на окружность, не добавляя к ним расстояния до уголков лесенки. Конечно, это избыточное расстояние до уголков сокращается. Но и самих уголков становится больше. В пределе это к нулю не сходится.

А зачем абстрактной интерпретации залезать в голову программиста? Обычно есть примитивные операции, вроде number->u8/saturating, которые абстрактный интерпретатор понимает. При помощи таких операций программист может выразить своё намерение.

Lisp - это не чистое бестиповое Lambda-исчисление, а как минимум расширенное большим набором примитивных операций, поэтому динамическая типизация есть, вопросы возникают, и их решают теми или иными способами.

Ну... В принципе, да имел в виду ту же самую проблему, но только в очередной раз она вылезла мне боком с совершенно другой стороны: попытка сделать простенький скриптовый язык поверх Rust библиотеки снова потребовала писать unsafe-код. Ну, потому что в скриптовом языке тоже нет концепции владения. Получается, что в экосистеме Rust безопасно можно писать только на Rust и в терминах Rust с серьёзными ограничениями на структуры данных и алгоритмы. ??‍♂️

Я в ручную так пробовал. Она просто зацикливается на ошибках, и всё.

Плохо то, что оно реально не упрощается, но всех пытаются заставить поверить в то, что упрощается.

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

Information

Rating
Does not participate
Registered
Activity

Specialization

System Software Engineer, scientific programming
Scheme
C
Assembler
Linux
Maths
Julia
Compilers
Math modeling
Machine learning
Computer Science