Собираю сам на Mac DLL'ки (DYLIB) нужной мне библиотечки кода.
Версия для Intel весит на 28% больше, чем версия для ARM64. Потом обе версии склеиваются в один Universal Binary (единый DYLIB).
Здравствуйте, PeterOne, Вы писали:
PO>Версия для Intel весит на 28% больше, чем версия для ARM64.
Это еще более странно, чем полутора-двукратное превышение x64 над x86. Вы там определенно делаете что-то не так. На своем коде я вижу превышение x64 над ARM64 максимум на 1-2%.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, PeterOne, Вы писали:
PO>>Версия для Intel весит на 28% больше, чем версия для ARM64.
ЕМ>Это еще более странно, чем полутора-двукратное превышение x64 над x86. Вы там определенно делаете что-то не так. На своем коде я вижу превышение x64 над ARM64 максимум на 1-2%.
У меня в два раза программа растолстела после обновления им VC++ 2008 на последнюю. Никто не знает, как там уменьшить размер mfc программ до прежнего? У меня мысли, что они могут в exe пихать в том числе и зашифрованные исходники! Чтобы декомпилировать всё что угодно!
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Экстремальный случай — это раза в три, когда я llvm использовал. Но в полтора раза стабильно меньше
ЕМ>Непорядок это. Не смотрели, что именно там дает такое различие?
Здравствуйте, Morgan, Вы писали:
M>У меня в два раза программа растолстела после обновления им VC++ 2008 на последнюю.
Я локальные сборки делаю на VS 2008, а версии 14.x использую только для релизов. Новые компиляторы в режиме оптимизации по скорости (/O2) дают чуть более объемный код, но лишь на единицы процентов. А вот библиотечные функции могут быть больше на 20-30% — там более корректная многопоточность, поддержка локалей и встроенные проверки.
M>как там уменьшить размер mfc программ до прежнего?
Так надо смотреть map-файл, или вообще сравнивать с прежними. Удобно это делать в AMap.
M>У меня мысли, что они могут в exe пихать в том числе и зашифрованные исходники!
Не. А вот отладочная информация, в зависимости от ключей компилятора/линкера, туда попадать может.
M>Чтобы декомпилировать всё что угодно!
Мощные декомпиляторы, вроде Ghidra/IDA, неплохо восстанавливают исходники по бинарнику и его PDB, где лежит много сведений об исходнике. Если опасаетесь декомпиляции, то следите, чтобы PDB не утекали.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, PeterOne, Вы писали:
PO>>Версия для Intel весит на 28% больше, чем версия для ARM64.
ЕМ>Это еще более странно, чем полутора-двукратное превышение x64 над x86. Вы там определенно делаете что-то не так. На своем коде я вижу превышение x64 над ARM64 максимум на 1-2%.
Ну например, lcms2. Команда компиляции DYLIB:
./configure --disable-static && make
На M1 Маке создается aarch64 версия. Под Rosetta или на Intel Мак создается x86_64 версия.
Разница в размере +28% к Intel версии.
Тоже самое с другими open source библиотеками, в которых есть и более сложные скрипты компиляции. Результат похожий.
Здравствуйте, PeterOne, Вы писали:
PO>Разница в размере +28% к Intel версии.
Вот я и говорю — странно. Но предметно это можно обсуждать только с конкретными данными.
PO>Тоже самое с другими open source библиотеками, в которых есть и более сложные скрипты компиляции.
Скрипты-то при чем? Нужно рассматривать результаты работы компилятора/линкера. А то, может, те скрипты тупо накидывают туда каких-нибудь внешних файлов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, PeterOne, Вы писали:
PO>>Разница в размере +28% к Intel версии.
ЕМ>Вот я и говорю — странно. Но предметно это можно обсуждать только с конкретными данными.
PO>>Тоже самое с другими open source библиотеками, в которых есть и более сложные скрипты компиляции.
ЕМ>Скрипты-то при чем? Нужно рассматривать результаты работы компилятора/линкера. А то, может, те скрипты тупо накидывают туда каких-нибудь внешних файлов.
