Java v Scala с точки зрения параллелизма
Я начинаю свой последний год проекта прямо сейчас. Я собираюсь исследовать параллельные подходы с точки зрения Java и Scala. Выйдя из java-модуля параллелизма, я могу понять, почему люди говорят, что подход к созданию потоков с общими состояниями трудно рассуждать. У вас есть критические разделы, о которых нужно беспокоиться, риск возникновения гоночных состояний, взаимных блокировок и т. Д. Из-за недетерминированного способа работы потоков Java. С 1.5 эта аргументация получила некоторую ясность, но все еще далека от кристально чистой.
На первый взгляд, scala, кажется, устраняет эту сложную аргументацию в классе актеров. Это дало программисту возможность разрабатывать параллельные системы с более последовательной точки зрения и облегчить концептуализацию. Но, в связи с этим, я прав, говоря, что есть некоторые недостатки? Например, скажем, мы хотим отсортировать большой список в обоих сценариях - с помощью Java вы создаете два потока, разбивает список на два, заботитесь о критических разделах, атомарных действиях и т. Д. И переходите к коду. В scala, поскольку это "ничего не поделится", вам действительно нужно передать list/2 двум акторам, чтобы выполнить операцию сортировки, верно?
Я предполагаю, что мой вопрос в том, что цена, которую вы платите за более простые рассуждения, - это издержки производительности, связанные с необходимостью передавать коллекцию вашим актерам в scala?
Я думал о том, чтобы сделать несколько тестов производительности для этого эффекта (сортировка по выбору, быстрая сортировка и т. Д.), Но поскольку один из них функционален, а другой обязателен - я не буду сравнивать яблоки с яблоками с точки зрения алгоритма.
Я был бы очень признателен за любые ваши взгляды, высказанные выше, чтобы дать мне несколько идей, чтобы начать меня. Большое спасибо.
2 ответа
Хорошая особенность Scala в том, что вы можете выполнять параллелизм Java, если хотите. Все классы Java доступны.
Таким образом, это действительно сводится к разнице между моделью, в которой у вас есть потоки с одновременным доступом к изменяемым переменным, и моделью, в которой у вас есть субъекты с состоянием, которые отправляют сообщения друг другу, но не заглядывают во внутренние компоненты друг друга. И вы абсолютно правы в том, что в некоторых сценариях вы должны выбирать между производительностью и простотой получения правильного кода.
Как правило, я считаю, что если у вас будет куча потоков, тратящих значительное количество времени на ожидание открытия блокировки с использованием модели Java, и нет чистого способа разделить работу чтобы все не ждали этого ресурса, и если выполнение быстро переключается между потоками, то модель Java намного превосходит модель актера, в которой актор отправляет сообщение "Я закончил" супервизору, который затем отправляет a "Вот новая работа!" сообщение для существующего незанятого актера. Алгоритмы сортировки, в зависимости от того, как вы их представляете, могут очень сильно попасть в эту категорию.
Для большинства всего остального, как я видел, снижение производительности, связанное с актерами, не так много. Если вы можете представить свою проблему как множество реактивных элементов (т. Е. Им нужно только время, когда они получили сообщение), тогда актеры могут масштабироваться особенно хорошо (миллионы доступны, хотя в любой момент времени работает только горстка); с потоками вам понадобится какое-то дополнительное внутреннее состояние для отслеживания того, кто должен выполнять какую работу, поскольку вы не можете обрабатывать такое количество активных потоков.
Здесь я просто укажу, что Scala не копирует аргументы, переданные актерам, поэтому актеры могут делиться тем, что им передают.
В отличие от Эрланга, программист обязан избегать обмена изменчивыми вещами. Тем не менее, нет никакого наказания в обмене неизменяемым материалом, так как нет необходимости блокировать его, так как все доступы к нему доступны только для чтения. И у Scala есть сильная поддержка неизменных структур данных.