"Особенность потоков эрланг в том, что они легковесные. Это значит, что они:

быстро стартуют и завершаются;
быстро переключаются;
потребляют мало памяти.

Вы все сравниваете с С++ ))) Для многоядерных архитектур он отстой.

А я думал это про активные объекты А2. Не?

Я так понимаю, что активные объекты A2 "ещё легковеснее", т.к. у них нет своей кучи. Но в этом же и минус их. Я, правда, честно сказать, не знаю, не создаётся ли тред на каждый активный объект, но я думаю, это не так сложно поменять в ядре. Можно спросить у Сергея, когда он будет выступать, хотя это наверняка где-то написано. Уж в кооперативной-то версии точно есть "легковесные" активные ообъекты.

SVE от ARM (Scalar Vector Extensions) - и аналогичная работа из Berkeley 4 - дает еще один взгляд на лучший интерфейс между программой и оборудованием. Обычные векторные единицы предоставляют векторные операции фиксированного размера и ожидают, что компилятор попытается сопоставить алгоритм с доступным размером единицы. В отличие от этого, интерфейс SVE ожидает, что программист описывает степень доступного параллелизма, и полагается на оборудование, чтобы сопоставить его с доступным количеством исполнительных блоков. Использовать это из C сложно, потому что автовекторизатор должен вывести доступный параллелизм из циклических структур. Сгенерировать код для него из операции сопоставления в функциональном стиле тривиально: длина сопоставленного массива - это степень доступного параллелизма.

Кеши большие, но их размер - не единственная причина их сложности. Протокол согласования кэша - одна из самых сложных частей современного ЦП, которую нужно сделать как быстрой, так и правильной. Большая часть сложности возникает из-за поддержки языка, в котором данные должны быть как общими, так и изменяемыми, как само собой разумеющееся. Рассмотрим для сравнения абстрактную машину в стиле Erlang, где каждый объект является либо локальным для потока, либо неизменяемым (в Erlang есть упрощение даже для этого, где есть только один изменяемый объект на поток). Протокол согласованности кэша для такой системы будет иметь два случая: изменяемый или совместно используемый. Программный поток, переносимый на другой процессор, потребует явной недействительности кэша, но это относительно необычная операция.

Неизменяемые объекты могут еще больше упростить кеширование, а также удешевить некоторые операции. Проект Sun Labs Максвелл отметил, что объекты в кэше и объекты, которые будут размещены в молодом поколении, имеют почти одинаковый набор. Если объекты мертвы до того, как их нужно удалить из кеша, то никогда не записывать их обратно в основную память можно сэкономить много энергии. Project Maxwell предложил сборщик мусора (и распределитель) молодого поколения, который работал бы в кеше и позволял бы быстро перерабатывать память. С неизменяемыми объектами в куче и изменяемым стеком сборщик мусора становится очень простым конечным автоматом, который легко реализовать на оборудовании и позволяет более эффективно использовать относительно небольшой кеш.

поведение по умолчанию Erlang исторически заключалось в запуске одного планировщика, который в основном является родным потоком ОС, который выбирает задачи Erlang для запуска из очереди. С появлением многоядерных и многопроцессорных систем среда выполнения была расширена, чтобы воспользоваться преимуществами. Запуск среды выполнения с помощью -smp enabled заставит среду выполнения создать несколько планировщиков, обычно по одному на логический процессор. Вы можете вручную указать количество планировщиков с -S флаг например -S 16.

это описано в Erlang Run-Time System Справочное Руководство.

более глубокое обсуждение поддержки SMP можно найти в этой теме.


Я должен также отметить, что, начиная с R12B, SMP включен по умолчанию на платформах, которые его поддерживают (эквивалентно -smp auto флаг). Если вам интересно узнать о вашей собственной среде выполнения, приведенная ниже цитата из потока обсуждения будет интересно:

"... вы можете увидеть, что было выбрано в первой строке распечатки из команда "Ерл". Например. Erlang (BEAM) emulator версия 5.6.4 [источник] [smp:4] [asynch-потоки:0] .....

"[smp:4]" выше говорит, что SMP VM запущен и с 4 планировщиками".

История знает много примеров решений, которые опередили свое время и, не получив признания современности, отправлялись пылиться на полку. Сегодня IT-индустрия переживает очередной виток развития, вызванный переходом к многоядерным микропроцессорам, и сталкивается с новыми проблемами – например, рост количества ядер центрального процессора совсем не приводит к пропорциональному увеличению скорости исполнения приложений на нем. Быть может, наилучшее решение этой проблемы следует искать не в новых методах оптимизации прикладных программ, а в радикальной смене парадигмы программирования, оживив ранее забытые проекты?

На самом деле системы на Erlang вовсе не масштабируемые и не надежные. Это системы на Java такие. Системы на Erlang просто непробиваемы как скалы.

А это интерес практический или просто в рамках общей дискуссии?

... есть простая модель параллельности. Она масштабируемая: может работать с любым количеством потоков. Простая для понимания, что соотносится с Oberon Way.

В предыдущих Oberon Day я рассказывал про то, какая есть простая модель параллельности. Она масштабируемая: может работать с любым количеством потоков. Простая для понимания, что соотносится с Oberon Way. И ее по сути можно реализовать на любом Обероне, если доработать сборщик мусора. Если выделять динамическую память в параллельной программе не требуется, то можно и сборщик мусора не дорабатывать.

ссылку не уточните?

А что надо доделать в сборщике мусора?

https://www.youtube.com/watch?v=M0uvLtP7Gjg
https://www.youtube.com/watch?v=IV3Ewv82Zq4


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

Кстати, надо вернуться к вопросу об унитазе. Как в такой программе, где у каждого потока своя куча, работать с журналом отладки, например?

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