Тёмная тема
На 27-ой минуте.
Dimich
> На 27-ой минуте.
Ну там печально конечно. Не самый идеальный код компилятора. Причём сравнивается с memcpy который наверняка писался вручную на ассемблере. Примерный идеал, который стоит ожидать:
mov ecx, size / 16 mov eax, ptr repeat: movdqa xmmword ptr [eax] dec ecx jnz repeat
И что у него
rep: movdqa add ... cmp ... ; с ожиданием результата add jb rep
То есть ECX тактов уже мы точно теряем.
Truthfinder
>Примерный идеал, который стоит ожидать:
Я б ещё x4 заанроллил.
FordPerfect
> Я б ещё x4 заанроллил.
А это часто может не давать результата, кстати. Современные архитектуры слишком умные (например копирование памяти что вперёд, что назад роли не играет, ещё и prefetch автоматом).
Это тупо выхлоп студии, без инлайна.
Truthfinder
> ещё и prefetch автоматом
Кстати, а можно как-то руками префетч делать? Ну кроме чтения из памяти по указателю.
Dimich
> Кстати, а можно как-то руками префетч делать? Ну кроме чтения из памяти по
> указателю.
_mm_prefetch
prefetchnta
prefetcht0
prefetcht1
prefetcht2
Для memset надо мимо кеша делать, stream, а не store (ещё одна ошибка в ролике).
Truthfinder
> А это часто может не давать результата, кстати.
Хз. Может и так.
https://rextester.com/MVSVD41130
> Для memset надо мимо кеша делать, stream, а не store
В очередной раз запощу:
https://twitter.com/rygorous/status/838928063844921344
А вот ERMSB может знать, как правильно мимо кеша делать запись.
return [](){};
> то не каст нельзя, это нельзя объект одного типа интерпретировать как другой.
> Ты можешь сколько угодно кастовать указатели, но разыменовывать указатель на
> int можно только если он содержит адрес int объекта.
FordPerfect
> Здесь тонна мелкого шрифта про совместимые типы, которые есть в C, но не в C++,
> но в целом ага.
Подождите-подождите, я верно, отстал от жизни.
Адрес - эта обезличенная сущность. По адресу лежат биты и байты.
По адресу не могут лежать инты или флоты.
Мы сами определяем, как мы хотим интерпретировать биты и байты по такому-то адресу. И сколько.
Так же всегда было )
Вопрос, а как юзать SIMD математику, в CLR?
Поясню:
1) Есть матлиба, написанная на С++
2) Требуется внедрить SIMD
3) Есть код (игровые сущности), который обращается к данной матлибе
4) Есть CLR враппер(для редактора), который дергает эти сущности
5) Компилятор ругается, что в CLR невозможно использовать выравненные по 16 объекты.
Собственно вопрос - есть ли способ обойти это все? (Например, некоторые проблемы возможно решать с использованием PIMP, например, при вызове треда)
это всё супер… кто поделится коммерческой пользой SIMD оптимизации?
innuendo
Коммерческий успех зависит от многих вещей в совокупности, в том числе и от SIMD оптимизаций.
Я видел много коммерческих проектов в которых они успешно использовались в той или иной мере -- начиная от рендеринга и заканчивая машинным обучением.
Глупо было бы говорить, что SIMD оптимизации определяют коммерческую успешность проекта, но вот что они экономят деньги которые пришлось бы тратить на закупку железа/времени на ферме -- это точно.
Truthfinder
Ты рассказывал что отделял обработку пикселей от растеризации -- не для того ли чтобы параллелить обработку фрагментов внутри одного треугольника?
Расскажи плиз про опыт распараллеливания )
Я раньше делал по тайлам 64x64 но ускорения больше 2 раз в среднем не получал -- и это на виндовсе.
А на линуксе что-то совсем плохо.
Truthfinder
> prefetchnta
> prefetcht0
> prefetcht1
> prefetcht2
оно одинаково работает на разных CPU?
Тема в архиве.