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

[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 и тут хочешь-не-хочешь, несколько потоков прямо работать могут.