⏸ Название определено (думаю, все уже заметили), больше мучить этим вас не буду 😃
Ссылки в телеге изменены, но старые тоже работают в режиме переадресации.
⏸ Хотел написать интру для Lovebyte 2023 под Para||elix, но не успел. Жаль, конечно. Но с другой стороны, есть возможность доработать и потом показать более полноценную версию.
⏸ Заметил, что legacy FPU работает пипец как медленно в сравнении со скалярным SSE/AVX (с векторным, думаю, будет такая же картина). По крайней мере, на Alder Lake. На Sandy Bridge замечал разницу, но не настолько большую. Вообще, странно, Instruction Tables (Agner Fog) показывает незначительные различия. В общем, чтобы говорить об этом более предметно, нужно потестить более обстоятельно. И на AMD в том числе.
Плюс вылезли вопросы сохранения FPU и SIMD-регистров (ибо некоторые API типа @GetDurationFloat — получение времени с момента старта, могут их портить).
⏸ Также задумался о 64-битной версии (на будущее). Раньше, конечно, тоже думал, но эта мысль казалось не столь интересной. По сути, интры получаются не шибко больше в размере, зато кол-во регистров удваивается (как общего назначения, так и SIMD). Но сложнее организовать API-вызовы по похожей схеме (т.е. call [ebp+fn], где fn — это любое число, сделать уже не получится). В общем, поживём — увидим. До этого ещё далеко.
⏸ Исправил баг: при использовании многопоточных функций интра висла через несколько секунд или минут. Причина была неочевидна, но чисто интуитивно решил положить notify_all внутрь залоченного мьютекса (раньше он был снаружи) — баг пропал :)
⏸ При старте интры, а также при вызове функций потоков (к примеру, для каждого пикселя) в регистр ebx теперь записывается выровненный по границе 256 байт адрес 4КБ буфера в TLS, т.е. потоко-локальной области. Это оказалось офигенно удобно. Т.е. вы можете хранить локальные переменные не только в стеке, но и в TLS, используя адресацию вида [ebx+n]. Потокобезопасно! Скажу по секрету, что можно адресовать не только в плюс, но и в минус (до 128 байт), т.е. у вас есть не 4КБ, а даже 4096+128 байт :)
Но, наверное, я расширю эту область до 64КБ (18МБ для 256+32 потоков — не так уж и много). Может, урежу стек (для каждого потока) до 512КБ (вместо дефолтного 1МБ) или даже до 256КБ (к чему такой большой?) 🤔
⏸ Поменял значение регистра ebp при старте интры. На нём завязана таблица API, а также зона сервисных данных. Раньше было ebp = 0x08000000 (напомню, что код грузится по адресу 0x10000000 (ebp*2), фрейм буфер — 0x40000000 (ebp*8)). Сейчас сделал ebp = 0x01C71C80. Это же гораздо лучше, согласны? 😀
Объясняю суть. При таком значении ebp можно использовать не только [ebp], но и [ebp+ebp], [ebp+ebp*2], [ebp+ebp*4], и [ebp+ebp*8], т.е. целых 5 вариантов почти за ту же цену (но первый всё же дешевле на байт) :)
✅ Первые 2 варианта (1x, 2x) можно зарезервировать для API (таким образом, кол-во функций увеличивается с 255 до 511 — с учётом возможных расширений, пусть будет).
✅ Следующий (3x) — для сервисных данных (инфа о процессоре, событиях (юзер нажал Esc), опциях, настройках видео и аудио, коэффициенты для приведения координат к диапазону 0..1, FP-координаты центра и т.д.). Причём, если раньше под них выделялось 128 байт, то сейчас можно 256 (128 оказалось мало).
✅ Ещё один (5x) — для хранения констант (0, 0.5, 1, π, 2π, e, √2 и т.д., включая векторные по 16 float'ов для SIMD вплоть до AVX-512).
✅ И последний [ebp+ebp*8] (9x) — это адресация 0x10000080 (теперь понятно почему 0x01C71C80?) Т.е. добавляя байтовую константу (-128..127) можно иметь доступ к первым 256 байтам кода (а сделав, скажем, lea edx,[ebp+ebp*8+127] — к смещениям 127..382 через edx). Тоже удобно.
Ссылки в телеге изменены, но старые тоже работают в режиме переадресации.
⏸ Хотел написать интру для Lovebyte 2023 под Para||elix, но не успел. Жаль, конечно. Но с другой стороны, есть возможность доработать и потом показать более полноценную версию.
⏸ Заметил, что legacy FPU работает пипец как медленно в сравнении со скалярным SSE/AVX (с векторным, думаю, будет такая же картина). По крайней мере, на Alder Lake. На Sandy Bridge замечал разницу, но не настолько большую. Вообще, странно, Instruction Tables (Agner Fog) показывает незначительные различия. В общем, чтобы говорить об этом более предметно, нужно потестить более обстоятельно. И на AMD в том числе.
Плюс вылезли вопросы сохранения FPU и SIMD-регистров (ибо некоторые API типа @GetDurationFloat — получение времени с момента старта, могут их портить).
⏸ Также задумался о 64-битной версии (на будущее). Раньше, конечно, тоже думал, но эта мысль казалось не столь интересной. По сути, интры получаются не шибко больше в размере, зато кол-во регистров удваивается (как общего назначения, так и SIMD). Но сложнее организовать API-вызовы по похожей схеме (т.е. call [ebp+fn], где fn — это любое число, сделать уже не получится). В общем, поживём — увидим. До этого ещё далеко.
⏸ Исправил баг: при использовании многопоточных функций интра висла через несколько секунд или минут. Причина была неочевидна, но чисто интуитивно решил положить notify_all внутрь залоченного мьютекса (раньше он был снаружи) — баг пропал :)
⏸ При старте интры, а также при вызове функций потоков (к примеру, для каждого пикселя) в регистр ebx теперь записывается выровненный по границе 256 байт адрес 4КБ буфера в TLS, т.е. потоко-локальной области. Это оказалось офигенно удобно. Т.е. вы можете хранить локальные переменные не только в стеке, но и в TLS, используя адресацию вида [ebx+n]. Потокобезопасно! Скажу по секрету, что можно адресовать не только в плюс, но и в минус (до 128 байт), т.е. у вас есть не 4КБ, а даже 4096+128 байт :)
Но, наверное, я расширю эту область до 64КБ (18МБ для 256+32 потоков — не так уж и много). Может, урежу стек (для каждого потока) до 512КБ (вместо дефолтного 1МБ) или даже до 256КБ (к чему такой большой?) 🤔
⏸ Поменял значение регистра ebp при старте интры. На нём завязана таблица API, а также зона сервисных данных. Раньше было ebp = 0x08000000 (напомню, что код грузится по адресу 0x10000000 (ebp*2), фрейм буфер — 0x40000000 (ebp*8)). Сейчас сделал ebp = 0x01C71C80. Это же гораздо лучше, согласны? 😀
Объясняю суть. При таком значении ebp можно использовать не только [ebp], но и [ebp+ebp], [ebp+ebp*2], [ebp+ebp*4], и [ebp+ebp*8], т.е. целых 5 вариантов почти за ту же цену (но первый всё же дешевле на байт) :)
✅ Первые 2 варианта (1x, 2x) можно зарезервировать для API (таким образом, кол-во функций увеличивается с 255 до 511 — с учётом возможных расширений, пусть будет).
✅ Следующий (3x) — для сервисных данных (инфа о процессоре, событиях (юзер нажал Esc), опциях, настройках видео и аудио, коэффициенты для приведения координат к диапазону 0..1, FP-координаты центра и т.д.). Причём, если раньше под них выделялось 128 байт, то сейчас можно 256 (128 оказалось мало).
✅ Ещё один (5x) — для хранения констант (0, 0.5, 1, π, 2π, e, √2 и т.д., включая векторные по 16 float'ов для SIMD вплоть до AVX-512).
✅ И последний [ebp+ebp*8] (9x) — это адресация 0x10000080 (теперь понятно почему 0x01C71C80?) Т.е. добавляя байтовую константу (-128..127) можно иметь доступ к первым 256 байтам кода (а сделав, скажем, lea edx,[ebp+ebp*8+127] — к смещениям 127..382 через edx). Тоже удобно.