Физическая память

Разобраться как были устроены исторические типы памяти интересно просто чтобы в очередной раз восхититься, каким изощренным и изворотливым может быть человеческий разум, особенно при нехватке ресурсов.

Разобраться как были устроены исторические типы памяти интересно просто чтобы в очередной раз восхититься, каким изощренным и изворотливым может быть человеческий разум, особенно при нехватке ресурсов.

Вот, например, Milvius(DiskANN) рассчитан на вектора размерности до 32 768, но это приближенный поиск. Но как насчёт поиска точного?
В данной статье рассматривается работоспособность 1024 мерного индекса, хранилищем которого служит обычное B‑дерево (насколько вообще может быть обычным такое дерево). Используемый диск — вполне себе «железный» старый добрый WD Purple, оперативная память сознательно ограничена 8 Гб. Можно ли что‑то из этого выжать на рядовом десктопе за приемлемое время?

Оптимизация поиска выхода из лабиринта представляется относительно простой задачей. Но она подразумевает накопление данных, обучение, если угодно.
Как только возникает потребность накапливать данные, стоит исходить из того, что этих данных станет много и придётся прибегнуть к технологиям из области баз данных.
Здесь представлена робкая попытка разобраться в теме.

Продолжение статьи о разработке стекового процессора с оригинальной архитектурой.
Здесь мы занимаемся инфраструктурой - ассемблером, компилятором С и эмулятором процессора.
Про функцию Аккермана тоже будет, она используется в качестве теста.
Уж извините за кликбейтный заголовок.

Эту фразу из «Макбета» Шекспира автор осмелится перевести как «благодаря зуду на кончиках моих пальцев может появиться что‑то очень странное».
Изначально хотелось всего‑лишь ознакомиться с Verilog, но, «опасное это дело, выходить за порог: стоит ступить на дорогу и, если дашь волю ногам, неизвестно куда тебя занесет».
Занесло в сторону процессора с собственной архитектурой. Автор давно неровно дышит в сторону стековых процессоров, здесь так же присутствуют раздельные конвейеры для потоков управления/исполнения и расширяемая упаковка кода.
Надеюсь, это окажется кому‑то полезным, так же как когда‑то автору был полезен игрушечный hoc из книги Кернигана и Пайка «Unix — программное окружение».

Развитие технических конструкций или же программных систем зачастую напоминает эволюцию живых организмов. С тем отличием, что происходит быстрее и гораздо лучше задокументировано. Можно наблюдать постепенное усложнение, появление новых механизмов/алгоритмов по мере появления новых технических возможностей, комбинирование разных механизмов, исчезновение тупиковых ветвей ... В конце концов это приводит к балансу на пределе физических возможностей и, глядя на результат, уже непонятно, как вообще такое могло появиться на свет, сколько пядей во лбу требуется для общего понимания конструкции.
Аллокатор памяти в С - именно тот случай, когда при попытке ознакомиться с его современным устройством возникает стойкое желание остановиться, мысленно поблагодарить авторов и далее обращаться как с черным ящиком. Если же в читателе сильна любознательность, и/или есть желание постигнуть тайное знание, которое даст ощущение понимания странного поведения программ в нетривиальных случаях, добро пожаловать под кат.

Проводится сеанс разоблачения магии (CISC, RISC, OoO, VLIW, EPIC, ...).
Без традиционной рубрики “а что, если” тоже не обошлось.
Добро пожаловать под кат, правда, лёгкого чтения ожидать не стоит.

По ощущениям, 4К страницы памяти были с нам всегда, они воспринимаются как нечто совершенно естественное, аксиоматическое. В технике, где за любым числом стоит компромисс, это означает, что либо удалось нащупать объективный баланс, либо что число это находится в самом фундаменте и трогать его себе дороже, даже если изменения назрели.
Но, "для нас нет ничего святого"(С), попробуем выяснить почему именно 4К, изменится ли что-то если сделать 8К, 64К... Зачем вообще фиксировать конкретный размер, почему не сделать страницы произвольной (в пределах разумного) длины.











