Комментарии 16
А почему LLVM не используется? Не очень то подходит для Kotlin? Или есть другие причины?
Ничего особенного с точки зрения компиляторов. Одна из возможных архитектур в развитии. Показательна ссылка на Dragon book как одну из базовых и уже достаточно устаревших.
Нет, я не эксперт здесь. Я понимаю, что это ирония. Я читаю классический курс по компиляторам - ничего особенного.
Но действительно, архитектура K1 - совершенно классическая, архитектура K2, где синтаксическое дерево затем украшается семантикой, - тоже классическая. Выгода здесь понятно в рефакторинге. И два бонуса. Основной - это масштабирование на несколько целевых архитектур. Я думаю, ради этого всё затевалось. Второй - ускорение компиляции - это бонусом. Повторюсь, не случайно в списке литературы абсолютно стандартная и древняя Dragon book.
Из альтернатив, тоже довольно стандартных, является построение по синтаксису отдельного семантического дерева. Здесь есть свои преимущества и недостатки, но их никто толком не анализировал.
Про сахарные преобразования в статье сказано скупо, что этот этап есть. А это самое интернюесное, потому что именно здесь могут быть конфликты - некоторые сахарные преобразования можно выполнять только до других, а иные рекурсивно зависят от других, и нет регулярной литературы, описывающей решения. Наконец, понятно, что в сахарных преобразованиях участвует семантика, но проблема в том, что семантика может быть на момент сахарных преобразований еще не до конца выведена. Вот об этом было бы интересно послушать. Об этом не пишут в учебниках и не сравнивают с другими реализациями.
Выгода здесь понятно в рефакторинге. И два бонуса. Основной - это масштабирование на несколько целевых архитектур. Я думаю, ради этого всё затевалось. Второй - ускорение компиляции - это бонусом.
Языку уже 13 лет, цели изменились, много нового добавилось.
Из-за появления новых целевых архитектур замедлялась разработка фичей языка. Поэтому JB в последних релизах и в том числе в 2.0 не выпускают ничего нового. Но в будущем новый компилятор открывает дорогу.
Я бы не сказал что была основная цель, а что-то далось бонусом. Тк ускорение фронтенда и масштабирование на разные архитектуры происходит в разных частях компилятора. Поэтому логично предположить что работа над этими улучшениями была разделена.
Ничего особенного с точки зрения компиляторов. Одна из возможных архитектур в развитии.
Чем плоха классическая архитектура, если она решает нужные задачи и уже опробована в действии много раз. Kotlin не экспериментальный язык, чтобы испытывать что-то особенное в компиляторе)
Из альтернатив, тоже довольно стандартных, является построение по синтаксису отдельного семантического дерева. Здесь есть свои преимущества и недостатки, но их никто толком не анализировал.
Тк компилятор переписывался то я думаю что в JB анализировали разные подходы.
Наличие нескольких структур данных в предыдущей версии компилятора ухудшала JIT-оптимизацию и кеширование процессора. Видится, что в варианте с наличием нескольких деревьев может быть аналогичная проблема.
Но, конечно, интересно, какие альтернативы JB рассматривали. Я эту информацию в открытых источниках не нашел.
Про сахарные преобразования в статье сказано скупо, что этот этап есть. А это самое интернюесное, потому что именно здесь могут быть конфликты - некоторые сахарные преобразования можно выполнять только до других, а иные рекурсивно зависят от других, и нет регулярной литературы, описывающей решения. Наконец, понятно, что в сахарных преобразованиях участвует семантика, но проблема в том, что семантика может быть на момент сахарных преобразований еще не до конца выведена.
Так это часть алгоритма компилятора. Благо компилятор открытый. Статья и так получилась нагруженной и не было задачи разобрать все нюансы работы компилятора.
94% - маркетинговая цифра из одного бенчмарка. В реальности сокращение времени компиляции не более 10-15%.
94% это ускорение по чистому билду. Помимо этого в статье с замерами есть и другие сценарии.
Замеры проведены на реальных развивающихся опенсорсных проектах: Anki-Android, Exposed. Понятно, что эти проекты не эталонные, и будет интересно увидеть цифры от крупных компаний в будущем.
Ускорение на 94% - это ускорение в 16 раз! Кто-то сильно приукрашивает
Вы неправильно трактуете это число. Как трактовать эти числа можете почитать в статье.
Также в этой статье привожу пример на официальные замеры JB. Там явно видно числа: 94% это не в 16 раз ускорение, у чуть меньше чем в 2.
Извините, но как раз я правильно толкую. Счёт ведётся от старого значения. было 100%, осталось (100-94)=6%, ускорение 100/6=16 раз. Правильно было сказать ускорение на 45%, но на 94% звучит гораздо маркетологичнее
К сожалению, вы невнимательно читаете. Речь идет не об уменьшении времени компиляции на 94%, а об увеличении производительности (скорости) компилятора на 94%.
Таким образом:
Раньше я мог выполнять работу X за время Y - начальная производительность.
Теперь я могу выполнять работу X за время Y / 2 - конечная производительность.
Итого: конечная производительность в 2 раза больше начальной.
Пусть прибыль в прошлом году была миллион, а в этом году - 2 миллиона. На сколько увеличилась прибыль? Все согласны, что на 100%. К миллиону нужно прибавить 100% от миллиона, получится два миллиона. Никто не скажет, что прибыль увеличилась на 50%.
Если время сборки проекта составляло 10 секунд, а теперь составляет 5 секунд, на сколько оно уменьшилось? На 50%, нужно из 10 секунд вычесть 50% от 10 секунд, получится 5 секунд. А вовсе не на 100%, хотя по-видимому маркетологам JetBrains хотелось бы сделать из этих 50% целых 100%.
Все верно, только в вашем примере увеличение в два раза, а в статье уменьшение в два раза. Если бы прибыль упала до 550 миллионов, вы бы написали что она упала на 45% а не на 95%.
В статье говорится об ускорении компилятора на 94%, а не уменьшении времени компиляции на 94%. См объяснение выше.
Как новый компилятор K2 ускоряет компиляцию Kotlin на 94%