Твій комп'ютерний запис – це містифікація

Коли ви починаєте програмувати, пам’ять здається досить простою. У вас є купа байтів, кожен з яких має свою адресу. Якщо ви хочете щось прочитати або записати, ви вказуєте адресу, і комп’ютер йде туди і виконує вашу команду. Звичайно, деякі адреси можуть бути зарезервовані для обладнання або операційної системи, але загальна ідея проста: пам’ять — це великий масив байтів.

Так само, як ми вдаємо, що дріт є ідеальним провідником, модель великого масиву пам’яті колись була невеликим викривленням правди. Однак у сучасному комп’ютері це майже повністю брехня. Адреса, яку ви використовуєте, ймовірно, не є фізичною адресою. Дані, які ви читаєте, можуть взагалі не надходити з ОЗП. Навіть якщо надходять, вони можуть бути в одному з кількох кешів. І якщо ви заглибитеся, то виявите, що ваш SSD — це, мабуть, ще один рівень в ієрархії пам’яті.

Потреба у швидкості

Фундаментальна проблема полягає в тому, що процесори стали набагато швидшими за пам’ять. Сучасний процесор може виконувати кілька інструкцій за один такт, але доступ до звичайної ОЗП може зайняти сотні тактів. Якби процесор мав чекати на ОЗП щоразу, коли йому потрібні дані, значна частина цієї вражаючої обчислювальної потужності марнувалася б.

Рішенням є кешування. Зберігайте копії часто використовуваних даних у менших, швидших пам’ятях, ближчих до процесора. Більшість сучасних настільних процесорів мають щонайменше три рівні кешу. Кеш L1 крихітний, але надзвичайно швидкий, і часто розділений між інструкціями та даними. L2 більший і трохи повільніший, тоді як L3 ще більший і зазвичай також повільніший.

Ситуація стає цікавішою з кількома ядрами, як це часто буває в наші дні. Зазвичай кожне ядро має власний кеш L1 і L2, тоді як кілька ядер спільно використовують кеш L3. Але це не універсально. Деякі процесори спільно використовують кеші L2 між ядрами. Інші мають кілька кешів L3, кожен з яких обслуговує групу ядер. Точне розташування залежить від архітектури процесора.

Важлива деталь: кеші зазвичай не працюють побайтово. Вони передають та відстежують блоки, які називаються кеш-лініями, зазвичай 64 байти на сучасних настільних процесорах. Якщо ви читаєте один байт, якого немає в кеші, процесор зазвичай витягує всю лінію, що містить цей байт.

Саме тому послідовний доступ до пам’яті часто набагато швидший, ніж випадковий. Якщо ви читаєте наступний байт, є велика ймовірність, що він вже є в кеші. Апаратні префетчери можуть навіть передбачати, що вам знадобиться далі.

Але можуть виникнути проблеми. Уявіть, що два ядра модифікують абсолютно різні змінні. Якщо ці змінні випадково потрапляють до однієї кеш-лінії, ядра можуть багаторазово анулювати копії один одного, витрачаючи час, навіть якщо вони логічно не спільно використовують дані.

Протоколи, такі як MESI, підтримують узгодженість кешів, координуючи, яке ядро володіє лінією, а які копії є дійсними. MESI — це акронім станів кеш-лінії: модифікований (modified), ексклюзивний (exclusive), спільний (shared) або недійсний (invalid). Системи пам’яті повинні з’ясувати, як підтримувати кеші в синхронізованому стані. Але узгодженість не усуває необхідності в синхронізації або правилах порядку операцій з пам’яттю в багатопотокових програмах. Суть у тому, що навіть наша проста адресована побайтово пам’ять таємно працює більшими шматками.

Адреса теж не справжня

Досі ми припускали, що адреса, яку ви надаєте, ідентифікує місце в ОЗП. Зазвичай це не так. Сучасні операційні системи використовують віртуальну пам’ять. Ваша програма бачить простір віртуальних адрес, який операційна система та процесор спільно відображають на фізичну пам’ять.

Блок керування пам’яттю, або MMU, перетворює віртуальні адреси на фізичні, зазвичай використовуючи таблиці сторінок. Це дозволяє різним програмам використовувати однакові віртуальні адреси, не заважаючи одна одній. Це також забезпечує захист пам’яті та дозволяє спільно використовувати фізичні сторінки.

Звісно, перетворення адрес займає час. Тому ми додаємо ще один кеш.

Буфер перекладу адрес, або TLB, запам’ятовує нещодавно використані перетворення адрес. Влучення в TLB дозволяє уникнути потенційно дорогого пошуку по таблиці сторінок. Деякі процесори навіть мають кілька рівнів TLB. На відміну від звичайного кешу ЦП, який зазвичай працює з кеш-лініями, віртуальна пам’ять зазвичай працює зі сторінками, часто 4 КБ, хоча підтримуються і більші сторінки.

Зверніть увагу, що відбувається. У нас є кеші для даних, кеші для інструкцій та кеші для інформації, необхідної для пошуку даних та інструкцій.

Простий акт читання змінної став напрочуд складним.

Не вся ОЗП створена однаково

Навіть якщо ми пройдемо через кеші і нарешті дістанемося до ОЗП, справи не обов’язково будуть простими. У системах з кількома процесорами або певними конфігураціями багатоядерних систем доступ до пам’яті може бути неоднорідним. Це називається NUMA, або Non-Uniform Memory Access (неоднорідний доступ до пам’яті).

Процесор може мати відносно швидкий доступ до пам’яті, підключеної до його власного вузла NUMA, тоді як доступ до пам’яті, пов’язаної з іншим вузлом, вимагає перетину інтерконекту. Обидва розташування є звичайною ОЗП, і обидва можуть відображатися в одному адресному просторі, але час доступу та доступна пропускна здатність можуть відрізнятися.

Операційна система намагається розмістити пам’ять поблизу процесорів, які її використовують. Тому переміщення потоку на інший ЦП може змінити продуктивність його пам’яті, хоча адреси програми не змінилися.

І NUMA не обмежується традиційними багатопроцесорними серверами. Сучасні системи з чіплетами, гетерогенною пам’яттю та технологіями, такими як CXL, роблять топологію пам’яті дедалі цікавішою.

Що, якщо це не в пам’яті?

Віртуальна пам’ять має ще один трюк. Віртуальна сторінка не обов’язково має бути прив’язана до фізичної ОЗП в момент її доступу.

Коли програма звертається до сторінки, яка наразі не відображена належним чином, процесор генерує помилку сторінки (page fault). Операційна система вирішує, що робити. Іноді вона просто виділяє нову сторінку. Іноді вона отримує дані з виконуваного файлу або файлу, відображеного в пам’яті. В інших випадках сторінка була переміщена з ОЗП у простір підкачки (swap space) і повинна бути отримана. Зверніть увагу, що такі дані, як виконувані дані, зазвичай незмінні, тому більшість операційних систем не вивантажують їх. Вони просто видаляють їх і знають, що зможуть перезавантажити ту саму сторінку пізніше, коли це буде потрібно.

Це означає, що ваша програма може звертатися до даних, яких зараз немає у фізичній пам’яті. Природно, доступ до SSD набагато повільніший, ніж доступ до ОЗП, тому надмірне використання підкачки може призвести до краху комп’ютера.

Однак віртуальна пам’ять не обов’язково вимагає підкачки. Перетворення адрес та захист корисні навіть у системах, які ніколи не переміщують сторінки на диск.

Ваш SSD — це теж пам’ять

Припустимо, ваша програма читає файл. Ви можете уявити, що операційна система надсилає запит на SSD і чекає на дані. Але якщо файл нещодавно використовувався, дані можуть бути вже в ОЗП.

Операційні системи підтримують кеш файлової системи, зберігаючи часто або нещодавно використані дані файлів у пам’яті. Записи також можуть буферизуватися в ОЗП, перш ніж зрештою досягти постійного сховища.

Це робить ОЗП кешем для вторинного сховища, так само, як L3 є кешем для ОЗП.

Аналогія не ідеальна. ОЗП також є основним робочим сховищем для запущених програм, а анонімна пам’ять не обов’язково є копією чогось на диску. Але загальна ієрархія зрозуміла: регістри, кеші ЦП, ОЗП та постійне сховище забезпечують прогресивно різні компроміси між швидкістю, місткістю та вартістю.

Навіть SSD мають власні кеші та перетворення адрес. Їхні шари перетворення флеш-пам’яті відображають логічні адреси блоків на фізичні розташування флеш-пам’яті, приховуючи балансування зносу та збирання сміття від хоста. Очевидно, ніхто не хоче говорити правду про адреси.

Стиснення середини

Але що, якби ми могли зробити ОЗП ефективно більшою, не додаючи більше? Стиснення пропонує ще один спосіб ускладнити нашу ієрархію пам’яті. Замість того, щоб негайно переміщувати нечасто використовувану сторінку на диск, чому б її не стиснути і не тримати в ОЗП?

Linux має два відомих механізми для цього: zram та zswap. Zram створює стиснутий блоковий пристрій в ОЗП. Він зазвичай використовується як пристрій підкачки, дозволяючи сторінкам зберігатися у стиснутій формі, а не записуватися на фізичне сховище.

Zswap, з іншого боку, є стиснутим кешем перед пристроєм підкачки. Коли Linux вирішує вивантажити сторінку, zswap намагається стиснути її та зберегти в ОЗП. За необхідності сторінки згодом можуть бути витіснені на основний пристрій підкачки.

Обидва варіанти обмінюють час процесора на місткість пам’яті та зменшення операцій вводу-виводу зі сховищем. Розпакування сторінки коштує циклів ЦП, але це може бути значно дешевше, ніж отримання її з SSD.

Однак є нюанс. Ці механізми працюють через підсистему підкачки. Коли стиснута сторінка потрібна знову, її потрібно розпакувати до звичайної сторінки, перш ніж програма зможе отримати до неї доступ. Це означає помилки сторінок, накладні витрати на керування пам’яттю та переміщення даних. Але що, якби стиснена пам’ять могла поводитися більше як звичайна ОЗП?

Meta хоче змінити правила

Це ідея CRAM, або Compressed RAM (стиснута ОЗП), проєкту, представленого Грегорі Прайсом з Meta на конференції Linux Plumbers Conference у жовтні 2026 року.

Замість того, щоб розглядати стиснену пам’ять як звичайний пристрій підкачки, CRAM пропонує виставляти її через спеціальний вузол NUMA. Linux потім зможе використовувати існуючі механізми керування пам’яттю для переміщення сторінок між звичайною ОЗП і стиснутою пам’яттю. Найцікавішою частиною є апаратне стиснення та розпакування, що дозволяє доступ з набагато дрібнішою гранулярністю, ніж звичайний стиснутий підкачування, орієнтований на сторінки.

Розробники повідомляють про вражаючі результати бенчмаркінгу, включаючи швидкість читання, яка в деяких тестах наближається до звичайної ОЗП, та значні покращення порівняно з zram для вибраних робочих навантажень.

Це не означає, що стиснення раптом стало безкоштовним. Записи, коефіцієнти стиснення, вимоги до обладнання та керування нестислими даними — все це має значення. CRAM — це все ще розробницька робота, не готова для повсякденного використання.

Але це ілюструє, куди прямує ієрархія пам’яті. Замість того, щоб просто вирішувати, чи сторінка знаходиться в ОЗП чи на диску, операційна система може вибирати між звичайною ОЗП, стиснутою пам’яттю, повільнішими рівнями пам’яті та вторинним сховищем.

Ілюзія — це функція

Більшості програмістів не потрібно думати про все це більшість часу. У цьому й полягає суть абстракції. Але коли продуктивність має значення, ілюзія починає пропускати. Послідовний доступ може перевершувати випадковий доступ на величезні відсотки. Два потоки, що модифікують незалежні змінні, можуть боротися за кеш-лінії. Переміщення процесу між ЦП може змінити затримку його пам’яті. Сторінка, яка виглядає як звичайна пам’ять, насправді може вимагати розпакування або поїздки на SSD.

На менших вбудованих системах, звичайно, картина може бути дуже різною. Без MMU або складних кешів пам’ять може виглядати набагато більше як простий фізичний адресний простір, про який ми дізналися спочатку.

Ми почали з масиву байтів. Ми закінчили ієрархією кешів, таблицями перекладу, вузлами NUMA, пулами стиснутої пам’яті та пристроями постійного зберігання, які співпрацюють, щоб підтримувати цю просту ілюзію. Дивовижно, наскільки складною може бути щось таке просте.

Опубліковано в Featured, Interest, Rants, Slider. Теги: cache, CRAM, memory, MMU, swapfile, zram, zswap. Навігація по запису:

← Стрічки резервного копіювання повертаються до Homelab

DARPA Lift Challenge виграв гелікоптер →

46 думок про “Ваша комп’ютерна пам’ять — це брехня”

Anonymous каже:
12 жовтня 2026 о 7:14 ранку
Це нагадує мені про одну думку, яка у мене виникла.

З успіхом 3D Vcache від AMD, я відчуваю, що наступним кроком буде введення чіплета ОЗП на їхні ЦП. Це було б ще одним варіантом з нижчою затримкою перед переходом до системної пам’яті. Тоді, якщо його буде достатньо, він також дозволить людям запускати міні-машини без ОЗП.

Reply
1. D каже:
  12 жовтня 2026 о 9:01 ранку
  Ви винайшли кеш L4, який також іноді називають eDRAM (вбудована DRAM)
  
  Reply
  1. Anonymous каже:
    12 жовтня 2026 о 1:53 дня
    Круто, тепер зробіть це
    
    Reply
    1. bac каже:
      13 жовтня 2026 о 1:29 ночі
      Зроблено, близько десятиліття тому
      
      https://www.intel.com/content/www/us/en/products/sku/88040/intel-core-i75775c-processor-6m-cache-up-to-3-70-ghz/specifications.html
      
      Reply
      1. Anonymous каже:
        13 жовтня 2026 о 6:06 ранку
        Не AMD і не з сучасним дизайном чіплетів.
        
        До речі, частина моєї думки про дизайн полягає в тому, що ОЗП буде не на чіпі, як кеш L3 (або L4 eDRAM), а окремим чіплетом на платі та підключеним до Infinity Fabric, як інший кристал.
        
        Оскільки це буде цілий інший чіп, він може бути величезним зі спеціальним апаратним забезпеченням для керування пам’яттю та набагато кращою затримкою, ніж стандартна ОЗП.
  2. DerAxeman каже:
    13 жовтня 2026 о 11:07 ранку
    Насправді вбудована пам’ять — це не кеш. Це просто пам’ять.
    
    Reply
Gardoni каже:
12 жовтня 2026 о 7:19 ранку
ЛоЛ, це речі, які вивчають на першому семестрі курсу CS.

Людям без освіти, які хочуть писати код, не слід дозволяти це робити, тому що вони завдають більше шкоди, ніж розвивають.

Reply
1. Anonymous каже:
  12 жовтня 2026 о 7:48 ранку
  Добре, що люди можуть робити речі, не маючи на це «дозволу»!
  
  Reply
  1. Nik каже:
    12 жовтня 2026 о 8:26 ранку
    Точно, вони кодують під настрій, щоб усі могли насолоджуватися їхньою некомпетентністю 🙂
    
    Reply
  2. irox каже:
    12 жовтня 2026 о 11:39 ранку
    Як стоматологи, лікарі та хірурги?
    
    Reply
  3. Aknup каже:
    13 жовтня 2026 о 1:32 дня
    Ну, так і ні, код не дозволяє вам змінювати літери команд, тому компілятор заборонить Gardoni генерувати код 🙂
    
    (Жартую)
    
    Reply
2. threeve каже:
  12 жовтня 2026 о 8:20 ранку
  Зараз трильйони доларів поставлені на те, що ніхто більше ніколи не повинен розуміти код, який він пише.
  
  Reply
3. Mark Topham каже:
  12 жовтня 2026 о 8:28 ранку
  Ми відзначили вашу вищість, на жаль, вона нівелюється читанням статті після клікбейтного заголовка.
  
  Reply
  1. Gardoni каже:
    12 жовтня 2026 о 10:02 ранку
    Мені не потрібно читати. Я просто натискаю та коментую ( ͡° ͜ʖ ͡°)
    
    Reply
4. DerAxeman каже:
  12 жовтня 2026 о 8:37 ранку
  Це твердження безглузде. Усі ці функції призначені для абстрагування проблем програмування від розробника програмного забезпечення через апаратне забезпечення. Це було зроблено для того, щоб програмісти могли зосередитися на фундаментальному завданні написання коду, ігноруючи деталі розташування пам’яті та кодування для продуктивності. Дизайнери апаратного забезпечення могли б уникнути багатьох проблем, якщо б це виключили. Процесори могли б бути швидшими, дешевшими та використовувати менше енергії, якби це робили.
  
  Проблема з випускниками CS полягає в тому, що вони знають програмування, а не обов’язково конкретну тему/додаток, для якого призначена програма. Ось чому ми маємо людей, які програмують без ступенів CS. Іноді, якщо ви хочете, щоб щось було зроблено правильно, ви повинні зробити це самі.
  
  Reply
  1. Edgar каже:
    12 жовтня 2026 о 12:24 дня
    Останній абзац — величезне «бінго». Якщо вам доводиться чекати, поки ІТ-спеціалісти налаштують речі, ви ніколи не отримаєте саме те, що хочете, через сліпуче очевидну умову, що вони не розуміють вашої роботи.
    
    Reply
5. A каже:
  12 жовтня 2026 о 10:46 ранку
  Я особисто вважаю, що їм слід закрити всю комп’ютерну журналістику, дискусійні форуми та навчальні матеріали, оскільки, якби я отримав належну освіту в дорогому престижному університеті (як я), мені б це не знадобилося; ці ресурси завдають більше шкоди, ніж користі, оскільки дозволяють іншим, крім мене, намагатися кодувати. Я особисто весь день читаю лише man pages та специфікації мов.
  
  Reply
6. douyarou каже:
  12 жовтня 2026 о 7:04 вечора
  Пфф, дозволяти? Це сайт для хакерів. Вся передумова полягає в тому, щоб робити речі, які нам «не дозволено» робити. Якби ми хотіли лише читати посібники та дотримуватися інструкцій, ми б не були тут.
  :p
  
  Reply
  1. DerAxeman каже:
    13 жовтня 2026 о 3:00 дня
    Це на 100%
    
    Reply
7. man-x86 каже:
  13 жовтня 2026 о 2:57 ранку
  Це стосується більшості мов високого рівня та бібліотек, де програмісти не повинні знати, як працює комп’ютер, щоб отримати результати. Це також відповідає вашому твердженню, що мови високого рівня так само швидко пишуться, як і повільно виконуються.
  
  Reply
Reggie каже:
12 жовтня 2026 о 7:21 ранку
Клікбейтний заголовок. Чому HA опускається так низько?

Reply
1. Iman каже:
  12 жовтня 2026 о 7:29 ранку
  Бо HA копає глибше, щоб зберегти запас у -Z напрямку
  
  Reply
2. Nathan каже:
  12 жовтня 2026 о 7:46 ранку
  Так, також інший темп написання, ніж я очікував. Майже здається трохи ШІ з блоками параграфів і розпливчастими, трохи клікбейтними заголовками.
  Можливо, саме написання за допомогою ШІ змінює те, як пишуть люди… Що може бути ще страшнішим, ніж сам ШІ, який використовується для написання цього?
  
  Reply
  1. Upgrade pi-top [3] каже:
    12 жовтня 2026 о 1:09 дня
    О ні, ви мали рацію з першого разу; це точно «допомога» від LLM.
    …
    «Більшість програмістів не повинні думати про все це більшість часу. У цьому й полягає суть абстракції. Але коли продуктивність має значення, ілюзія починає пропускати. Послідовний доступ може перевершувати випадковий доступ на величезні відсотки. Два потоки, що модифікують незалежні змінні, можуть боротися за кеш-лінії. Переміщення процесу між ЦП може змінити затримку його пам’яті. Сторінка, яка виглядає як звичайна пам’ять, насправді може вимагати розпакування або поїздки на SSD.»
    … це класичний приклад вихідних даних, згенерованих LLM. Стиль невпізнанний.
    
    Reply
    1. David каже:
      12 жовтня 2026 о 3:53 дня
      Я бачив цей стиль написання «дозвольте мені пояснити, що я кажу, поки я це говорю, перелічивши речі, які потрібно сказати» задовго до того, як з’явилися LLM. Набагато менш поширений, звичайно, але він існував.
      
      Reply
    2. irox каже:
      12 жовтня 2026 о 4:41 дня
      Ну, я насправді вам не повірив, тому я скопіював і вставив цей параграф у кілька різних детекторів тексту ШІ. Три сказали 100% ШІ, один сказав 92% ймовірність, що це ШІ… Я також пробував великі фрагменти (оскільки точність покращується з більшою кількістю даних), статті, все ще 100% ШІ (з 92% перейшовши до 96%).
      
      Для довідки я використовував grammarly.com, humalingo.com, app.gptzero.me та pangram.com. Humalingo також заявив про 91% ризик плагіату.
      
      Я не кажу, що вони використовували ШІ для написання цього, чи ні. Але ваші зауваження, здається, підтверджені даними.
      
      Reply
      1. douyarou каже:
        12 жовтня 2026 о 7:08 вечора
        Ну, Ал — головний редактор. Ігноруючи той факт, що він автор цієї статті, вони використовують його для написання кожної статті. Вам не потрібен grammarly.com, щоб це зрозуміти. Вам просто потрібно перевірити сторінку персоналу.
Nik каже:
12 жовтня 2026 о 8:30 ранку
Якщо хтось зацікавлений у читанні про ієрархії пам’яті та узгодженість пам’яті, на мою думку, канонічною книгою є «Комп’ютерна архітектура: кількісний підхід» Паттерсона та Хеннесі.

Якщо хтось може запропонувати інші якісні статті, будь ласка, поділіться назвами.

Reply
CRJEEA каже:
12 жовтня 2026 о 8:33 ранку
Це пройшло довгий шлях з часів використання RAM-диска в DOS, щоб уникнути очікування дисковода.

Reply
Greg A каже:
12 жовтня 2026 о 8:55 ранку
Це гарна оглядова стаття, наскільки вона йде, але мені дуже не сподобався заголовок, це обрамлення «брехні». Нікого не обманюють. Люди, які достатньо добре розуміють пам’ять, щоб уявити контрафактичний варіант (одна шинна транзакція для кожної інструкції завантаження/збереження), також достатньо добре розуміють пам’ять, щоб знати все це вже. Є люди, які ще не дізналися про кеш, узгодженість та всі деталі, але здебільшого вони не мають хибних уявлень, вони просто ще не знають.

Адреса — це просто ручка. Немає потреби робити її моторошною.

Reply
1. Ostracus каже:
  12 жовтня 2026 о 9:39 ранку
  Моторошне адресування на відстані.
  
  Reply
  1. Upgrade pi-top [3] каже:
    12 жовтня 2026 о 1:12 дня
    Браво за посилання на Ейнштейна!
    
    @Greg A ця стаття майже повністю згенерована LLM, тому вона має цей нудотний клікбейтний стиль. Як тільки ви почнете це помічати, ви зможете визначити, чи згенероване відео на YouTube є сміттям, згенерованим LLM, чи дезінформацією…
    
    Reply
    1. Gardoni каже:
      12 жовтня 2026 о 5:46 вечора
      А, тож мої чуття підказували мені, що я знову правильно зробив, сказавши собі пошипстерити в коментарях, не читаючи «статтю» 😂
      
      Це вищого гатунку м’ясо-корабель там ♪
      
      Reply
Nik каже:
12 жовтня 2026 о 9:29 ранку
Вибачте, але стаття написана в стилі «Вони нам брешуть! Все — це обман!»

Ми повністю усвідомлюємо, що наші комп’ютери мають віртуальну пам’ять. Особисті (вони ж ПК) мають її приблизно з 1985 року, тобто 41 рік тому. Причина, з якої її було прийнято, полягала в тому, щоб дозволити ОС і кільком програмам працювати одночасно, не ламаючись/не заважаючи одна одній. Якщо ви не хочете віртуальної пам’яті та захищеного режиму (що більше, ніж просто захист пам’яті), ви можете вимкнути його і запускати будь-яке програмне забезпечення, доступне для такої конфігурації (можливо, DOS?).

Щодо кешів, усі повністю усвідомлюють їхнє існування, і практично ніхто не дбає про це настільки, щоб їхні програми працювали добре (і інженери розробляють свої ієрархії пам’яті таким чином, щоб програми клієнтів працювали трохи швидше з кожним випуском моделі ЦП).

Ці теми широко вивчаються в університетських програмах CS, і існує величезна кількість технічної літератури, яка їх охоплює. Усі ці технології є лише природним розвитком рішень та компромісів, на які ми готові піти, щоб підвищити продуктивність наших комп’ютерів.

Reply
Ostracus каже:
12 жовтня 2026 о 9:36 ранку
Чи можемо ми створювати архітектури, де фундаментальною ціллю оптимізації є щільність інформації, а не пропускна здатність інструкцій? В основному більше результату за ті ж гроші.

Reply
1. Nik каже:
  12 жовтня 2026 о 10:15 ранку
  Ну, вам не потрібна ціла архітектура для цього, лише оптимізоване за щільністю сховище.
  
  Поточні чіпи NAND FLASH здаються цілком відповідними — вони мають чудову площинну, об’ємну щільність та щільність на біт. Також у нас вже є файлові системи, здатні до різних рівнів стиснення, включаючи файлові системи з відкритим кодом.
  
  Чи є у вас якесь екзотичне застосування, яке не задовольняється поточними технологіями?
  
  Reply
paulvdh каже:
12 жовтня 2026 о 9:56 ранку
Кого хвилює, чи має SSD сектори і циліндри, чи ні. Поки він надає правильні байти, я згоден.

Reply
J.C. Wren каже:
12 жовтня 2026 о 10:04 ранку
IBM мала MXT ще в 2000-х. Я не читав статтю CRAM, але апаратне стиснення пам’яті в реальному часі на базі чіпсету існує вже давно.

Reply
Jon Mayo каже:
12 жовтня 2026 о 10:53 ранку
Віртуальна пам’ять — це таблиця пошуку, підключена до деяких старших бітів вашої адреси. Логічно, все, крім нижніх 12 бітів (4K), але насправді це рівні пошуку, щоб зробити розріджену структуру даних, щоб ви могли мати багато невикористаних (і невідображених) областей, або об’єднати деякі рівні, щоб створити більші сторінки (великі сторінки).

Віртуальна пам’ять не є концептуально дуже складною для розуміння. І навіть у фізичному світі ми використовуємо одну таблицю для пошуку чогось в іншій. (Або, принаймні, ми так робили, коли люди ще вміли користуватися картотекою або офісною системою файлів)

Reply
1. Nik каже:
  12 жовтня 2026 о 7:41 вечора
  О, так, все так просто, коли хтось інший це реалізує :D.
  
  Reply
Nick Sargeant каже:
12 жовтня 2026 о 11:10 ранку
Якщо це є, і ви можете це побачити, це реально
Якщо це є, і ви не можете цього побачити, це віртуально
Якщо цього немає, і ви можете це побачити, це уявне

Якщо цього немає, і ви не можете цього побачити, це було вкрадено.

Reply
Larppa каже:
12 жовтня 2026 о 1:44 дня
Мені насправді сподобалася ця стаття.

Reply
1. douyarou каже:
  12 жовтня 2026 о 7:12 вечора
  Мені теж.
  
  Це не все нове, але це призводить до нещодавніх зусиль Meta щодо стиснення. Більшість статей ігнорують ту частину, де потрібне нове обладнання, якого зараз немає в наших комп’ютерах, і створюють враження, ніби ми можемо просто завантажити більше ОЗП. Ал уникнув цього.
  
  Reply
noname каже:
12 жовтня 2026 о 2:08 дня
Ви кажете «брехня», я кажу «техніка». «Брехня» — це надто сильне слово..

Reply
T-rev каже:
12 жовтня 2026 о 4:40 дня
Мені сподобалася ця стаття.

Reply
Oliver каже:
13 жовтня 2026 о 2:02 дня

Zswap, з іншого боку, є стиснутим кешем перед пристроєм підкачки.

Але більше не з фізичним диском як резервом.

Якийсь хлопець провів гарне дослідження, і виявилося, що zswap зараз кращий за zram + swap.

Reply

Залишити відповідь

Скасувати відповідь

Будьте ввічливими та шанобливими, щоб коментарі були чудовими. (Політика коментарів)

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.

Пошук

Ніколи не пропускайте новинки

Слідкуйте у Facebook

Слідкуйте у Twitter

Слідкуйте на YouTube

Слідкуйте за RSS

Зв’язатися з нами

Підписатися

Якщо ви пропустили

FPGA Хроніки: Готові до зондування

4 Коментарі
Ваша комп’ютерна пам’ять — це брехня

46 Коментарів
Виведіть вихід із Discord за допомогою сервера Matrix

59 Коментарів
ESP32 як ваш бездротовий співпроцесор Linux Raspberry Pi

12 Коментарів
Використання LineageOS для телефонів та DIY смарт-телевізорів є досить чудовим

26 Коментарів

Більше з цієї категорії

Наші колонки

Hackaday Links: 11 жовтня 2026 року

4 Коментарі
Найдивніші відеоігри були хаками

29 Коментарів
Hackaday Podcast Епізод 390: DOOM, речі для черепа та дивні можливості OpenSCAD

2 Коментарі
Цього тижня в безпеці: нові атаки Spectre, величезна кількість вразливостей Linux, Google отримує занадто багато ШІ та злом газонокосарок

10 Коментарів
Гарнітура, гідна письменника Hackaday

21 Коментарів