Странное падение производительности JDK8 LocalDate.toEpochDay

Question

Мне было любопытно, если мы наконец получим быструю библиотеку datetime с JDK8. Почти все вычисления LocalDate используют toEpochDay, поэтому я посмотрел на source, и большое количество подразделений и филиалов мне с любопытством, если бы я мог сделать лучше.

Я устранил некоторые ветвление и все, но одно деление, однако убыстрение хуже, чем ожидалось. Поэтому мой первый вопрос: как возможно, что алгоритм с использованием множественного деления занимает всего около 30 циклов (пропускная способность). Комментарии Хольгера, кажется, ответили на это: Подразделение по небольшой константе получает JIT-ed для умножения. Я сделал это вручную, и теперь я постоянно избивая первоначальную реализацию с коэффициентом 2.

benchmark довольно просто, просто итерация хотя массив случайных LocalDate с и преобразования каждого из них toEpochDay. Несмотря на случайность, results довольно последовательны. Размер массива - это параметр, и мой главный вопрос: , где большое замедление между 2000 и 30000 происходит от. Должно быть некоторое замедление, поскольку данные больше не вписываются в кеш-память L1, но обращения к памяти обоих алгоритмов абсолютно одинаковы (т. Е. Нет, но выбор date из массива).

Вопрос по-прежнему открытым: Как получается, что поведение двух простых реализаций без доступа к памяти с той же функцией изменяется при итерации по массиву? Исходный алгоритм страдает гораздо более сильным замедлением, чем мой.

Answer 1

thats, потому что в алгоритме нет делений. все/4 заменяются сдвигами. и все/100 на самом деле составляют 0,01. подразделения существуют для чтения (хе-хе). im не уверен, что эта оптимизация происходит во время выключения байт-кода или компиляции JIT, было бы интересно посмотреть на файл класса и узнать.

Answer 2

Я не поймал причину напрямую, но это, безусловно, недостаток базового уровня. Что-то связано с расходами GC и per-invocation. У меня такая же деградация производительности с JMH, кроме скамейки со 100 датами, которая показывает лучший перфект, чем с 2000 датами. Я попытался создать массив dates с максимальным размером и перебрать только первые 100, 2000, 30000 элементов. В этом случае все версии выполнялись одинаково (15.3 + - 0.3 нс на моей машине).

import org.openjdk.jmh.annotations.*; 

import java.time.LocalDate; 
import java.util.*; 
import java.util.concurrent.ThreadLocalRandom; 
import java.util.concurrent.TimeUnit; 


@State(Scope.Benchmark) 
@BenchmarkMode(Mode.AverageTime) 
@OperationsPerInvocation(LocalDateBenchmark.ITERATIONS) 
@OutputTimeUnit(TimeUnit.NANOSECONDS) 
public class LocalDateBenchmark { 
    public static final int MAX_ITERATIONS = 1000000; 
    public static final int ITERATIONS = 30000; 

    private static final LocalDate MIN_DATE = LocalDate.of(1900, 1, 1); 
    private static final LocalDate MAX_DATE = LocalDate.of(2100, 1, 1); 
    private static final int DAYS_BETWEEN = (int) (MAX_DATE.toEpochDay() - MIN_DATE.toEpochDay()); 

    public LocalDate[] dates = new LocalDate[MAX_ITERATIONS]; 
    private Random random; 

    @Setup(Level.Trial) 
    public void setUpAll() { 
     Random r = ThreadLocalRandom.current(); 
     for (int i=0; i< dates.length; ++i) { 
      dates[i] = MIN_DATE.plusDays(r.nextInt(DAYS_BETWEEN)); 
     } 
    } 

    @Setup(Level.Iteration) 
    public void setUpRandom() { 
     random = new Random(); 
    } 

    @GenerateMicroBenchmark 
    public int timeToEpochDay(LocalDateBenchmark state) { 
     int result = 0; 
     LocalDate[] dates = state.dates; 
     int offset = random.nextInt(MAX_ITERATIONS - ITERATIONS); 
     for (int i = offset; i < offset + ITERATIONS; i++) { 
      LocalDate date = dates[i]; 
      result += date.toEpochDay(); 
     } 
     return result; 
    } 
}