DF
А, верно
Size: a a a
2020 December 19
AT
Кроме того, для стекового байт-кода не нужно заниматься аллокацией регистров. 😃
E
для сценариев дебага байт код и не надо в натив компилировать
AT
для сценариев дебага байт код и не надо в натив компилировать
О том и речь.
E
ну так это то что я назвал и оно работает
E
вот ограничения инстант рана в андроид студио
AT
OK, прикольно что в Java/.NET переизобрели этот приём. 😊
E
например меняешь layout класса - то уже не рабоает (но и логично)
AT
Интересно, были ли такие ограничения в Eiffel Studio? Или они класс целиком в байт-код перегоняли? 🤔
E
я думаю это связано с тем, что там для других уже скомпиленных методов мог заинджектится константый размер класса или офсет поля и всё надо переделывать, ну что-то типа такого.
фиксить это думаю смысла нет, эта фича больше направлена на изменения внутри методо
фиксить это думаю смысла нет, эта фича больше направлена на изменения внутри методо
DB
Меняем вопрос на зачем ускорять IDE и не возникает вопрос целесообразности
Ну ускорение IDE это скорее про ускорение фронтэнда, ускорение компилятора - это скорее ускорение кодгена. В контексте IDE задача актуальна, да.
M
Ну ускорение IDE это скорее про ускорение фронтэнда, ускорение компилятора - это скорее ускорение кодгена. В контексте IDE задача актуальна, да.
Да кто это сказал, сушественная часть компилятора это сематический анализ.
Если у нас болид формулы 1 и мы облегчели кузов и получили прирост в 3-4% мы все еше получили прирост, да и для задачи кодогена узким местом будет перегнать с одного ir в другое
Если у нас болид формулы 1 и мы облегчели кузов и получили прирост в 3-4% мы все еше получили прирост, да и для задачи кодогена узким местом будет перегнать с одного ir в другое
M
Dmitry Ponyatov
инкрементная компиляция + оптимизации и анализ, работающие в фоне интерактивной системы?
(косясь на Pharo Smalltalk)
(косясь на Pharo Smalltalk)
Да, мне вообше странно почему так никто не делает, зачем вообше запускать компилятор когда он может работать все свободное время как часть IDE, сейчас все есть сервис, ну пусть и компилятор им будет
A
А зачем ускорять компиляторы? JITы разве что, но если скорость выполнения программ критична, то AOT будет лучше. Разве что супероптимизатор какой-нибудь на GPU может иметь какой-то практический смысл.
Ну поменял что то в используемом почти всеми хедере и ждёшь 20 минут. Ещё для ci может быть важно. Но это я так жалуюсь
A
Инкрементальная сборка не в помощь?
Ну зависит от того что делаешь обычно норм да. Хотя субъективно даже несколько минут это достаточно долго. Конкретно в моем случае наверно в таких кейсах больше времени занимает линкер, не задумывался
E
https://github.com/hajimehoshi/go2cpp - порадовало, перевод го в С++ через васм -_- сс @maxgraey
PS
Ну поменял что то в используемом почти всеми хедере и ждёшь 20 минут. Ещё для ci может быть важно. Но это я так жалуюсь
Кстати да, для ci крайне важно, на JAVA какой-нибудь микросервис можно каждый раз в новом докере собирать на каждом прогоне, она быстро компилируется, а с c++ да чем-то большим так не получится. И тут нужна какая-то штука, которая обеспечит корректный билд при условии, что вот был код Васи, мы его собрали, протестили и удалили, а теперь прилетел код Пети и желательно собрать его без хвостов. Хотя если собирать какой-нибудь Eclipse platform, то и то, что он на JAVA не поможет.
BD
я так понимаю "Instant Run" для андроида так работает, когда изменения кода небольшие и это позволяет мгновенно перезапустить апп
Д, оно просто досыпает к бинарю измененные методы и пропатчивает вызовы
E
Д, оно просто досыпает к бинарю измененные методы и пропатчивает вызовы
чем это отличается от того что я сказал?