Почему GraalVM CE имеет меньшую пропускную способность, чем GraalVM EE или OpenJDK 8 - PullRequest
Новая
       25

Почему GraalVM CE имеет меньшую пропускную способность, чем GraalVM EE или OpenJDK 8

0 голосов
/ 16 декабря 2018

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

@Benchmark
  def longestCommonSubsequenceDP(): String = {
    val s1 = "Pellentesque lacinia"
    val s2 = "Mauris purus massa"
    val up = 1
    val left = 2
    val charMatched = 3

    val s1Length = s1.length()
    val s2Length = s2.length()

    val lcsLengths = Array.fill[Int](s1Length + 1, s2Length + 1)(0)

    for (i <- 0 until s1Length) {
      for (j <- 0 until s2Length) {
        if (s1.charAt(i) == s2.charAt(j)) {
          lcsLengths(i + 1)(j + 1) = lcsLengths(i)(j) + 1
        } else {
          if (lcsLengths(i)(j + 1) >= lcsLengths(i + 1)(j)) {
            lcsLengths(i + 1)(j + 1) = lcsLengths(i)(j + 1)
          } else {
            lcsLengths(i + 1)(j + 1) = lcsLengths(i + 1)(j)
          }
        }
      }
    }

    val subSeq = new StringBuilder()
    var s1Pos = s1Length
    var s2Pos = s2Length

    do {
      if (lcsLengths(s1Pos)(s2Pos) == lcsLengths(s1Pos -1)(s2Pos)) {
        s1Pos -= 1
      } else if (lcsLengths(s1Pos)(s2Pos) == lcsLengths(s1Pos)(s2Pos - 1)) {
        s2Pos -= 1
      } else {
        assert(s1.charAt(s1Pos - 1) == s2.charAt(s2Pos - 1))
        subSeq += s1.charAt(s1Pos - 1)
        s1Pos -= 1
        s2Pos -= 1
      }

    } while (s1Pos > 0 && s2Pos > 0)

    subSeq.toString.reverse
  }

, и запустил его со следующей конфигурацией jmh:run -i 10 -wi 10 -f1 -t1 и получил следующие результаты:

GraalVM EE 1.0.0-rc10 

[info] Benchmark                        Mode  Cnt   Score   Error   Units
[info] LCS.longestCommonSubsequenceDP  thrpt   25  91.411 ± 4.355  ops/ms

GraalVM CE 1.0.0-rc10 

[info] Benchmark                        Mode  Cnt   Score   Error   Units
[info] LCS.longestCommonSubsequenceDP  thrpt   25  26.741 ± 0.408  ops/ms

OpenJDK 1.8.0_192 

[info] Benchmark                        Mode  Cnt   Score   Error   Units
[info] LCS.longestCommonSubsequenceDP  thrpt   25  45.216 ± 1.956  ops/ms

ТакжеЯ провел еще один тест, в котором я создал список с тысячами объектов, провел некоторую фильтрацию и сортировку, и thrpt был самым маленьким в GraalVM CE.

Почему это различие?

1 Ответ

0 голосов
/ 17 декабря 2018

Вы получите разные результаты, потому что во время выполнения вы используете разные JIT-компиляторы высшего уровня.Если не указано иное (например, с флагами команд):

  • OpenJDK 1.8.0_192 использует C2
  • GraalVM CE 1.0.0-rc10 использует компилятор Graal.
  • GraalVM EE 1.0.0-rc10 использует корпоративную версию компилятора Graal.

JIT компилирует ваш код во время выполнения в машинный код, который сильно зависит от исходного кода, рабочей нагрузки, конфигурации JIT, включенных оптимизаций и так далее.

Разумно ожидать, что разные реализации JIT-компилятора будут показывать разные результаты в одном и том же тесте.

Если вы спрашиваете, почему GraalVM CE не показывает лучшие результаты в этом конкретном тесте, скорее, философский вопрос о разнице в целом;вот краткое объяснение.Все компиляторы в чем-то хороши, например, Graal имеет превосходный анализ escape и встроенные алгоритмы, которые показывают отличные результаты в коде, который использует абстракции: выделяет объекты, вызывает методы и т. Д.

Этот конкретный тест заполняет массиввставляет и запускает цикл.Что, вероятно, не позволяет Граалу делать то, что у него хорошо получается.Таким образом, это пример микробенчмарка C2 лучше.Вероятно, вы можете создать аналогичный тест, который GraalVM CE будет показывать превосходство над OpenJDK (возможно, вы можете попробовать это: http://www.graalvm.org/docs/examples/java-simple-stream-benchmark/).

Команда GraalVM запускает большой набор тестов, и это источникзнание того, что GraalVM CE лучше, однако нужно понимать, что сведение сложного набора результатов тестов к одному числу - не самая значимая вещь для оценки производительности любого конкретного фрагмента кода и его рабочей нагрузки. Всегда следует стремиться оценитьпо их коду.

...