OSDev

Как ни странно, размер кода прямо указывает на размер программы. Это не всегда является определяющим, однако в абсолютно всех случаях является желательным, чтобы программа занимала меньше места, поэтому при прочих равных лучше тот транслятор, который порождает более компактный код.

То, что GCC не умеет оптимизировать код с целью сокращения размера, после проведённых испытаний можно утверждать абсолютно однозначно: при включённой оптимизации именно по размеру он даёт код, намного превосходящий по размеру код, порождаемый двумя коммерческими трансляторами под разные платформы, причём независимо от того, работают эти трансляторы с оптимизацией по скорости или по размеру.

Однако не менее важно то, что размер кода косвенно намекает и на его скорость. Да, такие вещи, как разворачивание циклов, раздувают код, но потенциально увеличивают скорость, однако: 1) далеко не всегда дело заключается в разворачивании циклов (трудно представить, что их так много, что вдвое раздувает код, тем более что в моём примерчике под АРМ циклы вырожденные и отнюдь не развёрнутые); 2) разворачивание циклов лишь в теории гарантирует увеличение скорости, а на практике может получиться наоборот (улёгся неразвёрнутый цикл в строку кэша и выполняется там на максимальной для процессора скорости, а вот развёрнутый цикл, занимающий ...ннадцать этих строк, регулярно тормозится для выборок из памяти).

SII, размер конечно имеет значение, хотя там не всё так плохо как кажется. И не всё так просто. Надо разбираться, на что конкретно тратятся байты, и используя дополнительные параметры компилятора/линковщика можно решить любую проблему. В GCC есть множество дополнительных параметров, положительно влияющих на размер кода, типа:

Линковщик здесь ни при чём. Разве что забыли выкинуть Debug Info.
Практика показывает, что оптимизация в большинстве случаев происходит одновременно и по размеру и по скорости. Эти два параметра очень сильно коррелируют. В ОТДЕЛЬНЫХ случаях оптимизация по скорости увеличивает код, но совсем не намного. Копаться в опциях компилятора — неблагодарное дело. Сказано оптимизировать, — пусть сам оптимизирует, как может. Если же оптимизация продуцирует нерабочий код, это стопроцентная ошибка компилятора.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Анекдот дня. Садится программист в автомобиль, и ищет на приборной панели кнопку "ЕХАТЬ"...

Для тебя, может, и анекдот. А для современных информационных технологий — насущная необходимость. Вспомни, часто ли тебе нужно было устанавливать КОНКРЕТНЫЙ уровень оптимизации компилятора или ассемблера? Сколько себя помню, всегда задавал компилятору максимальный уровень общей оптимизации плюс (в зависимости от проекта) оптимизация по скорости или по размеру. А уж что он там сможет сделать, — выносить неиспользуемые переменные из цикла, менять местами границы цикла или ещё чего-нибудь, — не моё дело. Да и на практике множество неудобоваримых опций оптимизации (с которыми приходится экспериментировать на предмет случайной вредоносности) — удел компиляторов, подобных GCC. Коммерческие компиляторы сами неплохо оптимизируют без моих тычков.
Также опять замечу, что большинство способов оптимизации ОДНОВРЕМЕННО и уменьшают код и увеличивают скорость, ибо МУСОР есть МУСОР и его надо вычищать! Только очень небольшое количество методов, типа loop unfolding, увеличивают скорость в ущерб размеру.
А работа окололинуксовых программистов (возвращаясь к автомобильной аналогии) мне часто напоминает автомобилистов старой закалки, — измазанных маслом, которые за 45 секунд собирают/разбирают карбюратор, возят с собой полный комплект запчастей, знают, что такое "подсос" и пренебрежительно смотрят на водителей современных авто с коробкой-автоматом. А в самых современных авто так и есть — кнопка "ПОЕХАЛИ", как бы это анекдотично ни звучало для многих.
Прошу сравнение не принимать за оскорбление, т.к. я сам прошёл через программирование на большинстве систем и на многих язиках и ассемблерах и перемазан маслом не меньше остальных :).

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

И то, как я уже написал, это не всегда приводит к увеличению скорости, поскольку растёт расход кэша и число обращений к памяти, и ещё неизвестно, что перевесит...



Мне тоже :) Конечно, в теории хорошо, когда у тебя есть возможность "допилить напильником" любую часть системы, но на практике такое нужно крайне редко. В то же время необходимость в лишних телодвижениях, даже привычных, с годами начинает раздражать -- и это как минимум. Так что неудивительно, что линух в определённой степени идёт в том же направлении, что и винда (например, та же автоматическая установка, требующая минимум ручных действий, давно уже стала нормой). Другое дело, что сам путь к созданию крупных систем, используемый в опенсорцном сообществе, порочен в принципе, поэтому по-настоящему хороший продукт сообщество никогда создать не сможет (однако это сможет сделать серьёзная фирма, даже если за основу изначально будет взят некий открытый проект, и уж тем более этому не мешает сама открытость проекта -- мешает именно отсутствие жёсткого контроля и управления проектом).

Эта тема как-то выпала из поля моего зрения, вот только что нашёл и прочитал...

Я данную тему обсуждаю с точки зрения ОСеписательства, точнее даже ядро-писательства. Поэтому ответ безусловно да, много приходилось "крутить" в компиляторе чтобы получилось то что надо для ядра.

1) Весь код GCC имеет определённый смысл, "вредного кода" там нет абсолютно.
2) Использование в GCC максимального уровня оптимизации не приводит к замедлению - вы во власти каких-то ошибочных представлений. По поводу того, что я лично не обнаружил разницы по скорости между 1 и 3 режимами, то тут может быть две причины. 1 - код планировщика моего ядра настолько упрощён, что там просто-напросто нет поля для высокой оптимизации. 2 - высший уровень оптимизации действует исключительно на точно заданной архитектуре процессора. При маллейших несоответствиях рабочей и целевой архитектурах, оптимизация может нивелироваться, и иногда даже стать тормозом - когда размеры кэш-линий либо конвееров не соответствуют рассчётным. Поэтому высший уровнь оптимизации для разрозненного парка машин даст непредсказуемый результат.

Тогда объясните, почему компилятор MS порождает существенно более компактный код на любых режимах оптимизации.



Скорей, это Вы слишком уж фанатично привержены ГЦЦ. На столь дубовом коде, который он порождает под ARM, разница между уровнями оптимизации действительно уже слишком шибко сказаться не может. Поскольку основная (и наиболее важная) часть оптимизации не зависит от целевой архитектуры, так что столь же дубовый код он будет порождать и под IA-32 (что подтверждает сравнение с компилятором MS), разве что инструкции будет подбирать чуть грамотнее.

Не могу, за отсутствием материала. У меня нет такого проекта для исследования, чтобы он компилировался как в GCC так и в VC.
Однако есть и небольшой антипример. На сайте http://sourceforge.net/projects/bochs/f ... chs/2.4.6/
Bochs-2.4.6.exe = 3,9МБ
bochs-2.4.6-1.i586.rpm = 2,7МБ

Просто я получаю от компилятора идеальный код для своих нужд :-)

Во-первых, rpm точно упакован, а про exe не знаю. Во-вторых, не факт, что исходники полностью идентичны. В-третьих, это версии для разных ОС, с разными API и т.п., а посему сравнение в принципе не может быть корректным.

Пы.Сы А убранное замечение про KEIL для IA-32 было просто глупым. На IA-32 есть резон сравнивать GCC с MS VC и ICC, на ARM -- с KEIL ну и т.д. В общем, с трансляторами, специально предназначенными для этих платформ. Достоинство GCC как кроссплатформенного транслятора никто и не оспаривает, проблема лишь в том, что это, похоже, единственное его достоинство.

АДД. А вот и разгадка размера Боша:

12.09.2011 19:14:19 Grindars: линуксовый собран гцц и слинкован с либц динамически
12.09.2011 19:14:29 Grindars: виндовый собран MSVC и слинкован с либц статически