LINUX.ORG.RU

Скорость чтения


0

0

А есть ли на современном оборудовании (SATA диск) и в современном linuxе (2.6.9) разница в скорости чтения данных в следующих 2х вариантах программы? Строчки, принадлежащие разным вариантам соответственно помечены цифрой в скобках.

#include <stdio.h>
int main ()
{
int x;
int xx [100000];
int i, z;
FILE *f;

f = fopen ("test6.dat", "r");
for (z = 1; z <= 200; z++)

(1) for (i = 1; i <= 800000; i++)
(2) for (i = 1; i <= 8; i++)
(1) fread (x, sizeof (x), 1, f);
(2) fread (xx, sizeof (xx), 1, f);

fclose (f);
return 0;
}

По моим проверкам
date +%s && ./test6 && date +%s;
ощутимой разницы не наблюдается.
Т. е. получается на уровне программы уровня пользователя не стоит заморачиваться с чтением данных большими "блоками" для увеличения скорости, а можно просто читать по одному значению?


Есть. Оверхед на переключение user/kernelspace.

anonymous
()

fread это libc-шная штука, которая имеет свои буферы и кеши, не надо ничем заморачиваться, за тебя уже K&R заморочились.

Даже если просто read, то всё равно ОС будет нормально кешировать. Хотя конечно если по байту читать, то расходы на переключение контекста будут.

anonymous
()

Первый вариант при больших объёмах читаемых данных намного медленне однозначно, поскольку:

1) Много больше переходов в режим ядра, где, твой запрос пройдёт через несколько уровней:
VFS -> файловая система -> generic block layer -> I/O scheduler

2) Не стоит забывать, что твой процесс не единственный, кому нужно читать данные, то есть серии
запросов твоего процесса в очереди вероятно будут короче.

Если этот файл читался уже в течение этой сессии, то разница в скорости будет меньше, поскольку
он уже находится в страничном кэше.

Agent666
()
Ответ на: комментарий от Agent666

>В чём я ошибаюсь?

Он его использует тогда, когда будут выбраны значения из внутреннего буфера структуры FILE или выполнен fseek, который сбрасывает этот буфер.

anonymous
()
Ответ на: комментарий от Agent666

ты читал маны и K&R? если и читал, то не внимательно.

так вот, там говорится что нехорошо (нехорошо равнозначно БЛЯ НЕ ДЕЛАЙ ТАК НИКОГДА СРАНЫЙ УБЛЮДОК!!!!!1111одинадынoneeleven) "высокоуровненые" вызовы fread(fwrite) с низкоуровневыми read (write). Чем же они такие высокоуровненые? тем что они реализованы как минимум с внутренней прозрачной (правда не очень, но можно думать так, скрестив пальцы) буферизацией, которая за тебя глупого все считывает большими блоками, но отдает тебе, как ты просишь. Возможно так еще что-то понапихали, но как минимум этого хватит.

//капча какая-то неполиткорректная niggers

anonymous
()
Ответ на: комментарий от Agent666

fread может обращаться к ядру в разы меньше засчет считывания (за раз) бОльшего количества блоков с их последующим кэшированием

rei3er
()
Ответ на: комментарий от anonymous

нельзя однозначно сказать, как конкретно в библиотеке реализованы fread/fwrite
кэширование _может_ применяться, но не более того
так что поумерьте свой пыл

rei3er
()
Ответ на: комментарий от rei3er

>так что поумерьте свой пыл

не переживайте, просто я думаю, что начинающему программисту надо думать именно так, потом уж разберется :)

хотя правильней, конечно, внимательней книжки да маны читать

anonymous
()

Пейсал жаст фо фан преобразование rgb2yuv - могу сказать что по 24 байта оно читало несколько быстрее чем по 3, но на финальном результате это не особо сказывалось :)

svr4
()

Поиграйтесь с setvbuf(3). Могу только добавить, что вызов 10^6 функций чтения по 1 байту тяжелее вызова одной функции по 1 байту (хоть и не намного).

anonymous
()

С учетом того, что уже после первого выполнения тела цикла по z файл будет лежать в дисковом кеше Линукса (в оперативке), SATA диск здесь совершенно не причем.

mky ★★★★★
()
Ответ на: комментарий от mky

Ну в общем-то да. "Современность" я больше имел ввиду, что диск с приличным кэшем (аппаратным) и ОС грубо говоря без всяких smartdrv :)

Ну если не нравится, то z можно <=1000 написать. Суть от этого не изменится.

ksicom
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.