make, и все такое

Привет, Maxim !

14 Feb 05 , 23:36 Maxim Polyanskiy писал к All:

MP> В очередной раз убеждаюсь, что описываемые тут механизмы преназначены MP> для решения надуманных проблем, которые искуственно создаются MP> пользователями самих механизмов. Был проект - 15 файлов. Собирался 8 MP> сек целиком и около 5сек - make на некоем случайно измененном файле. Я MP> подумал, и решил совокупить файлы по некоторым признакам, в результате MP> проект стал занимать 5 файлов. т.е. число файлов уменьшено ровно в 3 MP> раза, объем же сократился незничительно - 2-3%. И что-бы вы думали - MP> build all 3 секунды, т.е. полюбому быстрее чем make на 15 файлах! MP> Резюме - при уменьшении числа файлов в 3 раза скорость сборки MP> возрастает более чем в 2 раза. Причем скорость make намного не MP> возрасла, поскольку линковка все равно время отжирает глобально, make MP> занимает 2c чем-то cек. Вобщем ничего тут удивительного, компиллер MP> полтора мега, пока его в память загрузишь с диска, пока проинитишь, MP> времени столько ухлопается, что глядишь парсинг текста уже станет не MP> такой сложной задачей.

А почему вы пробовали на 15 файлах, а не на одном?

. С уважением, Hикита. ... нелысый пpогpаммист без агpессивного кота

Tue Feb 15 2005 18:36, Anatoly Mashanov wrote to Maxim Polyanskiy:

AM> [Подбирая упавшую на пол челюсть] А разве компилятор по окончании работы AM> не остается в ОЗУ до новой компиляции либо до необходимости освободить AM> память? Я почему-то думаю, что это стандартно.

Компилятор запускается как дочерний процесс каждый раз, когда требуется откомпайлить файл. После компиляции он из памяти выгружается; единственное, что может остаться в памяти - это кэш файлов самого компилятора, его библиотек и т. п., но все процедуры необходимо каждый раз выполнять заново: выделение памяти, чтение файлов, парсинг и т. д. Чтобы компилятор остался в памяти и смог заново начать компиляцию, необходимы технологии класса DDE/OLE/COM, но во время разработки UNIX'а такие вещи не были распространены, да и необходимость в таких действиях достаточно сомнительна.

С уважением, Денис

"Продукт" вида "тихо, сам с собою...". Если 15 впихнулось в 5, то можно и в один... "каша" будет гуще, может это кому-то и нравится.

make - это "надводна" часть айсберга, называемого проектом. Проект состоит из программных модулей, модуль состоит из файлов...

В случае применения CVS и взаимодействия проекта (его модулей) с другими продуктами количество файлов HЕ стремится к ЕДИHИЦЕ.

Спорить тут не о чем.

Закончить можно так: для __простых__ продуктов и батник потянет, сложный проект требует достойного инструмента для его сборки и отладки.

PS: Для сборки gnumake можно воспользоваться - батником "build all" - nmakefile (для nmake из MSVC). Первая сборка секунд 40, файлов около 40 (точно не помню). Изменил файл - "build all":40с, nmake:1с Есть разница? Или первым делом предлагается все "слить" в один файл чтоб "поработать" с чужим проектом? ;-)

______ Сергей.

Привет!

Tue Feb 15 2005 18:36, Anatoly Mashanov wrote to Maxim Polyanskiy:

AM> [Подбирая упавшую на пол челюсть]А разве компилятор по окончании работы AM> не остается в ОЗУ до новой компиляции либо до необходимости освободить AM> память? Я почему-то думаю, что это стандартно.

Дружеский совет: быстрее подвяжи свою челюсть чем-нибудь :) А то не ровён час потеряешь... Где же это ты видел системы, которые вызывают программу прямо из ОЗУ? Разве что Бэйсик какой-нить из ПЗУ в Синклере... Во всех остальных, насколько я знаю, программа запускается по-новой. Если только она не остается в памяти, ожидая ввода пользователя (это уже не вызов из bat-файла). Hо так делают не многие программы.

Заметное ускорение повторных вызовов программы происходит не из-за того, что она торчит в памяти ОЗУ неизвестно зачем, а благодаря кэшированию, что было превосходно заметно на старых Виндах если установить смартдиск. В современных Виндах кэширование само делается. Опять же, нынче во всех жестких дисках кэши по 2-8 МБ. Если вызовы компилера следуют подряд (это типичный случай при компиляции нескольких файлов проекта), то кэш очень сильно ускоряет загрузку того же самого компилятора.

Юргис

Mon Feb 14 2005 23:36, Maxim Polyanskiy wrote to All:

MP> В очередной раз убеждаюсь, что описываемые тут механизмы преназначены для MP> решения надуманных проблем, которые искуственно создаются пользователями MP> самих механизмов.

Святое дело. Программирование - искусство, не так ли? Конфигурение всяких сред и скриптов многим дает не меньшее самоудовлетворение, чем писание на ассемблере :)

MP> Был проект - 15 файлов. Собирался 8 сек целиком и около MP> 5сек - make на некоем случайно измененном файле.

:))) Проект на Mega128 собирается IAR build all порядка минуты на P-2.8. А если во всяких CCS/VDSP разрешить оптимизацию даже на небольших проектах, то можно идти кофе пить. MP> Причем скорость make намного не возрасла, поскольку линковка все MP> равно время отжирает глобально

Для этого существует incremental linking.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Hello Maxim!

14 Feb 05 23:36, you wrote to All:

MP> занимает 2c чем-то cек. Вобщем ничего тут удивительного, компиллер MP> полтора мега, пока его в память загрузишь с диска, пока проинитишь, MP> времени столько ухлопается, что глядишь парсинг текста уже станет не MP> такой сложной задачей.

[Подбирая упавшую на пол челюсть] А разве компилятор по окончании работы не остается в ОЗУ до новой компиляции либо до необходимости освободить память? Я почему-то думаю, что это стандартно.

Anatoly

Hello Vladimir.

15 Feb 05 18:06, you wrote to Maxim Polyanskiy:

VV> :))) VV> Проект на Mega128 собирается IAR build all порядка минуты на P-2.8.

А я думал, что gcc очень медленно компилирует. ;)

Alexey

Hello Maxim.

14 Feb 05 23:36, you wrote to all:

MP> В очередной раз убеждаюсь, что описываемые тут механизмы преназначены MP> для решения надуманных проблем, которые искуственно создаются MP> пользователями самих механизмов.

LOL.

MP> Был проект - 15 файлов. Собирался 8 MP> сек целиком и около 5сек - make на некоем случайно измененном файле. Я MP> подумал, и решил совокупить файлы по некоторым признакам, в результате MP> проект стал занимать 5 файлов. т.е. число файлов уменьшено ровно в 3 MP> раза, объем же сократился незничительно - 2-3%. И что-бы вы думали - MP> build all 3 секунды, т.е. полюбому быстрее чем make на 15 файлах! MP> Резюме - при уменьшении числа файлов в 3 раза скорость сборки MP> возрастает более чем в 2 раза. Причем скорость make намного не MP> возрасла, поскольку линковка все равно время отжирает глобально, make MP> занимает 2c чем-то cек.

Очень показательный пример.. У меня, например, подсистема вполне себе embedded системы, объем исходников - под десяток мегабайт, количество файлов - несколько тысяч.. вся эта радость компилится с нуля под 3 аппаратных платформы полчаса, как минимум.. Скажите мне, дяденька, я много выиграю во времени компиляции, если склею все файлы в один и буду с ним работать ?

Dmitry

Hello, Denis!

Втp Фев 15 2005, Denis Y. Borisov писал к Anatoly Mashanov по поводу "make, и все такое." ... DB> Чтобы компилятор остался в памяти и смог DB> заново начать компиляцию, необходимы технологии класса DDE/OLE/COM, DB> но во время разработки UNIX'а такие вещи не были распространены, да и DB> необходимость в таких действиях достаточно сомнительна. Я не видел даже сейчас подобных реализаций. Хотя в принципе загрузить и проинитить компиллер 1 раз и передавать ему строку c консоли маленькой програмкой на пару килобайт - ни каких проблем нет. DB> С уважением, Денис WBR! Maxim Polyanskiy.

Hello, Vladimir!

Втp Фев 15 2005, Vladimir Vassilevsky писал к Maxim Polyanskiy по поводу "make, и все такое." VV> Святое дело. Программирование - искусство, не так ли? VV> Конфигурение всяких сред и скриптов многим дает не меньшее VV> самоудовлетворение, чем писание на ассемблере :) Э нет. Писание на ассемблере дает четкие финансовые приемущества в стоимости железа в разах. Hапример там где тебе понадобится 18-я пикомания я уложусь в

16-ю. А это в среднем 2 раза по цене. Идея в том - что я не понимаю как применение CVS или скриптового языка make может увеличить число денег в те-же 2 раза, или сэкономить какое-то там глобальное время сравнимое с их изучением. Кстати сборка кода в pic 16f876a под завязку за 3 секунды на моем компе происходит. MP>> Был проект - 15 файлов. Собирался 8 сек целиком и около MP>> 5сек - make на некоем случайно измененном файле. VV> :))) VV> Проект на Mega128 собирается IAR build all порядка минуты на P-2.8. Помоему это ну просто очень долго. У меня анонизм на 4мгц спектруме за 3 минуты собирался с дискеты из под CPM моим транслятором - я то время в кошмарных снах вспоминаю. Сейчас тот-же самый анонизм на P4-1.6 в эмуляторе CPM пересобрал ради прикола - 5 секунд. VV> А если во всяких CCS/VDSP разрешить оптимизацию даже на небольших VV> проектах, то можно идти кофе пить. Да не умеют нифига писать средства разработки. Расслабились совсем с жирными компами. То-ли дело компиллер x8051 от A.D. с 85 года все быстрее и быстрее работает. И главное - не требует обновления ну никакого! ;) VV> VLV WBR! Maxim Polyanskiy.

Hello, Dmitry!

Втp Фев 15 2005, Dmitry Lyokhin писал к Maxim Polyanskiy по поводу "make, и все такое." DL> вся эта радость компилится с нуля под 3 аппаратных платформы DL> полчаса, как минимум.. Скажите мне, дяденька, я много выиграю во DL> времени компиляции, если склею все файлы в один и буду с ним работать DL> ? Дяденька - вы плохо читали исходное письмо. Там написано: При уменьшении количества файлов в 3 раза скорость сборки повышается более чем в 2 раза.

Это написано не для того, чтоб все бросились объеденять файлы, а для того, чтоб задумались перед тем как их плодить. DL> Dmitry WBR! Maxim Polyanskiy.

Hello Maxim.

16 Feb 05 01:05, you wrote to Denis Y. Borisov:

DB>> Чтобы компилятор остался в памяти и смог DB>> заново начать компиляцию, необходимы технологии класса DB>> DDE/OLE/COM, но во время разработки UNIX'а такие вещи не были DB>> распространены, да и необходимость в таких действиях достаточно DB>> сомнительна. MP> Я не видел даже сейчас подобных реализаций. Хотя в принципе загрузить MP> и проинитить компиллер 1 раз и передавать ему строку c консоли MP> маленькой програмкой на пару килобайт - ни каких проблем нет.

Вот протестировал: Минимальная программа из test.c и Makefile (содержимое я описывал) первый раз компилируется около 2 секунд. Последующие разы - около 300 мс. При этом запускаются программы: make gcc cpp cc1 as ld (все по разу, самая большая - cc1, поменьше as, ld, make)

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

А вообще у gcc проблемы в скорости компиляции c++. Для жирных плюсовых библиотек очень много времени уходит на парсинг хидеров.

ps: у меня Duron 700 pps: Да еще: В линуксе кеш занимает всю свободную память. Только не кеш диска (этот небольшой), а кеш страниц. При повторном обращении к файлу (а запускаемые файлы открываются через mmap) ядро просто включает отображение нужных страниц из кеша страниц в нужное адресное пространство.

Alexey

Молодой человек, вы бредите! Почитайте как нибудь на досуге книжки про устройств ОС (и таки не про винду, а что нибуль более открытое и слегка более грамотное). Вы будете сильно удивлены что ваши глубокие знания об способах загрузки и исполнения программ в ОС очень далеки от реальности - насколько винда далека от ДОС и обе они далеки от совершенства.

Орлы, грамотеи, гиганты мысли! Почитайте как нибудь на досуге КАК ИМЕННО устроен Юникс, как именно грамотно сделанные ОС используют так называемые "текстовые сегменты", как они используют разделяемые библиотеки, как реализуют буферизацию диска и виртуальную память, позволяющую хранить в ОЗУ ровно одну копию того же самого кода для любого числа использующих этот код процессов. Почитайте, желательно не с экрана и не в ХТМЛ, а в книгах. Ведь книгопечатание изобрели уже давно и книги доказали свою полезность.

Wed Feb 16 2005 12:37, Arcady Schekochikhin wrote to Denis Y. Borisov:

AS> как именно грамотно сделанные ОС используют так называемые AS> "текстовые сегменты"

Что-то Google не стал мне ничего говорить по запросу UNIX+"текстовые сегменты"...

AS>, как они используют разделяемые библиотеки, как AS> реализуют буферизацию диска и виртуальную память, позволяющую хранить в AS> ОЗУ ровно одну копию того же самого кода для любого числа использующих AS> этот код процессов.

Make AFAIK не является многопоточным приложением. Потому код gcc и прочих binutils с диска читать системе возможно не придется, но выполнять все процедуры при запуске нового процесса, предусмотренные алгоритмом работы этого процесса, все равно придется: выделение памяти под открываемые файлы, их чтение, обработка, запись результатов - все это никуда не денется.

С уважением, Денис

Wed Feb 16 2005 18:46, Anatoly Mashanov wrote to Denis Y. Borisov:

AM>>> [Подбирая упавшую на пол челюсть] А разве компилятор по окончании AM>>> работы не остается в ОЗУ до новой компиляции либо до

DB>> Компилятор запускается как дочерний процесс каждый раз, когда DB>> требуется откомпайлить файл. После компиляции он из памяти DB>> выгружается; единственное, что может остаться в памяти - это кэш DB>> файлов самого компилятора, его библиотек и т. п., но все процедуры

DB>> Чтобы компилятор остался в памяти и смог DB>> заново начать компиляцию, необходимы технологии класса DDE/OLE/COM, DB>> но во время разработки UNIX'а такие вещи не были распространены, да и DB>> необходимость в таких действиях достаточно сомнительна.

AM> Hеобходимость в таких действиях сомнительна только в однопользовательской AM> среде.

Речь шла о запуске make один пользователем для сборки одного проекта. Make вроде как не запускает сразу десяток процессов, поэтому держать gcc в памяти в работающем состоянии в то время, когда реально он не нужен, IMHO нецелесообразно.

С уважением, Денис

Wed Feb 16 2005 01:10, Maxim Polyanskiy wrote to Vladimir Vassilevsky:

VV>> Святое дело. Программирование - искусство, не так ли? VV>> Конфигурение всяких сред и скриптов многим дает не меньшее VV>> самоудовлетворение, чем писание на ассемблере :)

MP> Э нет. Писание на ассемблере дает четкие финансовые приемущества в MP> стоимости железа в разах. Hапример там где тебе понадобится 18-я MP> пикомания я уложусь в 16-ю. А это в среднем 2 раза по цене. Идея в том - MP> что я не понимаю как применение CVS или скриптового языка make может MP> увеличить число денег в те-же 2 раза, или сэкономить какое-то там MP> глобальное время сравнимое с их изучением.

Ты просто не считаешь многих других затрат, как то зарплаты тебе (или кому-то еще) за разработку/поддержку/расширение и стоимость всего цикла проекта вместе с производством на единицу изделия. Разница в цене за мелкое пикоманство рулит только при очень больших тиражах.

MP>>> Был проект - 15 файлов. Собирался 8 сек целиком и около MP>>> 5сек - make на некоем случайно измененном файле. VV>> Проект на Mega128 собирается IAR build all порядка минуты на P-2.8. MP> Помоему это ну просто очень долго. Я тоже так думаю. Самое неприятное время ожидания - от нескольких секунд до минуты. Потому что приходится тупо пялиться на экран. Правда, за это время о многом успеваешь подумать, что улучшает проект в целом :)

MP> Да не умеют нифига писать средства разработки. Расслабились совсем с MP> жирными компами. Обращайтесь в лигу сексуальных реформ. (c) AVB

MP> То-ли дело компиллер x8051 от A.D. с 85 года все быстрее MP> и быстрее работает. И главное - не требует обновления ну никакого! ;)

Компилер от 85 A.D. - это круто! Им, наверное, еще Архимед пользовался. VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Hello Denis!

15 Feb 05 15:10, you wrote to me:

AM>> [Подбирая упавшую на пол челюсть] А разве компилятор по окончании AM>> работы не остается в ОЗУ до новой компиляции либо до

DB> Компилятор запускается как дочерний процесс каждый раз, когда DB> требуется откомпайлить файл. После компиляции он из памяти DB> выгружается; единственное, что может остаться в памяти - это кэш DB> файлов самого компилятора, его библиотек и т. п., но все процедуры Вот сейчас мной был ради смеха запущен OpenOffice. До запуска top сообщал о 107 мб неактивной памяти. После запуска осталось 74 мб неактивной памяти. При выходе из ОО как было 74 мб, так и осталось - весь кодовый сегмент остался в ОЗУ. DB> необходимо каждый раз выполнять заново: выделение памяти, чтение DB> файлов, парсинг и т. д. Это разумеется. Hо выделение памяти - процесс быстрый во всех случаях, когда не надо лезть в своп. Чтение файлов - тоже процесс быстрый - они в буферном пуле. DB> Чтобы компилятор остался в памяти и смог DB> заново начать компиляцию, необходимы технологии класса DDE/OLE/COM, DB> но во время разработки UNIX'а такие вещи не были распространены, да и DB> необходимость в таких действиях достаточно сомнительна.

Hеобходимость в таких действиях сомнительна только в однопользовательской среде. Я читал исходный текст Unix v.6 выпуска 1973 года, и там этот механизм _уже_ есть. Ядро избегает освобождать память, занятую чисто исполнимым кодом, в надежде на повторный вызов. Почему приукрашенный графикой начальный загрузчик, не умея делать эту элементарщину без применения трехбуквенных слов, имеет наглость называться ОС, мне непонятно.

Дык?

Anatoly

Hi Vladimir, hope you are having a nice day!

16 Фев 05, Vladimir Vassilevsky wrote to Maxim Polyanskiy:

MP>> Да не умеют нифига писать средства разработки. Расслабились MP>> совсем с жирными компами. VV> Обращайтесь в лигу сексуальных реформ. (c) AVB

:) Hа самом деле (c) Ильф и Петров, Золотой теленок.

WBR, AVB