The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Проект Raspberry Pi выпустил микроконтроллер RP2040, стоимостью 1 доллар, opennews (??), 03-Июн-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


135. "Проект Raspberry Pi выпустил микроконтроллер RP2040, стоимос..."  +1 +/
Сообщение от Аноним (64), 04-Июн-21, 00:24 
> рилтайм. И чем больше у тебя ядер, тем проще с ним справляться

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

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

137. "Проект Raspberry Pi выпустил микроконтроллер RP2040, стоимос..."  –3 +/
Сообщение от Ordu (ok), 04-Июн-21, 01:01 
>> рилтайм. И чем больше у тебя ядер, тем проще с ним справляться
> На самом деле всё наоборот, чем больше ядер - тем хуже риалтайм.
> Риалтайм - это предсказуемая реакция, а чем больше ядер - тем
> хуже предсказуемость (доступ к шине, к памяти, вот это всё). Если
> при одиноком ядре у тебя точно ничего параллельно не вертится, то
> при двух ядрах ты встрянешь даже на обращении к памяти, будет
> неопределённый лаг, какой уж тут риалтайм.

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

Помимо этого, rt-железо даёт гарантии на максимальное время выполнений операций, в том числе и на обращение к памяти, то есть они не запрещены для rt, просто если их много то дисперсия времени выполнения будет расти. И ещё один нюанс: когда у тебя есть много ядер, то твой код может хранить критичные значения в регистрах, потому что эти регистры принадлежат ему и он ни с кем их не шарит. Может быть он может _все_ нужные ему значения хранить в регистрах. Механизм прерываний на одном ядре в этом смысле гораздо хуже -- прерывания могут случаться асихронно и гораздо больнее бьют по рилтайму остального кода, плюс обработчик прерывания вынужден начинать с создания стекового фрейма, чтобы потом можно было бы восстановить состояние регистров. А если на одном ядре и без прерываний, то тут у тебя вообще каждая строчка кода должна следовать требованиям жёсткого RT, потому что все они выполняются внутри одного большого цикла, включающего в себя поллинг периферии, и каждая итерация цикла должна выполнятся за (допустим) 20 микросекунд максимум. Шаг влево, шаг вправо и всё, то есть _всё_ (и может быть даже ВСЁ) пошло по ЖПП. И поэтому ты берёшь процик с частотой в туеву хучу гигагерц, дорогущую память к нему, чтобы был бы хороший запас.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру