1000000 Integers из бенчмарка влезут в кэш современных процессоров, тогда как в реальном приложении, скорее всего, читаться они будут не из кэша. В таком случае int (размер 4 байта) вместо Integer (24 байта) должен быть быстрее, но стримы с ним работать не умеют.
В случае ручного написания С кода можно код наподобие image = np.clip(127.5 * (image + 1.0), 0.0, 255.0).astype(np.uint8).transpose(1, 2, 0) уложить в 1 цикл, минимизировав обращения к памяти. Сможет ли C++ компилятор так сделать, или разобьёт на 5 проходов?
Это shared memory? Можно, но если объект не массив байтов - то после сериализации. Да в целом дополнительный сложности и оверхэд по сравнению с остальными языками, о том и статья.
Вместо проблем с gil будут проблемы с тем, что в каждом процессе свой экземпляр интерпретатора, и для сообщения между ними придётся сериализовывать объекты и передавать через сокеты.
Просто добавлю, что на CPU с simd оптимизацией это работает с примерно той же скоростью (5-20мс / кадр на среднем девайсе в на 1 поток), код для проверки https://github.com/yarston/Telegram
К счастью, это только лишь хотелки. Пускай сначала добьются, чтобы их кодек работал на каждой кофеварке, без этого ни о каком распространении не может быть и речи.
Ну уж не на порядок, 20-30% и то в сложных сценах. Пруфы: https://www.phoronix.com/review/talos2019-opengl-vulkan/2 В какой - нибудь казуалке типа "3 в ряд" или неигровом кейсе (вывод видеопотока с камеры на дисплей мобильного устройства например) разницу с лупой искать придётся)
станет понятно, что "поляна" стала на порядок-два меньше. Именно на порядок, а не в разы.
Да вот как-то не стало понятно. На практике же особой разницы между доходом после уплаты всех налогов европейского разработчика и российского я что-то не вижу особо, может быть десятки процентов, но уж никак не разы и тем более не 1-2 порядка. Озоны, Яндексы и Тиньковы как раньше составляли костяк местной продуктовой разработки, так и продолжают, галеры ушли, но они и раньше были на любителя. Ну а те, кто держал разработчиков здесь, а работал на глобальный рынок - вряд ли распустили свои команды, интернет не отвалился, международные платежи тоже.
Когда язык для каждого класса типа Point(x, y) выделяет место на куче, в каждом экземпляре класса хранит кучу служебных данных, а в любом контейнере вместо собственно точек - ссылки на кучу, а потом ещё долго и упорно чистит образовавшийся мусор, сложновато сделать что-то сравнимое с олдскульными движками по эффективности. Сейчас наверное самое перспективное выносить физику в вычислительные шейдеры - это и быстро и кроссплатформенно.
А, кстати, сколько нынче занимает времени передать 8 мегабайт в GPU и обратно?
PCIe 4.0x16 - это 64 GB/s, так что выходит 250 мкс на туда-обратно. А вообще по идее это неважно, т.к. для отображения на мониторе данные по любому придётся передавать в GPU, вопрос только на каком этапе, до обработки или после. Про пирамиду пишут, что на gpu делают.
Или вообще выбросим этот язык и начнём переписывать всю программу на очередном «модном современном и точно самом-самом-быстром-в-мире» языке? Нет.
Ну да, взять подходящий инструмент для решения задачи - это не наш метод, возьмём неподходящий и будем превозмогать)
Как использовать List вместо Map?
Есть такая штука - flatmap - вкратце, это как map, только данные в памяти лежат сплошным отсортированным массивом. За счёт этого итерация по flatmap так же быстра, как по массиву.
Блур тяжёлая операция, особенно без поддержки со стороны GPU или C/C++, скорее из-за него тормоза. Это можно поправить, размывая только вырезанную область кнопок.
А чтобы не создавать многократно Btimap, можно сделать 1 раз
val buttonBitmap = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888)
val canvas = Canvas(buttonBitmap)
И затем при перерисовке подложки кнопки
canvas.drawBitmap(backgroundNotBlurredBitmap, x, y, null) //отрисуется в buttonBitmap
blur(buttonBitmap, ...)
Для задач вроде "поработать с сетью и диском" есть бенчмарки, которые расставляют всё по своим местам. Конечно, задача синтетическая, на реальных задачах наверно всё не так плохо будет, но вот например икона чистого кода в лице Spring там показывает производительность 3.6% от топового решения. Вряд ли такое может пройти незамеченным для производительности.
Без попытки включить pgo тема сишки не до конца раскрыта. Плюс векторные инструкции скорее всего позволили бы значительно улучшить результат, на riscv во всяком случае, этот пример хорошо ложится.
Если в build.gradle добавить флаг оптимизации -O3 в строку cppFlags "-fexceptions -O3", то время выполнения с++ и java кода становится +/- одиноаковым, C++ чуть быстрее на устройстве и чуть медленнее в эмуляторе. Это не удивительно, потому что у вас последовательный проход по массиву в цикле - при этом проверки на выход за пределы массива вырезаются. А вот если паттерн доступа будет более сложный, то java код очень сильно проиграет, например, при преобразовании фурье.
Очень странно, что Ryzen 9 3900x + AMD Radeon 5700 XT не вытягивает базовую анимацию рабочего стола без дерготни. У меня такого даже на дохлом атоме не было в те времена, когда LLVM никто всерьёз не воспринимал.
О, спасибо, не знал про такой.
1000000 Integers из бенчмарка влезут в кэш современных процессоров, тогда как в реальном приложении, скорее всего, читаться они будут не из кэша. В таком случае int (размер 4 байта) вместо Integer (24 байта) должен быть быстрее, но стримы с ним работать не умеют.
В случае ручного написания С кода можно код наподобие
image = np.clip(127.5 * (image + 1.0), 0.0, 255.0).astype(np.uint8).transpose(1, 2, 0)
уложить в 1 цикл, минимизировав обращения к памяти. Сможет ли C++ компилятор так сделать, или разобьёт на 5 проходов?
Это shared memory? Можно, но если объект не массив байтов - то после сериализации. Да в целом дополнительный сложности и оверхэд по сравнению с остальными языками, о том и статья.
Вместо проблем с gil будут проблемы с тем, что в каждом процессе свой экземпляр интерпретатора, и для сообщения между ними придётся сериализовывать объекты и передавать через сокеты.
Просто добавлю, что на CPU с simd оптимизацией это работает с примерно той же скоростью (5-20мс / кадр на среднем девайсе в на 1 поток), код для проверки https://github.com/yarston/Telegram
К счастью, это только лишь хотелки. Пускай сначала добьются, чтобы их кодек работал на каждой кофеварке, без этого ни о каком распространении не может быть и речи.
Всё хуже: в wasm нет многопоточности и поддержки SIMD инструкций, так что тяжёлые алгоритмы в разы медленнее.
Ну уж не на порядок, 20-30% и то в сложных сценах. Пруфы: https://www.phoronix.com/review/talos2019-opengl-vulkan/2 В какой - нибудь казуалке типа "3 в ряд" или неигровом кейсе (вывод видеопотока с камеры на дисплей мобильного устройства например) разницу с лупой искать придётся)
Да вот как-то не стало понятно. На практике же особой разницы между доходом после уплаты всех налогов европейского разработчика и российского я что-то не вижу особо, может быть десятки процентов, но уж никак не разы и тем более не 1-2 порядка. Озоны, Яндексы и Тиньковы как раньше составляли костяк местной продуктовой разработки, так и продолжают, галеры ушли, но они и раньше были на любителя. Ну а те, кто держал разработчиков здесь, а работал на глобальный рынок - вряд ли распустили свои команды, интернет не отвалился, международные платежи тоже.
Когда язык для каждого класса типа Point(x, y) выделяет место на куче, в каждом экземпляре класса хранит кучу служебных данных, а в любом контейнере вместо собственно точек - ссылки на кучу, а потом ещё долго и упорно чистит образовавшийся мусор, сложновато сделать что-то сравнимое с олдскульными движками по эффективности. Сейчас наверное самое перспективное выносить физику в вычислительные шейдеры - это и быстро и кроссплатформенно.
Отучаемся говорить за всех. Я например, пользуюсь обоими (+vscode) для разных дел.
PCIe 4.0x16 - это 64 GB/s, так что выходит 250 мкс на туда-обратно. А вообще по идее это неважно, т.к. для отображения на мониторе данные по любому придётся передавать в GPU, вопрос только на каком этапе, до обработки или после. Про пирамиду пишут, что на gpu делают.
Ну да, взять подходящий инструмент для решения задачи - это не наш метод, возьмём неподходящий и будем превозмогать)
Есть такая штука - flatmap - вкратце, это как map, только данные в памяти лежат сплошным отсортированным массивом. За счёт этого итерация по flatmap так же быстра, как по массиву.
Блур тяжёлая операция, особенно без поддержки со стороны GPU или C/C++, скорее из-за него тормоза. Это можно поправить, размывая только вырезанную область кнопок.
А чтобы не создавать многократно Btimap, можно сделать 1 раз
И затем при перерисовке подложки кнопки
Тогда может и отдельный поток не нужен будет.
Для задач вроде "поработать с сетью и диском" есть бенчмарки, которые расставляют всё по своим местам. Конечно, задача синтетическая, на реальных задачах наверно всё не так плохо будет, но вот например икона чистого кода в лице Spring там показывает производительность 3.6% от топового решения. Вряд ли такое может пройти незамеченным для производительности.
Без попытки включить pgo тема сишки не до конца раскрыта. Плюс векторные инструкции скорее всего позволили бы значительно улучшить результат, на riscv во всяком случае, этот пример хорошо ложится.
Если в build.gradle добавить флаг оптимизации -O3 в строку cppFlags "-fexceptions -O3", то время выполнения с++ и java кода становится +/- одиноаковым, C++ чуть быстрее на устройстве и чуть медленнее в эмуляторе. Это не удивительно, потому что у вас последовательный проход по массиву в цикле - при этом проверки на выход за пределы массива вырезаются. А вот если паттерн доступа будет более сложный, то java код очень сильно проиграет, например, при преобразовании фурье.