Проблема еще в том, что нет операционной системы, написанной на Haskell, т.е. для работы с TRIPS всё равно нужет компилятор С, а он сильно неэффективный.
Сделать миллион сумматоров и заставить их параллельно что-то суммировать не проблема. Вопрос в осмысленности такой конструкции. Какую задачу вы собираетесь решить?
Объясните пожалуйста об анализе каких записей (которые я по-вашему должен производить) вы говорите? Ощущение что мы про разное говорим.
Нижний уровень page-table, который в «моём» случае одномерный массив с прямой индексацией, всё равно нужен каждому процессу. И он составляет 0.1% от фактически используемого процессом виртуального пространства.
Нужно ли при переключении контекста на другой процесс как-то сериализовать содержимое TLB и возвращать потом обратно я не знаю.
А почему вы считаете, что массив с прямой индексацией медленней дерева?
Вот у вас 4-х уровневое дерево, допустим, три уровня закэшировались,
всё сводится к трём переходам и одному чтению с диска (PTE).
В случае прямого доступа вы всего-лишь пытаетесь прочитать значение по указателю и возможно (в худшем случае) придётся прочесть страницу.
Такая схема успешно работала на VAX-е и сейчас вполне успешно работает на Эльбрусах.
Для сохранения общей части TLB есть механизм глобальных страниц.
Допустим, в некоторой архитектуре, если страница есть в TLB, то она есть и в памяти.
И мы промахнулись, всё равно лезть в page table за нужным элементом, а там уже указано на диске она или нет.
Второй вариант, в элементе TLB указано, в памяти страница или нет (или частично, чем черт не шутит). Если частично, это ваш вариант, надо на всякий случай лезть в page table и проверять.
Проще вместо частичной выгрузки разбить страницу на фрагменты.
В этой книге, кстати, в приложении 8 указано, что на PTE отводится 9 разрядов
плюс 12 на страницу, итого, большие страницы должны быть по 2Мб. Но выше действительно говорится о 4Мб. А откуда еще разряд?
«Страницы размером 4 Мбайт описываются с помощью двух смежных PTE
2-го уровня таблицы» что бы это значило?
Таких точек много, они возникают каждый раз, когда сталкиваются разные ветки мод.
Вот произошла первая бифуркация и моды разделились на два жгута.
В конце концов это жгуты сомкнулись и моды массово пересеклись в одной точке.
Такие же точки есть и в местах, когда сталкиваются жгуты от последующих бифуркаций.
Это уже за «горизонтом событий», но какая-то преемственность поведения траекторий сохраняется.
Проблема еще в том, что нет операционной системы, написанной на Haskell,
т.е. для работы с TRIPS всё равно нужет компилятор С, а он сильно неэффективный.
MSVC, GCC
В моей практике (С++) это не так.
Функции вызываются часто и глубоко.
Особенно это касается виртуальных функций.
Что касается не торчащих наружу функций, для них вообще необязательно ABI соблюдать,
компилятор и так знает какие регистры использованы, а какие нет.
Что же, на Nios II/f есть и предсказания переходов и какой-никакой кэш.
В данный момент нет у меня таких планов.
Сделать миллион сумматоров и заставить их параллельно что-то суммировать не проблема.
Вопрос в осмысленности такой конструкции.
Какую задачу вы собираетесь решить?
Спасибо за уточнения,
J11 я перепутал с V11.
И вам спасибо.
Эта конструкция называется купол Да Винчи, самоопирающийся каркас.
на этот случай есть sysconf
Каждый процесс имеет свою page table.
При промахе в TLB вычисляется адрес записи PTE и читается в одно чтение.
Нижний уровень page-table, который в «моём» случае одномерный массив с прямой индексацией, всё равно нужен каждому процессу. И он составляет 0.1% от фактически используемого процессом виртуального пространства.
Нужно ли при переключении контекста на другой процесс как-то сериализовать содержимое TLB и возвращать потом обратно я не знаю.
Вот у вас 4-х уровневое дерево, допустим, три уровня закэшировались,
всё сводится к трём переходам и одному чтению с диска (PTE).
В случае прямого доступа вы всего-лишь пытаетесь прочитать значение по указателю и возможно (в худшем случае) придётся прочесть страницу.
Такая схема успешно работала на VAX-е и сейчас вполне успешно работает на Эльбрусах.
Для сохранения общей части TLB есть механизм глобальных страниц.
И мы промахнулись, всё равно лезть в page table за нужным элементом, а там уже указано на диске она или нет.
Второй вариант, в элементе TLB указано, в памяти страница или нет (или частично, чем черт не шутит). Если частично, это ваш вариант, надо на всякий случай лезть в page table и проверять.
Проще вместо частичной выгрузки разбить страницу на фрагменты.
Возможно я не понял вопрос.
плюс 12 на страницу, итого, большие страницы должны быть по 2Мб. Но выше действительно говорится о 4Мб. А откуда еще разряд?
«Страницы размером 4 Мбайт описываются с помощью двух смежных PTE
2-го уровня таблицы» что бы это значило?
(тьфу, кнопкой промахнулся, -1 получилось:( )
Вот произошла первая бифуркация и моды разделились на два жгута.
В конце концов это жгуты сомкнулись и моды массово пересеклись в одной точке.
Такие же точки есть и в местах, когда сталкиваются жгуты от последующих бифуркаций.
Это уже за «горизонтом событий», но какая-то преемственность поведения траекторий сохраняется.
Деления на что? На всё.
Отсюда.
Кроме обсуждения автора то есть что сказать?