потеря производительности передачи сообщений в противоположность совместно используемым данным
Не технически, JavaScript имеет точки с запятой как дополнительные во многих ситуациях.
, Но, как правило, используйте их в конце любого оператора. Почему? Поскольку, если Вы когда-нибудь хотите сжать сценарий, он сохранит Вас с бесчисленных часов разочарования.
Автоматическая вставка точки с запятой выполняется интерпретатором, таким образом, Вы можете пропускать их если Вы, так выберите. В комментариях кто-то утверждал, что
Точки с запятой не являются дополнительными с операторами, любят, повреждаются/продолжают/бросают
, но это неправильно. Они являются дополнительными; то, что действительно происходит, - то, что разделители строки влияют на автоматическую вставку точки с запятой; это - тонкое различие.
Вот остальная часть стандарта на вставке точки с запятой:
Для удобства, однако, такие точки с запятой могут быть опущены из исходного текста в определенных ситуациях. Эти ситуации описаны путем высказывания, что точки с запятой автоматически вставляются в маркерный поток исходного кода в тех ситуациях.
7 ответов
Это реальная жизнь : вы должны учитывать эту возможность независимо от языка / платформы. В распределенном мире (реальном мире) вещи терпят неудачу: живите с этим.
Конечно, есть цена : в нашей вселенной нет ничего бесплатного. Но не следует ли вам использовать другой носитель (например, файл, базу данных) вместо перемещения «больших объектов» по каналам связи? Вы всегда можете использовать «сообщение» для обозначения «больших объектов», хранящихся где-то.
Конечно, нет: идея функционального программирования / Erlang OTP заключается в том, чтобы « изолировать » как можно больше областей, которые были "общее состояние" манипулируется. Более того, четкая маркировка мест , где разделяемое состояние мутирует, помогает тестируемости и отслеживаемости.
Я считаю, что вы упускаете суть: не существует такой вещи, как серебряная пуля. Если ваше приложение не может быть успешно создано с использованием Erlang, не делайте этого. Вы всегда можете использовать другую часть общей системы другим способом, то есть использовать другой язык / платформу. В этом отношении Erlang ничем не отличается от другого языка: используйте правильный инструмент для правильной работы .
Помните: Erlang был разработан, чтобы помочь решить одновременных , асинхронных и распределенные задачи. Он не оптимизирован для эффективной работы, например, с разделяемым блоком памяти ... если вы не учитываете взаимодействие с nif функциями, работающими в части игры с общими блоками: -)
Помните: Erlang был разработан, чтобы помочь решить одновременных , асинхронных и распределенные задачи. Он не оптимизирован для эффективной работы, например, с разделяемым блоком памяти ... если вы не учитываете взаимодействие с nif функциями, работающими в части игры с общими блоками: -)
Помните: Erlang был разработан, чтобы помочь решить одновременных , асинхронных и распределенные задачи. Он не оптимизирован для эффективной работы, например, с разделяемым блоком памяти ... если вы не учитываете взаимодействие с nif функциями, работающими в части игры с общими блоками: -)
nif функциями, работающими в части игры с общими блоками: -) Erlang был разработан для решения одновременных , асинхронных и распределенных задач. Он не оптимизирован для эффективной работы, например, с разделяемым блоком памяти ... если вы не учитываете взаимодействие с nif функциями, работающими в части игры с общими блоками: -) Реальные системы в любом случае всегда являются гибридами : Я не верю, что современные парадигмы на практике пытаются избавиться от изменяемых данных и общего состояния.
Цель однако одновременный доступ к этому общему состоянию не требуется. Программы можно разделить на параллельные и последовательные, и использовать передачу сообщений и новые парадигмы для параллельных частей.
Не каждый код получит одинаковые вложения : Есть опасения, что потоки в основном «считаются вредными. ". Что-то вроде Apache может нуждаться в традиционных параллельных потоках, и такая ключевая технология может быть тщательно доработана в течение нескольких лет, чтобы она могла взорваться с полностью параллельным общим состоянием. Ядра операционной системы - еще один пример, когда «решает проблему, какой бы дорогой она ни была». может иметь смысл.
Нет никакой пользы от быстрого, но сломанного : Но для нового кода или кода, которому не уделяется так много внимания, может оказаться, что он просто не является поточным. безопасный, и он не будет обрабатывать истинный параллелизм, и поэтому относительная «эффективность» не имеет значения. Один способ работает, а один нет.
Не забывайте тестируемость: Кроме того, какое значение вы можете придать тестированию? Параллелизм с общей памятью на основе потоков просто не поддается тестированию. Параллелизм при передаче сообщений есть. Итак, теперь у вас есть ситуация, когда вы можете протестировать одну парадигму, но не другую. Итак, какой смысл знать, что код был протестирован? Опасно даже не знать, будет ли другой код работать в любой ситуации?
Не привлекает столько внимания, может оказаться, что он просто не является потокобезопасным и не будет обрабатывать настоящий параллелизм, и поэтому относительная «эффективность» не имеет значения. Один способ работает, а один нет.Не забывайте тестируемость: Кроме того, какое значение вы можете придать тестированию? Параллелизм с общей памятью на основе потоков просто не поддается тестированию. Параллелизм при передаче сообщений есть. Итак, теперь у вас есть ситуация, когда вы можете протестировать одну парадигму, но не другую. Итак, какой смысл знать, что код был протестирован? Опасно даже не знать, будет ли другой код работать в любой ситуации?
Не привлекает столько внимания, что может оказаться, что он просто не является потокобезопасным и не будет обрабатывать настоящий параллелизм, и поэтому относительная «эффективность» не имеет значения. Один способ работает, а один нет.Не забывайте тестируемость: Кроме того, какое значение вы можете придать тестированию? Параллелизм с общей памятью на основе потоков просто не поддается тестированию. Параллелизм при передаче сообщений есть. Итак, теперь у вас есть ситуация, когда вы можете протестировать одну парадигму, но не другую. Итак, какой смысл знать, что код был протестирован? Опасно даже не знать, будет ли другой код работать в любой ситуации?
Не забывайте тестируемость: Кроме того, какое значение вы можете придать тестированию? Параллелизм с общей памятью на основе потоков просто не поддается тестированию. Параллелизм при передаче сообщений есть. Итак, теперь у вас есть ситуация, когда вы можете протестировать одну парадигму, но не другую. Итак, какой смысл знать, что код был протестирован? Опасно даже не знать, будет ли другой код работать в любой ситуации?
Не забывайте тестируемость: Кроме того, какое значение вы можете придать тестированию? Параллелизм с общей памятью на основе потоков просто не поддается тестированию. Параллелизм при передаче сообщений есть. Итак, теперь у вас есть ситуация, когда вы можете протестировать одну парадигму, но не другую. Итак, какой смысл знать, что код был протестирован? Опасно даже не знать, будет ли другой код работать в любой ситуации?
В ваших вопросах есть неявное предположение - вы предполагаете, что все данные могут соответствовать на одной машине и что приложение внутренне локализовано в одном месте.
Что произойдет, если приложение настолько велико, что не поместится на одной машине? Что произойдет, если приложение перерастет одну машину?
Вы не хотите иметь один способ программирования приложения, если оно умещается на одной машине и совершенно другой способ программирования, как только он перерастет одну машину.
Что произойдет, если вы захотите сделать отказоустойчивое приложение? Чтобы сделать что-то отказоустойчивым, вам понадобятся как минимум две физически разделенные машины и без совместного использования . Когда вы говорите о совместном использовании и базах данных, вы не упоминаете, что такие вещи, как mySQL кластера добиться отказоустойчивости точно за счет поддержки синхронизированных копий данные в физически разделенных машинах - много сообщений и копирование того, что вы не видите на поверхности - Erlang просто раскрывает это.
Способ программирования не должен внезапно меняться для обеспечения отказоустойчивости и масштабируемости.
Erlang был разработан в первую очередь для создания отказоустойчивых приложений.
Совместно используемые данные на многоядерном компьютере имеют свой собственный набор проблем - когда вы получаете доступ к общим данным вам нужно получить блокировку - если вы используете глобальную блокировку (самый простой подход), вы можете остановка всех ядер во время доступа к общим данным. Общий доступ к данным на многоядерном компьютере может быть проблематичным из-за проблем с кешированием, если ядра имеют локальные кеши данных, тогда доступ к «удаленным» данным (в кешах некоторых других процессоров) может быть очень дорогостоящим.
Многие проблемы внутренне распределены, и данные никогда не доступны в одном место в то же время так - такого рода проблемы хорошо вписываются в образ мышления Erlang.
В распределенной среде «гарантия доставки сообщений» невозможна - целевой компьютер мог выйти из строя. Таким образом, Erlang не может гарантировать доставку сообщений - здесь используется другой подход - система сообщит вам, не удалось ли доставить сообщение (но только если вы использовали механизм ссылок) - тогда вы можете написать свою собственную ошибку восстановления.)
Для чистого вычисления чисел Erlang не подходит - но в гибридной системе Erlang хорошо управляет распределением вычислений между доступными процессорами, поэтому мы видим множество систем, в которых Erlang управляет распределением и отказоустойчивыми аспектами проблемы, но сама проблема решается на другом языке
и других языках. используются
Например, в БД вы должны получить доступ и изменить ту же запись
Но это обрабатывается БД. Как пользователь базы данных вы просто выполняете свой запрос, а база данных гарантирует, что он выполняется изолированно.
Что касается производительности, одна из наиболее важных вещей в устранении общего состояния - это то, что оно позволяет проводить новые оптимизации. Общее состояние не особенно эффективно. Вы получаете ядра, сражающиеся за одни и те же строки кэша, и данные должны быть записаны в память, где они в противном случае могли бы остаться в регистре или в кеше ЦП.
Многие оптимизации компилятора также полагаются на отсутствие побочных эффектов и разделяемое состояние.
Можно сказать, что более строгий язык, гарантирующий эти вещи, требует большего количества оптимизаций для повышения производительности, чем что-то вроде C, но это также значительно упрощает реализацию компилятором этих оптимизаций.
Многие проблемы, подобные проблемам параллелизма, возникают в однопоточном коде. Современные процессоры конвейерны, выполняют инструкции в произвольном порядке и могут запускать 3-4 из них за цикл. Таким образом, даже в однопоточной программе жизненно важно, чтобы компилятор и ЦП могли определять, какие инструкции могут чередоваться и выполняться параллельно.
Несколько комментариев по поводу вашего недоразумения с Erlang:
- Erlang гарантирует, что сообщения не будут потеряны и будут приходить в том порядке, в котором они были отправлены. Основная ситуация с ошибкой заключается в том, что машина A не может связаться с машиной B. Когда это происходит, срабатывают мониторы процессов и срабатывают ссылки, а сообщения об отключении системы будут отправлены процессам, которые для нее зарегистрировались. Ничего молча не сбрасывается. Процессы будут «аварийно завершены», и супервизоры (если они есть) попытаются перезапустить их.
- Объекты не могут быть изменены, поэтому они всегда копируются. Один из способов обеспечить неизменяемость - скопировать значения в кучи других процессов erlang. Другой способ - размещать объекты в общей куче, ссылаться на них в сообщениях и просто не выполнять никаких операций, которые их изменяют. Erlang делает первым по производительности! Реальное время страдает, если вам нужно остановить все процессы, чтобы собрать мусор в общей куче. Спросите Java.
- В Erlang есть разделяемое состояние. Erlang этим не гордится, но прагматично. Одним из примеров является локальный реестр процессов, который представляет собой глобальную карту, которая отображает имя процесса, чтобы системные процессы могли быть перезапущены и потребовать свое старое имя. Erlang просто пытается избежать разделяемого состояния, если это возможно . Другой пример - общедоступные таблицы ETS.
- Да, иногда Erlang работает слишком медленно. Это происходит на всех языках. Иногда Java работает слишком медленно. Иногда C ++ работает слишком медленно. Просто потому, что жесткий цикл в игре должен был упасть до сборки, чтобы начать серьезную векторную математику на основе SIMD, вы можете '' Я пришел к выводу, что все должно быть написано на ассемблере, потому что это единственный язык, который работает быстро, когда это важно. Важно иметь возможность писать системы с хорошей производительностью, а Erlang вполне справляется с этим. См. Тесты yaws или rabbitmq.
Ваши факты не являются фактами об Erlang. Даже если вы думаете, что программирование на Erlang - это боль, вы обнаружите, что благодаря ему другие люди создают отличное программное обеспечение. Вам следует попытаться написать IRC-сервер на Erlang или что-то еще, что очень параллельно. Даже если вы больше никогда не собираетесь использовать Erlang, вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.
Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
Важно иметь возможность писать системы с хорошей производительностью, а Erlang вполне справляется с этим. См. Тесты yaws или rabbitmq.Ваши факты не являются фактами об Erlang. Даже если вы думаете, что программирование на Erlang - это боль, вы обнаружите, что благодаря ему другие люди создают отличное программное обеспечение. Вам следует попытаться написать IRC-сервер на Erlang или что-то еще, что очень параллельно. Даже если вы больше никогда не собираетесь использовать Erlang, вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.
Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
Важно иметь возможность писать системы с хорошей производительностью, а Erlang вполне справляется с этим. См. Тесты yaws или rabbitmq.Ваши факты не являются фактами об Erlang. Даже если вы думаете, что программирование на Erlang - это боль, вы обнаружите, что благодаря ему другие люди создают отличное программное обеспечение. Вам следует попытаться написать IRC-сервер на Erlang или что-то еще, что очень параллельно. Даже если вы больше никогда не собираетесь использовать Erlang, вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.
Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
Ваши факты не являются фактами об Erlang. Даже если вы думаете, что программирование на Erlang - это боль, вы обнаружите, что благодаря ему другие люди создают отличное программное обеспечение. Вам следует попытаться написать IRC-сервер на Erlang или что-то еще, что очень параллельно. Даже если вы больше никогда не собираетесь использовать Erlang, вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.
Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
Ваши факты не являются фактами об Erlang. Даже если вы думаете, что программирование на Erlang - это боль, вы обнаружите, что благодаря ему другие люди создают отличное программное обеспечение. Вам следует попытаться написать IRC-сервер на Erlang или что-то еще, что очень параллельно. Даже если вы больше никогда не собираетесь использовать Erlang, вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.
Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
вы бы научились думать о параллелизме по-другому. Но, конечно же, вы это сделаете, потому что Erlang потрясающе прост.Те, кто не понимает Erlang, обречены повторно реализовать его плохо.
Хорошо, оригинал был о Lisp, но ... это правда!
- Erlang предоставляет супервизоры и обратные вызовы gen_server для синхронных вызовов, поэтому вы будете знать об этом, если сообщение не доставлено: либо вызов gen_server возвращает тайм-аут, либо весь ваш узел будет отключен и выше, если запущен супервизор.
- обычно, если процессы находятся на одном узле, языки передачи сообщений оптимизируют копирование данных, так что это почти похоже на общую память, за исключением случаев, когда объект изменяется, используемый обоими впоследствии, что в любом случае невозможно выполнить с использованием разделяемой памяти
- Существует некоторое состояние, которое сохраняется процессами, передавая его себе в рекурсивных хвостовых вызовах, также некоторое состояние, конечно, может передаваться через сообщения. Я не особо использую мнезию, но это транзакционная база данных, поэтому, как только вы передали операцию mnesia (и она вернулась), вы почти гарантированно, что она будет выполнена ..
- Вот почему такие приложения легко привязать к erlang с использованием портов или драйверов. Самыми простыми являются порты, это очень похоже на канал unix, хотя я думаю, что производительность не так уж велика ... и, как уже говорилось, передача сообщений обычно заканчивается передачей указателя в любом случае, поскольку виртуальная машина / компилятор оптимизирует копию памяти. .
Для корректности рекомендуется использовать общий доступ, и данные должны быть максимально нормализованы. Для оперативности отправляйте сообщения об изменениях, но всегда подкрепляйте их опросом. Сообщения отбрасываются, дублируются, переупорядочиваются, задерживаются - не полагайтесь на них.
Если вас беспокоит скорость, сначала сделайте это однопоточным и отключите дневное освещение ]. Затем, если у вас несколько ядер и вы знаете, как разделить работу, используйте параллелизм.