Здравствуйте, Egor, Вы писали:

E>Суть программы в следующем — прочитать один большой файл разными размерами буфера (от 1Кб до 64Кб), вывести на экран символы и посчитать затраченное на все это время. Затем построить график зависимости времени от размера буфера.
E>Так вот если размер буфера увеличиваем — время уменьшается. Доходим до 64Кб — хлоп , а прочитать то нельзя.

Вот блин, никогда не думал, что придется вспоминать программирование под MS-DOS.
Давно это было, надеюсь, что меня поправят, если ошибусь.

MS-DOS работает в реальном режиме x86 процессоров. А там память выделяется сегментами, максимальный размер которых не может превышать 64K (т.к. смещение внутри сегмента определяется 16-битными значениями). Но! Ты не можешь получить от ОС блок памяти размером 64K, т.к. в каждом выделеном блоке ОС хранит еще, если не ошибаюсь, 16-байтовый блок MCB (Memory Control Block). Т.е., теоритический максимум в реальном режиме -- (64K — 16). Даже, если run-time Borland-а организует свое управление хипом, без управляющих блоков в каждом выделенном через malloc фрагменте, все равно память он получает от ОС и, поэтому, не может выделить тебе непрерывный блок объемом 64K.

Можно поменять модель памяти на huge для всего приложения. Тогда farmalloc сможет выделить тебе блок 64K. Но, по-моему, это будет не непрерывный блок. А блок из двух сегментов, вначале каждого из которых будет MS-DOS-ный MCB. И "плавный" переход через их границу обеспечивается просто хитрой реализацией работы с huge-указателями в компиляторе. Хотя на уровне (*p++) или memcpy/memmove в программе на это можно не заморачиваться.

Разницы между fread(buf,1024,64,f) и fread(buf,1024*64,1,f) нет, т.к. она все равно обращается к системной функции через прерывание int 21, в которую передается общее количество байт для чтения в виде 16-ти битового числа. А т.к. 1024*64 в 16-ти битах дает 0, то это эквивалентно fread(buf,0,0,f).