DAX vs 1C

[mit]

Цитата:

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

Маладец!

но обявление двух функций не эквивалентно объявлению одной функции с вложенной подфункцией.

ну началось!
я не просил оценить грамотность написания кода. код написан идентично для двух систем. надеюсь это ни у кого здесь не вызывает сомнений.

Цитата:

вместо n+1 можно использовать ++n

можно, но пример от этого быстрее работать не станет. тем более что для интерпретатора это одно и то же

Цитата:

для замера скорости лучше не пользоваться инфологом - это очень тяжелая
структура.

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

Цитата:

для замера скорости лучше пользоваться таймером. Их предлгалалось несколько вариантов.
См. обсуждения на форуме.

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

Цитата:

А также были обсуждения какие конструкции яызка X++ являются самыми медленными в рамках X++.

И еще одно соображение.
Предполагаю, что вы сейчас замерили не скорость "локальных вычислений", а скорость "сборки мусора".
Скорость сборки мусора сильно зависит от используемой памяти.
Т.е. для данного теста помимо скорости нужно показывать используемую клиентом память

ну еще раз обращу внимание что задача не стояла получить супер результат на этом куске кода (для супер результата - тупо бы взяли супер компьютер ). задача была сравнить две системы. причем на довольно узком участке - а именно - локальные вычисления. я подозреваю что тут все упрется даже не в вычисления, а в скорости перехода интерпретатора по коду со строки на строку.
понятно что для жизни вне лаборатории ситуация встретится навряд ли(сложно представить кусок кода длинной в пять милл. строк) разве что... да нет, навряд ли.

[Михаил Андреев]

Цитата:

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

задача была сравнить две системы. причем на довольно узком участке - а именно - локальные вычисления.

И какая польза от такого сравнения? Давайте сравним размеры болтов на брызговиках автомобилей.
Сравнивать имеет смысл решения конкретных задач, для которых системы предназначены. А так, извините, это просто глупость.

Цитата:

я не просил оценить грамотность написания кода. код написан идентично для двух систем. надеюсь это ни у кого здесь не вызывает сомнений.

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

Цитата:

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

Вспомнилось. На одном внедрении была задача оптимизации. После упрощения (точнее, дискретизации) её можно было привести к стандартной задаче, реализуемой обычными пакетами типа матлаб и т.п. Ан нет, решили в Аксапте. Потом месяц оптимизировали, так как суток для расчёта не хватало...

"Хрр!" - сказала японская пила.
"Ага!" - сказали суровые сибирские мужики.

[egorych]

Цитата:

Сообщение от Михаил Андреев

И какая польза от такого сравнения?

ИМХО польза таки есть - данный тест показывает "размер" накладных расходов при частом вызове методов, что очень часто имеет место быть в Аксапте.
Т.е. пропагандируемые методы разбиения одного большого метода на кучку маленьких ведут к потере производительности.

[mazzy]

Цитата:

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

ну началось!
я не просил оценить грамотность написания кода. код написан идентично для двух систем. надеюсь это ни у кого здесь не вызывает сомнений.

Нет, ВАШ код написан неидентичен.
Читайте еще раз DAX vs 1C

Цитата:

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

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

вот ведь неймется. У меня добавляет секунду к коду от Lev
DAX vs 1C
Без него 7 секунд. Добавил до таймера info - получил 8 секунд. Получается, что вызов инфолога добавиляет около 10-15%.

Цитата:

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

ну еще раз обращу внимание что задача не стояла получить супер результат на этом куске кода (для супер результата - тупо бы взяли супер компьютер ). задача была сравнить две системы. причем на довольно узком участке - а именно - локальные вычисления. я подозреваю что тут все упрется даже не в вычисления, а в скорости перехода интерпретатора по коду со строки на строку.

опять же. в чем проблемы? напишите в одну строку и оттестируйте.

Цитата:

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

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

легко.
создаете пять-десять новых номенклатур.
настраиваете их примерно одинаково. методика списания себестоимости ФИФО или средняя или другая на выбор.
создаете сотню приходов для каждой номенклатуры в обоих системах (замеряете время, используемую память)
создаете сотню расходов для каждой номенклатуры в обоих системах (замеряете время, используемую память)
после этого задним числом добавляете накладные расходы в обоих системах.
после этого рассчитываете себестоимость для новых номенклатур на одном компе или распраллеливаете алгоритм расчета на пару-тройку компьютеров (замеряете время, используемую память)

получаете очень хороший синтетический тест.

для полной картины надо бы добавить фоновые процессы разноски/проведения приходов/расходов других номенклатур для всех замеряемых этапов.

Но ведь тут выяснится, что накладной расход в 7ке на уже существующие приходы не начисляется, нужно перепроводить. Тут выяснится, что в 7ке нужно перепроводить все документы и прочая отсутствующая фигня типа невозможности распарралелить расчет себестоимости... К тому же неожиданно всплывет ваш упомянутый 1С++ и выяснится, что у вас полностью переписанная конфигурация, с которой надо разбираться и разбираться.

Вот и остается замерять скорость прогона пустых циклов

Цитата:

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

Т.е. пропагандируемые методы разбиения одного большого метода на кучку маленьких ведут к потере производительности.

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

[mazzy]

Цитата:

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

вот ведь неймется. У меня добавляет секунду к коду от Lev
DAX vs 1C
Без него 7 секунд. Добавил до таймера info - получил 8 секунд. Получается, что добавилось около 10-15%.

Кстати, попробовал на ax2009.
выполнилось за 5 секунд с инфологом и без инфолога

[mazzy]

Цитата:

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

По поводу методически более правильного решения.

PHP код:

т1 = _GetPerformanceCounter();
Для й = 0 По 5000000 Цикл
   
КонецЦикла;
т2 = _GetPerformanceCounter();
Сообщить(т2 - т1); 


1С: 7.518 секунд.

Выполнил этот код на 7.7.
Получил 4.681

[mazzy]

Цитата:

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

Так вот мне все таки интересно почему код static void AEliz_test(Args _args)
на Ax 3.0 SP6 = 8 сек, а на DAX 4.0 SP2 = 17 сек

У кого так же 3-ка и 4-ка по разному считают? или у меня что то с Аксаптой 4? Как на счет DAX 2009? Кому не лень проверить.. чистое любопытство.

Мне кажется, что вот это гораздо интереснее.
У меня на Ax 3.0 SP6 как и в ax2009 - без инфолога и с инфологом - 5 секунд.

Интересно...

[mazzy]

кстати, протестировал вариант с вложенным методом

static void AEliz_test(Args _args)
{
    int i = 5000000;
    int i1;
    int stratTime, endTime, runTime;

    int test(int n)
    {
        return n+1;
    }
    ;

    stratTime   = timeNow();

    for(i1=1;i1<i;i1++)
    {
        test(i1);
    }
    endTime     = timeNow();

    runTime     = endTime - stratTime;

    info(time2str(runTime, 1,1));
}

ax3.0 sp6 - 21 сек.
ax4.0 sp2 - 41 сек.
ax2009 - 14 сек.

изменил for-цикл на while-цикл, оставил вложенный метод, получил
ax3.0 sp6 - 19 сек.
ax4.0 sp2 - 38 сек.
ax2009 - 13 сек.

Прикольно.

mit, вы похоже пробуете на ax4, так?
Спасибо, что натолкнули Poleax на интересную мысль.
Poleax, спасибо за неожиданный, но очень конструктивный разворот темы. Надо подумать.

[RumataEstor]

Цитата:

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

mit, вы похоже пробуете на ax4, так?

Самое первое сообщение в теме:

Цитата:

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

Таким образом локальные вычисления в DAX происходят в 4.4 раза медленнее

1C 7.7 + компонента 1С++
DAX 4.0

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

Естесственно, решение об используемой платформе не может приниматься только на основании производительности. Иначе, все бы писали собственные ERP системы на С++.
Я предполагаю, что стандартный функционал Аксапты перекрывает функционал каждой существующей для 1С конфигурации. Именно поэтому Аксапта выглядит предпочтительней 1С.

Цитата:

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

ax3.0 sp6 - 21 сек.
ax4.0 sp2 - 41 сек.
ax2009 - 14 сек.

изменил for-цикл на while-цикл, оставил вложенный метод, получил
ax3.0 sp6 - 19 сек.
ax4.0 sp2 - 38 сек.
ax2009 - 13 сек.

Похоже, что скорость работы 1С сопоставима с AX3.
В свете информации о DAX2009 и возможном переводе всей системы на .NET Аксапта выиграет по производительности. Однако такой версии для сравнения я пока не имею.

[mazzy]

Цитата:

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

Похоже, что скорость работы 1С сопоставима с AX3.

Ура, 1С сделала систему, которая гоняет циклы за время, сопоставимое с Аксаптой.
Искренне поздравляю.

Копайте дальше. "Скорость работы" - это не только целочисленные циклы.
Может еще что интересное нароете.

Эх, кто-нибудь бы время расчета себестоимости бы сравнил...

[fed]

По моему опыту, скорость работы транзакционного приложения (каковым и Аксапта, безусловно, является) на 80-85% определяется ожиданием завершения операции базой данных. Поэтому трехкратный (например) прирост скорости интерпретации кода X++ даст всего-лишь 5-7% выигрыша в производительности. Вот собственно и вопрос - стоит ли вкладывать время и деньги в оптимизацию интерпретатора (кстати с шансами поломать совместимость), если при замене СУБД на более современную (скажем - SQL 2005 на SQL 2008 или Oracle 10 на Oracle 11), можно на том же железе добиться более существенного выигрыша в производительности ? А если очень хочется из Аксапты какие-то сложные вычислительные задачи порешать, так по моему проще написать DLL-ку на C++. Кстати и готовую (и бесплатную) матбиблиотеку или просто отдельную функцию для C++ найти гораздо проще.

[RumataEstor]

Цитата:

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

Ура, 1С сделала систему, которая гоняет циклы за время, сопоставимое с Аксаптой.
Искренне поздравляю.

Копайте дальше. "Скорость работы" - это не только целочисленные циклы.
Может еще что интересное нароете.

Эх, кто-нибудь бы время расчета себестоимости бы сравнил...

Программист сравнивает время работы примитивов, предоставляемых языком программирования. А не время работы бизнес-функций.

Приведенный тест показывает время работы примитива "вызов функции" и примитива "цикл".
Понятие "пустой цикл" для программиста не существует. Машина в любом случае нагружает процессор. Вопрос в том, насколько оптимально. Начинка цикла нисколько не уменьшит времени его выполнения.

Кстати, целочисленная арифметика, про которую вы говорили (i + 1) - это то, из чего строится работа процессора. И складывать числа любой язык программирования должен примерно одинаково (хотя в языках с динамической типизацией, например 1С, время уйдет еще на проверку типа).

Вместо того, чтобы критиковать тест, может лучше сравнить время работы массивов и хэш-таблиц? Это тоже примитивы, с которыми работает программист. И от того, насколько оптимально они реализованы, зависит и общее быстродействие приложения.

[mazzy]

Цитата:

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

По моему опыту, скорость работы транзакционного приложения (каковым и Аксапта, безусловно, является) на 80-85% определяется ожиданием завершения операции базой данных.

Во-во...

Цитата:

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

Программист сравнивает время работы примитивов, предоставляемых языком программирования. А не время работы бизнес-функций.

Понятно. Администратор SQL сравнивает время выполнения запросов. Администратор сети сравнивает время прохождения пакетов по сети. И т.п.

Это что-то новое.
И раньше 1Совцы всячески уходили от сравнения функционала, но хоть говорили о производительности "платформы" в целом. Теперь вот до примитивов скатились.

Цитата:

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

Похоже, что скорость работы 1С сопоставима с AX3.

Если вы настаиваете на гордом звании Программист, то чего ж смешиваете "скорость работы системы" и "скорость работы примитивов"?

Цитата:

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

Кстати, целочисленная арифметика, про которую вы говорили (i + 1) - это то, из чего строится работа процессора. И складывать числа любой язык программирования должен примерно одинаково (хотя в языках с динамической типизацией, например 1С, время уйдет еще на проверку типа).

Нет. Думайте дальше.
Скорость работы транзакционного приложения зависит не только от скорости работы процессора.

Цитата:

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

Вместо того, чтобы критиковать тест, может лучше сравнить время работы массивов и хэш-таблиц? Это тоже примитивы, с которыми работает программист. И от того, насколько оптимально они реализованы, зависит и общее быстродействие приложения.

Вам же говорят - мало от этого зависит.
Массивы и хеш-таблицы - структуры, которые работают на клиенте.
Еще раз перечитайте сообщения fed - "скорость работы транзакционного приложения"...

[RumataEstor]

Цитата:

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

Это что-то новое.
И раньше 1Совцы всячески уходили от сравнения функционала, но хоть говорили о производительности "платформы" в целом. Теперь вот до примитивов скатились.

Я не 1Совец. Просто у меня есть возможность проверить с точки зрения программиста какой из интерпретаторов (хотя Аксапта позиционируется как компилятор) выполняет свои функции быстрее.

Цитата:

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

Если вы настаиваете на гордом звании Программист, то чего ж смешиваете "скорость работы системы" и "скорость работы примитивов"?

Для меня (так как я не являюсь пользователем функционала) это одно и то же.

Цитата:

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

Вам же говорят - мало от этого зависит.
Массивы и хеш-таблицы - структуры, которые работают на клиенте.
Еще раз перечитайте сообщения fed - "скорость работы транзакционного приложения"...

Ну это не вы говорите. Давайте лучше сравним время расчета себестоимости. Возьмем функцию из Аксапты, портируем ее на 1С и замерим время.

[belugin]

Аксапте не "позиционируется как компилятор" в машкод.

Вы знаете как была устроена ява когда не было хотспота?

[belugin]

Цитата:

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

Ну это не вы говорите. Давайте лучше сравним время расчета себестоимости. Возьмем функцию из Аксапты, портируем ее на 1С и замерим время.

вот это уже ближе к реальности, только неосуществимо (ни у кого нет столько времени на такую хрень).

В принципе, не очень понятно, зачем тестировать примитивы, так как непонятно на какое решение будут влиять результаты такого рода тестов. Вы же не будете выбирать КИС по времени работы пустого цикла?
Или даже по времени работы "портированной себестоимости" - вам нужно знать сколько у вас будет происходить закрытие склада - в 1се одинесовское в аксапте аксаптовское или, например, сколько ользователей одновременнно могут вводит заказы с заданной скоростью. А еще такая есть вещь как масштабируемость.

Даже если вы программист, вы не пользуетесь примитивами. Как правило ваша работа базируется на существующей бизнеслогике.

Может быть стоит проводить какие-то исследования для определения теоретического предела оптимизации, но тогда надо проводить неки тести, которые будут отражать все аспекты программирования, от субд до лекгой интерграции сторонниз компонентов. Например, из Фч можно вызвать как DLL так и .NET код скомпилированный в машинный.

[blokva]

Есть предложение, давай те проверим сколько времени данный код твыполняется в SAP и тут же сделаем вывод что скорость работы 1С выше чем в SAP!
Сравнивать надо сопоставимые вещи!
Давайте не будем ездить в булочную на БелАЗе!

[RumataEstor]

Цитата:

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

Или даже по времени работы "портированной себестоимости" - вам нужно знать сколько у вас будет происходить закрытие склада - в 1се одинесовское в аксапте аксаптовское или, например, сколько ользователей одновременнно могут вводит заказы с заданной скоростью. А еще такая есть вещь как масштабируемость.

Я не сравниваю подходы к работе с БД в этих системах. И уж тем более не хочу сравнивать функционал систем. Ведь для 1Са написана куча разных конфигураций, в каждой из которых одна и та функция типа расчета себестоимости может выполняться своим собственным оригинальным образом.

Я хочу определить, на какой платформе идентичный код будет выполняться быстрее. Не с целью опустить какую-то систему. А с целью определения, какими механизмами лучше не пользоваться в какой-то системе.

Цитата:

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

Даже если вы программист, вы не пользуетесь примитивами. Как правило ваша работа базируется на существующей бизнеслогике.

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

Еще раз повторю. Перевод Аксапты на .NET должен увеличить быстродействие системы в таких задачах на как минимум 2 порядка. Аналогичный код на C# выполняется за долю секунды. Именно такое время я ожидал от "компилятора" Аксапты.

[CDR]

Не так давно на одном из проектов внедрения Аксапто 3.0, в связи с жалобами пользователей на быстродействие Аксапты, спецами клиента был произведен ряд тестов быстродействия Аксапты и 1C. Один из тестов заключался в простом формировании проводок в ГК (в DAX - это была разноска журналов ГК).
Так вот в результате проведенных тестов была выявлена одна интересная деталь. Для одного пользователя, формирующего проводки, производительность 1С действительно была лучше где-то в 3-4 раза. Однако с увеличением числа конкурентных пользователей производительность 1С очень быстро падала, в то время, как производительность Аксапты практически не изменялась. И при достижении где-то 10 конкурентных пользователей уже Аксапта выигрывала у 1С в производительности где-то в 3-4 раза.

Так что, замеры производительности системы при выполнении ей пустых циклов действительно не несут никакого смысла.

[mit]

тыгыгдын тыгыгдын тыгыгдын (поскакал конь тыгыгдынский).

в общем то не пытался чернить аксапту, или выгораживать 1с. хотел просто поделиться с общественностью наблюдением. думаю что это сравнение не даёт плюсов 1с, так как указанные операции в природе редко встречаются, а задачи быстродействием будут упираться совсем в другие вещи (напрмер в скорость выборки из БД), по сему общее быстродействие у ах будет думаю выше. так же нужно иметь ввиду историю. win95 тоже было нечто новым, но достаточно тормозным. так происходит всегда при переходе к новым технологиям, координально меняющим привычный уклад. в четверке было переписано очень очень многое, причем интерфейс старались оставить прежним. судя по переносу сроков все шло очень не гладко. надеюсь что следующие версии будут более производительными.

Цитата:

Сообщение от Михаил Андреев

И какая польза от такого сравнения? Давайте сравним размеры болтов на брызговиках автомобилей.

давайте. с какого авто начнем сравнивать? думаю что как минимум влияет на две вещи: стоимость этих болтов и аэродинамика (если продуть в трубе разница будет афигенной) с соответственно расходом топлива

Цитата:

Сравнивать имеет смысл решения конкретных задач, для которых системы предназначены. А так, извините, это просто глупость.

не извиняю. попрошу без оценок.

Цитата:

У меня вызывает. Компиляторы, штука сложная. Порой, для ускорения одних задач приходится жертвовать производительностью других. И что там сделали авторы обоих компиляторов, совершенно неважно. Важно, насколько они справляются с теми задачами, для которых они предназначены.Вспомнилось. На одном внедрении была задача оптимизации. После упрощения (точнее, дискретизации) её можно было привести к стандартной задаче, реализуемой обычными пакетами типа матлаб и т.п. Ан нет, решили в Аксапте. Потом месяц оптимизировали, так как суток для расчёта не хватало...

"Хрр!" - сказала японская пила.
"Ага!" - сказали суровые сибирские мужики.

и автобус и мерседес скорее всего одинаково быстро приедут по одинаковой дороге. вероятность увеличивается если расстояние невелико, а на дорогах пробки. а если пустить по пустой трассе то скорее всего не одинаково быстро. Михаил, по поводу задачи оптимизации - обращаю Ваше внимание на то что ах не предназначена для задач подобного рода это раз. на этот счет можно найти интегрируемые решения - если интересно то пишите в личку. и Ваш пример будет содержать обращение клиента к серверу, и к БД. так что тонкое место здесь нужно еще поискать это два.

2All не принимайте близко результаты. повторюсь это не показатель работы систем, это лишь наблюдение. думаю что при написании кода его можно учесть и тем самым избежать излишних накладных расходов. в любом случае, если это поможет хоть кому нибудь то это уже хорошо.