Comments 4
Спасибо! Интересно было бы также почитать про оптимизации, доступные JIT-компиляторам.
И вообще, какой метод компиляции даёт больше возможностей для анализа алгоритма, автовекторизации и т.д. - прямая компиляция (С/С++) или через байт-код (JVM)?
Оптимизации в первую очередь проводятся над intermediate representation, когда компилятор может взглянуть на control-flow и data-flow программы. Оптимизации под конкретную архитектуру происходят ближе к коду на уровне Register Transfer Language и это, по понятным, причинам в основном мелкие, peephole, оптимизации. Так что возможности анализа самого алгоритма мало зависят от целевой архитектуры.
И вообще, какой метод компиляции даёт больше возможностей для анализа алгоритма, автовекторизации и т.д. — прямая компиляция (С/С++) или через байт-код (JVM)?PGO, если вам реально нужен хороший код.
У JIT-компилятора ограниченые ресурсы, которые он может выделить на оптимизацию (если ваш JIT-компилятор будет генерировать просто суперский код, но сожрёт под себя 90% ресурсов — вы вряд ли будете в восторге).
У обычного компилятора — постоянно возникают описанные в статье затыки (будет этот цикл исполняться три раза или миллион раз?).
Хотя, при желании, состряпать пример, где JIT-компилятор выиграет, несложно, но PGO, на практике, даёт самый качественный результат.
Можно вики почитать en.wikipedia.org/wiki/Just-in-time_compilation
Особенно интересный момент про «HP project Dynamo», там самое весёлое — это «HPA-8000 essentially emulated itself and was faster by doing so» — в вики это описано как «Counterintuitively, this resulted in speed ups, in some cases of 30%».
Особенно интересный момент про «HP project Dynamo», там самое весёлое — это «HPA-8000 essentially emulated itself and was faster by doing so» — в вики это описано как «Counterintuitively, this resulted in speed ups, in some cases of 30%».
Sign up to leave a comment.
Как LLVM оптимизирует суммы степеней