Здравствуйте, Аноним, Вы писали:

А>Третий круг. Потому что я указал

А>class Matrix
А>(
А> operator @* ....
А> operator @+ ....
А> optimization(a:Matrix*b:Matrix+a*c:Matrix -> a*(b+c))
А>}

Ты забыл упомянут, что возможность оптимизации нужно описывать явно самому пользователю.

В таком виде это конечно возможно. Вот только имеет ли смысл тратить не мало времени на доработку компилятора только ради того, чтобы научить его работать с фичей которая нужна раз в код по обещанию и может быть спокойно оптимизирована вручную?

Здравствуйте, Аноним, Вы писали:

А>как минимум не вредно...

Делать серьезный объем работы только на основании, что что-то не вредно, явно не разумно.
Для реализации фичи в языке нужны очень серьезные основания. Иначе конца и края не будет работе над подобными фичами. Плюс язык превратится в помойку и его не сможет выучить даже самый пытливый ум.

А>теперь нужно уже

Кому и зачем?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>помойму вы не понимаете чем занимается jit,

VD>Предположение не верное.

А>> откуда он может знать что допустима такая замена?

VD>Он работает с типизированной стековой машиной, так что ему известны типы аргументов. Ну, и сделать предположение о целых числах ему точно не составит труда.

VD>Делать такие предположения для пользовательских объектов джит конечно не может. Но этого никто кроме автора этого кода не имеет права делать.

А>>fun1(fun2(x,y),y) -> fun1(x, fun2(x,y))

А>>и причем тут вообще процессор?

VD>Ну, не знаю. Может быть потому что он производит реальное исполнение кода?

А>>a:Matrix*b:Matrix+a*c:Matrix -> a*(b+c)

А>>откуда jit может знать что для класса Matrix допустима такая оптимизация?

VD>Ни откуда. Только если код этого Matrix будет заинлайнен и превратится в набор примитивных операций.
VD>Если для вашего Matrix нужны какие-то оптимизации, то имеет смысл сделать их самостоятельно.
VD>Кстати, это можно сделать на макросах.

Как это можно сделать в макросах?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, VladD2, Вы писали:

VD>>Кстати, это можно сделать на макросах.

А>Как это можно сделать в макросах?

Типизируем выражение и преобразоваываем его в соответствии с переместительным и сочетательным законом арифметики.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, VladD2, Вы писали:

VD>>>Кстати, это можно сделать на макросах.

А>>Как это можно сделать в макросах?

H>Типизируем выражение и преобразоваываем его в соответствии с переместительным и сочетательным законом арифметики.

Можно пример макроса?

Здравствуйте, Аноним, Вы писали:

А>Как это можно сделать в макросах?

Если сами вычисления буду передаваться в некий макрос, то не трудно будет разобрать выражния и переставить их содержимое как требуется.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>Как это можно сделать в макросах?

VD>Если сами вычисления буду передаваться в некий макрос, то не трудно будет разобрать выражния и переставить их содержимое как требуется.

Таким образом мы обязаны обертывать все в макрос?

Здравствуйте, Аноним, Вы писали:

А>для оптимизации было бы полезно делать преобразования кода при выполнении
А>например a*b+a*c -> a*(b+c)

А>или fun1(fun2(x,y),y) -> fun1(x, fun2(x,y)) и т д

Я всегда думал, что алгеброй должен все-таки заниматься программист, а не компилятор.
Если вы знаете, что для вашего типа данных сумма произведений рассчитывается быстрее, чем произведение суммы, так и напишите в своем коде.

Здравствуйте, catbert, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>для оптимизации было бы полезно делать преобразования кода при выполнении
А>>например a*b+a*c -> a*(b+c)

А>>или fun1(fun2(x,y),y) -> fun1(x, fun2(x,y)) и т д

C>Я всегда думал, что алгеброй должен все-таки заниматься программист, а не компилятор.
C>Если вы знаете, что для вашего типа данных сумма произведений рассчитывается быстрее, чем произведение суммы, так и напишите в своем коде.

Cjгласен, если только по вашему мнению и программист должен назначать регистры.

Здравствуйте, Аноним, Вы писали:

Просьба, цитировать только то на что отвечаешь.

VD>>Ни откуда. Только если код этого Matrix будет заинлайнен и превратится в набор примитивных операций.
VD>>Если для вашего Matrix нужны какие-то оптимизации, то имеет смысл сделать их самостоятельно.
VD>>Кстати, это можно сделать на макросах.

А>Как это можно сделать в макросах?

Скажем обрамить вычисление некой мкрой:

def result = Optimize(x * a + x * b);

А в этом макре уже анализировать код и делать нужные его трансформации.

Можно поступить сложнее. Повесить макрос на функцию, чтобы он выискивал в теле функции то что сможет оптимизировать.
Но вообще, это конечно баловство.

Здравствуйте, Аноним, Вы писали:

VD>>Если сами вычисления буду передаваться в некий макрос, то не трудно будет разобрать выражния и переставить их содержимое как требуется.

А>Таким образом мы обязаны обертывать все в макрос?

При таком подходе — да. Но в принципе может оказаться, что это не так уж и сложно. Ведь макросу можно дать синтаксис вроде того что используется для checked.

Здравствуйте, Аноним, Вы писали:

C>>Если вы знаете, что для вашего типа данных сумма произведений рассчитывается быстрее, чем произведение суммы, так и напишите в своем коде.

А>Cjгласен, если только по вашему мнению и программист должен назначать регистры.

Это разные уровни абстракции. Если бы я писал на ассемблере, и он бы начал сам менять мой код и переназначать регистры, я бы выкинул такой ассемблер на свалку. Если бы я написал ваше выражение на матлабе, а он бы не упростил его, я бы тоже удивился.

Но на уровне компилятора языка общего назначения, каким является Немерле, такие оптимизации ИМХО недопустимы. Ведь если данное выражение было бы частью LINQ-выражения, компилятор бы генерировал явно некорректный код. Если бы тип данных не подчинялся дистрибутивному закону умножения, компилятор опять бы генерировал некорректный код. Если я хотел бы посмотреть в окне отладчика подвыражения a*b и a*c, я удивился бы тому что увидел.

Конечно можно было бы проводить оптимизацию только для релиз-билдов, только для il-кода (а не для внутреннего представления кода), и только если такое поведение явно разрешено. Но представьте себе ситуацию, когда в классе Matrix есть баг, из-за которого при умножении больших чисел генерируется исключение. В Debug-режиме все тесты проходят. Но как только вы выкладываете код на сервер, выскакивает exception. Вы садитесь проверять дебаг-билд, а там исполняется другой код, и все чисто.

Да и если говорить только о double-ах, если a — маленькое число, а b и c — большие, с разными знаками, и приблизительно равны по модулю, ваша оптимизация может убить точность вычисления.

Я не говорю, что в Nemerle не осталось места для оптимизаций. Просто где-то нужно провести линию. И, как по мне, эта линия намного ниже по стеку абстракций, чем аксиомы алгебр и теории чисел.

Здравствуйте, catbert, Вы писали:

C>Но на уровне компилятора языка общего назначения, каким является Немерле, такие оптимизации ИМХО недопустимы. Ведь если данное выражение было бы частью LINQ-выражения, компилятор бы генерировал явно некорректный код. Если бы тип данных не подчинялся дистрибутивному закону умножения, компилятор опять бы генерировал некорректный код. Если я хотел бы посмотреть в окне отладчика подвыражения a*b и a*c, я удивился бы тому что увидел.

Не, ну, тут товарищ предлагал вполне рабочее решение — декларативно описывать возможность (и алгоритм) оптимизации прямо в типе для которого определены операторы.

Против такого решения лично я не возражаю. Просто фича не той важности чтобы ею заняться лично. Но если кто-то сделал бы, был бы только "за".

Здравствуйте, VladD2, Вы писали:

VD>Не, ну, тут товарищ предлагал вполне рабочее решение — декларативно описывать возможность (и алгоритм) оптимизации прямо в типе для которого определены операторы.

Тот же вопрос. Нахрена описывать возможности оптимизации прямо в типе, если можна прописать прямо оптимально в коде?

VD>Против такого решения лично я не возражаю. Просто фича не той важности чтобы ею заняться лично. Но если кто-то сделал бы, был бы только "за".

Да я тоже не возражаю. Просто не понимаю, какой в ней смысл. Ведь макрос не делает больше того, что может сделать программист. Он просто уменьшает количество работы для программиста. А тут никакого уменьшения нет.

Здравствуйте, catbert, Вы писали:

C>Тот же вопрос. Нахрена описывать возможности оптимизации прямо в типе, если можна прописать прямо оптимально в коде?

Наверно, чтобы не делать это по много раз.

VD>>Против такого решения лично я не возражаю. Просто фича не той важности чтобы ею заняться лично. Но если кто-то сделал бы, был бы только "за".

C>Да я тоже не возражаю. Просто не понимаю, какой в ней смысл. Ведь макрос не делает больше того, что может сделать программист. Он просто уменьшает количество работы для программиста. А тут никакого уменьшения нет.

Ну, автоматизация оптимизации — это тоже устранение лишней работы.

Так что некоторое рациональное зерно в этом есть. Вот только боюсь, что востребована фича будет очень редко, а труда на нее уйдет много.