Pull to refresh

Comments 25

Расскажите про работу с кэшем в сравнении двух архитектур ARM и x86.
Про работу с кэшем или работу кэша? Про работу с кэшем на х86 я написал выше в 5 пунктах, вы имеете в виду, что надо написать подробнее и добавить про Arm?
Добавить про Arm. Интересуют различия двух архитектур.
ОК, то есть надо писать новый пост. Попробую.
«на одном ядре работает код, который просыпается раз в миллисекунду, опрашивает датчики, исполняет PLC код, управляет какой-то железкой. Одновременно на другом ядре работает код ГУИ»

разве не только L3-кеш расшарен, но и L2/L1?
сомнительно, наверно всё же у каждого ядра свой кеш.

«cache lockdown» — запирание кеша?
L1/L2 конечно у каждого ядра свои (если ядра настоящие, не HT) Но если бы в них все помещалось, L3 был бы не нужен.

С «запиранием кэша» есть только одна проблема — если кто-то захочет найти в Армовской документации, что такое cache lockdown — не проблема. А чтобы найти «запирание кеша», надо сначала правильно перевести на английский.
У Core2Duo L2 расшарен. У AMD x2 — был у каждого свой.
Интел писали «но если что то ядру доступно больше кэша»
Многим бенчмарков общий кэш полезен. Некоторым, включая realtime — вреден.
Ну я это и имел в виду — зависит от задач. Если простое однопоточное приложение — то Интел лучше. Если многопоточное — АМД.
В общем случае ответ сложнее. У обоих подходов есть плюсы и минусы. Например, в примере выше, если бы улучшение производительности ГУИ было бы важнее, чем потенциальные задержки в выполнении PLC кода, общий кэш был бы эффективнее.
  1. Не так уж и много в промышленности процессов, где требуются циклы опроса в миллисекунду или около того.
  2. Там, где всё-таки оно нужно, никакого GUI и вообще многозадачности на процессоре не крутится. К тому же, x86 там встречается тоже редко.
1. У меня лично сейчас главная задача — использовать x86 там, где циклы опроса — 100 микросекунд.
Год назад один из немецких производителей пром контроллеров показывал на конференциях, как с x86 при сниженее цикла опроса с миллисекунды в 2 раза на каждой пластиковой бутылочке экономилось под 10% пластика.
2. Beckhoff, Tenasys, Windriver успешно и давно продают софт и контроллеры с Windows GUI, realtime и многозадачностью. Некоторые делают тоже для себя, или Linux решения.
А кассовые аппараты с Embedded Windows — это realtime системы?
soft realtime, наверное. там кассир не заметит если что-то не так, и если система не успеет просканировать код — еще раз пронесет товар над сканером.
Кассовый аппарат и сканер штрих-кодов это разные устройства.
ок, я не эксперт в POS агрегатах
А где вы видели такие аппараты? Сейчас в основном кассы работают под DOS, Linux или Windows. В последнем случае это несколько урезанная версия Windows XP, в которой кассовая программа работает как обычное приложение (например, на .net framework), а девайсы все подключены через обычный OPOS-совместимый windows-драйвер.
Хм… аж под 80% рынка POS терминалов занимает Windows Embedded, хотя что-то могло и измениться… Но у нас в Нижнем все крупные супермаркеты работают именно на таких.
Наврал, наврал, посыпаю голову пеплом. Это похоже суммарная доля всех Win терминалов. Но Spar точно использует версии на Embedded. Надо будет изучить эту тему.
1. То есть у нихдо этого был неэффективный способ управления? Или они изменили тех. процесс?
Просто от времени отклика пластик экономиться не будт.
изменили только контроллер, станок остался тот же.
> Вообще, архитектура х86 предоставляет не очень много
> возможностей программного управления работой кэша.
> Перечислю все эти способы, как раз хватит пальцев на одной руке:

При условии, что у вас на руке два безымянных пальца (два пункта в списке имеют номер 4).
Спасибо за багрепорт.
Cut&paste — зло. Оставить что-ли так, для прикола?
Sign up to leave a comment.