The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%, opennews (?), 03-Янв-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


191. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от ncemail (ok), 03-Янв-22, 23:21 
Насколько я понимаю, 50 лет назад были маленькие объемы оперативки. А модульность подразумевает компиляцию сразу всех файлов модуля в единое синтаксическое дерево, что позволяет вообще отказаться от include в рамках одного модуля (именно так в C# и Java). Далее, для каждого модуля определяется публичный интерфейс и приватная реализация, и интерфейсы всех модулей проекта должны быть в оперативке (в виде AST) всегда - только так можно избежать постоянной перекомпиляции инклудов (когда один инклуд подключен в тысячи файлов и перекомпилируется тысячи раз вместе с каждым исходником). Вероятно, когда оперативка измерялась килобайтами, сделать все это было затруднительно.
В Си решили поступить по простому - сделали псеводмодульность вручную, т.е. заголовочный файл - это написанный вручную публичный интерфейс. Ну и попались на этом - объемы оперативки стали расти, объемы кода тоже, переписывать язык и весь код уже было нереально, "работает - не трожь" и тому подобное. Кривизна этого подхода особенно явственно вылезла в С++, который унаследовал инклуды Си, а в заголовочные файлы стали пихать шаблонный код.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

200. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +1 +/
Сообщение от Ordu (ok), 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-е... какая оптимизация, ты о чём?

Ответить | Правка | Наверх | Cообщить модератору

201. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +1 +/
Сообщение от Аноним (201), 04-Янв-22, 01:24 
Это и так можно делать, достаточно не держать в инклюдах ничего кроме объявлений и порезать использование шаблонов. Но все равно не поможет, так как хотелось бы чтобы линкер пооптимизировал код между объектниками всякими LTO, PGO а может и BOLTом.
Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру