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

> date +%s && ./test6 && date +%s;

time ./test6

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

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

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

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

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

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

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

однозначно не стОит

Это было бы так если бы использовался обычный read

> Это было бы так если бы использовался обычный read

fread использует тот же sys_read(). В чём я ошибаюсь?

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

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

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

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

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

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

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

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

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

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

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

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

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

~610 Mb в 512 Mb оперативки?

"современное оборудование"? 512 Мбайт оперативки?

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

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