Во-первых, давайте выясним, на что вы ссылаетесь.Вы цитируете из вводной документации , где обсуждается, зачем нужна новая модель программирования.Я упоминаю об этом, потому что это все теория компьютерных наук, которая не имеет прямого отношения к изучению API.В целом, я бы посчитал это относительно второстепенным.
Но этот параграф документов уже дает пару примеров.Пункт в основном заключается в том, что параллелизм по своей природе сложен для современной системы, и что традиционные API параллелизма часто создают абстракции, которые имеют непреднамеренные последствия для производительности.
В частности, в параграфе говорится о том, даже если память «разделяется»через API параллелизма, что реалии современных архитектур ЦП означают, что не весь доступ одинаков.То, что если поток данных создается потоком 0 и используется потоком 1, то архитектура ЦП в конечном итоге аннулирует эти данные в потоке 0 и передает строку кэша в поток 1. То есть, даже если память помечена как«общий доступ» фактически приводит к значительному снижению производительности каждый раз, когда другой поток обращается к этой памяти.Модель «разделяемой» памяти является иллюзией, поскольку процессорам необходимо поддерживать различные кэши, которые приводят к тому, что память на самом деле не разделяется, а скорее передается туда-сюда (со значительными затратами).
Это простоодна небольшая точка обоснования открытия, но она приводит к некоторым преимуществам параллелизма, предоставляемым моделью Actor.Поскольку субъект имеет эксклюзивный доступ к своему состоянию, он не только упрощает API (потому что вам не нужно беспокоиться о параллелизме), но и физическому ЦП не нужно беспокоиться об этом параллелизме.Это не только не беспокоится о блокировках, но и о блокировке ЦП не должен беспокоиться: он сможет получать доступ к памяти, не пропуская строки кэша назад и вперед между физическими ядрами / процессорами.