.NET CLR vs X++

[Logger]

Привет всем.

Интересно, кто-нить пробовал замерять насколько быстрее исполняется clr код по сравнению с X++

Вопрос возник по прочтении этого блога :
daxmusings: X++ in the .NET CLR : Life in the Fast Lane

[lvan]

какой код?

логичнее было бы замерить разноску заказа в ax2009 и ax2012
наверняка в маркетинговых материалах на партнерсорсе есть какая-то инфа об ускорении этого или подобного процесса

[shogel]

Цитата:

Сообщение от lvan

логичнее было бы замерить разноску заказа в ax2009 и ax2012
наверняка в маркетинговых материалах на партнерсорсе есть какая-то инфа об ускорении этого или подобного процесса

Разноску заказа в DAX2012 очень сильно перепахали, так что сравнение будет не объективным. Самый простой вариант - взять этот метод:

PurchTable::initFromVendTableIL

и запустить его в среде X++, а потом в .NET. У меня выполнение кода в .NET в среднем дает прирост производительности на 10-15%

[Logger]

А возможно заставить 2012-ю делать разноску заказа не используя IL ?
Это было бы самым объективным сравнением.
Хотя наверно скорость несильно бы отличалась.
Все равно в разноске главное - время ожидания БД.

Надо какую-то другую длительную операцию подобрать. Там где БД меньше дергается.

[lvan]

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

[Logger]

В принципе незачем.
Просто интерес.

[belugin]

Цитата:

Сообщение от lvan

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

Например, чтобы понимать примерно, насколько ускорится нужный код. То есть, если мы знаем, что в нужном коде быстродействие жрет 50% X++ и 50% SQL и копиляция в CLR даст примерно 70 кратный прирост производительности X++ как такогого, то результирующее ускорение будет примерно в 2 раза.

=== ниже информация неофициальная и, возможно, ложная ===

Насколько я помню тупой код типа цикл с присваиванием переменной укоряется в 70 раз.

Еще есть разные факторы - в .NET используется недетерминированный сборщик мусора, а в X++ детерминированный (он должен убрать мусор сразу как только нет на него ссылок). В результе X++ при каждом присваивании считает циклы - что дает квадратичный, кажется, прирост времени выполнения при присваиваниях полей классов с развесистым графом объектов, например, в разноске больших журналов.

В-общем, попробуйте отпрофилировать TraceParserом ваши задачи.

Еще следует учесть что включение HotSwapping помещает ваши сборки в отдельный домен, что дает некоторое увеличение времени вызова между вашим кодом и ax32serv

[Logger]

Цитата:

Сообщение от belugin

В результе X++ при каждом присваивании считает циклы - что дает квадратичный, кажется, прирост времени выполнения при присваиваниях полей классов с развесистым графом объектов, например, в разноске больших журналов.

Максим, а можно эту тему поподробнее раскрыть ?
Не совсем понятно какие операции приводят к такому сканированию. И как этого избегать в своих разработках.

[Logger]

Кстати, по поводу сборки мусора.
Интересно как это все в 2012-й работает. Он теперь там всегда недетерминированный ? Или есть отдельно куча .Net и отдельно X++ и обрабатываются они по разному ?

Думаю это достаточно важный вопрос, так как в X++ в некоторых местах код явно закладывается на то что сразу после присваивания :

Object = null;

объект Object убивается и ресурсы (например файл на диске если Object - это файл) высвобождаются для работы. А теперь это может быть и не так.

[AndyD]

Цитата:

Сообщение от Logger

Максим, а можно эту тему поподробнее раскрыть ?

Поддерживаю.
Не совсем понятно, что имеется в виду.

[plumbum]

Класический пример плохой работы сборщика мусора в АХ, это перекрестные ссылки между деревом и элементами дерева:

Dynamics AX Performance issue. Cross object references drawbacks


Подробная информация о сборке мусора в X++ и .NET тут

[plumbum]

Цитата:

Сообщение от Logger

Кстати, по поводу сборки мусора.
Интересно как это все в 2012-й работает. Он теперь там всегда недетерминированный ? Или есть отдельно куча .Net и отдельно X++ и обрабатываются они по разному ?

Кучи у них разные, как и раньше:

X++, C# Comparison: Object Oriented Programming [AX 2012]

Цитата:

In C#, the System.GC.Collect method in the .NET Framework can be called to start the garbage collector. There is no similar function in X++ because X++ uses a deterministic garbage collector.

Собственно Х++ так и не стал Managed языком, для этого и ввели возможность перекомпилировать Х++ код в .NET код.

[Logger]

Цитата:

Сообщение от plumbum

Собственно Х++ так и не стал Managed языком...

Что же ему не хватает ?

[plumbum]

мне кажется просто не хотели переносить фокус на переработку IDE.
Само ядро AX интерпритирует код Х++ в P код, который по своей сути является чем-то вроде MSIL, но "не то"

[Logger]

Не совсем понимаю, в чем проблема.
А что вы подразумеваете под Managed языком ?

[plumbum]

Цитата:

Сообщение от Logger

Не совсем понимаю, в чем проблема.
А что вы подразумеваете под Managed языком ?

Я подразумеваю, что Managed языки, это те языки, на которых может писаться Managed код

Проблема была в том, что МС не хотели ламать то, что уже было в АХ. Они просто берут Р код, созданный компилятором, и его переводят потом в MSIL, а MSIL, как известно, может быть интерпритирован в любой язык, поддерживаемый .NET платформой. Но сам по себе X++ так и не стал "новым официальным языком .NET".

Это было скорее стратегиское решение. Думаю что в последующих версиях X++ будет становиться все меньше и меньше, пока они полностью не перейдут на Managed код.

[Logger]

Где-то проходила инфа что x++ чуть ли не Visual Studio появится. Возможно передумали.

[AndyD]

Цитата:

Сообщение от plumbum

Класический пример плохой работы сборщика мусора в АХ, это перекрестные ссылки между деревом и элементами дерева:

Dynamics AX Performance issue. Cross object references drawbacks

Не уловил, в чем здесь пример плохой работы GC.
По-моему, больше похоже на проблемы с быстродействие самого TreeView при большом количестве элементов и уровне вложенности. И с большим расходом памяти на непонятно зачем нужные объекты (я про хранение ссылок на FormTreeItem)

Цитата:

Сообщение от plumbum

Подробная информация о сборке мусора в X++ и .NET тут

Не понял, на что здесь надо обратить внимание в контексте высказывания belugin.
Что это за циклы в каждом присваивании на X++?

[gl00mie]

Цитата:

Сообщение от AndyD

Что это за циклы в каждом присваивании на X++?

Была в блоге команды разработчиков X++ статья X++: Garbage Collection and Ax Performance Whitepaper (занятно, сейчас ее в блоге не найти), там объяснялось, что детерминированный сборщик мусора в X++ поддерживает для каждого объекта два счетчика: один - для учета ссылок на объект (reference count) и второй - для учета "петель" ссылок (loop count), в которых участвует объект.

Объект не подлежит уничтожению до тех пор, пока число ссылок на него больше числа "петель" ссылок, в которых он участвует. Так вот, при каждом присваивании переменной ссылки на тот или иной объект сборщик мусора должен не только увеличить счетчик ссылок на этот объект, но и по графу ссылок между объектами пересчитать счетчик "петель" для него. А длительность последней операции с увеличением числа связанных между собой объектов имеет тенденцию расти экспоненциально.

[plumbum]

Цитата:

Не уловил, в чем здесь пример плохой работы GC.

собственно на примере показано, что при росте петель падает прозиводительность, так как сборщик мусора эти самые петли всега анализирует.

К сожалению не нашел сразу ссылку на вышеуказанную статью. Моя ссылка на MSDN подтверждала то, что GC в X++ детерминированный (там так и было написано).

Вот сейчас из блогов пришла статья о возможности скомпилировать X++ в IL.
X++ in the .NET CLR : Life in the Fast Lane

Там ремарка, о том, что при отладке IL, созданного из X++, код последнего выбирается фактически из AOT, а вот выполняется как раз прекомпилированная сборка. Я так понимаю, что обратное преобразование из IL в X++ не реализовано. Посему и не считаю что X++ таки стал Managed .NET Language.