OSDev http://osdev.su/ |
|
Об эффективности трансляторов http://osdev.su/viewtopic.php?f=6&t=433 |
Страница 4 из 4 |
Автор: | Himik [ 12 сен 2011, 18:25 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
SII писал(а): 12.09.2011 19:14:19 Grindars: линуксовый собран гцц и слинкован с либц динамически 12.09.2011 19:14:29 Grindars: виндовый собран MSVC и слинкован с либц статически Ясно. А я уж и поробовал bochs.exe архиватором сжать - а он почти не сжимается - и хотел написать, типа сжатие не в счёт :-) |
Автор: | SII [ 12 сен 2011, 18:27 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Himik писал(а): Ясно. А я уж и поробовал bochs.exe архиватором сжать - он почти не сжимается - и хотел написать, типа сжатие не в счёт :-) Оно всё равно в счёт, правда, неясно, в какую сторону. Как в счёт и формат файлов. Сравнивать надо всё ж по размерам секций кода, а не по файлам. Например, перемещаемый COFF займёт явно больше места, чем абсолютно тот же код, но в виде неперемещаемого бинарника, но, понятно, к эффективности транслятора это ни малейшего отношения иметь не будет. |
Автор: | Himik [ 12 сен 2011, 19:27 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
SII писал(а): Оно всё равно в счёт, правда, неясно, в какую сторону. Как в счёт и формат файлов. Сравнивать надо всё ж по размерам секций кода, а не по файлам. Лучше сравнивать по секциям кода и данных вместе, т.к. различные статики и структурные метаданные программы могут оказаться как в коде, так и в данных - это ни как не регламентировано. Касательно проекта bochs, ни какой статической линковки системных библиотек там нет, только что проверил. Там статические библиотеки создаются из собственных подпроектов, и это всё пользовательский код, который относится к основному функционалу, а не рантайму. Да, там как-бы статически линкуются системные библиотеки, но по факту они являются стабами к dll-кам. Так устроены все программы. |
Автор: | grindars [ 12 сен 2011, 19:37 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Вот виндовый: Код: $ wget http://sourceforge.net/projects/bochs/files/bochs/2.4.6/Bochs-2.4.6.exe/download -O bochs_inst.exe $ 7z x bochs_inst.exe $ objdump -x bochs.exe | grep 'DLL Name' DLL Name: WSOCK32.dll DLL Name: USER32.dll DLL Name: GDI32.dll DLL Name: WINMM.dll DLL Name: COMDLG32.dll DLL Name: COMCTL32.dll DLL Name: ADVAPI32.dll DLL Name: SHELL32.dll DLL Name: KERNEL32.dll MSVCRT или более новый аналог где? Не верю, что bochs не использует функции сишной либы. Вот размер: Код: text data bss dec hex filename 1844544 211456 0 2056000 1f5f40 bochs.exe Вот линуксовый: Код: $ mkdir -p usr/bin $ wget http://sourceforge.net/projects/bochs/files/bochs/2.4.6/bochs-2.4.6-1.i586.rpm/download -O bochs.rpm $ rpm2cpio bochs.rpm | cpio -i $ objdump -x usr/bin/bochs | grep NEEDED | grep 'libc.so' NEEDED libc.so.6 $ nm -u usr/bin/bochs | grep 'GLIBC' | tail U strtol@@GLIBC_2.0 U strtoul@@GLIBC_2.0 U strtoull@@GLIBC_2.0 U time@@GLIBC_2.0 U tolower@@GLIBC_2.0 U toupper@@GLIBC_2.0 U usleep@@GLIBC_2.0 U vfprintf@@GLIBC_2.0 U vsnprintf@@GLIBC_2.0 U vsprintf@@GLIBC_2.0 Здесь видно, что сборка из рпм использует системную глибц. Размер: Код: text data bss dec hex filename
1459490 63484 13953900 15476874 ec288a usr/bin/bochs |
Автор: | Himik [ 12 сен 2011, 19:56 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Часть этих функций в VC имеют атрибут intrinsic (тоесть встраиваемые), а часть из них отсутствует в VC, потому что являются POSIX функциями. Видимо, часть функций вызывается не прользовательским кодом, а рантаймом компилятора. В целом, статик не статик, а это внутренние проблемы VC. Так что GCC впереди :-) |
Автор: | LeftRadio [ 15 дек 2012, 05:47 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Соглашусь что GCC создает более раздутый код чем Keil, но! При оптимизации по размеру код у GCC может быть меньше и быстрее, это под ARM Cortex-M3. Причем код заметно быстрее работает, чем меня GCC приятно удивил В моем проекте переносного цифрового осцилла с выводом на ЖК TFT, Keil с макс. оптимизацией O3(по скорости) выдавал ~55кадров/сек., GCC же при O0 ~67, при Os ~85-90! И код получается по размеру чуть больше чем у Keil с O3 по размеру(скорость работы при этом в минусе полном 30-35 кадров). Это все на ЖК 240х400 и STM32F103, так что не все так плохо как тут пишут Но соглашусь что при работе с регистрами напрямую GCC может лажать, очень неприятный момент когда нужно работать с мелкими МК, так как приходится использовать библиотеки от ST(с ними 100% работает корректно), это конечно же расстраивает Все описанное относится к arm-none-eabi-gcc 4.6 который я использовал совместно с CooCox CoIDE. А в целом хорошо что существуют альтернативы платным компиляторам, спасибо сообществу за GCC! Не всем по карману Keil/IAR/Atollic и т.д. особенно для личных проектов. |
Страница 4 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |