LINUX.ORG.RU

JIT-компиляция не работает

 ,


0

1

Код примерно такой:

public class ... {
     final int ITERATION=1000000000;
     ...
     public void doMeasurement() {
          for (int i = 0; i < ITERATION; i++) {
               long timeMarkStart = System.nanoTime();
               doJavaException();
               long timeMarkEnd = System.nanoTime();
               // Время работы doJavaException() на stdout
               System.out.println(timeMarkEnd - timeMarkStart);
          }
     }
     private static void doJavaException() {
          String testString = new String();
          try {
               testString.contains(null);
          } catch (NullPointerException e) {
               return;
          }
    }
}
Метод doJavaException() каждый раз отрабатывает за примерно одинаковое время, где хваленый jit?
>>> java -version
java version «1.7.0_09»
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
P.S. Опережая очевидный вопрос, хочу ответить, заданием было замерить время выполнения try/catch, потому в doJavaException() и размещена эта порнография.

★★★★★

Или разница в 1.3 раза и есть результат jit-компиляции? Как-то слабенько.

f1xmAn ★★★★★
() автор топика
-XX:+PrintCompilation -XX:CompileThreshold=n
maloi ★★★★★
()

Следующий очевидный вопрос: миллиард мелких замеров — это так и задумывалось?

i-rinat ★★★★★
()
Ответ на: комментарий от Karapuz

Вот ёлки, похоже препод нам нами пошутил, сказав сделать прогрев перед замерами, а потом экспериментально определить, после какой итерации происходит оптимизация.

f1xmAn ★★★★★
() автор топика
Ответ на: комментарий от f1xmAn

Ну ты же понимаешь, что погрешность измерения при таком способе просто чудовищная?

Надо снаружи цикла измерять.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Внутри цикла я замерял время чтобы узнать, когда же произойдет магия. А вообще временные метки у меня стоят перед началом цикла и после него, а само время работы определяется как конец - начало / кол-во итераций.

f1xmAn ★★★★★
() автор топика
Ответ на: комментарий от f1xmAn

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

этот самый nanoTime очень большую погрешность имеет, насколько я помню. я ошибаюсь если что, на йаве не пишу.

nanoolinux ★★★★
()

Но почему исключения? И как вообще представляется возможность их ускорения путем трансляции?

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

note173 ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

не знаю насколько они житятся но процесс заполнения стектрейса - нативная функция, и там тааакие тормоза http://wayerr.livejournal.com/11819.html (там в 10 раз ускорение було)

Deleted
()
Ответ на: комментарий от note173

Но почему исключения?

Изначально заданием было определить разницу во времени выполнения между try/catch и if/else и проделать еще кучу манипуляций с эксепшнами, которые сейчас и изучаем. Ну а т.к. я быстро справился и сидел без дела, препод предложил определить, после какой итерации мой метод doJavaException() преобразуется в нативный код.

f1xmAn ★★★★★
() автор топика
Ответ на: комментарий от nanoolinux

Почему же, у меня в одну переменную кладется время выполнения предыдущей итерации, в другую — текущей. После чего переменные сравниваются и если текущая меньше предыдущей в n раз, то вот и моя оптимизация.

f1xmAn ★★★★★
() автор топика
Ответ на: комментарий от f1xmAn

в n раз

из-за погрешности измерения времени n может прыгать вокруг, допустим единицы. что бы исключить ложные срабатывания ты должен будешь ввесли интервал, что бы отсеить эту погрешность. но тогда если влияние оптимизации меньше чем погрешность, так ты никогда не нейдёшь где начинается оптимизация, т.к. она будет скрыта за «шумом» твоего измерения времени.

допустим на 100 итераций необходимо ровно в десять раз больше времени, чем на 10. тогда график от нуля до ста будет линеен. если же при 1000 начнётся оптимизация, тогда время уже не будет расти линейно, оно будет немного меньше. вот эта дельта и будет влиянем оптимизации и на графике ты эту точку легко увидишь, даже если оптимизация меньше чем шум. инфа 100%.

nanoolinux ★★★★
()

Чтобы корректнее мерять, сделай внешний цикл и вложенный цикл, чтобы вложенный около секунду работал и его меряй и выдавай сразу время, ускорение заметишь, если jit сработает. Ещё желательно кидать свой exception с перегруженным пустым fillInStacktrace, чтобы время лишнее не тратить на ненужные действия.

Legioner ★★★★★
()

Exception вызывает деоптимизацию (что медленно), от того и нет уменьшения времени выполнения doJavaException.

anonymous
()
Ответ на: комментарий от nanoolinux

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

f1xmAn ★★★★★
() автор топика
Ответ на: комментарий от Legioner

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

f1xmAn ★★★★★
() автор топика

1.System.out.println в отдельный поток для печати(ибо без потока разницы не будет)

2.Мерять не внутри программы,а темже time -лучший выход

3.Ваш код неверен,это детская поделка а не код,вы не знаете как работает java

anonymous
()
Ответ на: комментарий от anonymous

1.System.out.println в отдельный поток для печати(ибо без потока разницы не будет)

Разницы с чем? System.out.println за пределами измеряемой области.

2.Мерять не внутри программы,а темже time -лучший выход

А как мне time замерить скорость выполнения не всей программы, а отдельного участка кода?

3.Ваш код неверен,это детская поделка а не код,вы не знаете как работает java

Что, правда? Не может быть!

f1xmAn ★★★★★
() автор топика
Ответ на: комментарий от f1xmAn

Разницы с чем? System.out.println за пределами измеряемой области.

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

У вас в коде вызов ФУНКЦИИ из одного класса где и вызов Систем....весь класс постоянно будет «обрабатываться».

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

А как мне time замерить скорость выполнения не всей программы, а отдельного участка кода?

Для этого есть отладочные версии(которые вы должны сделать),и средства отладки JVM

anonymous
()
Ответ на: комментарий от anonymous

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

Да вы упоролись, комилируется не класс, а его методы и не все разом, а по необходимости. Более того, можно при запуске jvm явно указать какие можно компилировать, а какие нет.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.