prst 0 27 августа, 2012 Опубликовано 27 августа, 2012 · Жалоба Помнится когда-то тут, в этом разделе кажется, было интересное обсуждение, где один из уважаемых (в то время) пользователей приводил интересную статью(помоему даже его собственную) - сравнение размера скомпиллированного кода ARM компилятора в зависимости от структуры файлов программы. Суть в топике передавался следуюший, есть арм компилятора, один, и есть по разному устроенная тестовая программа, которая делает одно и тоже в разных ее исполнениях. В одном варианте все сделано в одном .c файле, потом разбито на разные .c, потом на .c+.h, потом все это разбросано и для объектов какието параметры менялись... и сравнивался результирующий hex(или чтото еще на выходе). Помнится что самый большой выигрыш был когда все написано в одном файле, но при этом правда код привратился в той еще длины "полотенце"... Я сейчас не могу найти эту интересную статью, ребята, помогите плиз ее найти. Надеюсь на сторожил раздела форума, вы точно должны помнить, это было длинное интересное обсуждение, гдето в 2008-2010гг. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 27 августа, 2012 Опубликовано 27 августа, 2012 · Жалоба Помнится что самый большой выигрыш был когда все написано в одном файле, но при этом правда код привратился в той еще длины "полотенце"... ИМХО, не актуально, так как современные компиляторы имеют режим multifile compilation. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prst 0 27 августа, 2012 Опубликовано 27 августа, 2012 · Жалоба ИМХО, не актуально, так как современные компиляторы имеют режим multifile compilation. не, тут мне важно не актуальность, а сама статья, там обсуждалась природа этого явления, вот это то что щас нужно мне Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 28 августа, 2012 Опубликовано 28 августа, 2012 · Жалоба Странно, в 2008 у, например, GCC, ключики combine (все файлы из командной строки компилировать как один файл) и whole-program (и это вся программа, больше ничего нет) ещё существовали (сейчас пропали в пользу LTO). И не надо было бы в портянку соединять. MS студия, кажется, в режиме финальной компиляции тот же эффект использует, все файлы проекта Возможно, стоит ещё раз поискать (гуглом) по форуму с применением названий указанных выше ключей, что-то ещё на эту тему найдется. Природа проста — когда компилятор знает, что это у него всё, что вообще есть, то он при необходимости встраивает по месту те функции, которые иначе находились бы в другом файле, что-то вообще выбрасывает и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 28 августа, 2012 Опубликовано 28 августа, 2012 · Жалоба Если в те времена, когда в ходу ARM7TDMI были, то там еще при вызовах stub'ы очень быстро накапливались, а компиляция одним файлом позволяла их минимизировать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 28 августа, 2012 Опубликовано 28 августа, 2012 · Жалоба Странно, в 2008 у, например, GCC, ключики combine (все файлы из командной строки компилировать как один файл) и whole-program (и это вся программа, больше ничего нет) ещё существовали (сейчас пропали в пользу LTO). И не надо было бы в портянку соединять. А откуда эта информация? -fwhole-program жив и здоров в 4.7.1, как раз собрал его на днях, занимаюсь оптимизацией под NEON, а combine по умолчанию всегда (Compiling multiple files at once to a single output file mode allows the compiler to use information gained from all of the files when compiling each of them). А вот вопрос слегка мимо темы - может быть знаете, при сборке gcc в чем разница между CLooG на базе PPL и ISL? опция у configure --enable-cloog-backend=xxxxx, это только на производительность влияет, или на оптимизацию тоже? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prst 0 28 августа, 2012 Опубликовано 28 августа, 2012 · Жалоба Если в те времена, когда в ходу ARM7TDMI были, то там еще при вызовах stub'ы очень быстро накапливались, а компиляция одним файлом позволяла их минимизировать. То я помню просто года... и там явной привязки к архитектуре не было на сколько я помню, в обзоре рассматривалось в рамках армовского компилятора, и помоему кто-то делал аналогичные тесты в мс-студии и т д Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 28 августа, 2012 Опубликовано 28 августа, 2012 · Жалоба А откуда эта информация? -fwhole-program жив и здоров в 4.7.1Ну может я с спутал с прямым углом. Вроде где-то проскакивало, что в связи с введением LTO что-то убрали (или это был --relax ?). Тоже немного мимо темы -- а на avr-gcc 4.7.1 / Ubuntu64 (32) шансы есть? Всёж набитой рукой это легче. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 28 августа, 2012 Опубликовано 28 августа, 2012 · Жалоба Тоже немного мимо темы -- а на avr-gcc 4.7.1 / Ubuntu64 (32) шансы есть? Всёж набитой рукой это легче. Да шансы то есть, но тут возникает вопрос - во первых "/Ubuntu" у меня нет и не предвидится, я под центос-ом собираю все, но это все фигня. А во вторых - я не знаю особенностей glibc для авр. Сам же я собираю glibc 2.16 с gnu, но я не уверен, что для авр используется тот же монстр. И вообще не знаю особенностей сборки gcc/glibc для мелко-мелкоконтроллеров. У меня то таки Cortex-A. с этим, короче, велкам в icq Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться