All streams
Search
Write a publication
Pull to refresh
226
0
Борис Муратшин @zzeng

Пользователь

Send message

Сделать миллион сумматоров и заставить их параллельно что-то суммировать не проблема.
Вопрос в осмысленности такой конструкции.
Какую задачу вы собираетесь решить?

И вам спасибо.
Эта конструкция называется купол Да Винчи, самоопирающийся каркас.

Да, у альфы было 8к,
на этот случай есть sysconf
В худшем случае придётся загрузить страницу и найти запись за одно чтение.

Каждый процесс имеет свою page table.
Видимо всё же page-table а не TLB, последний в своей собственной памяти ищет.

При промахе в TLB вычисляется адрес записи PTE и читается в одно чтение.
Объясните пожалуйста об анализе каких записей (которые я по-вашему должен производить) вы говорите? Ощущение что мы про разное говорим.

Нижний уровень page-table, который в «моём» случае одномерный массив с прямой индексацией, всё равно нужен каждому процессу. И он составляет 0.1% от фактически используемого процессом виртуального пространства.

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

Такая схема успешно работала на VAX-е и сейчас вполне успешно работает на Эльбрусах.

Для сохранения общей части TLB есть механизм глобальных страниц.
Допустим, в некоторой архитектуре, если страница есть в TLB, то она есть и в памяти.
И мы промахнулись, всё равно лезть в page table за нужным элементом, а там уже указано на диске она или нет.

Второй вариант, в элементе TLB указано, в памяти страница или нет (или частично, чем черт не шутит). Если частично, это ваш вариант, надо на всякий случай лезть в page table и проверять.

Проще вместо частичной выгрузки разбить страницу на фрагменты.
Это же не std::vector, вставляйте на здоровье.
Возможно я не понял вопрос.
В этой книге, кстати, в приложении 8 указано, что на PTE отводится 9 разрядов
плюс 12 на страницу, итого, большие страницы должны быть по 2Мб. Но выше действительно говорится о 4Мб. А откуда еще разряд?
«Страницы размером 4 Мбайт описываются с помощью двух смежных PTE
2-го уровня таблицы» что бы это значило?
да, комплексные корни и образуют всю эту фрактальную бахрому
(тьфу, кнопкой промахнулся, -1 получилось:( )
Таких точек много, они возникают каждый раз, когда сталкиваются разные ветки мод.
Вот произошла первая бифуркация и моды разделились на два жгута.
В конце концов это жгуты сомкнулись и моды массово пересеклись в одной точке.

Такие же точки есть и в местах, когда сталкиваются жгуты от последующих бифуркаций.
Это уже за «горизонтом событий», но какая-то преемственность поведения траекторий сохраняется.
А как насчет распределения остатков от деления первых 10 млн. простых чисел.
image
Деления на что? На всё.
Отсюда.
Желчи многовато, а так в целом согласен.
Кроме обсуждения автора то есть что сказать?
Существует некоторая разница между знанием как устроены вещи и
пониманием почему они устроены именно так.
Статья об этом.
Надеюсь что ответил на ваш вопрос.
Был бы я "Беспристрастным Свидетелем", да в мантии, пожалуй, так бы и выражался.
Добавлю еще.
Пролистал мельком, именно того, о чем собрался рассказать не увидел,
не стал полностью смотреть, чтобы «не сбивать прицел».
Спасибо,
но я не стал бы приравнивать бифуркационную диаграмму к хаосу :)

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Registered
Activity