Разработчики подтвердили, что она прошла испытание травами.
UPD.
following the events of The Witcher 3, Ciri has undertaken the famously painful Trial of the Grasses which has mutated her into a powerful and resilient warrior
Данные 4 значения, фактически, являются константами. В ходе выполнения скрипта эти значения могут встречаться тысячи раз. Было бы крайне расточительно выделять новую область памяти на каждое объявление переменной с одним из этих типов.
Возможно я неправильно понял, но разве выделять на объявление каждой переменной область памяти на хранение ссылки на константное значение не столь же расточительно, сколько и выделение памяти на хранение самого этого константного значения? (для которого, кстати, по идее достаточно лишь одного байта, вместо четырех для ссылки)
Спасибо, что поделились информацией про подводные камни SIMD'ов. Я действительно не знал о некоторых нюансах.
По поводу простых бенчмарков с заполнением массивов: их главной целью было показать, что код с SIMD при компилировании без всяких оптимизаций работает также быстро, как обычный код, но с максимальной оптимизацией.
Реальным бенчмарком скорости является онлайн демка - вот в ней уже видно, что даже с максимальной оптимизацией компилятор создаёт программу, которая работает в 2 раза медленнее, чем моя с SIMD'ами
Однако небольшой момент: подобным стоит заниматься когда компилятор не осилил оптимизировать.
Полностью согласен. Этому посвящён небольшой абзац в статье:
На этом этапе у вас резонно может возникнуть вопрос «А зачем самим использовать SIMD инструкции, если компилятор может сам догадаться, как их применить?». На практике компилятор не всегда эффективно выполняет векторизацию вычислений, если он вообще сумеет до неё додуматься. Поэтому в действительно сложных вычислениях приходится самим векторизировать вычисления.
Странно, что он у вас смог векторизовать изначальный вариант, потому как на годболте (см. ниже) он честно пытается в цикле пройтись. Но вот если переписать её чуть-чуть, чтобы компилятор мог понять что тут происходит, то и на годболте происходит нечто чудесное
В том то и дело, что для неподготовленного читателя этот код окажется магией :) По этой причине я решил не использовать итераторы, чтобы не осложнять статью, посколько они специфичны конкретно для Rust, в отличие от SIMD команд. Но вы правы, компилятор Rust очень хорошо их оптимизирует.
Пропустил что-то этот момент. Сравнивать производительность кода в дебаг-режиме (а opt=0 это именно оно) это совершенно отвратительная идея. Лучше бы придумался пример который компилятор не осиляет (это сделать элементарно, как я выше показал самые простые вещи его могут смутить), и от него уже плясать.
Признаю, это сравнение получилось нечестным. Но до этого как раз было сказано о честном сравнении:
И при проверке мы увидим в консоли… что векторная реализация работает медленнее? Так происходит из-за того, что компилятор оптимизирует скалярную реализацию до того же уровня скорости.
Неправда, чтобы такого не происходило — надо принимать буфер в generate_fractal_image параметром, а не создавать его каждый раз.
Как вариант. На практике в онлайн демо работа с буфером происходит практически также: буфер создаётся в JS (через wasm), а потом в функцию отрисовки передаётся указатель на этот буфер. Но после заполнения картинки буфер удаляется.
Неправда, чтобы инвертировать комплексное число — следует воспользоваться функцией inv
Если не оптимизировать вычисления, то можно обойтись и функцией diff.inv() или выражением 1.0 / diff. Здесь же речь о том, как 2 раза не считать одно и то же: вначале мы используем норму чтобы проверить близость точки, а потом используем её для инверсии diff:
let mut diff = z - root;
let square_norm = diff.norm_sqr();
if square_norm < MIN_DIFF {
return z;
}
diff.re /= square_norm;
diff.im /= -square_norm;
sum += diff;
Боюсь, что уточнение результата так же, как и в алгоритме быстрого обратного корня, для произвольной степени будет не оптимально. В быстром обратном корне используется метод Ньютона, который использует производную от изначальной функции. А у нас функция вида , так что её производная будет , что также содержит в себе степень. Получается, что нам придется помимо того, что возводитьв степень, также возводитьв степень, для чего снова придется использовать один из быстрых алгоритмов, который будет снова использовать себя, и так далее, пока не дойдем до какой-то степени, которую можно посчитать за один такт. По поводу других методов уточнения результата ничего сказать не могу, не изучал эту тему.
Спасибо, что написали про ассоциативность, добавлю пометку. Однако на практике погрешности не возникает. Видимо, встроенные методы тоже подвержены этому эффекту (на скриншотах ниже погрешность отображается в столбце Sum difference).
Тесты в C++
Тесты в C#
Тесты в Java
Про способ с возведением через кубы я тоже думал. Было бы интересно посмотреть на программную реализацию троичного возведения в степень и сравнить его с другими методами.
С энергопотреблением все просто: увидел, что светодиод красный — выключил свет в пустых комнатах (у нас дома это частая проблема) или отключил электропечку.
Уровень TVOC позволяет следить за экологией квартиры, и, если мы наблюдаем красный уровень, то это значит, что пора открыть окна и проветрить квартиру.
Отображение температуры несёт скорее исследовательский характер. Мне хотелось проследить за показаниями температуры нашей квартиры в течение года.
Есть ли предел развития компьютерной графики в видеоиграх, и если есть, то когда он будет преодолен? Какие новые технологии улучшения графики придут на замену классическим методам увеличения количества полигонов и разрешения текстур?
Добавлена функция повторного напоминания.
Нажмите на кнопку под уведомлением чтобы бот напомнил о нём ещё раз через 5 минут.
По прошествии 5 минут данная кнопка исчезнет автоматически.
Интересная статья, подчеркнул для себя важные моменты для переработки парсера в будущем, за что большое спасибо.
А боту нужно просто час указать, сделано для того, чтобы в групповых беседах меньше реагировал и не так засорял чат:
Разработчики подтвердили, что она прошла испытание травами.
UPD.
Source: https://www.ign.com/articles/inside-the-witcher-4-cd-projekt-reds-plans-for-its-next-big-rpg
Возможно я неправильно понял, но разве выделять на объявление каждой переменной область памяти на хранение ссылки на константное значение не столь же расточительно, сколько и выделение памяти на хранение самого этого константного значения? (для которого, кстати, по идее достаточно лишь одного байта, вместо четырех для ссылки)
Кому-то все равно пришлось этот код написать.
coreведь откуда-то знает как складывать числа.Есть ли в планах сделать рейтинг устройств публичным?
Спасибо, что поделились информацией про подводные камни SIMD'ов. Я действительно не знал о некоторых нюансах.
По поводу простых бенчмарков с заполнением массивов: их главной целью было показать, что код с SIMD при компилировании без всяких оптимизаций работает также быстро, как обычный код, но с максимальной оптимизацией.
Реальным бенчмарком скорости является онлайн демка - вот в ней уже видно, что даже с максимальной оптимизацией компилятор создаёт программу, которая работает в 2 раза медленнее, чем моя с SIMD'ами
Полностью согласен. Этому посвящён небольшой абзац в статье:
В том то и дело, что для неподготовленного читателя этот код окажется магией :)
По этой причине я решил не использовать итераторы, чтобы не осложнять статью, посколько они специфичны конкретно для Rust, в отличие от SIMD команд. Но вы правы, компилятор Rust очень хорошо их оптимизирует.
Признаю, это сравнение получилось нечестным. Но до этого как раз было сказано о честном сравнении:
Это из-за модульных веб-воркеров. Довольно странно, потому что на локальном сервере полифилл работает. Возможно гитхаб ломает его.
Как вариант. На практике в онлайн демо работа с буфером происходит практически также: буфер создаётся в JS (через wasm), а потом в функцию отрисовки передаётся указатель на этот буфер. Но после заполнения картинки буфер удаляется.
Если не оптимизировать вычисления, то можно обойтись и функцией
diff.inv()или выражением1.0 / diff. Здесь же речь о том, как 2 раза не считать одно и то же: вначале мы используем норму чтобы проверить близость точки, а потом используем её для инверсииdiff:Боюсь, что уточнение результата так же, как и в алгоритме быстрого обратного корня, для произвольной степени будет не оптимально. В быстром обратном корне используется метод Ньютона, который использует производную от изначальной функции. А у нас функция вида
, так что её производная будет 
, что также содержит в себе степень. Получается, что нам придется помимо того, что возводить
в степень
, также возводить
в степень
, для чего снова придется использовать один из быстрых алгоритмов, который будет снова использовать себя, и так далее, пока не дойдем до какой-то степени, которую можно посчитать за один такт.
По поводу других методов уточнения результата ничего сказать не могу, не изучал эту тему.
Спасибо, что написали про ассоциативность, добавлю пометку.
Однако на практике погрешности не возникает. Видимо, встроенные методы тоже подвержены этому эффекту (на скриншотах ниже погрешность отображается в столбце Sum difference).
Тесты в C++
Тесты в C#
Тесты в Java
Про способ с возведением через кубы я тоже думал. Было бы интересно посмотреть на программную реализацию троичного возведения в степень и сравнить его с другими методами.
Совсем забыл добавить их, вернул. С ними сразу как-то понятней стало.
P.S. В порядке бреда можно уровнем энергопотребления рисовать на панели :)
Уровень TVOC позволяет следить за экологией квартиры, и, если мы наблюдаем красный уровень, то это значит, что пора открыть окна и проветрить квартиру.
Отображение температуры несёт скорее исследовательский характер. Мне хотелось проследить за показаниями температуры нашей квартиры в течение года.
Нажмите на кнопку под уведомлением чтобы бот напомнил о нём ещё раз через 5 минут.
По прошествии 5 минут данная кнопка исчезнет автоматически.
А боту нужно просто час указать, сделано для того, чтобы в групповых беседах меньше реагировал и не так засорял чат: