Современное ПО
От: kov_serg Россия  
Дата: 09.07.21 16:10
Оценка: 1 (1) +6 -1 :))) :))) :))) :))) :)))
Простое объяснение почему всё так как есть

https://youtu.be/geY5cbImVwc?t=1300
Re[2]: Современное ПО
От: goto Россия  
Дата: 13.07.21 16:14
Оценка: +5
Здравствуйте, vsb, Вы писали:

vsb>Несерьёзно. Турбопаскаль занимал несколько мегабайтов и был консольной программкой с примитивным GUI. Intellij Idea занимает несколько сотен мегабайтов и содержит в себе невообразимо больше функционала с невообразимо более сложным интерфейсом.


Это миф, который очень напоминает мифы об СССР в том смысле, что совершенно непонятно, откуда они берутся.

ТурбоПаскаль был IDE практически в современном понимании. Оболочка Турбо во многом, если не в основном, определила само понятие IDE и ее развитие. Ближе к концу 80-х Турбо — это редактор со встроенными компилятором, линковщиком (тут не помню конкретно про Паскаль), отладчиком, контекстным Хелпом с гипертекстом, содержащим всю информацию по IDE, языку, процедурам, туториалы и примеры. Не помню, сколько места занимало, но немного. Для примера, наш первый рабочий писюк имел диск 5Мб. На этом диске был установлен ТурбоПаскаль, QuickC (IDE C от Микрософт), всякие Нортон Коммандеры и еще пара игрушек. Или такое: пришлось несколько дней поработать на писюке без диска — только 5" дискета 1.2М. На нее уместилась ДОС, QuickC, мои файлы — небыстрый рабочий вариант. (QuickC я чуть обрезал).

А с современным ПО в определенном смысле все просто. Критерии успеха этой инженерии не технические, а денежные. Пока все это монструозие позволяет сохранять над собой контроль, управляемость, а заказчик готов этот праздник оплачивать, перемены в технологиях и самих подходах не нужны. Другие финансово эффективные тенденции, технологии пока не просматриваются, следовательно, праздник будет продолжаться в нынешнем виде.

Тут еще интересно поглядеть на железо. Я в нем не спец, но как-то привык думать, что там, в отличие от софтостроения, оптимизациям уделяется больше внимания (больше параметров оптимизации). Понятно, что в области железа тоже можно найти свои фреймворки, свои пласты легаси, есть маркетинговая гонка за числом мегапикселей, ядер, но все же там "индусокодинга" и финтифлюшек значительно меньше. Как сейчас модно говорить, напишите, что думаете про железо в контексте темы ругания софтоделания.
Re: Современное ПО
От: vsb Казахстан  
Дата: 10.07.21 12:38
Оценка: 1 (1) -1
Несерьёзно. Турбопаскаль занимал несколько мегабайтов и был консольной программкой с примитивным GUI. Intellij Idea занимает несколько сотен мегабайтов и содержит в себе невообразимо больше функционала с невообразимо более сложным интерфейсом.

Я не спорю, что можно упаковать hello-world.html в Electron, который засунуть в докер-образ и это всё засунуть в виртуалку. Накидал бессмысленных слоёв и получил из 20 байтов 20 гигабайтов. И в какой-то мере это происходит, но в целом это скорей исключение. Про тот же электрон все понимают, что это неоптимальное решение и в какой-то момент его заменят на расшаренный движок браузера, что вернёт крохотный размер Electron-приложениям.

Ну и ещё одна большая проблема, если говорить про Java, которую я по крайней мере знаю, чтобы говорить о ней — отсутствие чего-то вроде LTO. Мне нужен один метод на 20 байтов байткода, я подключаю Guava на 3 мегабайта и одна с моим приложением уже бегает. Или я подключаю другую библиотеку, которой нужен тот самый метод на 20 байтов байткода и она подтягивает ту самую Guava. Причём в рамках Java это даже теоретически не факт, что возможно решить. Во-первых reflection позволяет использовать любой класс, поэтому ничего выкидывать уже нельзя. Если reflection ограничить, то if-ы позволяют в теории использовать блоки кода, которые на практике использоваться не будут, например написано у меня Charset.forName("UTF-8"). Мне кроме UTF-8 ничего не надо, но на всякий случай в программе лежат все кодировки с кучей таблиц, которые занимают уйму места. Также в Charset.forName прописана какая-то обработка случая, когда кодировка не найдена, и эти несколько десятков байткода лежат мёртвым грузом, т.к. UTF-8 всегда будет найдена.

Т.е. если взять типичное enterprise-приложение, проследить все возможные пути выполнения и посмотреть, сколько реально байткода задействовано, то скорей всего это будут вообще крохи от общего объёма поставляемого байткода в стандартной библиотеке и подключаемых библиотеках. А если ещё вспомнить про моду микро-сервисов, то там ситуация ещё хуже.

Но при всём при этом это не является, на самом деле, такой уж большой проблемой. Оно занимает место на диске, да и только. Если класс никто не трогал, то он даже с диска читаться не будет. Если метод никто не вызывает, то JIT на него вызываться не будет. Т.е. есть проблемы и они частично уже решены. Если не вглядываться, то да, беда, 10 метров жаваскрипта грузят текста 300 байт. А если вглядеться, может быть и не такая уж беда.

Но соглашусь, что было бы неплохо, если бы языки проектировали из расчёта возможности максимальной оптимизации и выбрасывания неиспользуемого кода. Не только на уровне классов и методов, но и на уровне отдельных блоков кода, про которые можно доказать, что они никогда не вызываются в текущей программе.
Отредактировано 10.07.2021 12:41 vsb . Предыдущая версия .
Re[2]: Современное ПО
От: kov_serg Россия  
Дата: 10.07.21 19:06
Оценка: +2
Здравствуйте, imh0, Вы писали:

I>Хотел отдельно тему завести, но ваша отлично подходит для обсуждения этой дичи...

I>https://tv.rbc.ru/archive/ekskluziv/60e2f2ce2ae59602f173f18d
I>Надо смотреть с 18:24, до этого просто фигня.
I>То есть я к тому, что надо раделять программистов и "эфективных пьющих менеджеров" — Последние аж даже воинстующее, хотят "других" программистов, которые не хоят так делать )
Власть случайно оказалась у инженеров и попёр технический прогресс. Нужны были инженеры, поэтому было такое образование. Всё постраивалось под это. Сейчас они не нужны и вымирают.
Теперь будут давать не знания, а компетенции. Т.е. навыки коммуникации и как оптимизировать конкретный процесс на конкретном производстве с использованием инструментов конкретной фирмы для увеличения прибыли предприятия.
А решение главной задачи человечества: энергообеспечения — нафиг это не приносит прибыли. Нужны компетентные потребители. А думать будет за вас tefal.
https://youtu.be/geY5cbImVwc?t=6271

То что программы такие избыточные это именно заслуга того что вычислительные мощности доступны практически на халяву (летать не надо). Естественный отбор ПО.
Так что без создания обратной положительной связи дальше будет тоже самое, только хуже. Сейчас наметилась тенденция сжигать мосты посмотрите на win11. (Даже blender уже отказывается пускаться на win7)
Отредактировано 10.07.2021 20:09 kov_serg . Предыдущая версия .
Re[2]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 12.07.21 13:40
Оценка: +1 :)
Здравствуйте, student__, Вы писали:

__>Добрышевский говорит о том, что нейронов и синапов примерно столько же.


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

__>В современном ПО гораздо больше логических компонент, чем в древнем.


Ну да. В дневнем софте возраст человека определялся вычитанием даты рождения из текущей даты. В современном для календарных дат применяются абстракции, состоящие из абстракций "день", "месяц" и "год", для обслуживания каждой из них подключается отдельная библиотека, возрасты людей, животных, документов и зданий выделяются в отдельные производные типы, и при каждой операции проверяется, не подвержены ли даты проблеме 2000-го года.
Re[3]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 13.07.21 16:25
Оценка: +2
Здравствуйте, goto, Вы писали:

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


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

С софтом же ситуация обратная — хочется до последнего сидеть на старом, который имеет вменяемые размеры, при работе не дает ощутимых задержек, и лицензия на который получена навсегда, а не на время.
Re[6]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 18:26
Оценка: 3 (1)
Здравствуйте, sergey2b, Вы писали:

S>Поддержки вещественных чисел в bios нет

S>Графику конечно можно выводить через bios или напрямую

Вещественные числа и графика нужны далеко не всем. Я, например, и посейчас в основном обхожусь без них.

S>В любом случаи система была хорошей


Она была отличным примером, как можно делать хорошо, удобно, надежно, и при этом — за разумные деньги (TP продавали за $50, TC — вроде бы чуть дороже).

S>А по какой книги вы изучали C ?


По хелпу к TC IDE. Брошюрку Кернигана/Ричи я прочитал значительно позже, и толку от нее было чуть, ибо в TC был реализован более-менее приличный ANSI C, а у K & R описан самый примитивный.
Re[5]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 14.07.21 07:39
Оценка: 2 (1)
Здравствуйте, goto, Вы писали:

G>Софтостроитель может впарить клиенту сырого уродца со словами: скоро пропатчим.


Железячники тоже любят обновлять прошивки. В том же телефоне, помимо основной прошивки с ОС, есть еще куча — в радиомодуле, контроллере питания, экране, датчике касания и т.п. Некоторые перешиваются спецсофтом, остальные — спецоборудованием.

G>не намечаются ли подобные тенденции у железячников?


Они давно наметились — даже относительно простые схемы, которые когда-то делались на чистой логике с обратными связями, часто делают на микроконтроллерах, хотя бы и простейших. Но это уже на втором и более высоких уровнях, когда для схемы берутся готовые компоненты. Когда делают кристалл, все равно проще использовать логику (обычную или ПЛМ).

G>Просматривал анонсы Вин11. На первом месте и самая обсуждаемая новость — кнопка Старт в середине, а не слева. Пипец как интересно.


Так это ж хорошо. Если с помпой подаются визуальные изменения — значит, в ядре и критичных подсистемах еще ничего не поломали, софт переделывать не придется.
Re[7]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.07.21 08:41
Оценка: 1 (1)
Здравствуйте, goto, Вы писали:

G>Речь была о железном железе — от CPU до хоть даже разводки платы, которые не перепрошьешь.


Многие CPU частично перепрошиваются, только в них, как правило, не используется долговременная память — только оперативная.

ЕМ>>Когда делают кристалл, все равно проще использовать логику (обычную или ПЛМ).


G>Интересно. Тут тоже появляется потенциал для "отвязки от реальности".


Ага. Например, если нужна схема с N входами и M выходами, с определенной статической зависимостью между ними, то уже никто станет городить логическую структуру — тупо поставят масочное ПЗУ нужных разрядности и объема. Проигрыш — только в площади кристалла, а по скорости и энергозатратам — выгоднее.

G>При отсутствии связей ("свободе" в кавычках) массовые процессы, видимо, всегда мигрируют в сторону "Дома-2".


"Было бы ошибкой считать бОльшую часть человечества тупой и ленивой. На самом деле она гораздо тупее и ленивее".
Re[4]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 14:13
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Сколько весит статически скомпилированный hello world в С++?


Если под виндой, через MessageBox — два килобайта, бОльшая часть из которых — выравнивание по границам 512 байт. Если через printf — несколько десятков килобайт.

vsb>Когда я последний раз проверял, там была цифра в мегабайтах.


То был плохой, негодный C++.

vsb>реально это несколько байтов кода — вызвать write(1, "Hello world", 11).


Традиционный HW делается через printf, а это сразу же подтягивает форматные преобразования, работу с плавучкой с локалями и т.п. Но их крайне сложно будет вычистить чисто сторонним анализом, это слишком затратно.
Re[2]: Современное ПО
От: kov_serg Россия  
Дата: 10.07.21 19:39
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Несерьёзно. Турбопаскаль занимал несколько мегабайтов и был консольной программкой с примитивным GUI. Intellij Idea занимает несколько сотен мегабайтов и содержит в себе невообразимо больше функционала с невообразимо более сложным интерфейсом.

Зато в turbo pascal была полная offline справка и он был самодостаточным.

vsb>Я не спорю, что можно упаковать hello-world.html в Electron, который засунуть в докер-образ и это всё засунуть в виртуалку. Накидал бессмысленных слоёв и получил из 20 байтов 20 гигабайтов. И в какой-то мере это происходит, но в целом это скорей исключение. Про тот же электрон все понимают, что это неоптимальное решение и в какой-то момент его заменят на расшаренный движок браузера, что вернёт крохотный размер Electron-приложениям.

Не. Еще же надо по облакам распихать.

vsb>Ну и ещё одна большая проблема, если говорить про Java, которую я по крайней мере знаю, чтобы говорить о ней — отсутствие чего-то вроде LTO. Мне нужен один метод на 20 байтов байткода, я подключаю Guava на 3 мегабайта и одна с моим приложением уже бегает. Или я подключаю другую библиотеку, которой нужен тот самый метод на 20 байтов байткода и она подтягивает ту самую Guava. Причём в рамках Java это даже теоретически не факт, что возможно решить. Во-первых reflection позволяет использовать любой класс, поэтому ничего выкидывать уже нельзя. Если reflection ограничить, то if-ы позволяют в теории использовать блоки кода, которые на практике использоваться не будут, например написано у меня Charset.forName("UTF-8"). Мне кроме UTF-8 ничего не надо, но на всякий случай в программе лежат все кодировки с кучей таблиц, которые занимают уйму места. Также в Charset.forName прописана какая-то обработка случая, когда кодировка не найдена, и эти несколько десятков байткода лежат мёртвым грузом, т.к. UTF-8 всегда будет найдена.

Таки эту проблему никто и не пытается даже рассматривать — зачем? Работает же — приемлимо.
Зато если взглянуть на clang или rust. Казалось бы простое решение использовать hardlink — что бы использовать один и тот же исполняемый файл под разными именами для разных функций. Что бы не делать много мелких которые динамически подгружают dll-ку. С dll у C++ вообще грусть, печаль. Но что получается: смотрим в visual studio — все файлы подписаны цифровой подписью. И эти тоже, причем каждый по разному. Итого имеем 20 одинаковых файлов, но с разными цифровыми подписями. Казалось бы 60Мб*20 всего-то лишний гигабайт с копейками. Но что мешает использовать сжатие например для статических библиотек (они же архивы бинарников) там 90% это просто длинные манглированные имена с неймспейсами, которые прекрасно жмуться, но нет. Не та фича.
ps: Всё новое, это не обязательно про улучшение.


vsb>Т.е. если взять типичное enterprise-приложение, проследить все возможные пути выполнения и посмотреть, сколько реально байткода задействовано, то скорей всего это будут вообще крохи от общего объёма поставляемого байткода в стандартной библиотеке и подключаемых библиотеках. А если ещё вспомнить про моду микро-сервисов, то там ситуация ещё хуже.

vsb>Но при всём при этом это не является, на самом деле, такой уж большой проблемой. Оно занимает место на диске, да и только. Если класс никто не трогал, то он даже с диска читаться не будет. Если метод никто не вызывает, то JIT на него вызываться не будет. Т.е. есть проблемы и они частично уже решены. Если не вглядываться, то да, беда, 10 метров жаваскрипта грузят текста 300 байт. А если вглядеться, может быть и не такая уж беда.
Привет cobol-у

vsb>Но соглашусь, что было бы неплохо, если бы языки проектировали из расчёта возможности максимальной оптимизации и выбрасывания неиспользуемого кода. Не только на уровне классов и методов, но и на уровне отдельных блоков кода, про которые можно доказать, что они никогда не вызываются в текущей программе.

В языки следует закладывать ограничения ресурсов, иначе никак. Все прорывы в программировании были связаны именно с ограничениями, как ни странно.
Отредактировано 10.07.2021 19:43 kov_serg . Предыдущая версия . Еще …
Отредактировано 10.07.2021 19:40 kov_serg . Предыдущая версия .
Re[5]: Современное ПО
От: jamesq Россия  
Дата: 11.07.21 03:13
Оценка: +1
Здравствуйте, Marty, Вы писали:

M>1) Какой-то общий код тогда выносится в отдельную DLL-ку — это дополнительный уровень косвенности при вызове, для мелочи, которая часто вызывается — это играет роль

что-что, простите? ерунду не пиши, пожалуйста.
абсолютно неважно, разнесен ли код по нескольким DLL, или лежит в одной. один чёрт все DLL мапятся в адресное пространство процесса, и вызов функции любой из них — это просто вызов по указателю на функцию
и скорость этого вызова одинакова для любой DLL, да хоть и самого EXE файла.
больше того, в Windows есть хорошее преимущество перед Linux — в Win адреса корректируются при загрузке DLL, и всё становится как родное (я знаю, очень туманно пишу. и сам туманно помню эту фишку. нет желания долго ковыряться в доках, вспоминать. посмотрите сами, если хотите). В Linux как я помню, идёт обращение через указатели, а в Win — по прямым адресам.

M>2) Много мелких файлов занимают на диске больше места, снижают производительность при обращении к ним

это несущественно
M>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке
тоже несущественно
Re[3]: Современное ПО
От: ути-пути Россия  
Дата: 11.07.21 18:57
Оценка: +1
Здравствуйте, kov_serg, Вы писали:

_>Тезисно — мы все умрём.


Это какой-то древний баян.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: Современное ПО
От: 4058  
Дата: 12.07.21 14:21
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ну да. В дневнем софте возраст человека определялся вычитанием даты рождения из текущей даты. В современном для календарных дат применяются абстракции ...


Напомнило: https://rsdn.org/forum/philosophy/4618210
Автор: Buss
Дата: 15.02.12

По большей части это так (и уже давно), ибо возможности аппаратных ресурсов слишком высоки для подавляющего кол-ва задач. Вот и собираются теперь по 20 макак, и с умным видом калякуют месяцами чего-то неэффективное и ненужное на скриптовых недо-языках и с множеством лишних зависимостей, чего раньше 1-2 человека могли сделать за неделю и при этом "железо потребить" на 2 порядка меньше.
Re[3]: Современное ПО
От: Ночной Смотрящий Россия  
Дата: 13.07.21 19:19
Оценка: +1
Здравствуйте, kov_serg, Вы писали:

НС>>Ага, как обычно, простое и неверное. Доказательства по аналогии — они всегда такие.

_>То есть наличие естественного отбора в софте вы отрицаете.

Я отрицаю использование аналогий в качестве доказательств.

_>Методы подобия часто применяются в инженерной практике


Для индукции, а не для дедукции, как это делаешь ты.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Современное ПО
От: kov_serg Россия  
Дата: 14.07.21 14:56
Оценка: +1
Здравствуйте, Skorodum, Вы писали:

_>>Какие замечательные ничем не обоснованные слова. Если вы не обеспечите 2кВт на человека то вас ждёт каменный век и войны за обычную воду

S>Если вы обеспечите хоть 100кВт на человека войны никуда не денутся.
Вы делаете не првильные логические выводы если из A следует B, то из B может не следовать A.
Re: Современное ПО
От: 4058  
Дата: 09.07.21 20:05
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


_>https://youtu.be/geY5cbImVwc?t=1300


Приблизительно всё так и есть.
Re: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 11:41
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


Там же сказано — "пользуемся интеллектом не по назначению".
Re: Современное ПО
От: imh0  
Дата: 10.07.21 12:29
Оценка:
Здравствуйте, kov_serg, Вы писали:

Хотел отдельно тему завести, но ваша отлично подходит для обсуждения этой дичи...

https://tv.rbc.ru/archive/ekskluziv/60e2f2ce2ae59602f173f18d

Надо смотреть с 18:24, до этого просто фигня.

То есть я к тому, что надо раделять программистов и "эфективных пьющих менеджеров" — Последние аж даже воинстующее, хотят "других" программистов, которые не хоят так делать )
Re[2]: Современное ПО
От: imh0  
Дата: 10.07.21 12:51
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Но соглашусь, что было бы неплохо, если бы языки проектировали из расчёта возможности максимальной оптимизации и выбрасывания неиспользуемого кода. Не только на уровне классов и методов, но и на уровне отдельных блоков кода, про которые можно доказать, что они никогда не вызываются в текущей программе.


Это как раз есть в С++. Мне кажется что проблема не из-за технических особенностей, а из-за того что сознательно требуют делать тяп-ляп. То есть оптимизационный карьерный отбор именно так и идет. Не надо чтобы хорошо и быстро работало, надо чтобы срочно и сейчас.
Re[3]: Современное ПО
От: vsb Казахстан  
Дата: 10.07.21 13:19
Оценка:
Здравствуйте, imh0, Вы писали:

I>Это как раз есть в С++.


Не думаю. Сколько весит статически скомпилированный hello world в С++? Когда я последний раз проверял, там была цифра в мегабайтах. При том, что реально это несколько байтов кода — вызвать write(1, "Hello world", 11). Всё остальное — ненужная шелуха.

> Мне кажется что проблема не из-за технических особенностей, а из-за того что сознательно требуют делать тяп-ляп. То есть оптимизационный карьерный отбор именно так и идет. Не надо чтобы хорошо и быстро работало, надо чтобы срочно и сейчас.


А зачем тут противопоставлять? Нужно, чтобы хорошо, быстро работало, срочно и сейчас.
Re[2]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 13:45
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Турбопаскаль занимал несколько мегабайтов


Каких еще "мегабайтов"? Там было всего несколько сотен килобайт. У Turbo C (без плюсов) 2.x файл tc.exe (оболочка со встроенными компилятором, линкером и отладчиком) была размером в 300 кб. И код там был далек от идеально оптимизированного, 10-15% за счет оптимизации вполне можно было выиграть.

vsb>Intellij Idea занимает несколько сотен мегабайтов и содержит в себе невообразимо больше функционала с невообразимо более сложным интерфейсом.


Я не пробовал Idea, но MS VS избыточна минимум на порядок.

vsb>Я не спорю, что можно упаковать hello-world.html в Electron, который засунуть в докер-образ и это всё засунуть в виртуалку. Накидал бессмысленных слоёв и получил из 20 байтов 20 гигабайтов. И в какой-то мере это происходит, но в целом это скорей исключение.


Исключение? Да Вы оптимист. Это, можно сказать, уже мейнстрим, в различных вариациях.

vsb>Про тот же электрон все понимают, что это неоптимальное решение


Сильно подозреваю, что это понимает лишь абсолютное меньшинство. Остальные видят, что работает, запредельных (по бюджету) ресурсов не просит, и довольны.

vsb>в какой-то момент его заменят на расшаренный движок браузера


Пока подвижек в эту сторону не видно никаких, равно как и к вынесению JS-машины из браузеров.

vsb>подключаю другую библиотеку, которой нужен тот самый метод на 20 байтов байткода и она подтягивает ту самую Guava.


Такое, в первую очередь, происходит от построения библиотек с избыточными зависимостями. Разработчики библиотек уже давно перестали рассматривать их, как набор компонент, каждая из которых должна тянуть только реально необходимые. Они тупо делают "библиотеку, как сущность", и работает она только целиком, а по частям — увы.

vsb>если взять типичное enterprise-приложение, проследить все возможные пути выполнения и посмотреть, сколько реально байткода задействовано, то скорей всего это будут вообще крохи от общего объёма поставляемого байткода в стандартной библиотеке и подключаемых библиотеках.


Не только. Изрядную долю объема добавляет и дублирующийся код. Его дублируют и на одном уровне, и на разных, и в разных библиотеках. Чем больше становится средств для повторного использования кода, тем больше дублированного кода порождают разработчики. Потому что так проще. И все чаще встречаются рекомендации "не стремитесь изолировать общий код, это сложно и опасно".

vsb>Если класс никто не трогал, то он даже с диска читаться не будет.


А что, в том же андроиде из APK извлекаются только реально используемые классы/методы? Подозреваю, что тупо загружается весь контейнер.
Re[3]: Современное ПО
От: vsb Казахстан  
Дата: 10.07.21 13:51
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>Если класс никто не трогал, то он даже с диска читаться не будет.


ЕМ>А что, в том же андроиде из APK извлекаются только реально используемые классы/методы? Подозреваю, что тупо загружается весь контейнер.


Про андроид на низком уровне я почти ничего не знаю. Там это ещё и меняется от версии к версии. Вроде сейчас идёт AOT-компиляция, т.е. байткод Dalvik при установке приложения превращается в машинный код. Там, вероятно, да, загружается весь контейнер. Но даже в этом случае загрузка это mmap файла в память, реально память используется только при первом обращении, т.е. если есть код, который не используется, то он так же в память не будет загружен. Думаю, что в Android примерно так же.
Re[5]: Современное ПО
От: vsb Казахстан  
Дата: 10.07.21 14:46
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Традиционный HW делается через printf, а это сразу же подтягивает форматные преобразования, работу с плавучкой с локалями и т.п. Но их крайне сложно будет вычистить чисто сторонним анализом, это слишком затратно.


Если мы про C++ говорим, то там std::cout. Там вроде должно быть возможно всё вычистить.
Re[4]: Современное ПО
От: imh0  
Дата: 10.07.21 15:06
Оценка:
Здравствуйте, vsb, Вы писали:

I>>Это как раз есть в С++.


vsb>Не думаю. Сколько весит статически скомпилированный hello world в С++? Когда я последний раз проверял, там была цифра в мегабайтах. При том, что реально это несколько байтов кода — вызвать write(1, "Hello world", 11). Всё остальное — ненужная шелуха.


echo "
#include <stdio.h>
void main ( )
{
   printf(\"hello world\");
}">main.c && make main && ./main || ls -l


вывод :
cc     main.c   -o main
hello world
total 24
-rwxr-xr-x 1 user user 16608 Jul 10 18:04 main
-rw-r--r-- 1 user user    65 Jul 10 18:04 main.c


16Кб
Отредактировано 10.07.2021 15:07 imh0 . Предыдущая версия .
Re[4]: Современное ПО
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 10.07.21 15:31
Оценка:
Здравствуйте, vsb, Вы писали:

I>>Это как раз есть в С++.


vsb>Не думаю. Сколько весит статически скомпилированный hello world в С++? Когда я последний раз проверял, там была цифра в мегабайтах. При том, что реально это несколько байтов кода — вызвать write(1, "Hello world", 11). Всё остальное — ненужная шелуха.


Не знаю, что ты там проверял, но в сотню другую килобайт легко можно уложить виндовое оконное приложение без внешних зависимостей
Маньяк Робокряк колесит по городу
Re[6]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 15:32
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Если мы про C++ говорим, то там std::cout.


Использование C++ само по себе не предполагает использования потоков — это просто рекомендация.

vsb>Там вроде должно быть возможно всё вычистить.


Да, если потоковые классы реализованы аккуратно, с расчетом именно на такие случае. Но десятки килобайт перестали считать еще в самом начале 2000-х.

Еще, кстати, бывают неочевидные реализации, требующие runtime-кода. Я не знаю, как реализованы потоки в унихах, а в винде для полноценной поддержки консольного вывода и перенаправления в файл процесс должен слегка менять поведение в зависимости от того, куда фактически привязан стандартный поток.
Re[3]: Современное ПО
От: sergey2b ЮАР  
Дата: 10.07.21 15:32
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, vsb, Вы писали:


vsb>>Турбопаскаль занимал несколько мегабайтов


ЕМ>Каких еще "мегабайтов"? Там было всего несколько сотен килобайт. У Turbo C (без плюсов) 2.x файл tc.exe (оболочка со встроенными компилятором, линкером и отладчиком) была размером в 300 кб. И код там был далек от идеально оптимизированного, 10-15% за счет оптимизации вполне можно было выиграть.


я с вами полностью согласен
но как постоянный пользователь tc 1.5 с 89 по 92, хотел бы уточнить
tc с ide отладчиком, библиотеками и графическими драйверами занимал 720 k

я это знаю тк у меня на работе был amstrad 1640 без hdd но двумя флоповодами на 360
а дома tandy 1000 с одним дисководом на 720

оптимизатора как такового у компилятора не было


на XT с hdd можно было откомпилировать программу для win 3.0 используя Borland 3.0
Re[5]: Современное ПО
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 10.07.21 15:33
Оценка:
Здравствуйте, imh0, Вы писали:


I>16Кб


Не корректный эксперимент. libstdc/libstdc++ скорее всего отдельно лежат, я не увидел ключиков, чтобы они статически линковались. Но в линуксах — да, они считай что часть системы
Маньяк Робокряк колесит по городу
Re[2]: Современное ПО
От: sergey2b ЮАР  
Дата: 10.07.21 15:36
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Несерьёзно. Турбопаскаль занимал несколько мегабайтов и был консольной программкой с примитивным GUI. Intellij Idea занимает несколько сотен мегабайтов и содержит в себе невообразимо больше функционала с невообразимо более сложным интерфейсом.


turbo pascal 5.5 (с нормальным OOO) с IDE и внешними утилитами
+ библиотеки
+ графические драйвера

занимал 360K и компиляция 20 тыс строк на xt 8mhz занимала меньше полминуты

те для большенства реальных задачь этого компилятора хватало
мы например с другом писали на нем эмулятор робота который мог двигаться по цеху и не сносить все вокруг
Re[6]: Современное ПО
От: vsb Казахстан  
Дата: 10.07.21 15:38
Оценка:
Здравствуйте, Marty, Вы писали:

I>>16Кб


M>в линуксах — да, они считай что часть системы


Они и в винде часть системы. Но это некорректное сравнение, у меня в федоре и Java идёт в базовой установке, что теперь, Java стала образцом минимализма?
Re[3]: Современное ПО
От: vsb Казахстан  
Дата: 10.07.21 15:40
Оценка:
Здравствуйте, sergey2b, Вы писали:

S>turbo pascal 5.5 (с нормальным OOO) с IDE и внешними утилитами

S>+ библиотеки
S>+ графические драйвера

S>занимал 360K и компиляция 20 тыс строк на xt 8mhz занимала меньше полминуты


https://winworldpc.com/product/borland-pascal/7x

14.48MB в архиве. Под турбо паскалем я имел в виду эту версию.
Re[4]: Современное ПО
От: sergey2b ЮАР  
Дата: 10.07.21 15:47
Оценка:
Здравствуйте, vsb, Вы писали:


vsb>https://winworldpc.com/product/borland-pascal/7x

vsb>14.48MB в архиве. Под турбо паскалем я имел в виду эту версию.

на скриншоте TPW 1.5 — turbo pascal for windows
это точно не досовская версия

для DOS 7.0 можно было поместить на дискету 1.44 но на XT и 286 он уже реально компилировал не быстро
я сейчас на 486 66 запускаю софт написанный на Turbo Pascal с Turbo Vision прямо видно как программа окна отрисовывает
Re[5]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 17:36
Оценка:
Здравствуйте, Marty, Вы писали:

M>в сотню другую килобайт легко можно уложить виндовое оконное приложение без внешних зависимостей


Такое приложение можно уложить в единицы килобайт, и оно даже будет делать что-нибудь полезное.
Re[4]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 17:57
Оценка:
Здравствуйте, sergey2b, Вы писали:

S>но как постоянный пользователь tc 1.5 с 89 по 92, хотел бы уточнить

S>tc с ide отладчиком, библиотеками и графическими драйверами занимал 720 k

В TC, для программирования на C, все это было необязательным. Чтобы написать программу, не использующую библиотек (например, работающую через функции DOS/BIOS), собрать, запустить и отладить ее, было достаточно одного файла tc.exe размером 290 килобайт.

S>оптимизатора как такового у компилятора не было


Был. Простенький, конечно, но со многими конструкциями хорошо справлялся.
Re[6]: Современное ПО
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 10.07.21 18:00
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>в сотню другую килобайт легко можно уложить виндовое оконное приложение без внешних зависимостей


ЕМ>Такое приложение можно уложить в единицы килобайт, и оно даже будет делать что-нибудь полезное.


Ну, я давно ничего такого не делал, не хотел соврать
Маньяк Робокряк колесит по городу
Re[4]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 18:02
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>https://winworldpc.com/product/borland-pascal/7x

vsb>14.48MB в архиве. Под турбо паскалем я имел в виду эту версию.

Так оно было очень сильно разное. Первые версии TP/TC были очень компактными и быстрыми. Затем Borland прикрутил Turbo Vision, добавил модульности, и оно очень быстро разрослось и стало сильно тормозить. Тот же TC 2.x на XT летал, а TC++ 2.x даже на AT заметно подтормаживал.
Re[5]: Современное ПО
От: sergey2b ЮАР  
Дата: 10.07.21 18:15
Оценка:
Поддержки вещественных чисел в bios нет
Графику конечно можно выводить через bios или напрямую но в моем случаи для графиков и статической картинки bgi от Боплана было достаточно

В любом случаи система была хорошей
А по какой книги вы изучали C ?
Re[3]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.07.21 20:12
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Казалось бы простое решение использовать hardlink — что бы использовать один и тот же исполняемый файл под разными именами для разных функций.


Зачем? Это же костыль для убогой парадигмы "файл есть имя команды". Стоит добавить самый легкий промежуточный уровень трансляции, и можно определять любые команды с любыми параметрами независимо от файлов, которые их исполняют.

_>Что бы не делать много мелких которые динамически подгружают dll-ку.


DLL-ек в системе должно быть много небольших, чтобы каждое приложение могло выбирать по вкусу. Ссылки на их можно объединять в более крупные DLL, и все это кэшировать.

_>С dll у C++ вообще грусть, печаль.


В каком смысле?

_>что мешает использовать сжатие например для статических библиотек


Сжатие нужно использовать после того, как библиотека сделана в правильной иерархии (функции разнесены по модулям, зависимости только объективно необходимые). В подавляющем большинстве библиотек множество неочевидных зависимостей, при запросе простых функций может подключаться бОльшая часть библиотеки.

Ну и типовые библиотеки таки должны быть в составе ОС. В винде вон, safe string functions по неизвестной причине не включены в состав системных DLL — они частично определены в заголовках SDK, частично — в его же статических библиотеках. То есть, все приложения, и системные, и сторонние, имеют свои собственные копии. То же самое — с регулярными выражениями.
Re[4]: Современное ПО
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 10.07.21 20:33
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>DLL-ек в системе должно быть много небольших, чтобы каждое приложение могло выбирать по вкусу. Ссылки на их можно объединять в более крупные DLL, и все это кэшировать.


С чего это лучше?

1) Какой-то общий код тогда выносится в отдельную DLL-ку — это дополнительный уровень косвенности при вызове, для мелочи, которая часто вызывается — это играет роль
2) Много мелких файлов занимают на диске больше места, снижают производительность при обращении к ним
3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке
Маньяк Робокряк колесит по городу
Re[7]: Современное ПО
От: sergey2b ЮАР  
Дата: 10.07.21 22:57
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

оказываеться OWL досих пор развиваеться интузиастами
Re[6]: Современное ПО
От: imh0  
Дата: 11.07.21 07:48
Оценка:
Здравствуйте, jamesq, Вы писали:

J>абсолютно неважно, разнесен ли код по нескольким DLL, или лежит в одной. один чёрт все DLL мапятся в адресное пространство процесса, и вызов функции любой из них — это просто вызов по указателю на функцию

J>и скорость этого вызова одинакова для любой DLL, да хоть и самого EXE файла.

+1

J>больше того, в Windows есть хорошее преимущество перед Linux — в Win адреса корректируются при загрузке DLL, и всё становится как родное (я знаю, очень туманно пишу. и сам туманно помню эту фишку. нет желания долго ковыряться в доках, вспоминать. посмотрите сами, если хотите). В Linux как я помню, идёт обращение через указатели, а в Win — по прямым адресам.


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

M>>2) Много мелких файлов занимают на диске больше места, снижают производительность при обращении к ним

J>это несущественно

На самом деле это ножет быт проблемой — например 10 тысяч dll в одной папаке, программа будет загружаться ну очень долго.

M>>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке

J>тоже несущественно

+1
Re[5]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.07.21 07:52
Оценка:
Здравствуйте, Marty, Вы писали:

ЕМ>>DLL-ек в системе должно быть много небольших, чтобы каждое приложение могло выбирать по вкусу. Ссылки на их можно объединять в более крупные DLL, и все это кэшировать.


M>С чего это лучше?


С того, что более адекватно распределяются функции. Например, в kernel32.dll, начиная с висты, для многих функций лежат переходники в мелкие api-ms-*.dll.

M>1) Какой-то общий код тогда выносится в отдельную DLL-ку — это дополнительный уровень косвенности при вызове, для мелочи, которая часто вызывается — это играет роль


Это играет примерно ту же роль, что и замена обычной функции на виртуальную. Заметно лишь при частоте вызовов где-то от десяти тысяч раз в секунду. Какие из функций WINAPI вызываются хотя бы тысячи раз в секунду, и насколько оптимизирован весь этот код, чтобы считать косвенность заслуживающей внимания?

M>2) Много мелких файлов занимают на диске больше места, снижают производительность при обращении к ним


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

M>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке


Опять же, это заметно лишь для очень частой загрузки. Ну и загрузить несколько десятков DLL, в каждой из которых по паре десятков функций, будет все равно дешевле, чем загрузить одну kernel32, в которой их три с лишним тысячи.
Re[6]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.07.21 08:01
Оценка:
Здравствуйте, jamesq, Вы писали:

J>абсолютно неважно, разнесен ли код по нескольким DLL, или лежит в одной. один чёрт все DLL мапятся в адресное пространство процесса, и вызов функции любой из них — это просто вызов по указателю на функцию


Это верно для независимых DLL. А тут речь об иерархии, когда есть много мелких, на десяток-другой простых функций, и "групповых", включающих переходники на них (чтобы не засорять таблицы PE-файлов клиентов сотнями мелких, иметь готовые схемы загрузки и т.п.). Хотя и в этом случае загрузчик, видя, что функция представляет собой простой переходник, может прослеживать цепочку ссылок и подставлять финальный адрес в таблицу DLL самого верхнего уровня. Чуть больше затрат при загрузке, зато никаких издержек при работе.

J>больше того, в Windows есть хорошее преимущество перед Linux — в Win адреса корректируются при загрузке DLL, и всё становится как родное (я знаю, очень туманно пишу. и сам туманно помню эту фишку. нет желания долго ковыряться в доках, вспоминать. посмотрите сами, если хотите). В Linux как я помню, идёт обращение через указатели, а в Win — по прямым адресам.


Типовой вызов функции из DLL — косвенный по таблице указателей. При загрузке корректируются указатели в таблице.
Re[6]: Современное ПО
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 11.07.21 11:27
Оценка:
Здравствуйте, jamesq, Вы писали:

M>>1) Какой-то общий код тогда выносится в отдельную DLL-ку — это дополнительный уровень косвенности при вызове, для мелочи, которая часто вызывается — это играет роль

J>что-что, простите? ерунду не пиши, пожалуйста.

Ты бы тоже не писал бы ерунду, так-то


J>абсолютно неважно, разнесен ли код по нескольким DLL, или лежит в одной. один чёрт все DLL мапятся в адресное пространство процесса, и вызов функции любой из них — это просто вызов по указателю на функцию


Важно. В случае крупных DLL общий код вообще может не торчать наружу, и может быть заинлайнен или еще как-то соптимизирован. В случае крупных DLL имеет смысл выставлять наружу только вызовы высокоуровневнего АПИ, которые делаются не слишком часто и косвенные расходы на которые не критичны


J>и скорость этого вызова одинакова для любой DLL, да хоть и самого EXE файла.

J>больше того, в Windows есть хорошее преимущество перед Linux — в Win адреса корректируются при загрузке DLL, и всё становится как родное (я знаю, очень туманно пишу. и сам туманно помню эту фишку. нет желания долго ковыряться в доках, вспоминать. посмотрите сами, если хотите). В Linux как я помню, идёт обращение через указатели, а в Win — по прямым адресам.

Хз, как там в линупсе. В винде — это не так. Вызовы идут через таблицу импорта



M>>2) Много мелких файлов занимают на диске больше места, снижают производительность при обращении к ним

J>это несущественно

А ты проверял, чтобы так утверждать?


M>>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке

J>тоже несущественно

А ты проверял, чтобы так утверждать?
Маньяк Робокряк колесит по городу
Re[6]: Современное ПО
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 11.07.21 12:16
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


M>>С чего это лучше?


ЕМ>С того, что более адекватно распределяются функции. Например, в kernel32.dll, начиная с висты, для многих функций лежат переходники в мелкие api-ms-*.dll.


Подозреваю, что это началось, когда начали 64 бита присовывать, всякие windows on windows 64 и пр загогулины.



M>>1) Какой-то общий код тогда выносится в отдельную DLL-ку — это дополнительный уровень косвенности при вызове, для мелочи, которая часто вызывается — это играет роль


ЕМ>Это играет примерно ту же роль, что и замена обычной функции на виртуальную.


Да


ЕМ>Заметно лишь при частоте вызовов где-то от десяти тысяч раз в секунду. Какие из функций WINAPI вызываются хотя бы тысячи раз в секунду, и насколько оптимизирован весь этот код, чтобы считать косвенность заслуживающей внимания?


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


M>>2) Много мелких файлов занимают на диске больше места, снижают производительность при обращении к ним


ЕМ>Я Вас умоляю. В винде полтораста тысяч файлов, минимум треть которых никогда не используется в типичной системе. Кто вообще заметит еще даже несколько тысяч, хотя и сотни-другой было бы достаточно по уши?


Ну, не знаю. Перечисление файлов в каталоге, где их очень много, занимает заметное время. А копирование кучи мелких файлов на флешку вместо одного большого — явно показывает, что у кучи файлов есть проблемы с производительностью


M>>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке


ЕМ>Опять же, это заметно лишь для очень частой загрузки. Ну и загрузить несколько десятков DLL, в каждой из которых по паре десятков функций, будет все равно дешевле, чем загрузить одну kernel32, в которой их три с лишним тысячи.


Разделение на кучи мелких DLL предполагает, в числе прочего, что более низкоуровневые API будут торчать из них. Ну, и загрузка нескольких DLL вряд ли дешевле загрузки одной, пусть и с большим числом функций
Маньяк Робокряк колесит по городу
Re: Современное ПО
От: Kolesiki  
Дата: 11.07.21 12:59
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


_>https://youtu.be/geY5cbImVwc?t=1300


Зачем ЗДЕСЬ этот ютюб?! Мы что, каждый должны полезть и тратиьт время на чьё-то растекание мыслью по древу? Напиши сюда тезисно, что именно ты хочешь открыть этому миру. Особенно то НОВОЕ, чего мы точно не знаем.
Re[2]: Современное ПО
От: kov_serg Россия  
Дата: 11.07.21 13:17
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Зачем ЗДЕСЬ этот ютюб?! Мы что, каждый должны полезть и тратиьт время на чьё-то растекание мыслью по древу? Напиши сюда тезисно, что именно ты хочешь открыть этому миру. Особенно то НОВОЕ, чего мы точно не знаем.

Тезисно — мы все умрём.
Re[7]: Современное ПО
От: Sergei I. Gorelkin Россия  
Дата: 11.07.21 13:44
Оценка:
Здравствуйте, Marty, Вы писали:

M>Здравствуйте, Евгений Музыченко, Вы писали:



M>>>С чего это лучше?


ЕМ>>С того, что более адекватно распределяются функции. Например, в kernel32.dll, начиная с висты, для многих функций лежат переходники в мелкие api-ms-*.dll.


M>Подозреваю, что это началось, когда начали 64 бита присовывать, всякие windows on windows 64 и пр загогулины.


Это началось, когда началось внедрение UWP. По крайней мере, на Windows 7 этих мелких dll изначально не было, а появились они примерно в одно время с телеметрией, когда уже вышла Windows 10.
И в этих мелких dll (опять же, у меня на Windows 7) нет кода, они сами проксируют вызовы куда-то еще. Кроме того, "современный софт" (у меня навскидку: Firefox, Thunderbird, Viber, DB Browse for SQLite, CPPCheck) зачем-то таскает все эти api-ms-*.dll с собой, хотя казалось бы, должен использовать системные.

Как я узнал, когда пытался выяснить причину таких изменений, целью разделения является исключительно огораживание API, чтобы UWP приложения не видели того, чего им видеть не положено. Предполагается, что разные редакции Windows будут иметь разные наборы этих dll, формирующие APISET-ы. Никакой оптимизации скорости загрузки там не подразумевается.



M>>>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке


ЕМ>>Опять же, это заметно лишь для очень частой загрузки. Ну и загрузить несколько десятков DLL, в каждой из которых по паре десятков функций, будет все равно дешевле, чем загрузить одну kernel32, в которой их три с лишним тысячи.


M>Разделение на кучи мелких DLL предполагает, в числе прочего, что более низкоуровневые API будут торчать из них. Ну, и загрузка нескольких DLL вряд ли дешевле загрузки одной, пусть и с большим числом функций


Время при загрузке модуля тратится только на поиск тех функций, которые есть в таблицах импорта вызывающих модулей. Конечно, если тупо использовать линейный поиск, то загрузка модуля с большим количеством экспортируемых функций займет больше времени, чем модуля с малым числом экспортов. Но линейный поиск вряд ли используется в современных ОС; в ELF модулях предусмотрена секция с хэш-таблицей имен, в PE модулях есть механизм ordinal hint, и в любом случае загрузчик может создать хэш на ходу.
Re[8]: Современное ПО
От: ути-пути Россия  
Дата: 11.07.21 18:54
Оценка:
Здравствуйте, sergey2b, Вы писали:

S>оказываеться OWL досих пор развиваеться интузиастами


Прикольно, я на ней что-то даже писал. А еще заметил, sourceforge немного жив
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[9]: Современное ПО
От: sergey2b ЮАР  
Дата: 11.07.21 19:03
Оценка:
Здравствуйте, ути-пути, Вы писали:

УП>Здравствуйте, sergey2b, Вы писали:


S>>оказываеться OWL досих пор развиваеться интузиастами


УП>Прикольно, я на ней что-то даже писал. А еще заметил, sourceforge немного жив


Я на си совсем немного писал c owl
Зато на tpw много тк он позволял на 386 нормально программироваться доя win
Re[7]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.07.21 20:39
Оценка:
Здравствуйте, Marty, Вы писали:

ЕМ>>Например, в kernel32.dll, начиная с висты, для многих функций лежат переходники в мелкие api-ms-*.dll.


M>Подозреваю, что это началось, когда начали 64 бита присовывать


Нет, в 64-разрядном 2k3 Server все это есть, но api-ms-*.dll нет.

M>Я так понял, ты вообще всё предлагаешь порезать в мелкую окрошку.


Не то, чтобы совсем мелкую, но тысячи функций в одной DLL — это чересчур. Особенно на фоне того, что многих нужных функций в системных DLL нет вообще, каждый тянет свои.

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


В подавляющем большинстве системных вызовов столько работы, что добавление даже десятка дополнительных команд будет совершенно незаметно. А при иерархии добавится меньше десятка. Ну и я ж подчеркнул, что загрузчик мог бы корректировать переходники в DLL более высокого уровня на прямые адреса в DLL низкого уровня.

M>Перечисление файлов в каталоге, где их очень много, занимает заметное время.


MS это совершенно не парит, в каждую новую версию она добавляет их по нескольку тысяч, большинство из которых в типовой системе не используется. А грамотно организованная структура DLL эффективно использовалась бы большинством приложений.

M>А копирование кучи мелких файлов на флешку вместо одного большого


Это потому, что на флешках большой размер страницы (8-16 кб), и сами они, кроме самых скоростных, гораздо медленнее даже тормозных HDD. На подавляющем большинстве томов NTFS гранулярность 4 кб.

M>>>3) С тех пор, как DLL-ки перестали загружать по их адресам, а случайно назначают адрес в каждом процессе — дополнительная работа при загрузке


ЕМ>>Опять же, это заметно лишь для очень частой загрузки. Ну и загрузить несколько десятков DLL, в каждой из которых по паре десятков функций, будет все равно дешевле, чем загрузить одну kernel32, в которой их три с лишним тысячи.


M>Разделение на кучи мелких DLL предполагает, в числе прочего, что более низкоуровневые API будут торчать из них. Ну, и загрузка нескольких DLL вряд ли дешевле загрузки одной, пусть и с большим числом функций


Если грамотно разделить структуру, то процессу, импортирующему сто функций, загрузится триста или пятьсот, а не три тысячи. Экономия на порядок не нужна?
Re[8]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.07.21 20:50
Оценка:
Здравствуйте, Sergei I. Gorelkin, Вы писали:

M>>Подозреваю, что это началось, когда начали 64 бита присовывать, всякие windows on windows 64 и пр загогулины.


SIG>Это началось, когда началось внедрение UWP. По крайней мере, на Windows 7 этих мелких dll изначально не было


Были. Они появились в висте.

SIG>И в этих мелких dll (опять же, у меня на Windows 7) нет кода, они сами проксируют вызовы куда-то еще.


Ага.

SIG>Кроме того, "современный софт" (у меня навскидку: Firefox, Thunderbird, Viber, DB Browse for SQLite, CPPCheck) зачем-то таскает все эти api-ms-*.dll с собой, хотя казалось бы, должен использовать системные.


Сейчас, по-моему, вообще все таскают с собой. "Шоб було".

SIG>целью разделения является исключительно огораживание API, чтобы UWP приложения не видели того, чего им видеть не положено. Предполагается, что разные редакции Windows будут иметь разные наборы этих dll, формирующие APISET-ы.


А что, тоже хорошая идея.

SIG>Никакой оптимизации скорости загрузки там не подразумевается.


Скорость вроде и так особо никого не парит. Я только читал о том, что кого-то напрягает, а сам даже на ранних версиях никогда не замечал тормозов.
Re[3]: Современное ПО
От: TheKnight  
Дата: 11.07.21 22:44
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А что, в том же андроиде из APK извлекаются только реально используемые классы/методы? Подозреваю, что тупо загружается весь контейнер.


Насколько я помню, стандартный подход при разработке Android приложений — это использование ProGuard, который с одной стороны обфусцирует приложение, а с другой вырезает ненужное. Однако, его надо уметь конфигурировать, иначе в рантайме разлетится.
Re[4]: Современное ПО
От: wl. Россия  
Дата: 12.07.21 02:32
Оценка:
Здравствуйте, TheKnight, Вы писали:

TK>Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>>А что, в том же андроиде из APK извлекаются только реально используемые классы/методы? Подозреваю, что тупо загружается весь контейнер.


TK>Насколько я помню, стандартный подход при разработке Android приложений — это использование ProGuard, который с одной стороны обфусцирует приложение, а с другой вырезает ненужное. Однако, его надо уметь конфигурировать, иначе в рантайме разлетится.


Java там вообще только при первом запуске приложения, во время которого происходит компиляция в native. Встроенные библиотеки тоже в виде нативных эльфов
Re: Современное ПО
От: student__  
Дата: 12.07.21 13:27
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


_>https://youtu.be/geY5cbImVwc?t=1300


Нет. Добрышевский говорит о том, что нейронов и синапов примерно столько же. В современном ПО гораздо больше логических компонент, чем в древнем. Аналогия совершенно неадекватная.
Re[2]: Современное ПО
От: IT Россия linq2db.com
Дата: 12.07.21 15:46
Оценка:
Здравствуйте, imh0, Вы писали:

I>https://tv.rbc.ru/archive/ekskluziv/60e2f2ce2ae59602f173f18d

I>Надо смотреть с 18:24, до этого просто фигня.
I>То есть я к тому, что надо раделять программистов и "эфективных пьющих менеджеров" — Последние аж даже воинстующее, хотят "других" программистов, которые не хоят так делать )

Всё верно. Берём талантливого инженера. Добавляем ему великолепный комуникейшин скил. Немного умения управлять людьми. И выгоняем вот такого манагера нахрен. Он больше нам не нужен.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Современное ПО
От: KRT  
Дата: 12.07.21 15:58
Оценка:
Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>Здравствуйте, Marty, Вы писали:


M>>Подозреваю, что это началось, когда начали 64 бита присовывать, всякие windows on windows 64 и пр загогулины.


SIG>Это началось, когда началось внедрение UWP. По крайней мере, на Windows 7 этих мелких dll изначально не было, а появились они примерно в одно время с телеметрией, когда уже вышла Windows 10.


Это началось намного раньше. См. MinWin
Re: Современное ПО
От: Ночной Смотрящий Россия  
Дата: 13.07.21 09:40
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


Ага, как обычно, простое и неверное. Доказательства по аналогии — они всегда такие.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Современное ПО
От: Ночной Смотрящий Россия  
Дата: 13.07.21 09:40
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Зачем ЗДЕСЬ этот ютюб?! Мы что, каждый должны полезть и тратиьт время на чьё-то растекание мыслью по древу? Напиши сюда тезисно, что именно ты хочешь открыть этому миру. Особенно то НОВОЕ, чего мы точно не знаем.


Широко известный в узких кругах биолог Дробышевский, опираясь на свое хорошее, хотя и несколько нетрадиционное знание процессов эволюции мозга и на свое очень плохое знание современных принципов разработки софта проводит между этими процессами параллели и делает далеко идущие выводы.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Современное ПО
От: kov_serg Россия  
Дата: 13.07.21 12:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ага, как обычно, простое и неверное. Доказательства по аналогии — они всегда такие.

То есть наличие естественного отбора в софте вы отрицаете. Текущее положение и вектор движения определяется иными факторами.
Методы подобия часто применяются в инженерной практике
Re[7]: Современное ПО
От: Privalov  
Дата: 13.07.21 13:31
Оценка:
Здравствуйте, Marty, Вы писали:

M>Ну, не знаю. Перечисление файлов в каталоге, где их очень много, занимает заметное время.


Я нарывался на тормоза с перечислением файлов, когда в именах файлов встречаются всякие странные символы типа знака %. В этом случае тормоза будут, даже если файлов не очень много. А если имена в порядке, то и 10000 файлов перечисляются быстро.
Re[3]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 13.07.21 13:42
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Широко известный в узких кругах биолог Дробышевский, опираясь на свое хорошее, хотя и несколько нетрадиционное знание процессов эволюции мозга и на свое очень плохое знание современных принципов разработки софта проводит между этими процессами параллели и делает далеко идущие выводы.


Совершенно правильные выводы, надо заметить.
Re[2]: Современное ПО
От: reson Россия  
Дата: 13.07.21 14:45
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Ну и ещё одна большая проблема, если говорить про Java, которую я по крайней мере знаю ...

Это потому, что вы смотрите на старый Enterprise.
Например, современный ява фреймворк Quarkus упрощенно делает:
1. На этапе компиляции анализирует код, исключает неиспользуемые части, вырубает по-умолчанию reflection (включать надо явно), проводит статическую инициализацию, компилирует в нативный код, сохраняет инициализированные объекты в виде образов памяти в исполняемый файл.
2. При запуске грузит код и инициализированные объекты, проводит рунтайм инициализацию.

Таким образом исполняемый файл становится сильно меньше, запускается и работает быстрее, памяти жрет тоже немного.

vsb>Т.е. если взять типичное enterprise-приложение, проследить все возможные пути выполнения и посмотреть, сколько реально байткода задействовано, то скорей всего это будут вообще крохи от общего объёма поставляемого байткода в стандартной библиотеке и подключаемых библиотеках. А если ещё вспомнить про моду микро-сервисов, то там ситуация ещё хуже.


vsb>Но при всём при этом это не является, на самом деле, такой уж большой проблемой. Оно занимает место на диске, да и только. Если класс никто не трогал, то он даже с диска читаться не будет. Если метод никто не вызывает, то JIT на него вызываться не будет. Т.е. есть проблемы и они частично уже решены. Если не вглядываться, то да, беда, 10 метров жаваскрипта грузят текста 300 байт. А если вглядеться, может быть и не такая уж беда.


Именно это и делают в Quarkus Bytecode Recorders, которые исполняют и записывают во время компиляции код, который реально выполнился, а остальное выкидывают.

vsb>Но соглашусь, что было бы неплохо, если бы языки проектировали из расчёта возможности максимальной оптимизации и выбрасывания неиспользуемого кода. Не только на уровне классов и методов, но и на уровне отдельных блоков кода, про которые можно доказать, что они никогда не вызываются в текущей программе.


Уже.

Но писать расширения (библиотеки, которые работают на системном уровне) становится сложнее, так как разработчик должен сам разделить код по времени работы: во время компиляции и рунтайм. Предметный код при этом пишется так же, как будто нет такой внутренней сложности.
Quarkus
Re[2]: Современное ПО
От: ArtDenis Россия  
Дата: 13.07.21 16:17
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Зачем ЗДЕСЬ этот ютюб?! Мы что, каждый должны полезть и тратиьт время на чьё-то растекание мыслью по древу? Напиши сюда тезисно, что именно ты хочешь открыть этому миру. Особенно то НОВОЕ, чего мы точно не знаем.


Там всего несколько минут надо послушать. Сказано кратно и по делу )
http://ufa-darts.ru/ — дартс-лига Уфы
Re[3]: Современное ПО
От: vsb Казахстан  
Дата: 13.07.21 16:33
Оценка:
Здравствуйте, reson, Вы писали:

vsb>>Ну и ещё одна большая проблема, если говорить про Java, которую я по крайней мере знаю ...

R>Это потому, что вы смотрите на старый Enterprise.
R>Например, современный ява фреймворк Quarkus упрощенно делает:
R>1. На этапе компиляции анализирует код, исключает неиспользуемые части, вырубает по-умолчанию reflection (включать надо явно), проводит статическую инициализацию, компилирует в нативный код, сохраняет инициализированные объекты в виде образов памяти в исполняемый файл.
R>2. При запуске грузит код и инициализированные объекты, проводит рунтайм инициализацию.

R>Таким образом исполняемый файл становится сильно меньше, запускается и работает быстрее, памяти жрет тоже немного.


А почему это делает некий "фреймворк"? Я, конечно, понимаю, что вероятно речь идёт о graal, но всё же. Ну и добавлю, что всё это счастье с нормальной производительностью платное.


vsb>>Но соглашусь, что было бы неплохо, если бы языки проектировали из расчёта возможности максимальной оптимизации и выбрасывания неиспользуемого кода. Не только на уровне классов и методов, но и на уровне отдельных блоков кода, про которые можно доказать, что они никогда не вызываются в текущей программе.


R>Уже.


Сколько килобайтов весит хелло ворлд на этом кваркусе?

PS спасибо за информацию, погляжу на него, заинтересовали, если отбросить сарказм.
Re[4]: Современное ПО
От: kov_serg Россия  
Дата: 13.07.21 17:16
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, goto, Вы писали:


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


ЕМ>Его и просто более аккуратно делают, ибо и размер кристалла (более компактных кристаллов можно банально больше нарезать с одной пластины), и энергопотребление, и тепловыделение, и всяческие наводки. Ни от кого не слышал, чтобы для разработки хотелось взять микросхему десяти- или двадцатилетней давности. Наоборот, чем новее микросхема — тем, как правило, компактнее, экономичнее, надежнее (у многих куча встроенных защит — спалить почти невозможно), удобнее в применении, и вместе с тем — дешевле.

Такая ситуация именно по тому что есть физические ограничения, и как в софте всё очень не бесплатно и постоянно приходится искать баланс, а конкуренция заставляет идти на пределе. В софте такого направляющего воздействия нет и получаем то что имеем.
Запускаешь android studio оно тебе такое увас идее уже очень старая почти недельной давности — обновимся. Ну ок. Обновляет, о еще тут плагины пообновлялись. Обновить — да. И грайдл надо новый — давай. Потом, ой едрёна вошь тут половида деприкатед, в новом грайдл так нельзя — правь. А еще же надо обновить зависимости проекта. Обновляем, падает не собирается, материться данный компонент раздели на несколько (для вашего удобства) и теперь вот это нельзя, только иначе. Простой запуск превращается в квест, который нужен как собаке колесо. При этом памяти хавает больше чем браузер

ЕМ>С софтом же ситуация обратная — хочется до последнего сидеть на старом, который имеет вменяемые размеры, при работе не дает ощутимых задержек, и лицензия на который получена навсегда, а не на время.

Да поэтому изо всех сил пытаются палки в колёса ставить. Новые компиляторы не поддерживают старые ос, новое по требует библиотеки, которых не в старых ос. PHP,node,cygwin,msvc не ускается в winxp, blender требует win10 и не пускается в win7, office требует только свежую редакцию win10, adobe xd — только десятка. visual studio code не пускается на ubuntu 14.04 без бубнов и т.п. win11 требует только новые поколения процов.
Если opensource можно с трудом, но пересобрать под целевую платформу, то с закрытым софтом только виртуалка. Ну а когда браузеры скажут только новая винда или никаких youtube, twiter, vk и tiktiok-ов, то хомячки пойдут выкидывать свои компутеры ибо ни на госуслуги не зайти, ни в налоговую, ни кркод получить... Светлое будущее одним словом.
Тенденция к cжиганию мостов усиливается с каждым днём.
Re[4]: Современное ПО
От: Ночной Смотрящий Россия  
Дата: 13.07.21 19:19
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Совершенно правильные выводы, надо заметить.


Правильные они потому что тебе так хочется? Маловато для обоснования.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Современное ПО
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 13.07.21 19:44
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Новые компиляторы не поддерживают старые ос


Что до винды, то VC++ из VS 2019 вполне себе собирает под Win95. Вообще, VC++ (не путать со студией) — один из немногих до сих пор качественных продуктов MS.

_>Ну а когда браузеры скажут только новая винда или никаких youtube, twiter, vk и tiktiok-ов, то хомячки пойдут выкидывать свои компутеры ибо ни на госуслуги не зайти, ни в налоговую, ни кркод получить...


Если ГНИВЦ (который клепает софт для ГосУслуг, ФНС и прочего) перестанет поддерживать вменяемые версии браузеров, можно попробовать вменить им необоснованное затруднение доступа к государственным ресурсам. Подобрать подходящие положения закона и закидать жалобами контролирующие органы. Где-нибудь на третьей сотне жалоб они что-нибудь родят.
Re[4]: Современное ПО
От: kov_serg Россия  
Дата: 13.07.21 20:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Методы подобия часто применяются в инженерной практике

НС>Для индукции, а не для дедукции, как это делаешь ты.
А причем здесь дедукция и индукция?
Методы подобия основываются на похожести физических законов которым подчиняется система.
Re[4]: Современное ПО
От: goto Россия  
Дата: 13.07.21 21:44
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Его и просто более аккуратно делают, ибо и размер кристалла (более компактных кристаллов можно банально больше нарезать с одной пластины), и энергопотребление, и тепловыделение, и всяческие наводки. Ни от кого не слышал, чтобы для разработки хотелось взять микросхему десяти- или двадцатилетней давности. Наоборот, чем новее микросхема — тем, как правило, компактнее, экономичнее, надежнее (у многих куча встроенных защит — спалить почти невозможно), удобнее в применении, и вместе с тем — дешевле.


Да, от друзей электронщиков слышал подобное.

У железячников больше ответсвенности, поэтому там, видимо, работают на порядок более квалифицированные люди. Софтостроитель может впарить клиенту сырого уродца со словами: скоро пропатчим. Железячник не может. Производитель софта не несет юридической ответственности за косяки (не знаю, как с этим у железячников). Это и прочее понятно и даже банально, просто для меня тут 2 интересные темы.

Околофилосоское: софт в определенном смыле оторван от реальности, и как всё, имеющее такое свойство, имеет потенциал мигрировать в задницу. Наверное, здесь можно говорить о "недостаточно адекватных", "недостаточно жестких" обратных связях. У железячников очень четкие и жесткие обратные связи.

Еще интересно, не намечаются ли подобные тенденции у железячников?

ЕМ>С софтом же ситуация обратная — хочется до последнего сидеть на старом, который имеет вменяемые размеры, при работе не дает ощутимых задержек, и лицензия на который получена навсегда, а не на время.


Это да. Год назад собирал проект под вин ХР, заказчик сидит на ней и слезать желания не имеет. Я его понимаю.

Просматривал анонсы Вин11. На первом месте и самая обсуждаемая новость — кнопка Старт в середине, а не слева. Пипец как интересно.
Re[5]: Современное ПО
От: Ночной Смотрящий Россия  
Дата: 14.07.21 05:10
Оценка:
Здравствуйте, kov_serg, Вы писали:

НС>>Для индукции, а не для дедукции, как это делаешь ты.

_>А причем здесь дедукция и индукция?

При том что они описывают область применимости аналогий.

_>Методы подобия основываются на похожести физических законов которым подчиняется система.


Еще раз, такие методы допустимы для индукции или для иллюстрации, и логически некорректны для дедукции. А ты в этом топике, в отличие от Дробышевского, занялся именно последним.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Современное ПО
От: Skorodum Россия  
Дата: 14.07.21 07:21
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>А решение главной задачи человечества: энергообеспечения

Вот хороший пример ущербности инженерного образования.
Re[4]: Современное ПО
От: kov_serg Россия  
Дата: 14.07.21 10:38
Оценка:
Здравствуйте, Skorodum, Вы писали:

_>>А решение главной задачи человечества: энергообеспечения

S>Вот хороший пример ущербности инженерного образования.
Какие замечательные ничем не обоснованные слова. Если вы не обеспечите 2кВт на человека то вас ждёт каменный век и войны за обычную воду
Re[5]: Современное ПО
От: Skorodum Россия  
Дата: 14.07.21 12:06
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Какие замечательные ничем не обоснованные слова. Если вы не обеспечите 2кВт на человека то вас ждёт каменный век и войны за обычную воду

Если вы обеспечите хоть 100кВт на человека войны никуда не денутся.
Re[6]: Современное ПО
От: goto Россия  
Дата: 14.07.21 15:37
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Железячники тоже любят обновлять прошивки. В том же телефоне, помимо основной прошивки с ОС, есть еще куча — в радиомодуле, контроллере питания, экране, датчике касания и т.п. Некоторые перешиваются спецсофтом, остальные — спецоборудованием.


Речь была о железном железе — от CPU до хоть даже разводки платы, которые не перепрошьешь. Накатывание прошивки в какое-то место, конечно, может исправлять некоторые чисто железячные косяки, но все же.

ЕМ>Они давно наметились — даже относительно простые схемы, которые когда-то делались на чистой логике с обратными связями, часто делают на микроконтроллерах, хотя бы и простейших. Но это уже на втором и более высоких уровнях, когда для схемы берутся готовые компоненты. Когда делают кристалл, все равно проще использовать логику (обычную или ПЛМ).


Интересно. Тут тоже появляется потенциал для "отвязки от реальности".

Здесь есть почва для размышлений о свободе. Свобода понимается и реализуется каждым по-своему. Если взять свободу в массовом шаблонном и банальном понимании — как отсутствие внешних ограничений, то она ведет к статистической деградации. Это касается любой области массовой деятельности, инженерия или, допустим, та же политика здесь — частные случаи.

При наличии жестких положительных и отрицательных обратных связей субъект либо как-то следует им, либо вылетает из потока (что не обязательно значит "плохо" или "хорошо" само по себе). При отсутствии связей ("свободе" в кавычках) массовые процессы, видимо, всегда мигрируют в сторону "Дома-2".

Если говорить об свободе индивидуальной, то жесткие обратные свзяи воспитывают хорошего свободного инженера, котрый имеет внутреннюю осознанную ответственность и квалификацию, позволяющую оптимизировать, где нужно, и не впадать в перфекционизм, где не нужно. И т.п. А негодного инженера жесткие связи отфильтровывают, он не доминирует. Статистически. Не только инженер.
Re: Современное ПО
От: kov_serg Россия  
Дата: 15.07.21 08:48
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


Windows 11 только для "нормалных" пацанов, а для остальных:

Встречайте Windows 365
Re[7]: Современное ПО
От: Skorodum Россия  
Дата: 15.07.21 09:47
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Вы делаете не првильные логические выводы если из A следует B, то из B может не следовать A.

Тут вообще нет логики, т.к. ваш исходный посыл совершенно неверен. Технический прогресс ортогонален желанию человеков убивать себе подобных.
Re[4]: Современное ПО
От: goto Россия  
Дата: 17.07.21 22:43
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>14.48MB в архиве. Под турбо паскалем я имел в виду эту версию.


Тогда где там примитивный UI и консоль(с)?

Это BorlandPascal, а не Турбо — другая линейка продуктов, более поздняя, с другим названием. А то можно и Дельфи к ТурбоПаскалю отнести.
Re[5]: Современное ПО
От: vsb Казахстан  
Дата: 17.07.21 23:25
Оценка:
Здравствуйте, goto, Вы писали:

vsb>>14.48MB в архиве. Под турбо паскалем я имел в виду эту версию.


G>Тогда где там примитивный UI и консоль(с)?


bp.exe вроде или что-то похожее.

G>Это BorlandPascal, а не Турбо — другая линейка продуктов, более поздняя, с другим названием. А то можно и Дельфи к ТурбоПаскалю отнести.


Не знаю, там всё намешано было.
Re: Современное ПО
От: Блудов Павел Россия  
Дата: 28.08.21 18:23
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Простое объяснение почему всё так как есть


Количество нейронов у попугайчика +- такое же как у человека

Идём в Википедию и видим там:

Название животного Количество нейронов
Волнистый попугайчик 149 000 000
Человек разумный 16 000 000 000
Дальше можно не смотреть.
Re[2]: Современное ПО
От: kov_serg Россия  
Дата: 28.08.21 18:52
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

БП>Дальше можно не смотреть.

Вы внимательней смотрите

Самыми «мозговитыми» оказались попугаи и певчие птицы: у них количество нейронов в паллиуме варьирует от 227 млн до 3,14 млрд и от 136 млн до 2,17 млрд, соответственно. Это вдвое больше, чем у приматов, имеющих мозг той же массы, и вчетверо больше, чем у грызунов.

 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.