Почему функция c "открыта" ~ в 4 раза медленнее на macOS по сравнению с виртуальной машиной Ubuntu на том же компьютере?

#c #macos #ubuntu #filesystems #fcntl

#c #macos #ubuntu #файловые системы #fcntl

Вопрос:

Почему macOS в ~ 4 раза медленнее открывает файлы, чем виртуальная машина Ubuntu на том же компьютере?

MWE, использующий настройки, аналогичные коду, на котором было обнаружено это поведение

 #include <stdio.h>
#include <fcntl.h>
#include <time.h>
int main()
{
    struct timespec tstart={0,0}, tend={0,0};
    clock_gettime(CLOCK_MONOTONIC, amp;tstart);

    int fd = open("/path/to/testfile.txt", O_RDONLY | O_CLOEXEC, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);

    clock_gettime(CLOCK_MONOTONIC, amp;tend);
    printf("%.0f µsn", (((double)tend.tv_sec   1.0e-9*tend.tv_nsec) - ((double)tstart.tv_sec   1.0e-9*tstart.tv_nsec)) * 1.0e6);

   return 0;
}

macOS 10.15.7, без SIP, без хранилища файлов, на MacBook Pro с SSD

 51 µs
46 µs
49 µs
30 µs
46 µs

Виртуальная машина Ubuntu 20.04 (parallels) на том же компьютере

 12 µs
12 µs
12 µs
13 µs
13 µs

1. Я предполагаю, что файловая система виртуальной машины находится в DRAM. Либо это, либо файловая система виртуальной машины намного меньше (меньше записей каталога для поиска при разрешении /path/to/ ).

2. Интересно. Существует ли определенный путь, по которому я мог бы поместить файл, чтобы обойти время разрешения? /aaaa.txt ?

3. Почему вы даже сравниваете две разные операционные системы, в которых работают два разных ядра в двух разных средах (разные библиотеки, разные исполняемые файлы и т. Д.)? Сравнивать эти цифры бессмысленно.

4. Хороший вопрос. Я пытаюсь понять, почему чтение небольших файлов в macOS значительно медленнее, чем в Ubuntu, для приложения, которое поставляется в разных ОС. Я надеялся, что эта настройка виртуальной машины будет иллюстрацией того, что аппаратное обеспечение, несомненно, одинаковое, но вопрос DRAM поставил это под сомнение.

Ответ №1:

Время, проведенное в open функции, вряд ли имеет какое-либо отношение к типу диска или резервной файловой системы; скорее, это в основном вопрос реализации операционной системой системных вызовов и, возможно, в частности, ее модели абстракций файловой системы. Linux — это монолитное ядро без задействованных доменов привилегий или пространств памяти, и оно нацелено на очень быстрое выполнение системных вызовов. По крайней мере, изначально macOS X была построена на микроядре, которое Apple любила десятилетиями, и если это все еще что-то в этом роде, системные вызовы, вероятно, намного дороже. В наши дни они могут даже подключаться к антивирусному программному обеспечению или тому подобному.

Ответ №2:

Виртуальная машина Linux быстрее, чем родная macOS, по-видимому, объясняется https://github.com/golang/go/issues/28739#issuecomment-1042652785

Просто FWIW, это проблема с дисками Apple NVMe (одинаково для Mac T2 и M1). Их производительность очистки кэша ужасна. Это влияет как на macOS, так и на (родной) Linux (предположительно, существующие решения для виртуальных машин не могут перенаправить это как F_FULLSYNC, если они работают быстрее). Вы получаете около 46 операций ввода-вывода F_FULLSYNC в macOS на компьютере M1 и примерно столько же в собственном Linux с fsync ().