MN
в этом коде имеет смысл только for но возвращать какой то результат ?
Size: a a a
2020 May 02
MN
все тема закрыто
MN
вот вопрос как измерят как долго выполняется метод и пытался вызывать System.currentTimeMillis() но всегда ноль неужели они так быстро идут и как увеличить точность если метод менше секунды
MN
просто проверяю сортировку
I
Привет одночатовцам!
Пока есть свободные деньки, решил поднять вопрос, который меня очень волнует. А именно, проблемы организации и оптимизации процессов в ИТ. Сижу в чатах, пытаюсь понять у кого что болит, кто как работает, кто какими способами укрощает Жиру и т.п.
Для этого даже подготовил небольшой опрос на 10-15 минут https://forms.gle/GikcgMiskNGSVzPTA
Кто сталкивается с граблями работы вашей команды или кто наоборот достиг дзена, пожалуйста, не поленитесь пройти! Это не реклама, не спам и не осуществление коммерческой деятельности) Так что welcome!
Пока есть свободные деньки, решил поднять вопрос, который меня очень волнует. А именно, проблемы организации и оптимизации процессов в ИТ. Сижу в чатах, пытаюсь понять у кого что болит, кто как работает, кто какими способами укрощает Жиру и т.п.
Для этого даже подготовил небольшой опрос на 10-15 минут https://forms.gle/GikcgMiskNGSVzPTA
Кто сталкивается с граблями работы вашей команды или кто наоборот достиг дзена, пожалуйста, не поленитесь пройти! Это не реклама, не спам и не осуществление коммерческой деятельности) Так что welcome!
этот вопрос более актуален тут: @tlbootcamp
Р
этот вопрос более актуален тут: @tlbootcamp
Огроиное спасибо за наводку)
AE
Привет. Может у меня странный вопрос, но тем не менее.
Допустим, есть вот такой кусочек кода:
Я решил с помощью утилиты JitWatch поизучать то, как оптимизируется этот код JIT компилятором. Первое, что мне показалось валидным, так это инлайнинг в main ф-ции
Теперь можно перейти к сути вопроса. Похоже ли то, что по факту JIT "видоизменяет"
И если да, то сильно ли это влияет на буст?
Допустим, есть вот такой кусочек кода:
public static void main(String[] args){
for (int i = 0; i < 100000000; i++) {
isNonNegative(5);
}
}
private static void isNonNegative(int num) {
if (num >= 0) {
// Some operations here...
int a = num / 1000 - 50;
if (a < 0) a = -1 * a;
int result = fastFibonacci(a);
} else {
// Some operations here...
int result = slowFibonacci(num);
}
}
Он достаточно прост, N-раз вызывается некоторая ф-ция, которая обрабатывает это число n.Я решил с помощью утилиты JitWatch поизучать то, как оптимизируется этот код JIT компилятором. Первое, что мне показалось валидным, так это инлайнинг в main ф-ции
isNonNegativeВторое, мне показалось, что вторую ветку с else-условием в принципе можно опустить на уровне assembler-кода. Я решил посмотреть чем в действительности отличается компиляция client/server компиляторов (https://ibb.co/3yQCfH1 и https://ibb.co/f8zN94Y). На сколько я понял из этих скринов, всё таки C2 решил затереть else-бранчу.
Теперь можно перейти к сути вопроса. Похоже ли то, что по факту JIT "видоизменяет"
isNonNegative, убирая else-ветку?
И если да, то сильно ли это влияет на буст?
MN
Привет. Может у меня странный вопрос, но тем не менее.
Допустим, есть вот такой кусочек кода:
Я решил с помощью утилиты JitWatch поизучать то, как оптимизируется этот код JIT компилятором. Первое, что мне показалось валидным, так это инлайнинг в main ф-ции
Теперь можно перейти к сути вопроса. Похоже ли то, что по факту JIT "видоизменяет"
И если да, то сильно ли это влияет на буст?
Допустим, есть вот такой кусочек кода:
public static void main(String[] args){
for (int i = 0; i < 100000000; i++) {
isNonNegative(5);
}
}
private static void isNonNegative(int num) {
if (num >= 0) {
// Some operations here...
int a = num / 1000 - 50;
if (a < 0) a = -1 * a;
int result = fastFibonacci(a);
} else {
// Some operations here...
int result = slowFibonacci(num);
}
}
Он достаточно прост, N-раз вызывается некоторая ф-ция, которая обрабатывает это число n.Я решил с помощью утилиты JitWatch поизучать то, как оптимизируется этот код JIT компилятором. Первое, что мне показалось валидным, так это инлайнинг в main ф-ции
isNonNegativeВторое, мне показалось, что вторую ветку с else-условием в принципе можно опустить на уровне assembler-кода. Я решил посмотреть чем в действительности отличается компиляция client/server компиляторов (https://ibb.co/3yQCfH1 и https://ibb.co/f8zN94Y). На сколько я понял из этих скринов, всё таки C2 решил затереть else-бранчу.
Теперь можно перейти к сути вопроса. Похоже ли то, что по факту JIT "видоизменяет"
isNonNegative, убирая else-ветку?
И если да, то сильно ли это влияет на буст?
советую задать этот вопрос на stackoverflow или поискать его , извини до JiT я еще не дошел
ЖМ
Привет. Может у меня странный вопрос, но тем не менее.
Допустим, есть вот такой кусочек кода:
Я решил с помощью утилиты JitWatch поизучать то, как оптимизируется этот код JIT компилятором. Первое, что мне показалось валидным, так это инлайнинг в main ф-ции
Теперь можно перейти к сути вопроса. Похоже ли то, что по факту JIT "видоизменяет"
И если да, то сильно ли это влияет на буст?
Допустим, есть вот такой кусочек кода:
public static void main(String[] args){
for (int i = 0; i < 100000000; i++) {
isNonNegative(5);
}
}
private static void isNonNegative(int num) {
if (num >= 0) {
// Some operations here...
int a = num / 1000 - 50;
if (a < 0) a = -1 * a;
int result = fastFibonacci(a);
} else {
// Some operations here...
int result = slowFibonacci(num);
}
}
Он достаточно прост, N-раз вызывается некоторая ф-ция, которая обрабатывает это число n.Я решил с помощью утилиты JitWatch поизучать то, как оптимизируется этот код JIT компилятором. Первое, что мне показалось валидным, так это инлайнинг в main ф-ции
isNonNegativeВторое, мне показалось, что вторую ветку с else-условием в принципе можно опустить на уровне assembler-кода. Я решил посмотреть чем в действительности отличается компиляция client/server компиляторов (https://ibb.co/3yQCfH1 и https://ibb.co/f8zN94Y). На сколько я понял из этих скринов, всё таки C2 решил затереть else-бранчу.
Теперь можно перейти к сути вопроса. Похоже ли то, что по факту JIT "видоизменяет"
isNonNegative, убирая else-ветку?
И если да, то сильно ли это влияет на буст?
Если будет выполнено условие для else ветки, профиль пересоберется и там будет код уже с else веткой
AE
Если будет выполнено условие для else ветки, профиль пересоберется и там будет код уже с else веткой
Значит всё верно. Причём самое главное, чтобы кол-во таких итераций было соответствующим для с2 компилятора.
ЖМ
Я бы посоветовал почитать в принципе как работает JIT, собственно ответ на вопрос "видоизменяет ли JIT компилятор код?", кроется в его названии - Just In Time, он для этого и создан
o
Я бы посоветовал почитать в принципе как работает JIT, собственно ответ на вопрос "видоизменяет ли JIT компилятор код?", кроется в его названии - Just In Time, он для этого и создан
а где это почитать?
AE
Я бы посоветовал почитать в принципе как работает JIT, собственно ответ на вопрос "видоизменяет ли JIT компилятор код?", кроется в его названии - Just In Time, он для этого и создан
В данном случае тут важно какой именно компилятор изменяет этот код. Инлайнинг в любом случае будет происходить, но если мы говорим про то, что убирается ненужная ветка else, то как тогда ускоряется работа программы в конкретно этом случае?
2020 May 03
DB
В данном случае тут важно какой именно компилятор изменяет этот код. Инлайнинг в любом случае будет происходить, но если мы говорим про то, что убирается ненужная ветка else, то как тогда ускоряется работа программы в конкретно этом случае?
ты уверен что там именно удаляется ветка else?
если я правильно понимаю, там должен быть trap в jvm, если в эту ветку вдруг зайдет исполнение
если я правильно понимаю, там должен быть trap в jvm, если в эту ветку вдруг зайдет исполнение
DB
как ускоряется - возможно просто не компилируется лишний код да и всё (формально так-то это ускорение, т.к. меньше jit потребляет времени проца)
(возможно есть какие-нибудь варианты в духе "меньше кода генерируется - проще кешам инструкций", но я не эксперт, это предположение без каких-то док-в)
(возможно есть какие-нибудь варианты в духе "меньше кода генерируется - проще кешам инструкций", но я не эксперт, это предположение без каких-то док-в)
DB
> Инлайнинг в любом случае будет происходить
как раз если больше инструкций получается для метода isNonNegative и чем сложнее он в итоге выглядит, тем меньше шансов что он будет заинлайнен
как раз если больше инструкций получается для метода isNonNegative и чем сложнее он в итоге выглядит, тем меньше шансов что он будет заинлайнен
AE
> Инлайнинг в любом случае будет происходить
как раз если больше инструкций получается для метода isNonNegative и чем сложнее он в итоге выглядит, тем меньше шансов что он будет заинлайнен
как раз если больше инструкций получается для метода isNonNegative и чем сложнее он в итоге выглядит, тем меньше шансов что он будет заинлайнен
Подожди, тут же мы вызываем всегда метод с одним значением, метод 100% будет заинлайнен)
DB
Подожди, тут же мы вызываем всегда метод с одним значением, метод 100% будет заинлайнен)
так это не "заинлайнен", а "сразу вычислено значение"
инлайн - это когда ты берешь целиком метод, (выбрасываешь пролог/эпилог/...), и подставляешь его код в вызывающую строку
то что значение всегда одинаково - это вопрос вообще к методологии твоей; если честно, это "опасные" штуки, т.к. желательно компилятору давать знать что все ветки в коде "значимы" и для него нет возможности сделать dead code elimination и т.д.
инлайн - это когда ты берешь целиком метод, (выбрасываешь пролог/эпилог/...), и подставляешь его код в вызывающую строку
то что значение всегда одинаково - это вопрос вообще к методологии твоей; если честно, это "опасные" штуки, т.к. желательно компилятору давать знать что все ветки в коде "значимы" и для него нет возможности сделать dead code elimination и т.д.
AE
как ускоряется - возможно просто не компилируется лишний код да и всё (формально так-то это ускорение, т.к. меньше jit потребляет времени проца)
(возможно есть какие-нибудь варианты в духе "меньше кода генерируется - проще кешам инструкций", но я не эксперт, это предположение без каких-то док-в)
(возможно есть какие-нибудь варианты в духе "меньше кода генерируется - проще кешам инструкций", но я не эксперт, это предположение без каких-то док-в)
Ну просто если у нас есть инлайнинг, то это в данном случае и правда ускорит компиляцию. Но неужели какой-то лишний else-бранч так влияет на общую картину 🤔