Оптимизация копирования файлов через несколько потоков

Question

Можете ли вы сделать копирование файлов быстрее благодаря многопоточности?

Редактировать : Для пояснения, предположим, что вы реализовали CopyFile (src, tgt). Кажется логичным, что при определенных обстоятельствах вы можете использовать несколько потоков для ускорения работы.

Редактировать Еще несколько мыслей:

Естественно, это зависит от рассматриваемого HW / хранилища.

Например, если вы копируете с одного диска на другой, совершенно очевидно, что вы можете одновременно читать и писать, используя два потока, что позволяет снизить затраты на производительность самого быстрого из двух (обычно чтение). Но вам не нужно несколько потоков для параллельного чтения / записи, просто async-IO.

Но если async-IO действительно может ускорить процесс (до 2 раз) при чтении / записи с разных дисков, почему это не реализация по умолчанию CopyFile? (или это?)

Answer 1

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

Answer 2

Вот сообщение в блоге об улучшениях производительности копирования файлов в Vista SP1:

http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

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

Поэтому всегда используйте функцию копирования файлов ОС (в Windows это FileCopyEx) и не пишите свою собственную.

Answer 3

Вы можете увидеть преимущество, особенно если файлы находятся на разных устройствах, и в этом случае ввод / вывод может быть очень эффективно перекрыт.

Однако есть также случаи, когда вы могли легко вызвать перегрузку оборудования, поэтому я не думаю, что это оптимизация, которую следует воспринимать легкомысленно.

Что касается добавленного вами дополнительного вопроса:

Но если Async-IO действительно может ускорить вещи (до 2х), когда чтение / запись с разных дисков, почему это не по умолчанию реализация CopyFile? (или есть это?)

Я не знаю внутренностей CopyFile(), но я не удивлюсь, если они не сделают это по нескольким причинам:

1. если бы они реализовали его, используя дополнительный поток (или потоки), который мог бы быть немного более навязчивым для процесса, чем это необходимо (особенно, если процесс является однопоточным до этого момента)
2. если бы они попытались реализовать его с использованием асинхронного ввода-вывода с одним потоком (как указывал ChrisW , это возможно), они могли бы также вызвать проблемы с перебоями и повысить производительность. Возможно, будет непросто определить, когда вы получите выгоду, а не ущерб.

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

Answer 4

Я бы подумал, что нет. Процессору так мало нужно делать.

Answer 5

Если вы реализуете CopyFile, то вместо использования нескольких потоков (например, один поток для чтения и другой поток для записи) вы можете использовать один поток, который инициирует асинхронный ввод / вывод (так что один поток может инициировать / повторно инициировать чтение и запись одновременно), используя порты завершения или что-либо еще.

Для улучшения производительности это может быть полностью реализовано в ядре.

Answer 6

Это зависит, но, как правило, нет, узким местом будет дисковый ввод-вывод, и вы не сможете ускорить дисковый ввод-вывод, используя несколько потоков.

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