in asm we trust

Я таки расковырял вопрос о том, как смотреть ассемблер для заданной функции в rust'е. Оказалось не очень тривиально из-за постоянного инлайнинга, но можно.

https://medium.com/journey-to-rust/viewing-assembly-for-rust-function-d4870baad941

И у меня есть ощущение появившегося фундамента. Если у меня будут какие-то непонятки, я всегда могу заглянуть вниз и посмотреть что там происходит.

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

Теперь - видно. Покой и довольствие.

SDL

Ага, texture.update кратно быстрее, чем пикселяция. За вычетом странных всплесков по 7 fps, от 45 до 120 fps в разрешении 2560x1440. В целом, SDL выглядит куда понятнее, чем пистон.

UPD, после минимального рефакторинга я имею стабильные 289 fps (1920х1080), что явно больше, чем нужно, и можно начать тыкать слипы.

SDL demo

Получилось круче, чем я ожидал. fullscreen 2560x1440 fade-in/out с примесью шума шпарит на 60fps 2560x1440 с 62% утилизацией CPU и нулём спецусилий по оптимизации (кроме использования texture.update).

Всё остальное в SDL офигенно. Нужен fullscreen? Фигак. Нужно курсор убрать? Фигак. Нужно узнать разрешение этого самого fullscreen? Фигак. Всё что нужно и без доп. заморочек. Я пока не до конца понимаю необходимость разделения между window и canvas, но это мелочь.

Вот код демки: https://github.com/amarao/sdl_random

В целом я чувствую нереальное освобождение после боли с недокументированным piston'ом в котором "texture context" это мистическая фигня, которая что-то делает, но что именно не разобрать.

В целом, в equart примерно треть накрученного кода была связана с тем, что я не мог просто и дёшего копировать байты в текстуры. Можно было 'draw', что было крайне далеко от "вот тебе массив u8, это новое содержимое текстуры". (Возможно, тут ещё разница между старым процом и новым...), в SDL это очень просто.

Сейчас я засяду за многопоточный диспетчер "рисования", и мне придётся снова решить как правильно рисовать. Видимо, всё-таки слать changes.

О чём речь?

У меня есть тред, задача которого рисовать и обрабатывать события (ресайз, потенциально "стрелочки" по картинке и т.д.). Я хочу, чтобы этот тред был 100% отзывчивым.

Ещё есть то, что я рисую - это график уравнения или функции. Функция может считаться очень медленно и совершенно нормально, если часть точек будет появляться со временем (вплоть до минут). Задача рассчёта полностью и легко параллелится на треды, так что можно утилизовать все ядра.

Возникает два подхода к тому, как эти треды сообщают о нарисованном:

Они раз в N времени пересылают в основной тред свой кусок битмапа целиком, все зависимости от того, что было посчитанно.

Либо, они шлют поток команд на рисование (т.е. список точек и их цветов).

... задача ресайза требует "группировки" данных от разных тредов.

Возможно, мне удастся засунуть в один тред процесс "рисования" по данным, а треды будут просто эти данные считать. Я глубоко впечатлён seqlock'ами в ядре (кто не знает - lockless метод доступа к шареным между тредами данным, позволяющий читать и писать одновременно, при условии, что запись происходит не сильно часто), так что можно с ними поиграть тоже.

UPD: Ещё, вся моя демка после компиляции - 350к (после strip). Это, конечно, не 64к com-файлы, но и не многие мегабайты.

... продолжаю разглядывать ассемблер...

if frames % 2 == 0 {

test al, 1
jne .LBB24_53