The OpenNET Project / Index page

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



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

Оглавление

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

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


17. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +9 +/
Сообщение от Аноним (17), 03-Янв-22, 11:50 
Потому, Delphi компиляет отдельные юниты в отдельные независимые модули (которые даже если и лежат в итоге в одном бинарнике - по сути, как набор отдельных взаимодействующих библиотек). А "Ява" - это вообще виртуальная машина, у неё вообще никаких гарантий на время выполнения нет. Одна и та же строчка кода может работать как 1, так и 1000 единиц времени.

В случае с Си, из-за того, что язык используется для системного программирования - требуются гарантии детерминированности времени исполнения кода. И если Delphi программа может позволить себе "подождать" несколько миллисекунд на то, чтобы подгрузить страницы другого модуля, инициализировать его и т.д., то если у тебя в обработчике прерывания в ядре начнёт происходить недетерминированная хрень и логика-отсебятина компилятора - то ядро просто работать не будет.

В си тоже вполне себе есть "модули". Библиотеки (статические и динамические) - это именно про это. Если ты разбиваешь свой проект на отдельные незавимые библиотеки - то чаще всего их можно собирать
и редактировать каждый по отдельности, и пересборка всего проекта не требуется. И даже ядро умеет динамически линковаться с кодом - kernel objects - это именно про это. Просто из-за особенностей ядерной разработки - одна правка в базовое ядро может сломать модули, собранные под старое ядро, причём самым неожиданным образом (т.к. всё работает в одном адресном пространстве, промахнулся на 1 байт в структуре - и ты уже, например, корраптишь данные файловой системы). Поэтому дешевле не портить себе нервную систему и не стрелять в ногу - так что ядро пересобирают целиком.

Ну, а то, что некоторые сишники и плюсовики (например, проект Chromium) закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе суток - это уже проблема рук, растущих не из того места, а не языка.

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

22. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +4 +/
Сообщение от Цезий Родонович (?), 03-Янв-22, 12:01 
Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей.
Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
Ответить | Правка | Наверх | Cообщить модератору

34. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –2 +/
Сообщение от Аноним (17), 03-Янв-22, 12:14 
Потому что это именно так и устроено - каждый дельфёвый модуль - это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой набор функций и использует функции других библиотек. Т.е. ничем концептуально не отличается от проекта на си, состоящего из нескольких десятков статически слинкованных библиотек. Когда пишешь на C - тебе не приходится пересобирать каждый раз glibc с проектом.

На сях обычно каждый C-файл не делают отдельной библиотекой. Во-первых, потому что растут накладные расходы, софт становится медленнее. А во-вторых, это закрывает целый ряд оптимизаций, который возможен в gcc (в том числе link-time optimization), но не возможен в Delphi, потому что МОДУЛЬНОСТЬ.

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

42. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –2 +/
Сообщение от iZENemail (ok), 03-Янв-22, 12:26 
> Потому что это именно так и устроено - каждый дельфёвый модуль -
> это шмоток законченного кода, по сути статическая библиотека. Которая предоставляет свой
> набор функций и использует функции других библиотек. Т.е. ничем концептуально не
> отличается от проекта на си, состоящего из нескольких десятков статически слинкованных
> библиотек. Когда пишешь на C - тебе не приходится пересобирать каждый
> раз glibc с проектом.

Приходится из-за детерминированности связей с обратными вызовами и LTO. В классическом Turbo Pascal и Delphi используется однопроходный компилятор без препроцессора.

> На сях обычно каждый C-файл не делают отдельной библиотекой. Во-первых, потому что
> растут накладные расходы, софт становится медленнее. А во-вторых, это закрывает целый
> ряд оптимизаций, который возможен в gcc (в том числе link-time optimization),
> но не возможен в Delphi, потому что МОДУЛЬНОСТЬ.

Delphi 2 (32-bit) на Pentium II показывала скорость компиляции ~300000 строк в секунду. Это быстрее, чем Turbo C на том же оборудовании в десятки раз. Дельфишник, как правило, чтобы запустить проект на пробное выполнение, статически собирал проект вместе с VCL в автономный EXE-файл, невзирая на размеры последнего. Потому что скорость компиляции и связывания с заранее откомпилированным (бинарным, .dcu) кодом была выше, чем каждый раз пересобирать такую же по функционалу "портянку" из исходников, написанных на С/С++ Builder.

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

65. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +1 +/
Сообщение от Аноним (65), 03-Янв-22, 13:20 
А теперь пойди и посмотри на классический трупопаскаль, ага. Один раз, а потом второй, но уже глазами
Ответить | Правка | Наверх | Cообщить модератору

23. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –2 +/
Сообщение от Цезий Родонович (?), 03-Янв-22, 12:01 
Что за дичь ты написал? Особенно доставило про делфи и инициализацию модулей.
Некоторые недостатки других ЯП и компиляторов, никак не оправдывают конченную модульность в C/C++
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

94. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –1 +/
Сообщение от Аноним (-), 03-Янв-22, 14:09 
>C/C++

Это что за язык такой?

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

122. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –2 +/
Сообщение от Аноним (122), 03-Янв-22, 16:27 
Он даже не в курсе, что это два разных языка. Просто второй скопипастил у первого, но как-то не очень уверенно и криво. Даже разные фишки выкидывать пришлось ради "святого ООП", который по факту просто макрос для вызова функций с контекстом (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).
Ответить | Правка | Наверх | Cообщить модератору

135. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (-), 03-Янв-22, 17:01 
> restrict появился в c99
> (и всё равно тот же restrict зачем-то выкинули, хотя он очень нехило может помочь в некоторых оптимизациях).

Экспердус опеннетус вульгарис ...


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

228. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +1 +/
Сообщение от Аноним (228), 04-Янв-22, 11:58 
Это два языка. Никогда не видел перечисление косой чертой?
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

290. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  –4 +/
Сообщение от Аноним (-), 04-Янв-22, 18:32 
В Юникс мире такого перечисления никто не знает.
Ответить | Правка | Наверх | Cообщить модератору

24. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +1 +/
Сообщение от Аноним (2), 03-Янв-22, 12:02 
> закидывают всё в один проект и делают монолитные проекты на 60 миллионов строк кода которые компиляются в районе суток

Ну зайди в билд систему любого дистра и убедись, что неоправданно долгая компилюха - это болезнь вообще всех сишных проектов. Перейдя в Линукс, в свое время удивился, как обычный gtk.-хелловорлд компилился секунды, а не наносекунды, как в Дельфи.

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

39. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от Аноним (17), 03-Янв-22, 12:22 
Я гентушник, мне не надо "заходить в билд систему", она у меня прямо на компе.

Я не сказал, что софт компиляется быстро. Сишные проекты действительно собираются ощутимо долго.

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

48. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +2 +/
Сообщение от Аноним (2), 03-Янв-22, 12:38 
> проблема рук, растущих не из того места, а не языка.

Следовательно, таки языка, а не рук.

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

412. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от n00by (ok), 08-Янв-22, 19:57 
А если бы хоть раз посмотрели машинный код после кодогенератора Дельфи, то удивления бы не было.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

416. "Опубликован набор патчей, ускоряющих сборку ядра Linux на 50..."  +/
Сообщение от A.N.Onimous (?), 08-Янв-22, 23:17 
>из-за особенностей ядерной разработки

Интересный эвфемизм для отсутствия архитектуры

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

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

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




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

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