Как делает общую память по сравнению с большими структурами данных дескриптора передачи сообщений?
Пространство сдвига управления (и завершение основан на типе, не называют)
Для большего совершенства: Справка-> Ссылка Контурной карты По умолчанию
9 ответов
Да, в этом случае общее состояние могло бы быть быстрее. Но только если вы можете отказаться от блокировок, а это возможно только в том случае, если он полностью доступен только для чтения. если он «в основном только для чтения», тогда вам понадобится блокировка (если вам не удастся написать структуры без блокировок, имейте в виду, что они даже сложнее, чем блокировки), и тогда вам будет трудно заставить его работать как быстро, как хорошая архитектура передачи сообщений.
Да, вы могли бы написать «серверный процесс», чтобы поделиться им. С действительно легкими процессами это не тяжелее, чем написать небольшой API для доступа к данным. Думайте как объект (в смысле ООП), который «владеет» данными. Разделение данных на куски для усиления параллелизма (называемое «сегментированием» в кругах БД) помогает в больших случаях (или если данные находятся в медленном хранилище).
Даже если NUMA становится популярным, у вас все еще есть все больше и больше ядер на ячейку NUMA. И большая разница в том, что сообщение может передаваться только между двумя ядрами, в то время как блокировка должна быть сброшена из кеша на ВСЕХ ядрах, ограничивая ее задержкой между ячейками шины (даже медленнее, чем доступ к ОЗУ). Во всяком случае, разделяемое состояние / блокировки становятся все более и более невыполнимыми.
короче ... привыкайте к передаче сообщений и серверным процессам, это все в моде.
Edit : пересматривая этот ответ, Я хочу добавить о фразе, найденной в документации Go:
разделяйте память, общаясь, а не общайтесь, разделяя память.
Идея такова: когда у вас есть блок памяти, совместно используемый между потоками, типичный способ Избегать одновременного доступа означает использовать блокировку для арбитража. Стиль Go - передать сообщение со ссылкой, поток обращается к памяти только при получении сообщения. Это зависит от некоторой степени программистской дисциплины; но в результате получается очень чистый код, который можно легко вычитать, поэтому его относительно легко отлаживать.
Преимущество состоит в том, что вам не нужно копировать большие блоки данных в каждое сообщение, и вам не нужно эффективно очистить кеши, как в некоторых реализациях блокировки. Еще рано говорить, приводит ли этот стиль к более высокопроизводительному дизайну или нет. (особенно потому, что текущая среда выполнения Go несколько наивна в отношении планирования потоков)
t должны эффективно очищать кеши, как в некоторых реализациях блокировки. Еще рано говорить, приводит ли этот стиль к более высокопроизводительным конструкциям или нет. (особенно потому, что текущая среда выполнения Go несколько наивна в отношении планирования потоков) t должны эффективно очищать кеши, как в некоторых реализациях блокировки. Еще рано говорить, приводит ли этот стиль к более высокопроизводительным конструкциям или нет. (особенно потому, что текущая среда выполнения Go несколько наивна в отношении планирования потоков)В Erlang все значения неизменяемы, поэтому нет необходимости копировать сообщение, когда оно отправляется между процессами, поскольку оно не может быть изменено в любом случае.
В Go передача сообщений осуществляется по соглашению - нет ничего, что могло бы помешать вам отправить кому-то указатель по каналу, а затем изменить указанные данные, только соглашение, поэтому снова нет необходимости копировать сообщение.
Одно из решений, которое здесь не было представлено, - это репликация главный-подчиненный. Если у вас большая структура данных, вы можете реплицировать изменения в нее на все ведомые устройства, которые выполняют обновление своей копии.
Это особенно интересно, если кто-то хочет масштабироваться до нескольких машин, которые даже не имеют возможности для совместного использования памяти без очень искусственных настроек (mmap блочного устройства, которое читает / записывает из памяти удаленного компьютера?)
Вариантом этого является наличие диспетчера транзакций, который можно красиво попросить обновить реплицированную структуру данных, и это обеспечит одновременное обслуживание одного-единственного запроса на обновление. Это больше похоже на модель mnesia для репликации master-master табличных данных mnesia, которые квалифицируются как «большая структура данных».
Один Следует понимать, что модель параллелизма Erlang НЕ на самом деле указывает, что данные в сообщениях должны копироваться между процессами, она утверждает, что отправка сообщений - единственный способ связи и что общего состояния не существует. Поскольку все данные неизменяемы, что является фундаментальным, то реализация вполне может не копировать данные, а просто отправлять на них ссылку. Или можно использовать комбинацию обоих методов. Как всегда, не существует лучшего решения, и приходится идти на компромисс при выборе того, как это делать.
BEAM использует копирование, за исключением больших двоичных файлов, куда он отправляет ссылку.
Большинство современных процессоров используют варианты протокола MESI . Из-за общего состояния передача данных только для чтения между разными потоками обходится очень дешево. Однако измененные общие данные очень дороги, потому что все другие кеши, в которых хранится эта строка кэша, должны сделать ее недействительной.
Так что, если у вас есть данные только для чтения, очень дешево разделить их между потоками вместо копирования с сообщениями. Если у вас есть данные, предназначенные в основном для чтения, их совместное использование между потоками может быть дорогостоящим, отчасти из-за необходимости синхронизации доступа, а отчасти из-за того, что запись разрушает дружественное к кешу поведение совместно используемых данных.
Неизменяемые структуры данных могут быть здесь полезным. Вместо того, чтобы изменять фактическую структуру данных, вы просто создаете новую, которая разделяет большую часть старых данных, но с теми изменениями, которые вам нужно изменить.
Что такое большая структура данных?
Один человек большой, другой маленький.
На прошлой неделе я разговаривал с двумя людьми - один человек делал встроенные устройства он использовал слово "большой" - я спросил его, что это означает - он сказал, что более 256 КБ - позже на той же неделе парень говорил о распространении СМИ - он использовал слово «большой» Я спросил его, что он означало - он немного подумал и сказал, что «не поместится на одной машине», скажем, 20-100 ТБ
В терминах Erlang «большой» может означать «не влезет в ОЗУ» - то есть с 4 ГБ ОЗУ структуры данных> 100 МБ могут считаться большими - копирование структуры данных размером 500 МБ может быть проблема. Копирование небольших структур данных (скажем, <10 МБ) никогда не является проблемой в Erlang.
Действительно большие структуры данных (то есть те, которые не помещаются на одной машине) должны быть копируются и "чередуются" на нескольких машинах.
Итак, я полагаю, у вас есть следующее:
Небольшие структуры данных не проблема - поскольку они малы, время обработки данных быстро, выполняется быстрое копирование и т. д. (просто потому, что они маленькие)
Большие структуры данных представляют собой проблему, потому что они не помещаются на одной машине, поэтому копирование необходимо.
На данный момент проблема действительно заключается в том, что блокировка и согласованность строк кэша могут быть такими же дорогостоящими, как копирование более простой структуры данных (например, нескольких сотен байтов).
В большинстве случаев умно написанный новый многопоточный алгоритм, который пытается устранить большую часть блокировок, всегда будет быстрее - и намного быстрее с современными структурами данных без блокировок. Особенно, если у вас есть хорошо спроектированные системы кэширования, такие как многопоточность на уровне микросхем Sun Niagara.
Если ваша система / проблема нелегко разбить на несколько простых обращений к данным, тогда у вас есть проблема. И не все проблемы можно решить с помощью передачи сообщений. Вот почему все еще продаются некоторые суперкомпьютеры на базе Itanium, потому что у них есть терабайты общей оперативной памяти и до 128 процессоров, работающих с той же общей памятью. Они на порядок дороже, чем обычный кластер x86 с той же мощностью процессора, но вам не нужно разбивать данные.
Еще одна причина, не упомянутая до сих пор, заключается в том, что программы могут стать намного проще писать и поддерживать когда вы используете многопоточность. Передача сообщений и подход без общего доступа делают его еще более удобным в обслуживании.
Например, Erlang никогда не создавался для ускорения работы, а вместо этого использует большое количество потоков для структурирования сложных потоков данных и событий.
Думаю, это было одним из основных моментов в дизайне. В веб-мире Google вас обычно не волнует производительность - если он может работать параллельно в облаке. А с передачей сообщений вы в идеале можете просто добавить больше компьютеров без изменения исходного кода.
Еще одна причина, не упомянутая до сих пор, заключается в том, что программы могут стать намного проще в написании и обслуживании, если вы используете многопоточность. Передача сообщений и подход без общего доступа делают его еще более удобным в обслуживании.
Например, Erlang никогда не создавался для ускорения работы, а вместо этого использует большое количество потоков для структурирования сложных потоков данных и событий.
Думаю, это было одним из основных моментов в дизайне. В веб-мире Google вас обычно не волнует производительность - если он может работать параллельно в облаке. А с передачей сообщений вы в идеале можете просто добавить больше компьютеров без изменения исходного кода.
Еще одна причина, не упомянутая до сих пор, заключается в том, что программы могут стать намного проще в написании и обслуживании, если вы используете многопоточность. Передача сообщений и подход без общего доступа делают его еще более удобным в обслуживании.
Например, Erlang никогда не создавался для ускорения работы, а вместо этого использует большое количество потоков для структурирования сложных потоков данных и событий.
Думаю, это было одним из основных моментов в дизайне. В веб-мире Google вас обычно не волнует производительность - если он может работать параллельно в облаке. А с передачей сообщений вы в идеале можете просто добавить больше компьютеров без изменения исходного кода.
Например, Erlang никогда не создавался для ускорения работы, а вместо этого использует большое количество потоков для структурирования сложных данных и потоков событий.
Думаю, это было одним из основных моментов в дизайне. В веб-мире Google вас обычно не волнует производительность - если он может работать параллельно в облаке. А с передачей сообщений в идеале вы можете просто добавить больше компьютеров без изменения исходного кода.
Например, Erlang никогда не создавался для ускорения работы, а вместо этого использует большое количество потоков для структурирования сложных данных и потоков событий.
Думаю, это было одним из основных моментов в дизайне. В веб-мире Google вас обычно не волнует производительность - если он может работать параллельно в облаке. А с передачей сообщений в идеале вы можете просто добавить больше компьютеров без изменения исходного кода.
Обычно языки передачи сообщений (это особенно просто в erlang, поскольку он имеет неизменяемые переменные) оптимизируют фактическое копирование данных между процессами (конечно, только локальные процессы: вы захотите продумать свой шаблон сетевого распределения), так что это не большая проблема.
Другой параллельной парадигмой является STM, программная транзакционная память. Судьи Клоджур привлекают к себе большое внимание. Тим Брэй (Tim Bray) неплохо изучает параллельные механизмы erlang и clojure
http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot-next
http://www.tbray.org/ongoing/When/200x/2009/12/01/Clojure-Theses