Маленький вопрос по write queue. Я так понимаю это то же самое что встречается в других архитектурах под именем write buffer. Но он должен по идее находиться между кешем и внешней шиной, и буферизует все записи, как кешируемые так и некешируемые (в случае ARM например его использрвание настраивается как тип памяти в MMU или MPU).
Можно ли грубо резюмировать что проблема с EPIC что в статике не получается так хорошо распараллелить инструкции как это делает в динамике out-of-order процессор. И причины — группировка инструкций не очень гибкая, предсказать внешние задержки в статике нереально в обычной системе.
И потом поскольку DDR latency очень высока глубина out-of-order должна быть тоже высока, и она недостижима в этих примерах VLIW?
DDR latency и производительность — мне сейчас очень интересна эта тема.
Есть несколько достаточно простых in-order RISC процессоров. Система занимается обработкой сетевых пакетов. Эти процессоры организую своего рода pipeline.
В результате многих оптимизаций пришли к резултату когда bolleneck СPU тратит ~1.6K тактов на пакет, 1.5 тактов на инструкцию, ~570 инструкций на пакет, ~750 тактов это pipeline stall на внешней шине.
ICache miss почти ноль (1-2 в среднем на пакет), DDR latency в зависимости от нагрузки 50-70 тактов.
Внутреннее состояние в tighly coupled memory, т.е. гарантированно очень быстро, как из обычного кеша.
Нужна еще большая производительность.
Оптимизировать код? Осталось всего 570 инструкций — буду пытаться, но шансов уже немного.
Уменьшать задержки с внешней памятью? 47% времени тратится на это. Скорее всего сюда надо смотреть.
DDR bandwidth похоже хватает с головой (жду результаты от ASIC team с тестами на FPGA), но практически уверен по косвенным данным.
Т.е. надо смотреть на DDR latency и уменьшать CPU stalls из-за этого. Процессор in-order, поэтому делать надо explicitly. Prefetch инструкций нет. Есть tightly coupled DMA, доступ к его регистрам близок, есть двухпортовая tightly coupled data memory. Пока вижу вариант делать prefetch с помощью этого DMA с целью спрятать DDR latency. Других возможностей пока не вижу.
Здравствуйте, gardener, Вы писали:
G>Вау, это была целая лекция
G>Маленький вопрос по write queue. Я так понимаю это то же самое что встречается в других архитектурах под именем write buffer. Но он должен по идее находиться между кешем и внешней шиной, и буферизует все записи, как кешируемые так и некешируемые (в случае ARM например его использрвание настраивается как тип памяти в MMU или MPU).
Нет, я имел в виду другое — между исполнительным механизмом и кэшами. О нём редко говорят, но, например, у Криса Касперски в "Техника оптимизации программ. Эффективное использование памяти" хорошо описано его поведение и влияние (на примере P3, P4, так что всё надо пересчитывать на новые процессоры, но основной принцип должен был остаться).
G>Можно ли грубо резюмировать что проблема с EPIC что в статике не получается так хорошо распараллелить инструкции как это делает в динамике out-of-order процессор. И причины — группировка инструкций не очень гибкая, предсказать внешние задержки в статике нереально в обычной системе.
Именно.
G>И потом поскольку DDR latency очень высока глубина out-of-order должна быть тоже высока,
Да. Уже говорил — в последних Intel оно более 200, и аналогичное говорили про топовые ARM.
G> и она недостижима в этих примерах VLIW?
Здравствуйте, s_aa, Вы писали:
_>Сделал бы так, чтобы все языки на момент создания поддерживали только русский язык. Проснулись бы американцы, ан кругом Пока() Если () Для (пер ё = 0; ё < массив.длина; ё++).
Попробуй просто писать на русском языке.
"Пока" и "Если" можешь не руссифицировать.
Гораздо прикольнее называть по-русски имена переменных и функций.
Сначала будет ломка, похожая на наркотическую, зато потом...
A>Гораздо прикольнее называть по-русски имена переменных и функций. A>Сначала будет ломка, похожая на наркотическую, зато потом...
Да я пробовал, нет никакой ломки. Полезно если алгоритм трудный для понимания. Названия функция и переменных типа "ПроверитьНаличиеКарты(ТипКартаПациента карта)" помогает. Недостатки — необходимость переключаться постоянно рус/лат и трудности при интеграции с языками где это не поддерживается.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во-первых, архитектуру x86/x64 предложили бы переделать все, тут сомнения нет, нечего обсуждать.А какую именно нужно — на эту тему и без того обсуждений немало PD>Во-вторых, я не вполне согласен с тезисом. Линукс где только не работает, и появись новый процессор -будет и на нем работать. Windows тоже PD>А все, что выше ОС — так это совсем слабо от процессора зависит
Сорри, малость не согласен насчёт слабой зависимости от архитектуры проца.
На сегодня симметричная система организации мультипроцессорности пока выигрывает, хотя потенциал маштабирования в ней никакой.
На уровне одного кристалла еще хоть как-то масштабируется, на уровне отдельных кристаллов — уже на порядок хуже.
Соответственно, АПИ современных ОС сильно завязаны на это SMP.
Стандарты мейнстримовых языков тоже покрывают лишь SMP.
А всё что вправо-влево — это даже непонятно как окучивать.
А ведь в своё время было и железо и языки и соотв.операционки, для реализации произвольной масштабируемости в отсутствии симметричности доступа к памяти. Т.е., рано или поздно (ИМХО, уже скоро), эту область придётся переизобретать заново.
По-сути, сегодня выгодней поставить один кристалл на 16 ядер, чем 4 кристалла по 4 ядра.
В итоге, эра настоящей мультизадачности началась намного позже, чем могла бы начаться.
Потому что всё упирается в ПО.
Уже имеющееся ПО был относительно легко допилить до SMP-сценариев.
А так-то, если представить, что параллельным вычислениям уделяется достаточное внимание всю дорогу, т.е. наличествуют и языки и операционки, то мощные многопроцессорные компы сугубо юзверского уровня (на относительно дешевых процах) можно было бы собирать еще в 90-е.
Но увы, увы. ))
Те многопроцессорные системы были крайне дороги из-за специфического внешнего контроллера когерентной памяти.
И каждый проц должен уметь общаться с такими контроллерами.
Т.е., там круги по воде пошли слишком далеко, сделав направление многопроцессорных машин неадекватной по стоимости.
Что в итоге еще больше замедлило направление в этой области и т.д. и т.п.
Здравствуйте, WolfHound, Вы писали:
WH>Либо в клиническом случае пользователи качают патч на эту программу и всё. WH>Ты кстати в курсе что винда молча при запуске исправляет некоторые популярные программы чтобы они работали.
Вернее, подставляет им ожидаемые от АПИ баги или недокументированные эффекты.
==============
Не пробовал на виндах до Висты изменить текущий фокус на другое окно прямо во время оповещения о получении окном фокуса и вернуть признак "всё ок"? Очень забавные получались иногда фишки — курсор находится в одном окне EDIT, выделение происходит в этом же окне, а буквы набираются в другое окно.
Т.е. на все экземпляры EDIT в текущем потоке у них был единственный "редактор", которому не всегда корректно выставляли оперируемое окно (зависело от того, в какой последовательности обрабатывать WM_FOCUS — вызывать сначала предыдущую оконную процедуру до сабклассинга, или сначала делать некие свои действия, а потом вызывать предыдущую процедуру).
Здравствуйте, WolfHound, Вы писали:
S>>1. Можно ли предотвратить такое вообще при помощи формальных методов детектирования? WH>Насчёт формальных методов не знаю. WH>Но я думаю можно загрубить таймер. Если таймер будет тикать в 10 раз медленнее чем промах кеша, то мы не сможем извлечь информацию через этот канал. И этого должно быть достаточно для работы со звуком и видео.
Это невозможно в общем случае. Потому как банальный код вида:
for(int i=0; ; i++) if(stop){
result=i;
break;
}
уже даст "счётчик времени" с точностью в десятки раз лучше, чем время обращения к оперативной памяти (отсутствие которого по сути и обнаруживают во всех этих уязвимостях).
Здравствуйте, alex_public, Вы писали:
_>уже даст "счётчик времени" с точностью в десятки раз лучше, чем время обращения к оперативной памяти (отсутствие которого по сути и обнаруживают во всех этих уязвимостях).
И как ты собираешься его использовать?
Твой поток висит на получении данных и ничего не делает.
Чтобы этот трюк сработал нужен таймер, который работает параллельно твоему потоку. В нативе это не проблема ибо есть rdtsc.
А что можно сделать в управляемой системе без разделяемой памяти я не знаю.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
Pzz>Я интересуюсь потому, что традиционные поточные API (напр., POSIX threads, C++ threads) просто не содержат необходимых операций, чтобы программировать компутер с некогерентным кэшом.
Согласен.
Но готовые решения есть в более раннем POSIX.
Например, QNX поддерживает старый POSIX, который, как и сама эта операционка, рассчитан на нессиметричную модель памяти.
Процессы в такой модели размножаются через обычный fork, где через флаги задаётся требуемый уровень шаринга памяти.
Если шаринг памяти м/у двумя экземплярами после форка не требуется, то новый процесс можно отправить на другой узел.
Если требуется, то получается что-то вроде "потоков" внутри одного узла.
Балансировщик нагрузки может перемещать независимые процессы или зависимую группу их м/у узлами.
Кароч, всё уже было изобретено, но забыто за ненадобностью в последние лет 20.
Теперь опять надо.
Pzz>Ну и соответственно, даже если это операции добавить в виде нестандартных расширений
Зачем нестандартных? ))
Классика жанра — пайпы.
После форка независимые по памяти процессы общаются через них, родимых.
В той же QNX общаются просто чудесно, виндовые пайпы работали заметно медленней на той же технике.
Pzz>то чужую библиотеку, если захочется ей воспользоваться, все равно придется перелопачивать, она к такой жизни будет не готова.
ХЗ.
Практически весь легаси гнутый код всегда был готов, бо сразу же писался универсальным образом, чтобы работать не только на SMP.
Pzz>Поэтому мне любопытно, если такое чудо существует, интересно, как люди на нем живут.
На QNX жили прекрасно.
Да и не только QNX, просто я когда-то в конце 90-х плотно щупал QNX4.
Не смотря на скудную графику (в сравнении с виндами), сама она была просто бомба.
А так-то все "большие" UNIX по состоянию на ~20 лет назад были построены сверху несимметричной схемы.
Потому что не могло быть никакой симметричной схемы на, допустим, 128-ми процессорной машинке.
Pzz>В ядре или на самодельной железке с собственной средой программирования такой проблемы нет, потому что и операции нужные, скорее всего, предусмотрены, и legacy кода нет.
Легаси код есть. Полный набор классических юниксовых утилит в наличии.
Здравствуйте, Pzz, Вы писали:
Pzz>Понятно, что если не позволять нитям одного процесса расползаться по ядрам, то проблема сильно поуменьшится. Но не до конца, потому что есть еще shared memory. Делать ее некешируемой — это аццкие тормоза. Да и процессу не давать расползаться по ядрам тоже несколько обидно.
Не по ядрам, а по узлам, где каждый узел — обычный SMP.
Поэтому, вовсе не обидно.
На сегодня "узлом" может быть отдельный кристалл многоядерного проца.
