Мимопроходящий,

В твоём случае мимопроходящий )

Соколинский Борис,

Это понятно. Просто кроме jpeg есть и другие алгоритмы с потерей качества
На видюхах они давно используются
Более того, на них даже FPS больше, потому что меньше памяти тягается

Соколинский Борис,

Почему искусственно?
Огромное количество текстур срисовывается или сфотографируется с реальных объектов
Так что не совсем согласен

А что насчёт jpeg-а - он неплохо кодируется и CPU. Просто почему Delphi 7 делает это в разы быстрее Delphi XE 10 - отдельный вопрос

Sapersky,

Dll в миллиард раз проще разумеется
Но если ты можешь прилинковать obj - автоматически снимается проблема развертывания, версии компонентов, конфликтов и прочей фигни

Если код на С++ - есть возможность экспортировать Си-функции
Если есть классы - можно делать обёртки

Но основная проблема - это зависимости
То есть стандартные функции типа malloc, вызов API, внутренние типа __chkstk_ms

С этими зависимостями бороться сложно, но можно
Та же библиотека jpeg, или zlib - хорошие примеры
Я где-то видел OpenSSL в обьектниках. Но не для всех платформ

Не обычный
Мне кажется если чисто zlib-ом жать - получится быстрее
Там разделение на чанки - я думаю, это замедляет

Я только под виндой и компилирую
Но так как имею дело с низкоуровневым кодом без зависимостей - окружение не настраивал
Ты прав, эта большая тема

Я создавал тему на геймдеве, мне там немного помогли, но дело с мёртвой точки не сдвинулось: https://gamedev.ru/flame/forum/?id=243821
Более того, я нанимал чувака, чтобы он сделал то же самое - но до результата не дошло. Остались несколько статей на вики в моём внутреннем репозитории. Если интересно почитать или можешь продвинуться в вопросе - могу предоставить права, переходи в личку.

А я преимущественно низкоуровневый на Clang и пишу
Очень удобно, условно один код, нажал скриптик - собралось сразу под 10 платформ: 5 операционных систем по 2 битности
GCC такой штукой к сожалению не обладает
И IDE не нужно - фигачу всё в годболте

На ассемблер перехожу неохотно и исключительно вынуждено
К сожалению Clang не всегда идеально оптимизирует код (и GCC кстати эквивалентный код выдаёт)
Насчёт реализации: там ассемблер только под x86 и x64. Под ARM-ы только на Си
Я сравнивал по производительности высокоуровневый вариант с ассемблером - было процентов на 20 медленнее
Я 2 недели эту функцию писал, а за основу (на малых размерах) взял код Шарахова из стандартного Move для x86

Sapersky,

А мне там вроде msys2 и посоветовали
Но до результата не дошло - билд сервер не был настроен
В любом случае будет желание посотрудничать по какому-либо направлению - милости прошу

20% было на размерах до 48 байт
По сути это и есть самые ходовые размеры

TinyMove - он ведь не для Си/С++ кода, он в первую очередь для Delphi/FreePascal, как аналог Move
Делать медленнее стандартного Move не вижу смысла
А так нормально получилось :)

Sapersky,

Не, там всё в комплексе
Главный инсайт - это важность выравнивания кода на 16 и 64 байта. Если заметишь - у меня там много nop-ов. Каждый nop выверен )

Ещё важна очередность сравнений и джампов. Поменяешь два джампа местами - для некоторых кейсов производительность просаживается

Для больших размеров стандартных 3 регистров не хватает - нужно пушить дополнительные. Но если это делать на высоком уровне - регистры пушатся в самом начале функции, а не на месте. Что раздувает код, жрет лишние такты

Для больших кусков case может выполняться стандартно через массив указателей. А я этого избежал. Из того рассчета, что каждый movups со смещением занимает 4 байта. Поэтому для Win64 я сваплю Count в rax, иначе movups занимает 5 байт

Кстати интересное наблюдение. movups даёт на выровненных данных такую же производительность, что и movaps

Sapersky,

Насчёт отдельно большого мува на высоком уровне
Я замерял, есть разница
Может даже в районе 5%

KreatorXXI,

Я думаю есть. Разные редакторы выдают идентичный png разного размера

Sapersky,

Это Move
Святое дело - гоняться даже за 5% )
Насчёт ссылок. У меня выравнивание функций 16 стоит. Некоторые я специально выравниваю на 64. Надо делать локальное выравнивание в некоторых местах. А не везде