Исходное сообщение
"Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..." Отправлено Ordu, 04-Янв-22 00:16
> модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое дерево Не, как я понимаю, не подразумевает. Если ты, компилируя модуль, будешь генерировать файл типа "скомпилированный модуль", который будет что-то типа комбинации сишных .o и .h, но подчёркнуто бинарным, чтобы можно было бы быстро оттуда в оперативку вытащить декларации и перегнать их во внутреннее представление, используемое компилятором, то... А если ты ещё дашь возможность импортировать не только модуль целиком, но и частями, типа: use std::io::{Read, Write}; то тогда можно из скомпилированного модуля извлекать не все декларации, а только нужные, экономя не только время на жонглирование ими, но и оперативку под их хранение. Интересности возникнут с inline-функциями и с параметризацией, потому что для первых придётся сохранять в файл либо исходный текст и каждый раз по-новой разбирать в AST, либо сохранять в файл в каком-то предкомпилированном виде, может даже в виде AST. С параметризацией примерно то же, но ещё жёстче, потому что с inline'ами можно сделать грязно, скомпилировав их в бинарный блоб инструкций и сопроводив метаинформацией для линковки этого блоба в вызывающую функцию -- таким образом оптимизации проводимые на AST не удастся проводить над кодом после того, как функции заинлайнены, но, по-крайней мере, накладные расходы на вызов можно снять. Но с параметризацией так уже не выйдет. Но, как бы это сказать, во-первых, проблема с инлайнами не является непреодолимой проблемой даже на 64Kb оперативки, просто взгеморроиться надо, а параметризацию по типу тогда всё равно не делали, то есть её проблемы можно игнорить. А во-вторых, в C из 70-х не было inline-функций. Правда вместо них были макросы. Паскаль разрабатывался на несколько лет позже чем C, и он вполне справлялся с модулями. ТурбоПаскаль в начале 80-х вышел и работал на тех PC, в которых не было никаких мегабайт оперативки, и я не думаю что в этих PC было больше оперативки чем в PDP-11, на котором создавался C и Unix. Скорее даже наоборот. Это сейчас модульность реализуют так, чтобы хранить в оперативке дохрена гигабайт AST. Но это, как я понимаю, делается с целью выполнить максимум оптимизаций на уровне AST, то есть там, где у компилятора больше всего семантической информации, и где больше возможностей для оптимизации. А в 70-е... какая оптимизация, ты о чём?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое дерево > Не, как я понимаю, не подразумевает. Если ты, компилируя модуль, будешь генерировать > файл типа "скомпилированный модуль", который будет что-то типа комбинации сишных .o > и .h, но подчёркнуто бинарным, чтобы можно было бы быстро оттуда > в оперативку вытащить декларации и перегнать их во внутреннее представление, используемое > компилятором, то... А если ты ещё дашь возможность импортировать не только > модуль целиком, но и частями, типа: > use std::io::{Read, Write}; > то тогда можно из скомпилированного модуля извлекать не все декларации, а только > нужные, экономя не только время на жонглирование ими, но и оперативку > под их хранение. > Интересности возникнут с inline-функциями и с параметризацией, потому что для первых придётся > сохранять в файл либо исходный текст и каждый раз по-новой разбирать > в AST, либо сохранять в файл в каком-то предкомпилированном виде, может > даже в виде AST. С параметризацией примерно то же, но ещё > жёстче, потому что с inline'ами можно сделать грязно, скомпилировав их в > бинарный блоб инструкций и сопроводив метаинформацией для линковки этого блоба в > вызывающую функцию -- таким образом оптимизации проводимые на AST не удастся > проводить над кодом после того, как функции заинлайнены, но, по-крайней мере, > накладные расходы на вызов можно снять. Но с параметризацией так уже > не выйдет. > Но, как бы это сказать, во-первых, проблема с инлайнами не является непреодолимой > проблемой даже на 64Kb оперативки, просто взгеморроиться надо, а параметризацию по > типу тогда всё равно не делали, то есть её проблемы можно > игнорить. А во-вторых, в C из 70-х не было inline-функций. Правда > вместо них были макросы. > Паскаль разрабатывался на несколько лет позже чем C, и он вполне справлялся > с модулями. ТурбоПаскаль в начале 80-х вышел и работал на тех > PC, в которых не было никаких мегабайт оперативки, и я не > думаю что в этих PC было больше оперативки чем в PDP-11, > на котором создавался C и Unix. Скорее даже наоборот. > Это сейчас модульность реализуют так, чтобы хранить в оперативке дохрена гигабайт AST. > Но это, как я понимаю, делается с целью выполнить максимум оптимизаций > на уровне AST, то есть там, где у компилятора больше всего > семантической информации, и где больше возможностей для оптимизации. А в 70-е... > какая оптимизация, ты о чём?
	Введите код, изображенный на картинке: