История изменений
Исправление den73, (текущая версия) :
Ну, во-первых, не существует - она зависит от того, какие данные придут на вход этому коду. Во-вторых, даже если мы примем какое-то определение максимально быстрой формы выполнения, то нужно понять, насколько долго она будет вычисляться и есть ли гарантия хотя бы того, что процесс оптимизации займёт конечное время. Например, мы можем начать вычислять такие a,b,c,N < 100000000000000 что a^n + b^n = c^n.
Если процесс оптимизации займёт конечное время, то устроит ли это конечное время пользователей нашего компилятора? В SBCL, к примеру, цикл оптимизации (основанный на тех самых rewrite rules или чём-то близком) завершается просто по достижению магического числа итераций, допустим, 42. Это означает, что любое изменение в исходнике может привести к тому, что то решение, до которого вчера оптимизатор додумался, сегодня уже не будет обнаружено. Но мы об этом напрямую не узнаем, поскольку компилятор не обо всех удачах и неудачах оптимизации нам сообщает. Мы узнаем об этом только тогда, когда заметим снижение производительности нашей программы. Это делает процесс разработки с таким оптимизатором весьма увлекательным приключением, полным неожиданностей. Уверен, что и в других компиляторах так. И это наводит на мысли, а всё ли в порядке с самим подходом? Да, это инженерная дисциплина, но всё же вопросы остаются.
Исправление den73, :
Ну, во-первых, не существует - она зависит от того, какие данные придут на вход этому коду. Во-вторых, даже если мы примем какое-то определение максимально быстрой формы выполнения, то нужно понять, насколько долго она будет вычисляться и есть ли гарантия хотя бы того, что процесс оптимизации займёт конечное время. Например, мы можем начать вычислять такие a,b,c,N < 100000000000000 что a^n + b^n = c^n.
Если процесс оптимизации займёт конечное время, то устроит ли это конечное время пользователей нашего компилятора? В SBCL, к примеру, цикл оптимизации (основанный на тех самых rewrite rules или чём-то близком) завершается просто по достижению магического числа итераций, допустим, 42. Это означает, что любое изменение в исходнике может привести к тому, что то решение, до которого вчера оптимизатор додумался, сегодня уже не будет обнаружено. Это делает процесс разработки с таким оптимизатором весьма увлекательным приключением, полным неожиданностей. Уверен, что и в других компиляторах так. И это наводит на мысли, а всё ли в порядке с самим подходом? Да, это инженерная дисциплина, но всё же вопросы остаются.
Исходная версия den73, :
Ну, во-первых, не существует - она зависит от того, какие данные придут на вход этому коду. Во-вторых, даже если мы примем какое-то определение максимально быстрой формы выполнения, то нужно понять, насколько долго она будет вычисляться и есть ли гарантия хотя бы того, что процесс оптимизации займёт конечное время. Например, мы можем начать вычислять такие a,b,c,N < 100000000000000 что a^n + b^n = c^n.
Если он займёт конечное время, то устроит ли это конечное время пользователей нашего компилятора? В SBCL, к примеру, цикл оптимизации (основанный на тех самых rewrite rules или чём-то близком) завершается просто по достижению магического числа итераций, допустим, 42. Это означает, что любое изменение в исходнике может привести к тому, что то решение, до которого вчера оптимизатор додумался, сегодня уже не будет обнаружено. Это делает процесс разработки с таким оптимизатором весьма увлекательным приключением, полным неожиданностей. Уверен, что и в других компиляторах так. И это наводит на мысли, а всё ли в порядке с самим подходом? Да, это инженерная дисциплина, но всё же вопросы остаются.