Это настолько сложно, что даже трудно начать объяснять, поэтому я просто упомяну несколько основных способов работы программ.
Первый и самый очевидный способ, который часто является самым медленным, - это работа непосредственно с файлом на диске. В основном каждый блок на диске имеет свой логический адрес, и приложение может напрямую работать с данными на диске. Поэтому, если я создаю простой текстовый редактор, я могу загрузить экран текста в видеопамять с диска и записать любые изменения непосредственно на диск, как только они будут сделаны. Этот тип подхода (насколько я знаю) сегодня почти никогда не используется из-за его многочисленных недостатков. Первая проблема заключается в том, что диск настолько медленный по сравнению с ОЗУ, что ЦП практически тратит все свое время на ожидание, пока диск не поспевает за данными. Положительным моментом является то, что мы практически не используем ОЗУ, так как все данные с диска могут быть переданы непосредственно в ОЗУ на видеокарте. Помимо всего этого, у вас есть современные операционные системы, которые делают прямой доступ к оборудованию еще медленнее и во многих случаях невозможным.
Далее у нас есть (к сожалению) общее и наиболее очевидное решение проблемы медленного доступа к диску: мы просто скопируем весь файл в ОЗУ и обработаем копию ОЗУ. Когда мы закончим, мы каким-то образом синхронизируем версию RAM с версией на диске и решим проблему. Современные операционные системы делают это относительно легко, так как программист приложения может использовать сервисы, предоставляемые ОС, для обновления файла, не слишком задумываясь о том, как на самом деле это делается. Основным преимуществом этого подхода является скорость. Оперативная память (по сравнению с дисками) очень быстрая, и диски обычно работают лучше, когда требуется передать больший объем данных. Кроме того, этот подход оставляет диск доступным для использования другими приложениями, и вы можете редактировать файл, пока другое приложение работает с диском. Недостатком является то, что предполагается, что весь файл может быть загружен в ОЗУ за разумное время и что в файле останется достаточно места для других задач в ОЗУ. Иногда это не так. Например, однажды мне пришлось открыть текстовый файл ~ 3,5 ГиБ, и оказалось, что большинство приложений предполагают, что текстовый файл помещается в ОЗУ.
Следующий подход, который обычно используется, когда мы работаем с приложением, которое ожидает большие файлы, - это загрузить часть файла в оперативную память и работать с ней. Когда мы закончим, мы сохраним эту часть на диске и прочитаем следующую часть. Как именно это работает, зависит от структуры самого файла.
В некоторых типах файлов вы можете найти индекс в начале файла, который вы можете загрузить в оперативную память и использовать его для определения логических адресов интересных частей файла. В некоторых других типах файлов вам может потребоваться выполнить поиск во всем файле раздела, содержащего необходимые данные, а затем просто загрузить эту часть файла в ОЗУ.
Этот подход также предоставляет пространство для умных оптимизаций, таких как разрешение редактирования части файла, когда другая часть загружается в ОЗУ в фоновом режиме, чтобы минимизировать время ожидания, необходимое для открытия файла, и так далее.
Таким образом, в примере видеофайла некоторые данные о самом формате будут закодированы в начале штрафа, а затем программе, которая воспроизводит файл, потребуется иметь в памяти только ту часть файла, которая воспроизводится в данный момент. Чтобы сделать воспроизведение более плавным, программы также сохранят часть файла, которую еще предстоит воспроизвести в ОЗУ. Обычно нелегко точно определить, сколько времени потребуется диску для доступа к данным. Например, из-за фрагментации часть файла может находиться в начале диска, а часть - в конце диска. Также во время воспроизведения видео другое приложение может попытаться записать большие объемы данных на диск. Поскольку видеоплеер уже имеет некоторый буфер в ОЗУ, воспроизведение должно продолжаться без видимых прерываний.
Этот подход имеет преимущество в использовании меньшего количества ОЗУ, чем в предыдущем, и в то же время достаточно быстрый для использования, которое предсказывает программист. Недостатком является то, что вы полагаетесь на то, что программист может предсказать, какие части файла будут широко использоваться и как, а иногда и ожидаемый шаблон использования может отличаться от реального шаблона использования. Другим недостатком является то, что требуются усилия, чтобы точно определить, какая часть файла должна быть в ОЗУ и насколько большой должна быть эта часть. Если часть слишком мала, вы не набираете достаточную скорость, а если часть слишком велика, вы забираете ОЗУ.
Итак, суммируя 3 варианта, которые я описал: Первый - это ребенок в начальной школе, который подчеркивает каждую букву, которую видит карандашом, пытаясь прочитать слово.
Второй будет печатать весь текст на одной странице, и если страница размером с стену, мы можем столкнуться с некоторыми проблемами.
Третий вариант будет похож на чтение из книги. Вы открываете книгу на определенной странице, а прямо рядом с ней у вас открывается другая страница! Когда вы закончите читать оба, вы переходите к следующей паре.
Обратите внимание, что в этом ответе я не много говорил о бесчисленных кэшах и уровнях абстракции, которые существуют на современных компьютерах между диском, оперативной памятью и процессором. Например, в реальной ситуации, если у вас есть одна программа, которая обращается к жесткому диску, а другая пытается сохранить небольшой файл, этот файл может храниться где-то в ОЗУ в кеше, пока на диске не будет достаточно свободного времени для его записи. , Кроме того, сам диск имеет выигранный внутренний кэш, и он может хранить файл там некоторое время, прежде чем записать его на диск. Также при чтении сама ОС может загружать в ОЗУ больше дисковых блоков, чем запрашивало приложение, поскольку она (правильно или нет) предсказывала, что приложение может скоро понадобиться. То же самое относится и к дисковому кешу. Тогда может оказаться, что диск на самом деле не диск, а RAID, и что у нас есть кэш на контроллере raid и на каждом отдельном диске и так далее.
