Средство для программирования контроллера: Си или МЭК 61131?

Первоначально опубликовано evgen Первоначально опубликовано Владимир Е. Зюбин Это же просто проверяется... сейчас я опытным путем получил, что один миллион операций взятия квадрата из плавающей переменной равной двум занимает 100 секунд, при затратах на организацию цикла в десять секунд... (Борланд 3.5, 1ГГц Пентиум)... т.е. одна операция взятия квадрата на Си занимает всего 90 нс... Какие-то у вас пчелы неправильные на P2-350 миллион раз выполняется за 0.256 секунды или 256нс. Это без оптимизации, без MMX и прочих нововедений.

 

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

В качестве тестовой задачи мы занималисть непрерывным извлечением корня квадратного из "флоат" числа, с подсчетом количества циклов которое получалось за 2 секунды.

Причем - в качестве платформы мы выбрали "средний" 386 процессор, без сопроцессора. То что обычно встречается в промышленных контроллерах.

Текст на С этой незамысловатой программы выглядит так:

#include <stdio.h>
#include <math.h>
#include <time.h>

void main (void)
{
   float calc = 0.;
   float empty_time, calc_time;
   time_t t, t1, t2;
   time (&t);
   do
      time (&t2);
   while (t == t2);     // wait for start of second
   // phase2
   do {
      sqrt (10.0);
      time (&t);
      ++calc;
   }
   while (t - t2 < 2);
   printf ("Squrare root calculation on C, 80386, FP emulation\n");
   printf ("Cycles per 2 seconds: %g\n", calc);
};

Исходник можно взятьс  ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/test5.c

Скомпилируйте и запустиеи его под ДОС. Если запускать по Windows - то надо нажимать клавишу "Control" - иначе результаты будут крайне плохие...

Для "ленивых" - результат компиляции: ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/TEST5.EXE

Так вот, на моем Р4 (Win2000) этот C-шный тест дает ~ 170 000 циклов за две секунды. Хороший результат, но это для нас еще не главное. Главное - как это поведет сеты в реальном контроллере.

Так вот, на контроллере 6040 (Octagon Sysytems) результат - всего 2207 циклов за 2 сек. По моему - стоит задуматься...

Таперь попробуем сделать тот же алгоритм на UL. Владельцы UL могут скачать исходник с ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/test4.plc,

а остальные посмотреть графически:

(ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/test4.jpg)

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

 

Так как в этой программе пришлось делать вывод в консоль (однократную, в конце теста), то для этого в проекте используется внешняя функция, написанная на С следующего вида:

#include <stdio.h>

void _pascal comment (int *n)
{
   switch (*n)
   {
    case 7:
       printf ("Polynomial approximation on FBD, 80386, FP emulation\n");
       break;
     case 8:
       printf ("Cycles per 2 seconds: ");
       break;
   }
}

Исходник - на ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/comment.c

Для тех, у кого еще нет UL, привожу также результат компиляции проекта целиком:

ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/TEST4.EXE

Кстати, это как раз пример "правильного" использования внешней функции, напсанной на С внутри UL, ибо именно для таких задач эта возможность и была предусмотрена!!! Согласитесь, что писать аналог printf на FBD - это уже слишком. А то, что это работает медленно, это в данном случае не критично, поскольку это сообщение делается однократо и после основного цикла.

А теперь самое интересное. Запускаем test4.exe на моем Р4. Результат -

1 101 200 циклов за 2 секунды !!! Это более чем в 6 раз быстрее, чем SQRT на С!!! А что на "слабом" контроллере?

Резутьтат теста на 6040 (Octagon Sysyems) - 11 427 за 2 сек. Т.е. более чем в 5(!) раз быстрее, чем на С!

Результаты сводного теста:

 

Можно также скачать с ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/COMPARE.jpg

 

Таким образом, результаты тестирования предельно объективно показывают, насколько оптимальнее работает компилятор UltraLogik даже по сравнению со столь уважаемым многими Borland C версии 3.1.

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

Именно поэтому я и утверждал, как Вы помните, что если Вы хотите получит программу, (особенно если это не "ТЕТРИС", а программа с минимум консольных операций, и с максимум расчетов реального временм) выполняющуюся в Вашем контроллере МАКСИМАЛЬНО бысто, то быстрее, чем UltraLogik может быть токьло прямой Ассемблер.

По крайне мере, - изо всех известных мне компилирующих языков программирования. Не говоря уже о других широко известных "псевдо-компиляторах" формата IEC-61131.3, которые на самом деле являются либо интерпретаторами, либо "кросс-компиляторами" через С, Паскаль или Java. Производительность таких систем по сравнению с С ничуть не выше, а даже серьезно ниже.

Наверно, именно отсюда у многих есть предубеждение к самому стандарту 61131, как к чему-то "нехорошему". Надеюсь, что проимер UL позволит это предубеждение рассеить, и доказать, что и в рамказ МЭК-овского стандарта можно сделать хороший и быстрвй компилятор, причем, иногда даже более оптимальный чем С.

Все остальные материалы по теме я также выложил на ftp://ftp.prosoft.ru/pub/Software/ultralogik/SQRT_issue/

С уважением.

Сергей Гусев:
do {
                           sqrt (10.0);
                           time (&t);
                           ++calc;
                        }
                        while (t - t2 < 2);


Ребята, это несерьезно... Вы чужих баранов на sqrt
вешаете... :-) У Вас погрешность "эксперимента"
под 50% будет...

В итоге, за счет неверной организации "эксперимента",
Вы завышаете действительное время вычисления sqrt минимум
в два раза...

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

Так все, что угодно "обосновать" можно... :-)

Вот Вам приблизительный текст теста:

#include <stdio.h>
#include <MATH.h>


main () {
long i;
float data;

    data = 2.0;

printf("\n ============ START. ======");
    for (i = 0; i < 1000000000; i++) {
      sqrt(data);
    }

printf("\n ============ END OF PART 1 ======");

    for (i = 0; i < 1000000000; i++) {
    }
printf("\n ============ END OF PART 2 ======");


return(NULL);

}


Замеряйте время выполнения цикла с SQRT
(время между появлением на экране "START" и
"END OF PART 1") и время на накладные расходы...
(время между появлением на экране "END OF PART 1" и
"END OF PART 2"). Время замеряйте просто "ручками"...
10% погрешности тут, я вижу, что слону дробина...
чтобы снизить погрешность увеличивайте число в цикле...

Замерьте, а потом отнимите от первого времени второе...
можно и автоматом эти замеры и вычисления делать,
коль функцией time вы владеете...

Сергей Гусев, Вы меня сильно огорчили,
нехорошо пытаться лапшу окружающим вешать...
да еще и лапшу такого низкого качества...

Добавлю, что подобными "обоснованиями" ничего, кроме
подрыва имиджа UL, добиться нельзя...

P.S. я тут экспериментик поставил на основе ваших исходников
пока у Вас сайт "глючил"...
Так вот. У меня получилось, что
за 100 сек с sqrt исполняется -
18929185 циклов, а без sqrt (тот же самый цикл)-
19103533...

среднее время вычисления sqrt -
50 нс (НОНОСЕКУНД с учетом накладных расходов), и
50 мс (МИКРОСЕКУНД!) (если без учета)...

Резюме - вы завышаете время исполнения не в два раза, а в тысячу (sic!)
раз.

Вы что, ребята?! Надеюсь, все же, что ваш "тест" вы не специально
придумали, а просто по непониманию "сляпали"...
Совет: Вам имеет смысл хорошего консультанта для таких дел принять...
ну, чтобы не позориться прилюдно...

тексты на Си см. здесь:
               calc = 0L;
               time (&t);
               do
                  time (&t2);
               while (t == t2);     // wait for start of second
               // phase2
               do {
                  sqrt (data);
                  time (&t);
                  ++calc;
               }
               while ((t - t2) < TIME_VALUE);
               printf ("\nCycles per %d seconds: %ld", TIME_VALUE, calc);
               N1=(float)calc;


               calc = 0L;
               time (&t);
               do
                  time (&t2);
               while (t == t2);     // wait for start of second
               // phase2
               do {
//                  sqrt (data);
                  time (&t);
                  ++calc;
               } while ((t - t2) < TIME_VALUE);
               N2=(float)calc;
               printf ("\nCycles per %d seconds: %ld", TIME_VALUE, calc);
               printf ("\nseconds per SQRT: %g",
                      (float)(N2-N1)*(float)TIME_VALUE/(N1*N2));

Все зациклилились на скорости, я для себя уже решил и ни кто меня не переубедит, все опробовано на реальных системах, С++ лучше и не только скоростью но и гибкостью. Я динамически могу менять реакцию системы(сейчас это бысстрее, а после этого другое, а это пока подождет), тоесть выделяя больше ресурсов и временени тому, что в этот момент требует большего внимания.

Я согласен, что все языки если есть пользователи имеют право на существования, но С++ более универсален, быстр(если вы сомневаетесь в его прямом быстродействии, то уж за счет оптимального построения задачи с изменяющимися приоритетами тут спору нет). Может для кого то он и неудобен, но это его проблемы. Да и дешевле он.

 

Я вам больше того скажу - приличный компилятор с приличной оптимизацией и с инлайнизацией из цикла
do {
      sqrt (10.0);
      time (&t);
      ++calc;
   }
sqrt уж точно должен выкинуть...

>Увольте. Довольно будет, что я Вам ссылку дал.
>Что я тут, насильно просвещать буду, что ль? :-)

>>>>>>>>>>>>>>>>>>

Придется прозябать в темноте J.

>Сергей, во-первых, не надо рассказывать очевидных вещей.
>а, во-вторых, - читайте внимательно мою статью,
>которую Вы критикуете, по-видимому, предварительно даже
>не удосужившись прочитать...

>>>>>>>>>>>>>>>>>>>

Да читал я ee.

>Прочтите внимательно, и осознайте, что никто не
>говорит, что переносимость - это плохо...

>>>>>>>>>>>>>>>>>>>

Вы так же читайте внимательно. Моя реплика относится не к статье, а к Вашему предыдущему письму.

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

>>>>>>>>>>>>>>>>>>>>>

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

 

С Уважением,

 

Сергей Сорокин