bug fix 2

Author: returned-to-life

ru/overviews/parallel-collections/configuration.md

@@ -11,11 +11,11 @@ num: 7
 
 ## Обслуживание задач
 
-Параллельные коллекции предоставляют возможность выбора методов планирования задач при выполнении операций. В числе параметров каждой параллельной коллекции есть так называемый объект обслуживания задач, который и отвечает за планирование и распределение нагрузки на процессоры.
+Параллельные коллекции предоставляют возможность выбора методов планирования задач и распределения нагрузки на процессоры. В числе параметров каждой параллельной коллекции есть так называемый объект обслуживания задач, который и отвечает за это планирование.
 
 Внутри объект обслуживания задач содержит ссылку на пул потоков; кроме того он определяет, как и когда задачи разбиваются на более мелкие подзадачи. Подробнее о том, как конкретно происходит этот процесс, можно узнать в техническом отчете \[[1][1]\].
 
-В настоящее время для параллельных коллекций доступно несколько реализаций объекта поддержки задач. Например, `ForkJoinTaskSupport` реализован посредством "fork-join" пула и используется по умолчанию на JVM 1.6 или более поздних. Менее эффективный `ThreadPoolTaskSupport` является резервом для JVM 1.5 и тех машин, которые не поддерживают пулы "fork-join". `ExecutionContextTaskSupport` берет реализацию контекста исполнения по умолчанию из `scala.concurrent`, и использует тот же пул потоков, что и `scala.concurrent` (в зависимости от версии JVM, это может быть пул "fork-join" или "thread pool executor"). По умолчанию каждой параллельной коллекции назначается именно обслуживание задач контекста выполнения, поэтому параллельные коллекции используют тот же пул "fork-join", что и API объектов "future".
+В настоящее время для параллельных коллекций доступно несколько реализаций объекта поддержки задач. Например, `ForkJoinTaskSupport` реализован посредством "fork-join" пула и используется по умолчанию на JVM 1.6 или более поздних. Менее эффективный `ThreadPoolTaskSupport` является резервом для JVM 1.5 и тех машин, которые не поддерживают пулы "fork-join". `ExecutionContextTaskSupport` по умолчанию берет из `scala.concurrent` объект контекста выполнения `ExecutionContext` и, таким образом, использует тот же пул потоков, что и `scala.concurrent` (в зависимости от версии JVM, это может быть пул "fork-join" или "thread pool executor"). По умолчанию каждой параллельной коллекции назначается именно обслуживание задач контекста выполнения, поэтому параллельные коллекции используют тот же пул "fork-join", что и API объектов "future".
 
 Сменить метод обслуживания задач для параллельной коллекции можно так:
 
@@ -31,15 +31,15 @@ num: 7
     scala> pc map { _ + 1 }
     res0: scala.collection.parallel.mutable.ParArray[Int] = ParArray(2, 3, 4)
 
-Код выше настраивает параллельную коллекцию на использование "fork-join" пула с уровнем параллелизма равным 2. Заставить коллекцию использовать "thread pool executor" можно так:
+Код выше настраивает параллельную коллекцию на использование "fork-join" пула с количеством потоков равным 2. Заставить коллекцию использовать "thread pool executor" можно так:
 
     scala> pc.tasksupport = new ThreadPoolTaskSupport()
     pc.tasksupport: scala.collection.parallel.TaskSupport = scala.collection.parallel.ThreadPoolTaskSupport@1d914a39
 
     scala> pc map { _ + 1 }
     res1: scala.collection.parallel.mutable.ParArray[Int] = ParArray(2, 3, 4)
 
-Когда параллельная коллекция сериализуется, поле объекта обслуживания задач исключается из сериализуемых. Когда параллельная коллекция восстанавливается из полученной последовательности байт, это поле приобретает значение по умолчанию-- способ обслуживания задач контекста выполнения.
+Когда параллельная коллекция сериализуется, поле объекта обслуживания задач исключается из сериализуемых. Когда параллельная коллекция восстанавливается из полученной последовательности байт, это поле приобретает значение по умолчанию, то есть способ обслуживания задач берется из `ExecutionContext`.
 
 Чтобы реализовать собственный механизм поддержки задач, достаточно унаследовать трейт `TaskSupport` и реализовать следующие методы:
 

ru/overviews/parallel-collections/performance.md

@@ -57,10 +57,9 @@ language: ru
 
     java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=300000 Map 10
 
-Флаг `server` требует использовать серверную VM. Флаг `cp` означает "classpath", то есть указывает, что файлы классов требуется искать в текущем каталоге и в jar-архиве библиотеки Scala. Аргументы `-Dpar` и `-Dlength`-- это уровень параллелизма и количество элементов соответственно. Наконец, `10` означает что тест производительности будет запущен на одной и той же JVM именно 10 раз.
+Флаг `server` требует использовать серверную VM. Флаг `cp` означает "classpath", то есть указывает, что файлы классов требуется искать в текущем каталоге и в jar-архиве библиотеки Scala. Аргументы `-Dpar` и `-Dlength`-- это количество потоков и количество элементов соответственно. Наконец, `10` означает что тест производительности будет запущен на одной и той же JVM именно 10 раз.
 
-Устанавливая уровень параллелизма `par` в `1`, `2`, `4` и `8`, получаем следующее время выполнения
-на четырехъядерном i7 с поддержкой гиперпоточности:
+Устанавливая количество потоков `par` в `1`, `2`, `4` и `8`, получаем следующее время выполнения на четырехъядерном i7 с поддержкой гиперпоточности:
 
     Map$	126	57	56	57	54	54	54	53	53	53
     Map$	90	99	28	28	26	26	26	26	26	26