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

Можете ли вы сделать копирование файлов быстрее с помощью нескольких потоков?Оптимизация копирования файлов с помощью нескольких потоков

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

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

Естественно, это зависит от HW/хранения в вопросе.

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

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

источник

2009-02-11 Assaf Lavie

Вы говорите об одном файле с потоками? Или несколько файлов с потоками? – JFV

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

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

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

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

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

если бы они были для реализации его с использованием дополнительного потока (или потоков), который может быть немного более навязчивым для процесса, чем это уместно (особенно если процесс является одним потоком до этой точки)
, если они попытались реализовать его с использованием асинхронного I/O с одной нитью (как вариант ChrisW indicated), они могут быть скорее вероятны как проблемы с улучшением производительности.В общем случае нелегко будет определить, когда вы получите выгоду, а не ущерб.

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

источник

2009-02-11 19:00:42

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

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

источник

2009-02-11 18:49:01

@ocdecio: Кроме того, не забывайте об ограничениях сетевой карты, ЦП и ОЗУ. Если вы копируете несколько файлов одновременно в разных потоках, вам также необходимо учитывать эти соображения. – JFV

@JFV - Правильно. Единственный раз, когда я видел хорошее использование для нескольких потоков, было сканирование каталогов в параллельном режиме. –

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

я думаю нет. Для процессора так мало.

источник

2009-02-11 18:50:01 sblundy

Правда, но вы не могли бы извлечь выгоду из чтения/записи в одно и то же время, например? Или от чтения и записи в разных местах в одном и том же (в некоторых решениях для хранения)? –

Но процессор не выполняет всю эту работу для этих целей. Disk IO делает. – sblundy

@sblundy - но у вас есть потенциал для одновременного хранения разных аппаратных компонентов. –

Это зависит, но, как правило, нет, ваше узкое место будет дисковым IO, и вы не сможете быстрее сделать IO с помощью нескольких потоков.

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

источник

2009-02-11 18:51:48 Nir

, даже если вы читаете/записываете отдельные диски? –

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

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

источник

2009-02-11 19:03:40 ChrisW

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

Нет, это похоже на «начинать чтение, начинать запись, блокировать до тех пор, пока не завершится ... когда один (чтение или запись) завершается, а затем запускает асинхронный другой (который принимает незначительное время для начала), а затем возвращается в ожидании следующего завершения ». – ChrisW

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

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

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

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

источник

2009-02-11 19:32:13 Nir

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

ответ

Смежные вопросы