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

Гдеж они там от распараллеливания процессов к политике свалились?! 
Rizado, обратил внимание, что в профиле у тебя ryzen. А что стояло до этого и насколько ощутима разница в производительности? Да, и почему винда 7 а не 10?

Декларативный язык предполагает решающий задачи движок.

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

Что же касается символьных вычислений...
У Клоксина и Меллиша в книжке по Прологу зачатки были даны для программы символьного дифференцирования.
Показал их старшему сыну, когда он Matlab в ЛЭТИ изучал. Теперь деточка работает в Алмаз-Антей, куда его взяли с радостным визгом.
А то у них там всё больше на Delphy и десятилетней давности.

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

Совершенно верно, но зачем нам лишние сущности?
Ведь проще жить, когда есть просто ещё один процесс, который поставляет сериализованные данные
(как последовательность сообщений),
и плевать с высокой горки, как его там зовут теоретики.
А то потом некоторые выучат Хаскель, а кроме монады IO в ихних программах что-то искать утомишься.
И это именно при том, что в Хаскель, в отличие от Java, например, потоки именно зелёные/лёгкие.

Ну, грубо говоря, актор как актёр - у него есть своя роль. И он её выполняет.
Выполнение своей задачи - это процесс.
Всё прозрачно, всё понятно, легко искать, где что пошло не так.
И на уровне поиска ошибок в коде, и на уровне работы супервайзера.

Да, но есть и забавная такая игрушка - Scala native.

Затруднюсь назвать больший источник непоняток.
Потому и выдумали Akka.

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

Да и просто для того, чтобы понять, что такое декларативное программирование - шикарнейший инструмент.
Или просто как язык для первого знакомства с программированием.

Декларативный язык предполагает решающий задачи движок.
Так устроены пакеты для символьного решения математических уравнений.
Мало пользовался такими пакетами, они дорогие, тот же Matlab, хоть и имеет процедурный язык.
Хотя верю, что появятся открытые пакеты.

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

Вы меня заинтересовали.
Scala вроде как работает на JVM.
Я знаю Java и C# - очень удобно, когда не надо вручную уничтожать объекты и возникает меньше ошибок с выделением памяти.
Параллельность в них реализована классом Thread - можно запускать параллельные потоки.
Вообще, объектно-событийная модель присуща всем RAD - Rapid Application Development инструментам.

Был такой язык - Prolog.

Смею вас заверить, что культура Prolog-программирования представляет и нынче вовсе не только археологический интерес.
Начиная от структурных преобразований термов на основе механизма унификации
(один шаг до метапрограммирования, а временами и вовсе оно самое,
и что самое сладкое - не во время компиляции, а во время выполнения программы),
и вплоть до всё той же акторной модели, и распараллеливания запросов к базам данных/знаний.

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

Да и просто для того, чтобы понять, что такое декларативное программирование - шикарнейший инструмент.
Или просто как язык для первого знакомства с программированием.

А ещё - это "моя первая любовь" в программировании ab

Наверно, вы имели в виду иерархию типов.

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

Что же касается соответствующих компиляторов...
Альтернатива - Erlang/Elixir+OTP или Scala/Akka - не как языки,
а скорее как фреймворки для работы со всеми этими умными словами -
параллельность, конкуррентность, дистрибутивность.

Ведь работа с асинхронностью реализована уже и в JavaScript, не говоря уже о более прочих языках.
Причём простенько и со вкусом.

Ага. А наиболее прогрессивная часть человечества предпочла работать с одним ядром, но очень мощным. Правда несколько ограниченным, в отличии от ЦП, но действительно мощным. И весьма преуспела в этом.

Я не говорил, что распараллеливание вычислений - это плохо.
Одно время даже интересовался языком Вирта Modula-3.
Для решения задач математического моделирования физических явлений,
для решения больших матриц линейных уравнений распараллеливание просто необходимо.

Интересно было бы нарисовать график повышения производительности распределённых вычислений
в зависимости от числа ядер конкретного процессора, чтобы было наглядно.

По большому счёту - да.
И при визуализации архитектуры системы в erlang:Observer используется именно UML.
Просто разные уровни абстракции одной модели, акторной:
в рамках UML рисуется картинка, чтобы начать забарывать сложность,
в рамках инфраструктуры Erlang/Elixir пишется код
(не сильно отличается от картинки - потому что скриптота с динамической типизацией),
а когда вся эта красота начинает тормозить,
на С/C++ переписываются тормозные участки кода, имея перед глазами рабочий прототип.
Дык встроенные функции (стандартная библиотека языка) Erlang отродясь на С писалась

Был такой язык - prolog. (programming logic)
Задавались начальные условия, а остальное выводилось логически.
Я лично только читал книгу по prolog.
Про Erlang слышал, но не знаком.
Сам программировал только приложения баз данных на RAD + SQL.
Иногда тонкий клиент на Web.
Грубо говоря, прикручивал морды к базе данных.
Есть ещё интересная задача - распараллеливание запросов к базам данных.

Вот вы и коснулись вопроса иерархичности процессов.
Используя то же ООП, можно строить иерархию объектов.
За распараллеливание кода отвечает компилятор.
Другое дело, как этот компилятор так написать.
Программирование процедурами - труднее, так как при большом объёме работы требует много процедур без какой бы то ни было иерархии.
Хотя, возможно, работает быстрее.

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

Акторы - это UML?

По большому счёту - да.
И при визуализации архитектуры системы в erlang:Observer используется именно UML.
Просто разные уровни абстракции одной модели, акторной:
в рамках UML рисуется картинка, чтобы начать забарывать сложность,
в рамках инфраструктуры Erlang/Elixir пишется код
(не сильно отличается от картинки - потому что скриптота с динамической типизацией),
а когда вся эта красота начинает тормозить,
на С/C++ переписываются тормозные участки кода, имея перед глазами рабочий прототип.
Дык встроенные функции (стандартная библиотека языка) Erlang отродясь на С писалась

Дерево супервизоров - совершенно устойчивое понятие 
И большой ай-я-яй - в адрес архитектора системы. Проще надо быть, проще.
Чему помогает Процесс-Ориентированное Программирование (а не ООП).
Не тупая замена объектов процессами, а по-умному

В Scala+Akka - сложнее с переписыванием - тут уже в кишки JVM надо залезать,
чтобы получить от кода на С реальное ускорение работы.
Но исходные принципы модели - одни и те же.

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

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

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

Всё равно путь один. Сокет процессора один. Дорожки на плате для обмена данными одни для всех ядер вместе.
*** Добавлено: 30.05.2020 12:52:53 ***

Акторы - это UML?

Это очень интересно!

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

Вот интересно, как он работает со многими ядрами.
Это ведь совсем нетривиальная задача.

Эта задача упрощается до вполне понимабельного уровня в акторной модели выполнения -
так работают, например, Erlang, и Akka - для Java-мира.
То бишь процессы, сообщения (а именно запросы и ответы),
и все разделяемые ресурсы - тоже процессы, хоть ты тресни.
Над всей этой красотой надзирает супервизор (не более чем ещё один процесс ) -
и, если он располагает адекватной системой ранжирования процессов по приоритетам,
даже и конкуреннтые системы работают ожидаемым и предсказуемым образом.
Отдельно следует отметить проблему времени при согласовании работы процессов -
чтобы система была актуальной в каждый момент времени и давала релевантные ответы именно
для текущего состояния "обрабатываемого мира" -
чтобы не вышло так, что выдан ответ по текущему состоянию какой-нибудь структуры,
а через мгновение в эту структуру прилетает нечто,
требующее дать совершенно другой ответ на тот же самый запрос.

Но! Так выглядит работа с зелёными, легковесными, в отличие от процессов ОС, процессами.
На более низком уровне, внутри BEAM, JVM, ядер ОС -
треша и угара ещё больше. Борются с ними и вышеприведёнными методами, и более врукопашную.
Но так мой пост никогда не кончится

А при чем тут системная шина и как она мешает вычислительном процессу?

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