A
Наоборот
Size: a a a
2021 July 03
A
Это 0
K
короче как минимум тебе нужно делать switch по Mul/div (если не менять алгоритм)
K
mul делить на div
K
у тебя от этого зависит, а не от бесконечных ифов
K
раскрывается в таблицу переходов
TG
mulltiplier = 8, divider = 4 идёт по медленному пути, я пока таких анимаций ещё не встретил, где кейфреймы так далеко расположены (30/8 - порядка 0.125 сек на кейфрейм)
K
и как я говорил статистику
A
Бтв можно же просто в один так например расписать switch (int64(int32 << 32, int32)) {
}
}
TG
если mul делить на div, получится плохо, т.к. целые числа
d
так мы не знаем их значений в компил тайме
A
Добавлять новые кейсы если захочешь будет проще, к тому же
K
короче всё это воняет таблицей функций table[5][5], которые выбираются за нормальное время без бесконечных ифов
TG
как вариант
A
Кст из интересных вариантов оптимизации можешь попробовать заставить инлайнить компилятор простые, ожидаемые варианты (fast path) и неинлайнить медленные (slow path)
TG
по-хорошему, нужна PGO, но я не знаю как её можно собрать с геймбоя )
AT
я там не вижу call
A
Ну предлагается неинлайнить то что работает редко/долго, так как это может влиять на то что работает быстро и часто. Если ты мне
AT
это даст выигрыш, если в камне есть спекулятивное исполнение и предсказание переходов, предвыборка в кеш инструкций и предаврительное декодирование. Если всего этого нет, то о чём беспокоиться?
K
я так понимаю мой вариант со сбором статистики не рассматривается