Файловый ввод/вывод в несколько потоков

[lastpriot]

Здравствуйте,
пишу приложение для кодирования файлов (си), логика: read -> encode/decode -> write
имеет ли смысл распараллеливать эти операции?

насколько понимаю: если source и destination на разных дисках - профит очевиден, а вот как оно поведет себя в рамках одного раздела?

[eddy]

ЕМНИП, шустрей sendfile ничего нет. Но это для копирования содержимого.
В данном случае можно попробовать ускорить процесс, если размер файла назначения заведомо известен, при помощи mmap.
А просто параллелить запись, сдается мне, смысла нет: если все упирается в производительность encode/decode, то скорость записи некритична; если все упирается в IO, то распараллеливание только усугубит проблему.

Тьфу, чушь написал. Параллелить чтение-преобразование-запись имеет смысл лишь если процесс преобразования занимает очень много времени по сравнению с остальными.

[azsx]

сейчас обрабатываю на делфи текстовой файл 60 гб (мечта поваторить успех одной проги, выборка строк в файле за секунду - две).
запись в несколько потоков на один физический hdd диск значительно усугубляет ситуацию. На ssd уже не факт (вроде даже в плюс). Но плюс не особо очевиден.

логика: read -> encode/decode -> write

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

[Bizdelnick]

Параллелить чтение-преобразование-запись имеет смысл лишь если процесс преобразования занимает очень много времени по сравнению с остальными.

Я бы сказал, параллелить имеет смысл, если преобразование занимает время того же порядка, что и чтение/запись. Если существенно больше или существенно меньше — выгода будет небольшая.

[lastpriot]

при попытке измерять скорость аглоритмов и дискового IO, столкнулся с интересным поведением.
приведу пример на sha256sum:
тест 1:

Spoiler

Код: Выделить всё

mkfifo ~/test.fifo
dd if=/dev/zero of=~/test.fifo bs=1M count=8K

в другом терминале
time sha256sum ~/test.fifo

результаты:
8192+0 records in
8192+0 records out
8589934592 bytes (8,6 GB) copied, 84,0374 s, 102 MB/s

ebfb4ef19ae410f190327b5ebd312711263bc7579970e87d9c1e2d84e06b3c25  test.fifo

real    1m24.063s
user    1m22.524s
sys    0m1.408s

тест 2:

Spoiler

Код: Выделить всё

dd if=/dev/zero of=~/test.bin bs=1M count=8K
time sha256sum ~/test.bin

результаты:
ebfb4ef19ae410f190327b5ebd312711263bc7579970e87d9c1e2d84e06b3c25  test.bin

real    1m37.436s
user    1m27.556s
sys    0m3.368s

тест 3:

Spoiler

Код: Выделить всё

dd if=~/test.bin of=/dev/null bs=1M count=8K
8192+0 records in
8192+0 records out
8589934592 bytes (8,6 GB) copied, 93,2284 s, 92,1 MB/s

собственно вопрос: почему время хеширования данных с диска лишь на 13 сек больше чем с fifo?

ноутбук HP 250(i3-2348M, 2G RAM, 5400rpm), Xubuntu-15.04 (64 bit)

[Bizdelnick]

почему время хеширования данных с диска лишь на 13 сек больше чем с fifo?

А это разве мало?
Потому что подсчёт хеш-суммы занимает больше времени, чем чтение файла с диска.

[lastpriot]

sha256sum не многопоточный

[azsx]

ноутбук HP 250(i3-2348M

с подобной (интересной для себя) проблемой я столкнулся, когда поставил программу дубликатор данных на другой комп. У меня данных с архива 1+ тб. Однако изначально процессор i5-2500 просто умер от расчетов, еле шевелился комп. а ведь там просто расчитывались md5 для каждого 5 мб блока.
Короче, хоть я не спец, но мд5 (тем более сха256) - это очень ресурсоемкие операции.

[Bizdelnick]

Что-то я ступил вчера. В Вашем тесте операции не распараллелены. Сначала dd считывает мегабайт нулей, а sha256sum ничего не делает. Потом sha256sum берёт потихоньку куски этого мегабайта (размер которых соответствует размеру блока, лень гуглить) и считает хеш-сумму, а dd ничего не делает, пока весь мегабайт не будет передан. Потом цикл повторяется.

[lastpriot]

выяснил в чем суть: чтение ускоряется за счет read ahead, и весьма существенно