portnov
есть гм... проблема кодстайла

Minoru
portnov: пока гуглил, понял, что неправильно вспомнил размер линии кеша — она же 64 *байта*, а не бита. Т.е. даже если JVM всё выравнивает до восьми байт, все равно в одной линии несколько переменных будет

странные проблемы странных языков

Minoru
и с такой точки зрения получается, что *иногда* выгодно переиспользовать, а *иногда* лучше в новой линии сделать себе новые переменные, чтобы не дёргать несколько старых линий

portnov
@noktoborus За такой код, с использованием одной переменной с двумя разными целями, вообще говоря, хочется по пальцам бить

portnov
но хочется понимать, бывает ли такому оправдание

portnov
"я восемь байт в стеке сэкономил!!!"

portnov
Minoru: это ты к тому, что размер стека желательно экономить, чтобы он целиком в кэш поместился?

Minoru
нет, я к тому, что в общем случае непонятно, экономить или нет

portnov
а кэши у проца для кода и для данных разные?

Minoru
представь какую-нибудь портянку математическую, в ней несколько блоков типа: 7 промежуточных переменных, которые потом складываются в восьмую. Спустя восемь таких блоков все те «финальные» переменные как-нибудь в цикле обрабатываются и возвращается результат

Minoru
L1 разные, остальные шарятся

Minoru
ну так вот, с одной стороны ты можешь для цикла новую линию не использовать, а просто дёргать уже существующие финальные переменные

Minoru
но они каждая на своей линии, и придётся держать все восемь линий (512 байт) в кеше, пока работает цикл

Minoru
альтернатива: перед циклом скопировать все финальные переменные в новую линию, и в цикле юзать только эти копии. Тогда предыдущие восемь линий можно выбросить, а держать придётся только 64 байта

portnov
но при этом явного управления кэшем нету

portnov
и остаётся только рассуждать, что если у нас 10 локальных переменных в методе, то первые 8 зачитаются в первую линию, а другие 2 во вторую

Minoru
в твоём примере вместо print мог быть какой-то свой блок с кучей переменных (≥64 байт). В этом случае второе присваивание дергало бы старую линию, которая, быть может, уже вывалилась из кеша. Тут компилятор должен решить, что ему важнее: сэкономить стек (но держать в кеше старую линию) или экономить количество линий (и тогда, наверное, лучше переиспользовать переменную из недавних линий, или вообще завести новую)

Minoru
да. Управления нет, только рассуждения

Minoru
возвращаясь к твоему вопросу про «есть ли смысл?», я считаю так: если рядом со вторым присваиванием нет комментария с историей о том, как изначально там была отдельная переменная, но это мешало JIT в JVM версии 0.314 на PDP-11, поэтому пришлось переприсваиваться — если комментария нет, то переприсваивание не оправдано, можно идти пинать автора