The OpenNET Project / Index page

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



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

Оглавление

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

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


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ообщить модератору

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

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




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

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