Быстродействие ПЛК ОВЕН vs ПЛК Siemens

[capzap]

Повторяю: авторы CoDeSys пишут, что оптимизации в КДС есть. Вот: http://forum.codesys.com/viewtopic.php?f=11&t=5384

Я не говорю про just in time оптимизации. Разумеется их тут нет. Да, steady state. Но это не мешает делать базовые отпимизации, что КДС и делает (вычисляет 2+2 на уровне компиляции, а не при каждом выполнении цикла программы).

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

в каком месте я оправдываюсь, берется один и тот же код, одна и та же КДС, в которой соответственно один и тот же компилятор со своей оптимизацией, разные здесь только плк, который уже выполняет только машинный код. Ни какого научного подхода здесь не требуется. Первым пунктом для создания бенчмарков, @shipilev пишет включать мозги

[Newcomer]

Имею на руках ПЛК110-24.30.Р-М [M02] и потому продолжил тестирование производительности.
Как известно ПЛК110 М02 имеет процессор 400 МГц, в то время как предыдущая модель ПЛК110 имела 180 МГц.
Из сего я ожидал увидеть увеличение производительности примерно в 2 раза, но увидел, увеличение производительности примерно в 15 раз (см. "Тест производительности.jpg").
Из чего вопрос к разработчикам: почему при увеличении тактовой частоты процессора в 2 раза производительность возросла примерно в 15 раз?

Тестовый проек прикрепляю (+ собственная библиотека статистики).

В S7-300 ЦП хилый, но из него выжали по максимуму. В старом ПЛК110 ЦП много мощней, но его возможности программисты фирмы "ОВЕН" использовали плохо. В новом ПЛК110 из ЦП выжали много больше. Вот и результат.

[Владимир Ситников]

в каком месте я оправдываюсь

Слова "К системам реального времени оптимизация, как это может делаться на ПК, ни какого отношения не имеет." говорят лишь "у нас всё особенное, поэтому правильно замерять мы не будем".
Это и есть "оправдываетесь".

Гораздо проще поставить несколько экспериментов и узнать как ведёт себя конкретный компилятор и железка.

@shipilev пишет включать мозги

И обязательно использовать научный подход. Если я попрошу @shipilev'а в twitter'е написать "при замерах не забывайте использовать научный подход" (ну или как он сформулирует), вам проще станет?
Благо, мы сейчас на расстоянии вытянутой руки.

[capzap]

на картинке его доклад в 13 году, он прямо так и говорит померять время и будет бенчмарк, через год (ссыль) он уже конечно стал добавлять что не всё так просто, на винде и солярисе время в разы увеличивается потому что из-за внутренних причин время может "убежать назад", далее добавлял, что подсчет операций в секунду не является верным потому что ОС может организовать кучу тредов, которые будут вклиниваться и мешать подсчету адекватного времени.
Всё им перечисленное ни как не относится к без операционным устройствам, в плк только один поток его ни кто не может нарушить. Функция TIME возвращает не системное время, которое может плавать даже назад, а количество миллисекундных тактовых импульсов с момента работы процессора.

ЗЫ и да у нас все особенно

[Владимир Ситников]

Всё им перечисленное ни как не относится к без операционным устройствам

Разумеется, команды java.lang.System.currentTimeMilis() и java.lang.System.nanoTime() к ПЛК110 никак не относятся.
А вот то, что не так важны результаты бенчмарка, как анализ "почему они такие" (==научный подход), я вам и говорю. Про это говорит и Шипилёв, и это относится и к java и к C++ и к КДС, и даже к CFC языку.

говорит померять время и будет бенчмарк

Надеюсь, это шутка была?

Русским по белому же: "Бенчмарки без анализа сильно расстраивают Шипилёва."

Вот несколько слайдов по теме:
shipilev_benchmark_12.png
shipilev_benchmark_13.png
shipilev_benchmark_74.png
Собственно, видео: http://jeeconf.com/materials/benchmarking/

в плк только один поток его ни кто не может нарушить

Во-первых, я в первую очередь говорю про оптимизатор в программе CoDeSys. То есть оптимизации ещё до того, как программа попадёт в ПЛК.
Во-вторых, бывают многоядерные ПЛК. Там запросто две задачи могут выполняться одновременно.
В третьих, ПЛК110[М02] это многоядерный ПЛК.
Но пёс с ним, для начала, нужно хотя бы разобраться какие оптимизации делает КДС.

ЗЫ и да у нас все особенно

Это лишь отмазка.

[capzap]

Во-первых, я в первую очередь говорю про оптимизатор в программе CoDeSys. То есть оптимизации ещё до того, как программа попадёт в ПЛК.
Во-вторых, бывают многоядерные ПЛК.

1) тогда какая связь в какой плк зальют код, может из таргета, да почем знает КДС какой проц и всё такое будет использовать некая компания из РФ или откуда то еще, чтоб подстраивать правила оптимизации под конкретную архитектуру

2) покажите, вроде бы в этой теме мне давали ссылку, только там всёравно одно ядро отвечало за программу, а второе испоьзовалась для коммуникаций

[Владимир Ситников]

1) тогда какая связь в какой плк зальют код, может из таргета, да почем знает КДС какой проц и всё такое будет использовать некая компания из РФ или откуда то еще, чтоб подстраивать правила оптимизации под конкретную архитектуру

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

2) покажите, вроде бы в этой теме мне давали ссылку, только там всёравно одно ядро отвечало за программу, а второе испоьзовалась для коммуникаций

http://www.owen.ru/forum/showthread....ht=OwenLogicRT
Можно оба ядра использовать для вычислений. Одно простое (PLC_PRG), второе PRU. Но оба могут вычислять одновременно. Прямо на ПЛК110 М02.

Или совсем простой пример: железка PB3000 построена на обычном многоядерном Intel Core CPU и тут хочешь-не-хочешь, несколько потоков прямо работать могут.

[Спорягин Кирилл]

Владимир, я не буду уходить в длинные рассуждения и споры. Замечу только лишь одно, если бы компилятор
оптимизировал цикл, так как Вы предполагаете, т.е. превращал
for j:=1 to JMax do
i := i + 1;
end_for;
в
i := i + JMax,
то время выполнения программы не изменялось бы при изменении параметра JMax.
А оно изменяется и для контроллера S7-1214 и для ПЛК110.

В целом я оцениваю эксперимент, как весьма объективный.

[Владимир Ситников]

В целом я оцениваю эксперимент, как весьма объективный.

Да, тут вы правильно говорите.

Но capzap вообще говорит, что "никакие эксперименты делать не нужно, у ПЛК всё особенное".

Да, уже убедились, что цикл компилятором не выкидывается.
Но, не исключена такая трансформация:

for j:=1 to JMax do
i := i + 1;
end_for;

==>

for j:=1 to JMax do
end_for;
i := i + JMax;

Т.е. время выполнения будет расти, но оно будет показывать не длительность "операции сложения", а длительнось обработки FOR цикла.

Я бы ещё сделал серию экспериментов: цикл с разным количеством переменных.

[capzap]

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

если КДС ещё до перехода к специфике соптимизирует код так, что "измеряемого" в коде не останется, то всё, никакой проц уже не исправит ситуацию

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