Обсуждение:Эльбрус/lcc: различия между версиями
(нач) |
м (→Размер бинарного кода: вынес из комментариев на habr/gaijin) |
||
Строка 7: | Строка 7: | ||
--[[Участник:MichaelShigorin|mike]] ([[Обсуждение участника:MichaelShigorin|обсуждение]]) 08:04, 18 декабря 2020 (UTC) | --[[Участник:MichaelShigorin|mike]] ([[Обсуждение участника:MichaelShigorin|обсуждение]]) 08:04, 18 декабря 2020 (UTC) | ||
== Размер бинарного кода == | |||
Со [http://habr.com/ru/company/gaijin/blog/533380/#comment_22435418 слов] Алексея Маркина: | |||
У e2k код «рыхлый» потому что для оптимизации необходимо делать много подстановок функций, | |||
а также иметь много версий одного цикла и много вариаций кода для предикатного режима | |||
(if-conversion). Тем не менее, обычно в горячих участках код получается нормальным, | |||
а «рыхлость» — это среднее по больнице. | |||
Более того, раскрутка — далеко не единственный метод оптимизации цикла, если это возможно, | |||
то к нему будет применена программная конвейеризация, которая обладает аппаратной поддержкой. | |||
Это, разумеется, не взаимоисключающая с раскруткой оптимизация, и их часто следует применять | |||
вместе, но размер кода она экономит сильно по сравнению с только раскруткой. | |||
Компилятор довольно сильно заботится о размере кода. Так, например в режиме -O3 действует | |||
специальная система СНОП, которая при возможности понижает линейку оптимизации для экономии | |||
времени компиляции и размера. Но сам по себе -O3 подразумевает что размер кода не является | |||
главной целью сборки. | |||
--[[Участник:MichaelShigorin|mike]] ([[Обсуждение участника:MichaelShigorin|обсуждение]]) 20:40, 18 декабря 2020 (UTC) |
Версия от 23:40, 18 декабря 2020
Little C Compiler
В некоторых проектах проверяют __LCC__, который другой lcc; Рамиль Саттаров пишет по этому поводу:
И это ещё повезёт, если LCC заботливо обернут сначала в ifdef WIN64 - тогда считай пронесло. Но часто - нет.
--mike (обсуждение) 08:04, 18 декабря 2020 (UTC)
Размер бинарного кода
Со слов Алексея Маркина:
У e2k код «рыхлый» потому что для оптимизации необходимо делать много подстановок функций, а также иметь много версий одного цикла и много вариаций кода для предикатного режима (if-conversion). Тем не менее, обычно в горячих участках код получается нормальным, а «рыхлость» — это среднее по больнице. Более того, раскрутка — далеко не единственный метод оптимизации цикла, если это возможно, то к нему будет применена программная конвейеризация, которая обладает аппаратной поддержкой. Это, разумеется, не взаимоисключающая с раскруткой оптимизация, и их часто следует применять вместе, но размер кода она экономит сильно по сравнению с только раскруткой. Компилятор довольно сильно заботится о размере кода. Так, например в режиме -O3 действует специальная система СНОП, которая при возможности понижает линейку оптимизации для экономии времени компиляции и размера. Но сам по себе -O3 подразумевает что размер кода не является главной целью сборки.
--mike (обсуждение) 20:40, 18 декабря 2020 (UTC)