Вопрос к программистам на C , Исходники ядра Linux

Исходник

#include <algorithm>
 
#define MAX_ARR 1024
 
int arr[MAX_ARR];
int n;
 
int main( int argc, char *argv[] )
{
    std::sort( arr, arr + MAX_ARR);
    return 0;
}

после стрипа занял 2932 байта. Ассемблерный листинг - на 14 кб.

Цитата

Ассемблерный листинг - на 14 кб.

Оххххх.... Fuck-то какой... Ээээ... Я хотел сказать, "грех-то какой..." :D:D:D

Цитата the_Shadow @ 19.04.06, 11:55

~80% ПО. Вспоминаем про 20|80.

Я пример просил. А не проценты.

Цитата the_Shadow @ 19.04.06, 11:55

Теперь, как неуюёмный, делаю
as helloworld.s, получаю 912 байт и, после стрипования, получаю 548 байт.

Так, стоп. Мы, по-моему, компиляторы сравниваем, а не ассемблеры.

Добавлено 19.04.06, 12:12

Цитата the_Shadow @ 19.04.06, 12:07

Оххххх.... Fuck-то какой... Ээээ... Я хотел сказать, "грех-то какой..." :D:D

Ээээ... Может быть по скорости сравним? Или мы оптимизируем только по размеру?

Что такое стрип?

Цитата

Я пример просил. А не проценты.

Пример? Ну, скажем, ядро самой windoZe, тот псевдо-С++, который я уже приводил (с сервисом).

Цитата

Так, стоп. Мы, по-моему, компиляторы сравниваем, а не ассемблеры.

Ja! Ja! А что, мне просто интересно, простите меня за мою тупость, что есть процесс компиляции? И не надо ли напомнить как именно работает компилятор С? Ээээ... "двухпроходная компиляция"... ни о чём не говорит? :D:D:D

Цитата

Ээээ... Может быть по скорости сравним? Или мы оптимизируем только по размеру?

Flex, я тебя умоляю! Ну, давай по скорости... :D:D:D
Давай, до кучи ещё и по скорости написания можно. Вот только ну его на фиг, т.к. я никогда не говорил, что на С писать проще. :D:D:D

Добавлено 19.04.06, 12:22

Цитата

Что такое стрип?

man strip, и будет тебе счастье.
Прога, удаляющая отладочную инфу из бинаря. В случае, когда Flex приводил нестрипованный бинарь, это эквивалентно версии DEBUG для M$. Кстати, во многих проектах вместо make install можно запросто использовать make install-strip.

Цитата the_Shadow @ 19.04.06, 12:20

Ja! Ja! А что, мне просто интересно, простите меня за мою тупость, есть процесс компиляции? И не надо ли напомнить как именно работает компилятор С? Ээээ... "двухпроходная компиляция"... ни о чём не говорит? :D:D

Тогда результат работы gcc и as должны были бы быть одинаковыми по размеру. Кстати, после некоторых манипуляций (правда, после этого исходный текст перестал быть кроссплатформенным) размер exe-шника, выдаваемого компилятором уменьшился до 624 байт.

Цитата the_Shadow @ 19.04.06, 12:20

Flex, я тебя умоляю! Ну, давай по скорости... :D:D

Давай лучше (без всяких "ну я тебя умоляю") просто определимся - что и как мы сравниваем. Я, кстати, это уже предлагал.

В размере EXE для Win надо учитывать еще наличие DOS-stub. Отрыжка совместимости.

Добавлено 19.04.06, 12:47
Минимизация размера программ

Цитата

Тогда результат работы gcc и as должны были бы быть одинаковыми по размеру.

Кто это сказал? Откуда это видно?

То, что ассемблирование имеет место быть -- бесспорно. Но вот какое ассемблирование? Я же предупреждал, что gcc как компилятор весьма не прост. И, более того, есть ещё такая весчь как линкер... :D:D:D

Цитата

Я, кстати, это уже предлагал.

Уффф... А я, если честно, то просто устал. Ну хоть теперь ты понимаешь, почему я не хожу в раздел по С и С++? Правильно. Потому что я туп, глуп и необразован. :D:D:D

Добавлено 19.04.06, 12:54
Правда, я могу написать как реально писать маленький код на С для Linux. Там... Есть некоторые "трюки"... :D:D:D

Цитата the_Shadow @ 19.04.06, 12:50

Кто это сказал? Откуда это видно?

Вот отсюда:

Цитата the_Shadow @ 19.04.06, 12:20

Ja! Ja! А что, мне просто интересно, простите меня за мою тупость, что есть процесс компиляции? И не надо ли напомнить как именно работает компилятор С? Ээээ... "двухпроходная компиляция"... ни о чём не говорит? :D:D

По этому у меня и возник вопрос - как же так? gcc - такой крутой высокоуровневый ассемблер, а на выходе дает код, вчетверо превышающий по размеру результат работы "низкоуровневого" ассемблера. Непорядок. Где же мощь второго прохода компиляции? А линкер... Он и там, и там используется, если я не ошибаюсь.

Цитата the_Shadow @ 19.04.06, 12:50

Уффф... А я, если честно, то просто устал. Ну хоть теперь ты понимаешь, почему я не хожу в раздел по С и С++? Правильно. Потому что я туп, глуп и необразован. :D:D

От чего устал? Доказывать, что gcc круче VC? Что, якобы, под линь генерируются экзешники более оптимальные, чем под винду? Ну, как мы видим из результатов - это не совсем так. То, что С лучше С++ - так это практически недоказуемо (ибо ты уже сейчас устал, а что же будет дальше?). Кстати, некоторое время назад (где-то сполгодика) ты грозился большой-большой холивар на эту тему открыть, где все разложишь по полочкам. Может быть таки пришло это время? Или интерес пропал?

Цитата

Может быть таки пришло это время? Или интерес пропал?

Да нет. Работа + проект "Святой Напильник" сжирают всё время. :(
"Святой Напильник" -- самопальный дистриб Linux. По причине использования таких вещей как prelink (по-прошу без приколов) процентов на 15-20% шустрее Slackware, не гворя уже о RedHat. www.linuxfromscratch.org остаётся в scratch'е.

Да. Добавь ещё то, что есть в скрытой теме в разделе UNIX. :D:D:D Гремучий коктейльчик, не так ли? :D:D:D

Добавлено 19.04.06, 13:09

Цитата

Доказывать, что gcc круче VC?

А это надо?
Или мне ещё сюда же "ливануть" Intel'овский компиль? На камне от Intel там будет всё ещё интереснее.

Добавлено 19.04.06, 13:11
В прочем, может быть, ты и прав. Но тогда нужно будет для UNIX-раздела написать материальчик... О том, как писать реально мелкий код. :D:D:D

Цитата the_Shadow @ 19.04.06, 11:55

as helloworld.s

У меня эта команда вообще не создает никаких новых файлов. Что не так?

Цитата

Что не так?

Не знаю.

Создается файл a.out. Как сделать, чтобы он имел другое название?

А почему, если преобразование сначала в ассемблер, а потом в исполняемый файл дает существенно меньший размер выходного файла, то в gcc не ввели возможность такой оптимизации?

Цитата

Создается файл a.out. Как сделать, чтобы он имел другое название?

gcc -o mycoolname hello.c

Цитата

А почему, если преобразование сначала в ассемблер, а потом в исполняемый файл дает существенно меньший размер выходного файла, то в gcc не ввели возможность такой оптимизации?

Потому, что процесс ассемблирования сам по себе достаточно сложен. Если мы "в тупую" перегоняем код в асм, то это во-все не значит, что и компиль поступает точно так же.
Да. Он ассемблирует, но с рядом, скажем так, "допущений". На самом деле, то, что я продемонстрировал -- довольно грязный трюк. И "стандартный" программист для Linux, как правило, даже не подозревает об этом. Ему и не надо. Более того! Этот трюк во-все не всегда сработает.

По-ищи в разделе UNIX мой "Ответ из семизвёздочного отеля", впрочем, вот она -> Ответ из семизвездочного отеля....

Далее. Если мы генерируем код для уровня helloworld, то это полбеды. Всегда можно (зная более-менее) синтаксис gas, который отличается от MASM по дефолту, подправить асм-код. Но что прикажете делать с 14кб кода? То же править? И как, если не секрет? Это же... просто смерть! Когда я стервенею по поводу С++, то это происходит от того, что мне говорят, что, дескать, он прост. Да не так он прост, как об этом говорят. Во-все не прост, если мы сунемся в то, как оно там выглядит. Кстати, прикинь, что было бы, если бы мы начали править проект, более сложный чем то, что мы тут разбирали... Угу... Если бы я правил асм-код в том виде, в котором он получается, то у меня борода бы тестикулы закрывала. В конце "правок".
С в данном случае даёт разумный компромисс, развязывая проггеру руки. Да. Есть асм, но есть и (с не таким большим оверхедом на реально сложных проектах) и "портируемый ассемблер", т.е. С.

Другой вопрос в том, что gas можно заставить работать не с AT&T-нотацией, а с MASM, но это просто... лирическое замечание. И на итог оно мало влияет.