CFLAGS для экономии памяти

а как же -fomit-frame-pointer?
он код больше не сделает

Мне интересно, что будет жирнее, prescott или i686?

хз - generic наверно - т.е. i686...хотя хз
а почему бы тогда не включить native?

>Мне интересно, что будет жирнее, prescott или i686?

а проверить?

Хм. У тебя настолько плохо с памятью, что ты готов экономить по 100-200 Кб на код на программу?

Ну сэкономишь в сумме мегабайт 10-15

Устройся на работу на 2 дня и купи себе планку на 4 Gb или глаза уже красные?

-Os -march=prescott -fomit-frame-pointer --param l1-cache-size XX --param l1-cache-line-size YY --param l2-cache-size ZZ

XX - размер L1 кеша в кб
YY - размер линии кеша в байтах (обычно 64)
XX - размер кеша L2 в кб, можно задавать значения меньше


можно еще такие флажки

-ffunction-sections -fdata-sections


в LDFLAGS -Wl,--gc-sections -Wl,--hash-style=gnu -Wl,-O1 -s -Wl,--as-needed

ну и самое главное - выкиньте и заминусуйте все лишнее в USE, чем меньше соберете зависимостей, тем меньше памяти отьест, а флаги сильно много не дадут (!)

Предложу использовать альтернативные программы для экономии памяти.
Если всё же это упорно не подходит то делать ./configure отключая виндовые костыли, интерфейсные, сетевые, меню и прочие ненужности. И использовать генту с уже её флагами, конечно же.

Хм... Может автор спрашивает про встраиваемую систему? Какие ещё «планки памяти»? А по теме: часто оптимизации себе дороже. Может очень сильно пострадать стабильность. При включении нестандартных опций, готовое ПО потом надо проверять и перепроверять.

Просто замени все современные программы аналогами 2000 (1995) года. Например вместо современного Amarok лучше использовать XMMS или старый консольный плеер. Ну ты понял да.

Мы в SliTaz все активно вырезаем через ./configure
По тестам, -Os не дает никакой выгоды на памяти больше 64 метров. (хотя я сейчас специально для kmandla собираю системку под 32 с Os).

P.S. используй -march=pentium4 или даже native

Программы выделяют основную часть памяти динамически, те при любом размере бинарника размер занятой ram будет один и тот же.

Флаги практически ничего не дадут.
Кроме того, большая часть любого бинарника - это куча нулей и nop-ов.

Чо? А как-бы то, что «бинарник» должен быть отображён в память вы не учитываете? А то, что возможно компилятор будет по умолчанию «упаковывать» структуры, с этим флагом? А выравнивание, отключение добавления всяких проверок, «раскрытие» циклов и прочее, прочее?
Не знаю как это в реальности, но теоретически флаги на многое должны влиять. В том числе, на использование памяти, на стабильность и на скорость.

>А как-бы то, что «бинарник» должен быть отображён в память
Я как-бы уже написал, что бинарник занимает в памяти меньшую часть, по сравнению с динамически выделенными структурами. Кроме того, в размере секций кода много не выиграть.

что возможно компилятор будет по умолчанию «упаковывать» структуры

А конкретнее?

А выравнивание

Оно есть всегда.

отключение добавления всяких проверок

Конкретнее, вы про -ffast-math?

«раскрытие» циклов

Вы имеете в виду раскрутку циклов? Это увеличивает размер кода.

Не знаю как это в реальности, но теоретически

Ну так чего спорить - проверяйте ;)

Чо?

Моветон..

> А конкретнее?
Что-то вроде глобального #pragma pack возможно переключить, используя флаги компилятора?

Конкретнее, вы про -ffast-math?

Конкретно, какие у gcc проверки я не знаю (а если и знал, то забыл).
Кажется, есть ещё omit-frame-pointers и что-то подобное, хотя и влияющий на скорость, а не на расход памяти.

Вы имеете в виду раскрутку циклов? Это увеличивает размер кода.

Иногда это увеличивает скорость.

Оно есть всегда.

Оно может быть разным...

Ну так чего спорить - проверяйте ;)

Нет уж, спасибо.

Также, возможно (с потолка), есть define'ы в glibc, которые влияют на её требовательность. Это, конечно, с натяжкой возможно отнести к флагам компиляции, но всё-же.
Плюс к тому, возможно сменить glibc на другой libc, менее затратный по памяти.

Оптимизации по потреблению памяти обычно плохо сказываются на производительности, и наоборот.

Также, возможно (с потолка), есть define'ы в glibc, которые влияют на её требовательность.

Пересобирать не пробовал.
Но, ЕМНИП, разработчики glibc не жалуют оптимизацию под embedded.

сменить glibc на другой libc, менее затратный по памяти.

Опять же, память выделяют в основном программы, а не glibc на свои внутренние нужды.
Хотя с uclibc можно выиграть несколько мегабайт.

> Оптимизации по потреблению памяти обычно плохо сказываются на производительности, и наоборот.
Угу, если бы на практике это было также. :-\ Хотя да... Только разве применительно к действиям компилятора - тоже раскрытие циклов. Но, наверное, на производительность большей части кривого кода эти оптимизации повлияют несильно. :-|

Опять же, память выделяют в основном программы, а не glibc на свои внутренние нужды.

Ну, опять же, выделяют-то они через libc (надеюсь на это). Может там реализуют какой-то хитрый механизмус и malloc/realloc будет работать менее затратно? :-]