java 8 потоков: почему параллельный поток медленнее?

<p>я играю с потоками java 8 и не могу понять результаты производительности, которые я получаю. у меня 2-х ядерный процессор (intel i73520m), windows 8 x64 и 64-битное java 8 обновление 5. я делаю простую карту для потока/параллельного потока строк и обнаружил, что параллельная версия несколько медленнее.</p><pre><code>function<stream<string>, long> timeoperation = (stream<string> stream) -> { long time1 = system.nanotime(); final list<string> list = stream .map(string::tolowercase) .collect(collectors.tolist()); long time2 = system.nanotime(); return time2 - time1; }; consumer<stream<string>> printtime = stream -> system.out.println(timeoperation.apply(stream) / 1000000f); string[] array = new string[1000000]; arrays.fill(array, "ababagalamaga"); printtime.accept(arrays.stream(array)); // prints around 600 printtime.accept(arrays.stream(array).parallel()); // prints around 900 </code></pre><p>разве параллельная версия не должна быть быстрее, учитывая тот факт, что у меня 2 ядра процессора? может ли кто-нибудь дать мне подсказку, почему параллельная версия медленнее?</p>

<p>здесь параллельно происходит несколько вопросов.</p><p>во-первых, параллельное решение проблемы всегда подразумевает выполнение более актуальной работы, чем выполнение ее последовательно. накладные расходы связаны с разделением работы между несколькими потоками и объединением или объединением результатов. проблемы, такие как преобразование коротких строк в нижний регистр, достаточно малы, так что они могут быть забиты параллельным разделением заголовка.</p><p>вторая проблема заключается в том, что программа java бенчмаркинга очень тонкая, и очень легко получить запутанные результаты. две распространенные проблемы - это компиляция jit и устранение мертвого кода. короткие тесты часто заканчиваются до или во время jit-компиляции, поэтому они не измеряют пиковую пропускную способность, и на самом деле они могут измерять сам jit. когда происходит компиляция, она несколько недетерминирована, поэтому она может привести к резкому изменению результатов.</p><p>для небольших синтетических тестов рабочая нагрузка часто вычисляет выброшенные результаты. jit-компиляторы достаточно хороши в обнаружении этого и устранении кода, который не дает результатов, которые используются где-либо. это, вероятно, не происходит в этом случае, но если вы возитесь с другими синтетическими рабочими нагрузками, это, безусловно, может произойти. конечно, если jit устраняет нагрузку на эталонный тест, он делает эталонный тест бесполезным.</p><p>я настоятельно рекомендую использовать хорошо разработанный фреймворк для тестирования, такой как <a href="http://openjdk.java.net/projects/code-tools/jmh/">jmh</a> , вместо того, чтобы использовать свой собственный. у jmh есть средства, помогающие избежать распространенных ошибок, связанных с бенчмаркингом, в том числе эти, и его довольно легко настроить и запустить. вот ваш тест, преобразованный для использования jmh:</p><pre><code>package com.stackoverflow.questions; import java.util.arrays; import java.util.list; import java.util.stream.collectors; import java.util.concurrent.timeunit; import org.openjdk.jmh.annotations.*; public class so23170832 { @state(scope.benchmark) public static class benchmarkstate { static string[] array; static { array = new string[1000000]; arrays.fill(array, "ababagalamaga"); } } @generatemicrobenchmark @outputtimeunit(timeunit.seconds) public list<string> sequential(benchmarkstate state) { return arrays.stream(state.array) .map(x -> x.tolowercase()) .collect(collectors.tolist()); } @generatemicrobenchmark @outputtimeunit(timeunit.seconds) public list<string> parallel(benchmarkstate state) { return arrays.stream(state.array) .parallel() .map(x -> x.tolowercase()) .collect(collectors.tolist()); } } </code></pre><p>я запустил это с помощью команды:</p><pre><code>java -jar dist/microbenchmarks.jar ".*so23170832.*" -wi 5 -i 5 -f 1 </code></pre><p>(опции указывают пять итераций разминки, пять итераций бенчмарка и одну разветвленную jvm.) во время своего запуска jmh выдает множество подробных сообщений, которые я пропустил. итоговые результаты следующие.</p><pre><code>benchmark mode samples mean mean error units c.s.q.so23170832.parallel thrpt 5 4.600 5.995 ops/s c.s.q.so23170832.sequential thrpt 5 1.500 1.727 ops/s </code></pre><p>обратите внимание, что результаты отображаются в секундах в секунду, поэтому похоже, что параллельный запуск был примерно в три раза быстрее, чем последовательный запуск. но у моей машины только два ядра. хммм. и средняя ошибка за цикл на самом деле больше, чем среднее время выполнения! wat? здесь происходит что-то подозрительное.</p><p>это подводит нас к третьему вопросу. при более пристальном рассмотрении рабочей нагрузки мы видим, что он выделяет новый объект string для каждого ввода, а также собирает результаты в список, который включает много перераспределения и копирования. я предполагаю, что это приведет к изрядному количеству мусора. мы можем увидеть это, перезапустив тест с включенными сообщениями gc:</p><pre><code>java -verbose:gc -jar dist/microbenchmarks.jar ".*so23170832.*" -wi 5 -i 5 -f 1 </code></pre><p>это дает результаты как:</p><pre><code>[gc (allocation failure) 512k->432k(130560k), 0.0024130 secs] [gc (allocation failure) 944k->520k(131072k), 0.0015740 secs] [gc (allocation failure) 1544k->777k(131072k), 0.0032490 secs] [gc (allocation failure) 1801k->1027k(132096k), 0.0023940 secs] # run progress: 0.00% complete, eta 00:00:20 # vm invoker: /users/src/jdk/jdk8-b132.jdk/contents/home/jre/bin/java # vm options: -verbose:gc # fork: 1 of 1 [gc (allocation failure) 512k->424k(130560k), 0.0015460 secs] [gc (allocation failure) 933k->552k(131072k), 0.0014050 secs] [gc (allocation failure) 1576k->850k(131072k), 0.0023050 secs] [gc (allocation failure) 3075k->1561k(132096k), 0.0045140 secs] [gc (allocation failure) 1874k->1059k(132096k), 0.0062330 secs] # warmup: 5 iterations, 1 s each # measurement: 5 iterations, 1 s each # threads: 1 thread, will synchronize iterations # benchmark mode: throughput, ops/time # benchmark: com.stackoverflow.questions.so23170832.parallel # warmup iteration 1: [gc (allocation failure) 7014k->5445k(132096k), 0.0184680 secs] [gc (allocation failure) 7493k->6346k(135168k), 0.0068380 secs] [gc (allocation failure) 10442k->8663k(135168k), 0.0155600 secs] [gc (allocation failure) 12759k->11051k(139776k), 0.0148190 secs] [gc (allocation failure) 18219k->15067k(140800k), 0.0241780 secs] [gc (allocation failure) 22167k->19214k(145920k), 0.0208510 secs] [gc (allocation failure) 29454k->25065k(147456k), 0.0333080 secs] [gc (allocation failure) 35305k->30729k(153600k), 0.0376610 secs] [gc (allocation failure) 46089k->39406k(154624k), 0.0406060 secs] [gc (allocation failure) 54766k->48299k(164352k), 0.0550140 secs] [gc (allocation failure) 71851k->62725k(165376k), 0.0612780 secs] [gc (allocation failure) 86277k->74864k(184320k), 0.0649210 secs] [gc (allocation failure) 111216k->94203k(185856k), 0.0875710 secs] [gc (allocation failure) 130555k->114932k(199680k), 0.1030540 secs] [gc (allocation failure) 162548k->141952k(203264k), 0.1315720 secs] [full gc (ergonomics) 141952k->59696k(159232k), 0.5150890 secs] [gc (allocation failure) 105613k->85547k(184832k), 0.0738530 secs] 1.183 ops/s </code></pre><p>примечание: строки, начинающиеся с <code>#</code>, являются обычными выходными строками jmh. все остальные сообщения gc. это только первая из пяти итераций прогрева, которая предшествует пяти итерациям бенчмарка. сообщения gc продолжали в том же духе в течение остальных итераций. я думаю, можно с уверенностью сказать, что в измеренной производительности преобладают издержки gc и что в представленные результаты не следует верить.</p><p>на данный момент неясно, что делать. это чисто синтетическая нагрузка. это явно требует очень мало процессорного времени для выполнения реальной работы по сравнению с выделением и копированием. трудно сказать, что вы на самом деле пытаетесь измерить здесь. один из подходов состоит в том, чтобы придумать другую рабочую нагрузку, которая в некотором смысле более "реальна". другой подход заключается в изменении параметров кучи и gc, чтобы избежать gc во время выполнения теста.</p>

<p>при выполнении тестов вы должны обращать внимание на jit-компиляцию, и это поведение синхронизации может меняться в зависимости от количества путей jit-компилированного кода. если я добавлю фазу прогрева в вашу тестовую программу, параллельная версия будет немного быстрее, чем последовательная. вот результаты:</p><pre><code>warmup... benchmark... run 0: sequential 0.12s - parallel 0.11s run 1: sequential 0.13s - parallel 0.08s run 2: sequential 0.15s - parallel 0.08s run 3: sequential 0.12s - parallel 0.11s run 4: sequential 0.13s - parallel 0.08s </code></pre><p>следующий фрагмент кода содержит полный исходный код, который я использовал для этого теста.</p><pre><code>public static void main(string... args) { string[] array = new string[1000000]; arrays.fill(array, "ababagalamaga"); system.out.println("warmup..."); for (int i = 0; i < 100; ++i) { sequential(array); parallel(array); } system.out.println("benchmark..."); for (int i = 0; i < 5; ++i) { system.out.printf("run %d: sequential %s - parallel %s\n", i, test(() -> sequential(array)), test(() -> parallel(array))); } } private static void sequential(string[] array) { arrays.stream(array).map(string::tolowercase).collect(collectors.tolist()); } private static void parallel(string[] array) { arrays.stream(array).parallel().map(string::tolowercase).collect(collectors.tolist()); } private static string test(runnable runnable) { long start = system.currenttimemillis(); runnable.run(); long elapsed = system.currenttimemillis() - start; return string.format("%4.2fs", elapsed / 1000.0); } </code></pre>

<p>использование нескольких потоков для обработки ваших данных требует некоторых начальных настроек, например, инициализация пула потоков. эти затраты могут перевесить выгоды от использования этих потоков, особенно если время выполнения уже довольно низкое. кроме того, если есть спор, например, в других запущенных потоках, фоновых процессах и т. д. производительность параллельной обработки может снизиться.</p><p>эта проблема не нова для параллельной обработки. в этой статье приводятся некоторые подробности в свете java 8 <code>parallel()</code> и некоторые другие вопросы, которые необходимо учитывать: <a href="http://java.dzone.com/articles/think-twice-using-java-8">http://java.dzone.com/articles/think-twice-using-java-8</a> </p>