Java ForkJoin Многопоточный медленнее, чем один поток

Я опробовал среду Java ForkJoin и написал простую тестовую программу, которая устанавливает пиксели изображения в случайные цвета. Например, он генерирует псевдошум.

Но во время тестирования производительности я обнаружил, что на самом деле быстрее запускать однопоточный, чем запускать его с несколькими потоками. Я заставляю его работать однопоточно, преодолев высокий порог.

Это класс рабочий класс:

public class Noise extends RecursiveAction {

    private BufferedImage image;
    private int xMin;
    private int yMin;
    private int xMax;
    private int yMax;
    private int threshold = 2000000; // max pixels per thread

    public Noise(BufferedImage image, int xMin, int yMin, int xMax, int yMax, int threshold) {
        this.image = image;
        this.xMin = xMin;
        this.yMin = yMin;
        this.xMax = xMax;
        this.yMax = yMax;
        this.threshold = threshold;
    }

    public Noise(BufferedImage image, int xMin, int yMin, int xMax, int yMax) {
        this.image = image;
        this.xMin = xMin;
        this.yMin = yMin;
        this.xMax = xMax;
        this.yMax = yMax;
    }

    @Override
    protected void compute() {
        int ppt = (xMax - xMin) * (yMax - yMin); // pixels pet thread
        if(ppt > threshold) {
            // split
            int verdeling = ((xMax - xMin) / 2) + xMin;
            invokeAll(new Noise(image, xMin, yMin, verdeling, yMax),
                    new Noise(image, verdeling+1, yMin, xMax, yMax));
        }
        else {
            // execute!
            computeDirectly(xMin, yMin, xMax, yMax);
        }
    }

    private void computeDirectly(int xMin, int yMin, int xMax, int yMax) {
        Random generator = new Random();
        for (int x = xMin; x < xMax; x++) {
            for (int y = yMin; y < yMax; y++) {
                //image.setPaint(new Color(generator.nextInt()));
                int rgb = generator.nextInt();
                int red = (rgb >> 16) & 0xFF;
                int green = (rgb >> 8) & 0xFF;
                int blue = rgb & 0xFF;

                red = (int) Math.round((Math.log(255L) / Math.log((double) red)) * 255);
                green = (int) Math.round((Math.log(255L) / Math.log((double) green)) * 255);
                blue = (int) Math.round((Math.log(255L) / Math.log((double) blue)) * 255);

                int rgbSat = red;
                rgbSat = (rgbSat << 8) + green;
                rgbSat = (rgbSat << 8) + blue;

                image.setRGB(x, y, rgbSat);
            }

        }
        Graphics2D g2D = image.createGraphics();
        g2D.setPaint(Color.RED);
        g2D.drawRect(xMin, yMin, xMax-xMin, yMax-yMin);
    }
}

При создании изображения 6000 * 6000 получаются следующие результаты:
Одиночный поток: 9,4 с при загрузке процессора 25%
Многопоточность: 16,5 с при загрузке процессора 80%-90%
(Core2quad Q9450)

Почему многопоточная версия медленнее?
Как это исправить?

Источник

4 ответа

Решение

Прежде всего, F/J - нишевый продукт. Если у вас нет огромного массива и вы обрабатываете его как DAG, значит, вы используете не тот продукт. Конечно, F/J может использовать несколько процессоров, но так же можно использовать простой многопоточный подход без дополнительных затрат на F/J.

Попробуйте использовать четыре темы и просто дайте каждому четверть работы напрямую.

Вот как F / J должен был использоваться:

Sum left  = new Sum(array, low, mid);
Sum right = new Sum(array, mid, high);
left.fork();
long rightAns = right.compute();
long leftAns   = left.join();
return leftAns + rightAns;

Когда вы не спускаетесь по листьям структурированного дерева, тогда все ставки выключены.

Источник

Я думаю, что обнаруженная вами проблема не связана напрямую с вашим кодом, виновником был метод BufferedImage#setRGB() :

      public synchronized void setRGB(int x, int y, int rgb) {...}

Таким образом, тестовый пример был таким медленным из-за разногласий по этому методу.

В качестве обходного пути в JDK 8 вы можете использовать аналогичный метод:

      public void setRGB(int startX, int startY, int w, int h,
                   int[] rgbArray, int offset, int scansize) {...}

Начиная с JDK 10 это больше не проблема, ключевое слово synchronized было удалено: https://bugs.openjdk.java.net/browse/JDK-8183576

Вот мое время исполнения:

Источник

Я думаю, что вы хотите использовать ThreadLocalRandom вместо Random.

http://docs.oracle.com/javase/tutorial/essential/concurrency/threadlocalrandom.html

Источник

Из-за накладных расходов? Форкинг и соединение также требуют времени.. может быть, вам нужен больший набор тестов? Или больше работать в самих темах?

Источник
Другие вопросы по тегам