Если я использую Python или блок для супер быстрой программы копии

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

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

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

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

Аналогично, когда вы работаете с коллекциями и другими библиотеками в Java, это в основном компилируемый C, а не интерпретируемый Java.

Есть несколько вещей, которые вы можете сделать, чтобы возможно ускорить процесс.

• Купить более быстрые жесткие диски (10K RPMs вместо 7.5K или меньшая задержка, большие кэши и так далее).
• Копирование между двумя физическими дисками может быть быстрее, чем копирование на один диск (из-за движения головки).
• Если вы копируете по сети, делайте это поэтапно. Другими словами, копируйте быстро на другой локальный диск, а затем медленно по сети.
• Вы также можете сделать это по-другому. Если вы запускаете ночной (или даже еженедельный) процесс для поддержания копии в актуальном состоянии (копируя только измененные файлы), а не три раза в год, вы не окажетесь в ситуации, когда вам нужно скопировать огромное количество данных.
• Также, если вы используете сеть, запускайте его на компьютере, где находится репозиторий. Вы же не хотите копировать все данные с удаленного диска на другой ПК, а затем обратно на еще один удаленный диск.

Вы также можете быть осторожны с Python. Я могу ошибаться (и, несомненно, Pythonistas меня поправят, если я ошибаюсь в этом вопросе), но я смутно припоминаю, что его потоковая обработка может не полностью использовать многоядерные процессоры. В таком случае вам лучше выбрать другое решение.

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

RICHCOPY уже копирует файлы параллельно, и я ожидаю, что единственный способ победить его - лечь в постель с файловой системой, чтобы минимизировать дисковый ввод-вывод, особенно поиск. Я предлагаю вам попробовать ntfsclone и посмотреть, удовлетворяет ли он вашим потребностям. Если нет, то следующим моим предложением будет параллизовать ntfsclone.

В любом случае, работать непосредственно с компоновкой файловой системы на диске проще всего на C, а не на Python и уж точно не на ассемблере. Тем более что для начала можно использовать код на Си из проекта NTFS 3G. Этот код разработан для надежности и простоты переноса, а не для производительности, но это все равно, вероятно, самый простой способ начать.

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

Нет. Или, точнее, при вашем нынешнем уровне владения системным программированием достижение значительного улучшения скорости будет непомерно дорогим. То, о чем вы просите, требует очень специальных знаний. Хотя у меня самого есть опыт внедрения файловых систем (гораздо более простых, чем NTFS, XFS или ext2), я бы не стал браться за эту работу; я бы нанял специалиста.

Сноска: если у вас есть доступ к Linux-ящику, выясните, какую пропускную способность необработанной записи вы можете получить на целевой диск:

time dd if=/dev/zero of=/dev/sdc bs=1024k count=100

даст вам время для последовательной записи 100 МБ самым быстрым возможным способом. Это даст вам абсолютный предел того, что возможно с вашим оборудованием. Не пытайтесь сделать это без понимания страницы руководства для dd! dd означает "уничтожить данные". (На самом деле это означает "копировать и преобразовывать", но cc был взят.)

Программист Windows, вероятно, сможет указать вам на эквивалентный тест для Windows.

1,5 ТБ примерно за 50 часов дает пропускную способность (1,5 * 1024 ^ 2) МБ / (50 * 60 ^ 2) с = 8,7 МБ / с. Теоретическая пропускная способность 100 Мбит / с должна дать вам 12,5 МБ / с. Мне кажется, что у вас проблема с FireWire-соединением. Вам следует подумать об обновлении драйверов или обновлении до лучшего интерфейса firewire / esata / usb.

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

Есть 2 места для замедления:

• Пофайловое копирование НАМНОГО медленнее, чем дисковое (где вы буквально клонируете 100% данных каждого сектора). Специально для файлов диаметром 20 мм. Вы не сможете исправить это с помощью наиболее настроенной сборки , если не переключитесь с клонирования файлов на клонирование необработанных данных на диске. В последнем случае да, Assembly действительно ваш билет (или C) .

• Простое сохранение файлов размером 20 мм и их рекурсивный поиск может быть менее эффективным в Python. Но это, скорее, функция поиска лучшего алгоритма, и вряд ли она будет значительно улучшена с помощью сборки. Кроме того, это НЕ будет основным вкладом в 50 часов

В итоге - сборка ПОМОЖЕТ, если вы выполняете необработанное копирование секторов диска, но НЕ поможет, если вы выполняете копирование на уровне файловой системы.

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

Я думаю, что общее правило здесь состоит в том, что всегда лучше профилировать свой процесс, чтобы увидеть, на что вы тратите время, прежде чем думать об оптимизации.

Прежде чем ставить под сомнение приложение для копирования, скорее всего, следует поставить под сомнение путь передачи данных. Каковы теоретические пределы и чего вы достигаете? Каковы потенциальные узкие места? Если путь передачи данных один, то, скорее всего, вы не получите значительного прироста за счет распараллеливания задач хранения. Вы можете даже усугубить ситуацию. Большинство преимуществ асинхронного ввода-вывода достигается на уровне блоков - на уровне ниже файловой системы.

Одна вещь, которую вы можете сделать для повышения скорости ввода-вывода, - это разделить части получения от источника и хранения до места назначения. Предполагая, что источник и место назначения являются отдельными сущностями, можно теоретически вдвое сократить время этого процесса. Но разве стандартные инструменты уже делают это?

О - и по поводу Python и GIL - при выполнении с привязкой к вводу-выводу GIL на самом деле не такое уж плохое наказание.

Как уже было сказано, здесь не тот язык, который имеет значение; сборка может быть крутой или быстрой для вычислений, но когда процессору приходится «разговаривать» с периферийными устройствами, они задают предел. В этом случае скорость определяется скоростью вашего жесткого диска, и это предел, который вы вряд ли сможете изменить, не поменяв свой жесткий диск и не дождавшись лучшего жесткого диска в будущем, но также и то, как данные организованы на диске, то есть файловой системой. . AFAIK, большинство используемых файловых систем не оптимизированы для быстрой обработки тонны «маленьких» файлов, скорее они оптимизированы для хранения «нескольких» огромных файлов.

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

Нет никакой причины писать программу копирования на ассемблере. Проблема заключается в количестве задействованных операций ввода-вывода, а не в ЦП. Кроме того, функция копирования в python уже написана экспертами на C, и вам не нужно больше скорости, написав ее самостоятельно на ассемблере.

Наконец, многопоточность тоже не поможет, особенно в python. Используйте либо Twisted , либо просто используйте новый модуль многопроцессорности в Python 2.6 и запустите пул процессов для создания копий. Избавьте себя от множества мучений, выполняя работу.

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

Переход на более низкий уровень не означает, что у вас будет лучшая производительность. Возьмем простой пример API-интерфейсов open () и fopen (), где уровень open намного ниже, это более прямой, а fopen () - это оболочка библиотеки для системной функции open ().

Но на самом деле fopen имеет лучшую производительность, потому что он добавляет буферизацию и оптимизирует множество вещей, которые не выполняются в исходной функции open ().

Реализация оптимизации на уровне сборки намного сложнее и менее эффективна, чем в python.

Ни то, ни другое. Если вы хотите воспользоваться преимуществами функций ОС для ускорения ввода-вывода, вам необходимо использовать некоторые специализированные системные вызовы, к которым проще всего получить доступ в C (или C ++). Вам не нужно много знать C, чтобы написать такую ​​программу, но вам действительно нужно знать интерфейсы системных вызовов.

По всей вероятности, вы можете решить проблему без написания кода, используя существующий инструмент или настраивая операционную систему, но если вам действительно нужно написать инструмент, C - самый простой способ сделать это.

С тех пор, как я разместил вопрос, я поигрался с некоторыми вещами, и я думаю, в первую очередь, не для аргументации, но те из вас, кто отправлял ответ, что я привязан к вводу / выводу, верны только частично. Ограничением является время поиска. Долгая история для тестирования различных вариантов. Я построил новую машину с процессором I-7 и достаточно мощной / функциональной материнской платой, а затем использовал те же два диска, с которыми работал, прежде чем я заметил довольно значительное увеличение скорости. Я также заметил, что когда я перемещаю большие файлы (один гигабайт или около того), я получаю устойчивую скорость передачи, превышающую 50 МБ / с, и скорость значительно падает при перемещении небольших файлов. Я думаю, что разница в скорости связана с неупорядоченным диском по сравнению с тем, как программа копирования читает структуру каталогов, чтобы определить файлы для копирования.

Я считаю, что нужно сделать следующее: 1: Прочтите MFT и отсортируйте по секторам, двигаясь снаружи внутрь диска (значит, мне нужно разобраться, как работают многопластинчатые диски) 2: Проанализировать и разделить все смежные файлы по сравнению с несмежными. Я бы справился с сначала смежные файлы, а затем вернитесь для обработки несмежных файлов 3: начните копировать смежные файлы извне внутрь 4. Когда закончите копировать несмежные файлы, по умолчанию они останутся на внутреннем кольца на диске (ах), и они будут смежными. (Хочу отметить, что делаю регулярно дефрагментировать, и менее 1% моих файлов / каталогов фрагментированы), но 1% от 20 миллионов по-прежнему составляет 200 КБ

Почему это лучше, чем просто запускать программу копирования.

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

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

3. Если я все сделаю правильно, я смогу проверять заголовки файлов и запись eof, а также кое-что поработать. CHKDSK - отличная программа, но отчасти тупая. Когда я получаю повреждение файла / папки, действительно трудно определить, что было потеряно, создав свою собственную программу копирования, я мог бы включить цикл обслуживания, который я мог бы вызвать, когда я хочу запустить некоторые тесты для файлов во время копирования. Это может немного замедлить его, но я не очень думаю, потому что ЦП будет перемещать файлы намного быстрее, чем они могут быть извлечены или записаны. И даже если он немного замедляет его при запуске, по крайней мере, я получаю некоторый контроль (возможно, понимание лучшее слово) о проблемах, которые неизбежно возникают в несовершенном мире.

Возможно, мне не придется делать это в A, я искал способы поиграть (прочитать) MFT, и для этого есть даже инструменты Python, см. http://www.integriography.com