IT в России и мире в реалиях мирового кризиса

Цитата: AndreyK-AV от 08.02.2022 22:51:14
Дональд Кнут  "Искусство программирования", на сегодня уже 4 тома....
Гениальная книга, вроде об программировании как искусстве, но в итоге ведёт программирование в категорию высокотехнологичных инженерных дисциплин....

Очень хорошая. Особенно второй том, получисленные алгоритмы.
Человек, который полностью (по факту на всю просматриваемую перспективу) закрыл проблему верстки естественно-научной, и не только, литературы.

Цитата: Поверонов от 08.02.2022 23:52:21Извините эффективность порядка вложения циклов при SQL запросе определяется не столько схемой сколько статистикой распределения данных по находящимся в распоряжении индексам ( execution plan ) А статистика вещь сугубо динамическая изменяющаяся во времени - то что было оптимально месяц назад сегодня может стать уже по-другому в зависимости от накопленных за это время данных в базе. Программист не должен каждый месяц переделывать порядок циклов в запросе ( вообще говоря - во всех запросах ) если конечно ему больше нечем заняться

Я не о "порядке вложения циклов при SQL запросе" пытался сказать, а о том, что (оракле считает точно так же), в случае статической схемы данных и в отсутствие крысиных гонок за рынком имеет смысл программить не в SQL, а прямо в ISAM. Именно по этой причине они и купили BerkeleyDB, которая тогда и сегодня является одной из лучших реализаций ISAM.
Во всех реализациях SQL всегда  транслируется в т\у или иную группу примитивов ISAM. Альтернативы тут нет – SQL построен поверх ISAM. Типа, как бейсик поверх ассемблера.

Цитата: mrt789 от 09.02.2022 01:08:21Простыми словами: если во внутренний фор из статьи добавить банальный вывод в консоль, то широкой команде и аппаратным циклам придет пушной зверек, потому что это 100% системный вызов, который еще неизвестно чего будет делать и куда выводить. Сначала да, там будет printf, который можно заинлайнить, но дальше уже будет write.

Никто во внутрений ("вычислительный") for никогда не вставляет ни одной функции, которая может быть прервана сигналом, отличным от сигнала, безусловно завершающего процесс (TERM или KILL, например). Мало того, если нужно во "внутреннем" for (я так понимаю, что это, типа "реалтайм" for?) что-то попросить у системы, то это всегда асинхронное и внутри for результаты этого вызова не нужны. А если вдруг оказывется. что таки нужны, имеет смысл пересмотреть постановку задачи.
На самом деле во "внутренние" for в приложениях, которые взаимодействуют с пользователями, никто никогда даже не вставляет функций, которые не могут быть реально inline, т.е. определены в отдельно компилируемых единицах трансляции. Все, что выполняется внутри Вашего for, должно пристутствовать в Вашем исходном модуле, либо оно должно быть функцией из стандартной библиотеки с (не c++, а именно c), а библиотека должна линковаться статически.

Цитата: adolfus от 12.02.2022 01:28:41Никто во внутрений ("вычислительный") for никогда не вставляет ни одной функции, которая может быть прервана сигналом, отличным от сигнала, безусловно завершающего процесс (TERM или KILL, например). Мало того, если нужно во "внутреннем" for (я так понимаю, что это, типа "реалтайм" for?) что-то попросить у системы, то это всегда асинхронное и внутри for результаты этого вызова не нужны. А если вдруг оказывется. что таки нужны, имеет смысл пересмотреть постановку задачи.
На самом деле во "внутренние" for в приложениях, которые взаимодействуют с пользователями, никто никогда даже не вставляет функций, которые не могут быть реально inline, т.е. определены в отдельно компилируемых единицах трансляции. Все, что выполняется внутри Вашего for, должно пристутствовать в Вашем исходном модуле, либо оно должно быть функцией из стандартной библиотеки с (не c++, а именно c), а библиотека должна линковаться статически.

Не спорю, просто на всем, что не укладывается в это, эльбрус с вливом будет демонстрировать производительность в десятки процентов от заявленной.
Что он и делает. Без возможности частично выправить ситуацию за счет "суперскалярности" с предсказанием и спекулятивным исполнением.

Цитата"внутреннем" for (я так понимаю, что это, типа "реалтайм" for?)

это из  исходной статьи, там был код с двумя вложенными циклами

Цитата: mrt789 от 12.02.2022 16:53:20Не спорю, просто на всем, что не укладывается в это, эльбрус с вливом будет демонстрировать производительность в десятки процентов от заявленной.
Что он и делает. Без возможности частично выправить ситуацию за счет "суперскалярности" с предсказанием и спекулятивным исполнением.

Цитата"внутреннем" for (я так понимаю, что это, типа "реалтайм" for?)

это из  исходной статьи, там был код с двумя вложенными циклами

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

Цитата: Поверонов от 12.02.2022 18:05:13Вообще-то непонятно почему поток инструкций процессору должен оптимизировать сам процессор, а не компилятор, который имеет достаточную информацию о ветвлении логики команд. Или это эффект мультизадачности где последовательность команд процессору определяется не программной логикой, а случайно переключаемым контекстом процессов ? Но хотя бы внутри отдельного процесса можно постараться оптимизировать поток инструкций на стадии компиляции

Велком ту зе реал ворлд, Нео.
Потому что на самом деле компилятор не имеет этой информации. По нескольким причинам:
1. Компилятор видит только, что собирает. Это следствие деления на прикладное ПО и системное, в экзешнике который вы скомпилируете, не будет кусков ядра ОС, на работу с которым он рассчитан. И при этом у вас получится исполняемый файл, который будет запускаться и работать с сетью на десятке разных машин с разным железом.
2. Ну и наконец, ветвление может зависеть от какого-то условия, которое будет или не будет только рантайме - ввод/вывод, сеть, etc. Это нельзя предсказать на этапе компиляции.

Цитатаэффект мультизадачности

Частично да, потому что мультизадачность подразумевает ОС в которую время от время надо передавать управление, чтобы что-то сделать, но только я бы сказал что это в целом деление на прикладное и системное ПО. Причем прикладное ПО может быть самым разным от и до каких-нибудь виртуальных машин / JIT комипялторов. Все должно оптимизировать под влив? Ну это фантастика.

Вот поэтому и не взлетело, в случае с тем же итаником. Реальное ПО на уровне потока инструкций к ЦПУ представляет собой полную кашу и мешанину из всего вышеперечисленного, и именно ЦПУ (и только он) имеет возможность как-то это все оптимизировать в целом, пусть и на масштабе в десяток команд.
----
Это может быть неправильно, не оптимально и ваще фу-фу-фу, вот только квака 1 почему-то гораздо лучше бегала на первом пентиуме, с меньшей частотой по сравнению с 486DX100. А кваку вряд ли можно назвать неоптимально написанным ПО - Кармак и Ко всегда выжимали максимум и по коду и по структурам данных.

Цитата: mrt789 от 12.02.2022 18:51:25Это может быть неправильно, не оптимально и ваще фу-фу-фу, вот только квака 1 почему-то гораздо лучше бегала на первом пентиуме, с меньшей частотой по сравнению с 486DX100. А кваку вряд ли можно назвать неоптимально написанным ПО - Кармак и Ко всегда выжимали максимум и по коду и по структурам данных.

Народ в "исторических" ветках всяких ретроигровых и ретрокомпьютерных форумов всегда говорил что Квака была ОЧЕНЬ сильно оптимизирован ИМЕННО и КОНКРЕТНО под Пентиум с его мощным FPU ("а других и не было" c OOE в момент разработки, К5 вышел когда квака уже к релизу готовилась), почему даже на К5/K6 (тоже с out-of-order execution, но своими) - работал "несколько медленней" (там fpu другие и тормозные), хотя в "прикладном ПО" без плавающей точки большинство согласны что К5 был быстрее per clock (откуда и "печально знаменитый" PR который pentium rating, нифига не отражавший на некоторых задачах).

Цитата: adolfus от 12.02.2022 01:28:41Никто во внутрений ("вычислительный") for никогда не вставляет ни одной функции, которая может быть прервана сигналом, отличным от сигнала, безусловно завершающего процесс (TERM или KILL, например). Мало того, если нужно во "внутреннем" for (я так понимаю, что это, типа "реалтайм" for?) что-то попросить у системы, то это всегда асинхронное и внутри for результаты этого вызова не нужны. А если вдруг оказывется. что таки нужны, имеет смысл пересмотреть постановку задачи.
На самом деле во "внутренние" for в приложениях, которые взаимодействуют с пользователями, никто никогда даже не вставляет функций, которые не могут быть реально inline, т.е. определены в отдельно компилируемых единицах трансляции. Все, что выполняется внутри Вашего for, должно пристутствовать в Вашем исходном модуле, либо оно должно быть функцией из стандартной библиотеки с (не c++, а именно c), а библиотека должна линковаться статически.

Практически весь системный софт содержит кучу системных вызовов внутри for или while. Пример - утилита печати содержимого каталогов ls и т.д.
В Линуксе любые демоны это всегда цикл с кучей системных вызовов внутри.

Цитата: mrt789 от 12.02.2022 16:53:20Не спорю, просто на всем, что не укладывается в это, эльбрус с вливом будет демонстрировать производительность в десятки процентов от заявленной.
Что он и делает. Без возможности частично выправить ситуацию за счет "суперскалярности" с предсказанием и спекулятивным исполнением.

К слову сказать, спекулятивное исполнение у Эльбруса есть.

Цитата: mrt789 от 12.02.2022 18:51:25Велком ту зе реал ворлд, Нео.
Потому что на самом деле компилятор не имеет этой информации. По нескольким причинам:
1. Компилятор видит только, что собирает. Это следствие деления на прикладное ПО и системное, в экзешнике который вы скомпилируете, не будет кусков ядра ОС, на работу с которым он рассчитан. И при этом у вас получится исполняемый файл, который будет запускаться и работать с сетью на десятке разных машин с разным железом.

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

Цитата2. Ну и наконец, ветвление может зависеть от какого-то условия, которое будет или не будет только рантайме - ввод/вывод, сеть, etc. Это нельзя предсказать на этапе компиляции.

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

Цитата: kerosene от 13.02.2022 19:07:35Практически весь системный софт содержит кучу системных вызовов внутри for или while. Пример - утилита печати содержимого каталогов ls и т.д.
В Линуксе любые демоны это всегда цикл с кучей системных вызовов внутри.

Насколько я понял, речь идет о производительности пользоватеских программ, причем именно того кода, который в выводе утилиты time маркируется, как user. А системные вызовы -- это отдельная песня.
Есть ряд рекомендаций, которых, к сожалению, приктически никто не придерживается, но соблюдение которых позволяет катастрофически повысить производительность кода в пользовательском пространстве.
Первая и самая простая – отказаться от использования .so (.dll) и использовать только статическую компоновку.
Вторая, более сложная – уменьшить гранулярность исходников. Т.е вместо сотни маленьких файлов использовать несколько больших. Это, с одной стороны, увеличивает время компиляции, но с другой позволяет компилятору выпустить более оптимизированный код.
Третья и самая сложная – отказатся от вызовов в циклах функций, определенных вне той единицы трансляции, где она вызывается. Это касается в том числе и библиотечных функций. Чаще всего это функции из libm. В этом случае дейстовать следует следующим образом – в отладочном режиме используется библиотека, а в режиме выпуска исходники библиотеки подключаются как static через #include в каждом исходном файле, где используются функции из этой библиотеки. В этом случае компилятор может выполнить сквозную оптимизацию и вынести инварианты за пределы циклов, что в ряде случаев увеличивает производительность в разы и более.

Цитата: OlegNZH-2 от 13.01.2022 19:16:47Так и сейчас , хоть и юникод -  пофигу , всё равно нет нет , да и встретишь , что непонимейшен  кириллицу в путях . ... Я уже не обращаю внимания . Везде, где можно, стараюсь обходиться латиницей и старым , добрым 8.3 .

Дык вот у людей далеких от всяких айти-технологий вызывает непогнимание почему для МЭДО (межведосмтвенного электронного документооборота) необходимо файлики называть по англицки. Причем вопрос один и тот же, у нас же импортозамещение, почему нельзя на русском?

Цитата: mrt789 от 12.02.2022 18:51:25Потому что на самом деле компилятор не имеет этой информации. По нескольким причинам:
1. Компилятор видит только, что собирает. Это следствие деления на прикладное ПО и системное, в экзешнике который вы скомпилируете, не будет кусков ядра ОС, на работу с которым он рассчитан. И при этом у вас получится исполняемый файл, который будет запускаться и работать с сетью на десятке разных машин с разным железом.
2. Ну и наконец, ветвление может зависеть от какого-то условия, которое будет или не будет только рантайме - ввод/вывод, сеть, etc. Это нельзя предсказать на этапе компиляции.
....
Вот поэтому и не взлетело, в случае с тем же итаником. Реальное ПО на уровне потока инструкций к ЦПУ представляет собой полную кашу и мешанину из всего вышеперечисленного, и именно ЦПУ (и только он) имеет возможность как-то это все оптимизировать в целом, пусть и на масштабе в десяток команд.

Привед, всем! А если собирать статистику run-time и использовать при повторном выполнении кода. Эдакое автоматическое профилирование онлайн в помощь планировщику, а может и компилятору…

Цитата: udaf от 23.02.2022 17:40:31Привед, всем! А если собирать статистику run-time и использовать при повторном выполнении кода. Эдакое автоматическое профилирование онлайн в помощь планировщику, а может и компилятору…

L1,L2 кэши в процессоре что-то такое и делают

Цитата: Поверонов от 23.02.2022 19:52:22L1,L2 кэши в процессоре что-то такое и делают

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

Цитата: udaf от 23.02.2022 20:17:52это про

Все давным давно придумано до вас.
Дело кончилось уязвимостями типа spectre.

Цитата: udaf от 23.02.2022 20:17:52это про текущее выполнение (ну и про данные, а не инструкции процессора), а я про статистику которая собирается  в процессе работы программы и сохраняется по окончании,  при следующем запуске  процессор может получать информацию о вероятности переходов в условиях, кол-во циклов и т.д.
Процессор запускает программу каждый раз, как в первый раз...), а тут  статистика как оно было ранее

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

Цитата: gvf от 23.02.2022 20:26:45Все давным давно придумано до вас.
Дело кончилось уязвимостями типа spectre.

1 Все давным давно придумано до вас. - Не спорю может и придумано, можете показать где?
2. Мимо...),  Meltdown, Spectre - это про время выполнение  и использования общих структур процессора с последующим анализом кэш, а так я с Вами полностью  согласен компьютеры поработят человекоff... пора выкидывать всю электронику и шапочку на лоб из фольги...
Если Эльбрус подвержен эти уязвимостям  то данная технология не увеличивает/уменьшает риски,  она не про это)

Цитата: Senya от 23.02.2022 20:30:14Процессор, который самостоятельно собирает информацию о всех запускаемых программах и имеет низкоуровневый доступ к долговременным накопителям будет посильнее Фауста Гёте процессора, выключаемого сигналом со спутника.
А если серьёзно - не представляю подобную вещь без поддержки со стороны операционной системы и компилятора. И без вопиющего нарушения многочисленных требований по изоляции памяти и безопасности выполнения. Т.е. для специальных изолированных систем.

1.Я могу сказать больше без поддержки самим процессором такая технология не возможна)
2.А где Вы увидели нарушение изоляции, этим грешат процессоры подверженные  Meltdown, Spectre,  я предлагаю использовать статистику конкретно по данной программе.
3.Видели фильм "День сурка"  там герой выполняет одну задачу много раз и добивается успеха, то что сейчас делают процессоры это  50 первых поцелуев 
4.Ваши страхи мне понятны, система модифицируется без участия человека, может и не туда зайти..

Цитата: C.K. от 25.02.2022 15:20:17Тайвань подтвердил остановку экспорта чипов в Россию

Похоже Тайвань подписал себе смертный приговор..Украинский сценарий для него стал неизбежен.