The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

Исходное сообщение
"Android портирован для плат на архитектуре RISC-V"
Отправлено Ordu, 27-Янв-21 21:51 
>> больше простора компилятору для оптимизаций
> Вся проблема RISC в том, что там нет рантайм-оптимизации. Которая вполне себе
> есть в CISCoRISC'ах.

Что это значит, ты можешь объяснить? Можешь привести пример ситуации, в которой то, что ты называешь "рантайм-оптимизацией" дало бы возможности выполнять код быстрее, чем тот же код скомпилированный для risc-v?

Может быть я чего-то не понимаю, но склоняюсь к мысли, что не понимаешь ты. Рантайм оптимизация строится вокруг параллельного выполнения команд во многих конвеерах, идея в том, чтобы иметь много исполняющих устройств для каких-то элементарных операций, и потом максимально загружать эти исполняющие устройства работой в рантайме. Но если ты присмотришься, то ты увидишь, что во-первых, для того, чтобы это работало приемлимо нужны костыли типа branch-prediction или out-of-order-execution, которые потребляют ватты и занимают драгоценные транзисторы, во-вторых, существенная часть работы выполняется в компайл-тайме компилятором, который, зная алгоритмы этой рантайм "оптимизации", подбирает инструкции и располагает их так, чтобы они нужным образом разложились бы по конвеерам, а потом по исполняющим устройствам. Втыкает, например, nop'ов, чтобы занять чем-нибудь конвеер, чтобы тот не воткнулся в бранчевание не вовремя и не сбросился бы. Или скажем атрибут unlikely для условия -- это же подсказка компилятору как расположить в памяти бранчи, дабы рантайм "оптимизация" не спотыкалась бы на этом условии. Или PGO -- топовое достижение "рантайм оптимизации": давайте соберём профайлером данные о том, как выполняется код, а потом скомпилируем его так, чтобы он хорошо "оптимизировался" бы в рантайме.

Последняя фраза не вызывает когнитивного диссонанса? Рантайм оптимизация в компайл-тайме -- как тебе?

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

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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