Параллельное чтение нескольких файлов

@HamsterGamer · Регистрация: 21.06.2019

Студворк — интернет-сервис помощи студентам

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

1) Если нет возможности параллельного чтения с жесткого диска, то те потоки, которые должны параллельно в очередь писать, будут работать по принципу тонкого горлышка, когда только один поток может производить основную работу (то есть прочитать из файла), конечно он может например после этого начать парсить текст, создать какой-нибудь объект и закинуть его в очередь (+- выйгрыш). Какое решение у такого рода проблемы может быть? Стоит ли тогда вообще сделать всего один читающий файлы и записывающий что-то в очередь поток?

2) А может стоит всё сделать очевиднее, пускай каждый поток и читает из файла, и парсит, и выполняет операции. Не будет никакой потокобезопасной очереди и никаких особых ограничений? Такое решение выглядит хоть и некрасиво, но проше. Только непонятно, будет ли оно оптимальным?

3) К вопросу из 1 нюанса, а можно ли с помощью C++ определить, есть ли возможность параллельного чтения с диска и получив ответ от системы, как-то подстраиваться под это. (например выполнять как я придумал выше в случае если можно, а в противном делать, используя 1 поток на чтение).

Хотелось бы разбираться в best practice когда нужна параллельная обработка и множество данных лежит на диске, понимать что и как нужно использовать. Заранее благодарю!

@nmcf · 19.05.2021, 10:40

Сообщение от HamsterGamer

которую процессор возможно обработает быстрее чем само чтение

Но пока не прочитал, обрабатывать нечего.

@HamsterGamer · 19.05.2021, 12:50 **[ТС]**

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

Добавлено через 1 час 59 минут
Ну неужели нет каких-то очевидных правил при такой проблеме с файловой системой? Или какого-нибудь способа узнать можно ли параллельно читать с диска? :c

@nmcf · 19.05.2021, 13:38

Чем тебе вариант 2 не нравится?

@HamsterGamer · 19.05.2021, 14:12 **[ТС]**

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

Возможно в C++ есть способ определить RAID массив тут или чтение из какого-то облака (то есть то, что обеспечит параллельность физическую) или же это диск с возможностью лишь однопоточного чтения. Тогда вероятнее способ когда один поток читает, а остальные слушают - лучше, а если же всё-таки RAID-массив, то уже 2) или 1) пункты. Хотя 1-й мне кажется самым эталонным и поэтому хочется его попробовать в первую очередь протестировать.

@nmcf · 19.05.2021, 17:35

Там будет всякое кеширование ниже твоей программы.
Если так интересно, сделай пробный вариант и посмотри.

@HamsterGamer · 23.05.2021, 04:52 **[ТС]**

Написал я наконец ту структуру, которую задумывал изначально, чтобы 4 потока читали из файлов и клали в очередь команды, а другие 4 потока брали команды из очереди и выполняли их. И протестировал этот способ со способом, когда есть лишь 1 читатель и когда каждый поток и читает и пишет. Результаты ниже (на 1000 файлов в директории). Почему CPU время для некоторых параллельных бенчей он вывел как 0 я хз.

Compute1 - 4 читают из файла 4 выполняют операции
Compute2 - 1 читает из файла 7 выполняют операции
Compute3 - 8 и читают из файла и выполняют операции

Вообще, думаю, 2 вариант может быть отличным, если операции реально долгие. Что-то такое я использовал когда писал приложение по поиску слов, в которых есть введенное пользователем слово. (брал по несколько десятков слов в ОЗУ под каждый из потоков и они уже искали там подходящие слова, вроде вышло быстро)

Думаю стоит потестить только с чтением из файла, и мб завтра этим займусь.

@JeyCi · 23.05.2021, 06:49

Сообщение от HamsterGamer

И протестировал этот способ со способом, когда есть лишь 1 читатель и когда каждый поток и читает и пишет.

зачем 1 читатель?.. смысл?.. читателей делайте по количеству потоков... это писатель может быть 1! (надо синхронизировать его доступ к ресурсу)

Добавлено через 3 минуты
по таймингу ведь лучше всех получился

Сообщение от HamsterGamer

Compute3 - 8 и читают из файла и выполняют операции

Добавлено через 42 секунды
а чем вам понравился? этот

Сообщение от HamsterGamer

Вообще, думаю, 2 вариант может быть отличным

@HamsterGamer · 23.05.2021, 12:09 **[ТС]**

JeyCi,

Сообщение от JeyCi

зачем 1 читатель?.. смысл?

Ну там нет разницы по общему времени между 4 читателями и 1 читателем, так как потоки, которые выполняют вычисления (4 и 7 соответственно) обрабатывают слишком быстро свои операции. (хотя читающие потоки еще и сплитят текст для создания операции + добавление в потокобезопасную очередь, но там всего символов 10).

Сообщение от JeyCi

по таймингу ведь лучше всех получился

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

Сообщение от JeyCi

а чем вам понравился? этот

Если операция над полученной из файла информацией будет долго обрабатываться, по-крайней мере читающий поток должен быстрее читать и класть в очередь текст, то это должно дать большое ускорение. (Однако я использовал такую реализацию, когда всё что нужно читать, лежит в одном файле. Но Вы, кажется, меня своим вопросом убедили, что если файлов много, а операции долго работают, то пускай 4 потока читает, а 4 пишет, тогда доступ к чтению будет асинхронный). Но и 8 потоков тогда наверное тоже подойдут и возможно даже лучше. Потестить надо, на этот раз мб даже с кодом прикреплю, если он выйдет небольшим.

@HamsterGamer · 23.05.2021, 14:22 **[ТС]**

Я ошибся в написании решения, когда 8 потоков и читает и пишет. У меня каждый из потоков в итоге обрабатывал все файлы, а вот уже с исправленным решением вывод по времени, и это всё выглядит, конечно, разрушающе по сравнению с моей теорией (писал потокобезопасную очередь с достаточно сложной реализацией напрасно :c ).

IGPIGP · 23.05.2021, 16:16

HamsterGamer, я подозреваю, что задача достаточно сильно завязана на железе. Если не рассматривать вопросы кеширования на самом диске, то механический диск и ssd ( не вникая в различия в пределах каждой категории) тоже отличаются. Механический диск пишет и читает цилиндрами. Это значит что блок головок двигается как единое целое (моноблок). Контроллер распараллеливает линейную запись по головкам (конвейерам, которые буферизуются). Это значит, что доступ к записи (и чтению - читается тоже трехмерная структура секторов расположенных на разных сторонах дисков вращающихся на одном шпинделе) не распараллеливается. То есть, физически доступ к одному диску (не дисковому пространству а устройству как таковому) последователен. Это говорит о том, что вы возможно правы в том что:

Сообщение от HamsterGamer

вариант может быть отличным, если операции реально долгие

Если вы имели ввиду вычисления. Например декомпрессия, парсинг и/или десериализация в данные (сложные объекты выделяющие память и пр.ресурсы), обработка, сжатие результатов и запись... Или что-то подобное. В конце концов сами вычисления тоже могут быть затратными по времени.
В этом случае, действительно, асинхронность когда один читает, - другие считают, может дать прирост общей скорости. Но тут важно ещё учесть, что диск может использоваться другими программами (OS не последняя, может свопить на него если так сконфигурировано и есть потребность). С этим вряд ли что-то можно сделать, но в принципе я бы попробовал симитировать сложную вычислительную задачу, чтобы увидеть профит.

@JeyCi · 23.05.2021, 17:39

сколько ядер на HDD и SSD?

Добавлено через 6 минут

Сообщение от HamsterGamer

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

ну, конечно, switch context при асинхронном выполнении - не бесплатная операция...
а вот выполнялись ли некоторые потоки параллельно (на 2х и более ядрах) - не знаю вашу конфигурацию...
и если задачи, действительно, быстрые (т.е. файлы не большие и их обработка не длительная)... то на переключениях контекстов вы могли больше потерять, чем выиграть...

IGPIGP · 23.05.2021, 17:43

HamsterGamer, случай когда файлы размещены на разных дисках заслуживает отдельного анализа)

@HamsterGamer · 23.05.2021, 18:31 **[ТС]**

IGPIGP,

Сообщение от IGPIGP

случай когда файлы размещены на разных дисках заслуживает отдельного анализа

возможно, но я думаю, что понял основной рецепт:

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

2) Случай, когда файл один с большим кол-вом данных. Тут я думаю, что реализация с потокобезопасной очередью и одним читающим потоком (и остальными вычисляющими) - лучшая, потому что в случае если потоков читающих из одного файла будет много, то диск улетит в космос от такой раскрутки вдоль файла + такая реализация проще и понятнее.

3) Случай, когда в директории нужно обработать много файлов с большими данными. Ну тут я думаю нужно использовать 2 случай и просто последовательно складывать части файлов в очередь, представляя всё как один большой сплошной кусок данных.

(при этом в пунктах 2 и 3 важно, что вычисляющие потоки не просто складывают 2+2, а например парсят и обрабатывают информацию, иначе появляется вариант всего с 2 потоками, где один читает из очереди, а другой в нее пишет)

JeyCi,

Сообщение от JeyCi

сколько ядер на HDD и SSD?

Не понял что это значит? Я уверен что они не поддерживают параллельное чтение, если Вы об этом.

Сообщение от JeyCi

то на переключениях контекстов вы могли больше потерять, чем выиграть

Да, думаю Вы правы, и я терял скорость на потоках, вычисляющих данные, потому что операции слишком быстрые + очередь, относительно операций медленная.

@JeyCi · 23.05.2021, 20:10

Сообщение от HamsterGamer

Я уверен что они не поддерживают параллельное чтение, если Вы об этом.

количество ядер важно для CPU-bound операций -- функции и их аргументы проходят через стэк CPU... но раз

Сообщение от HamsterGamer

вычисляющих данные, потому что операции слишком быстрые

- то, соглашусь, это детали...
есть IO-bound операции -- это как раз чтение ваших файлов... ускориться, вероятно, можно - Parallel I/O – Why, How, and Where to? - опять же всё сводится к файловой системе и потокам, или многопоточным (типа MPI) библиотекам... а это опять же Linux и его концепция "всё есть файл" и его многопоточная (серверная) природа, рассчитанная на обслуживание многих клиентов в параллеле даже с одного файла (пространства на диске) - но при условии, что доступ к файлу идёт от разных процессов или по сетевой технологии (когда инфо с node'ов стекается в корень)... в общем там по линку всё описано... и про файловую систему:

Parallel file systems stripe data over multiple storage servers for high performance in parallel access. There are many types of parallel file systems (LUSTRE, GPFS, PVFS2 …), each with their pros and cons depending on system architectures and applications’ data access patterns. Parallel file systems and parallel I/O are utilized mostly in high performance computing systems (HPC) and science applications running on those systems.

и главное преимущество появляется на серверах (которые всё на том же Linux'e)

Server-side optimizations would yield better performance in such situations. Recent HPC systems architectures and early designs for some of the future Exascale systems will employ I/O forwarding, since compute nodes might not even have local disks to store data. They will just use a fast network interconnect to forward their I/O requests to I/O servers to handle them. Moving the data through the network could be done asynchronously in the background of the applications running on the compute nodes.

...
в общем, бегло просмотрев статью, склоняюсь к тому, что можно пробовать (что уже давно попробовали и без нас) ускорять движение данных по сети... но ускорить считывание со своего родного жёсткого диска - маловероятно (куда уж быстрее, если он и так рядом, под боком у монитора, оперативки и проца) - только если ускорить аппаратно вращение диска (т.е. взяв более быстрый HDD)...
c SSD немного др. история

SSDs, for example, do much better with small fragmented data access than magnetic hard drives, which means that current optimizations to do collective I/O might not be needed on such architectures.

- думаю, что SSD без collective IO, что HDD (современный) с collective IO - может то на то и выходит... по крайней мере ваши исследования (+ теория по линку, который оставила) наталкивают на такую мысль ...
не работала с SSD, не видела ваш код, а, главное, не знаю, на каких библиотеках вы параллелите и не знаю, какие из имеющихся либ максимально продуктивно организуют параллельный IO... всё что заметила - то, что для обработки научных данных используют parallel IO - что и понятно, для повторности опытов - можно и параллельный IO организовать на входе...

Добавлено через 7 минут
спасибо за ваши тесты, если как-нибудь наковыряете ещё какие-нибудь субординарные результаты в придачу к этим, выкладывайте

@JeyCi · 25.05.2021, 07:55

касательно асинхронности: (ДЛЯ IO-BOUND)
вот ради интереса приложу свой старый код на Python - асинхронного чтения отсюда - выкладываю полностью с обращением к папке -

Кликните здесь для просмотра всего текста

выполняет в з потока - просто считывает и print'ует (в это место можно добавить свои вычисления) - мои тестовые 453 файла считывает за милисекунды, действительно быстро, файлы небольшие

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
import asyncio
import aiofiles
import time
import pathlib
 
async def task(name, work_queue):
        cn=0
        while not work_queue.empty():
            f = await work_queue.get()
 
            async with aiofiles.open( f, mode='r') as ff:
                contents = await ff.read()
                print(contents)
                print("------------------------------------------")
                cn=cn+1
        print(cn)
 
async def main(files):
    # Create the queue of 'work'
    work_queue = asyncio.Queue()
 
    # Put some 'work' in the queue
    for f in files:
       await work_queue.put(f)
 
    await asyncio.gather(
       asyncio.create_task(task("One", work_queue)),
       asyncio.create_task(task("Two", work_queue)),
       asyncio.create_task(task("Three", work_queue))
       )
 
def files_all() -> list:
    p = pathlib.WindowsPath("E:\\myFolder")
    files = [child  for child in p.iterdir()]
    print("Всего файлов: ", len(files))
    return files
 
if __name__ == "__main__":
    files=files_all()
    start_time = = time.time() 
    loop = asyncio.get_event_loop()
    results = loop.run_until_complete(main(files))
    elapsed_time = = time.time() - start_time
    print(time.strftime('%H:%M:%S:{}'.format(elapsed_time%1000), time.gmtime(elapsed_time/1000.0))+" ms")

в 1 асинхр. очередь - выполнил за 0,79ms
в 3 асинхр. очереди - выполнил за 0.61ms
в 3 асинхр. очереди без вывода (просто чтение) - тоже за 0.59ms
... синхронный вариант не проверяла для сравнения (не было времени)...

просто у Python свои огранчения в виде GIL (по сути "глобальный мьютекс" для всех потоков, т.к. интерпретатор не может параллельно обрабатывать все потоки - поэтому threads - так себе, а MultiProcessing вроде снимает эти блокировки c GIL)...
но следую обычно этому псевдо-коду с habr

Code
1
2
3
4
5
6
7
8
9
10
11
12
if io_bound:
    if io_very_slow:
        print("Use Asyncio")
    else:
       print("Use Threads")
else:
    print("Multi Processing")    'meaning CPU-bound - mostly calculations
/*
•CPU Bound => Multi Processing
•I/O Bound, Fast I/O, Limited Number of Connections => Multi Threading
•I/O Bound, Slow I/O, Many connections => Asyncio 
*/

приведу пару цитат про асинхронность -

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

ключевой момент здесь:

возишь ему дрова и сваливаешь у его ног.
Остальное он сам асинхронно выпускает скворечники.
Это дело сервера.
Твоё дело дрова подвозить.

вывод (можно картинкой)

если АСИНХРОННЫЕ ОПЕРАЦИИ НЕ НУЖНЫ, то выигрыша не будет.

потому что

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

- что полагаю и есть случай своего родного жёсткого диска...
===

свои нюансы асинхронности в C#.NET

- расходы на async и await ...
и хороший коммент оттуда

... если чтение производится очень маленькими фрагментами. Значительные задержки при операциях файлового ввода/вывода наблюдаются только в момент заполнения/сброса буфера, который очевидно имеет больший объем, чем массив используемый в операциях чтения из стрима. Получается, что подавляющее количество операций завершаются синхронно, поскольку происходит копирование из памяти в память, а не передача данных между памятью и устройством ввода вывода. Для этих синхронно выполненных операций мы и получаем основной оверхед из-за использования task'ов.

в любом случае всегда - дело ещё и в соотв. библиотеке

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

Кликните здесь для просмотра всего текста

ru_stackoverflow_com_/questions/503721/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%BF%D0% BE%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D0%B5-vs-%D0%B0%D1%81%D0%B8%D0%BD%D1%85%D1%80%D0% BE%D0%BD%D0%BD%D0%BE%D0%B5-%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0% B5-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0% BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D 0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0% BA%D0%B5

- и опять всё упёрлось в сервер...
==========================
касательно многопоточности: (ДЛЯ CPU-BOUND)
встречались советы "выравнивать нагрузку", т.к., например, при использовании пула потоков

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

Новые блоги и статьи Все статьи Все блоги /
Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Ниже машинный перевод статьи The Thinkpad X220 Tablet is the best budget school laptop period . Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы,. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .
От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .

@HamsterGamer 40 / 29 / 11 Регистрация: 21.06.2019 Сообщений: 201

	Параллельное чтение нескольких файлов 19.05.2021, 10:19. Показов 4462. Ответов 15 Метки c++, concurrency, многопоточность, чтение файолов (Все метки) Всем привет, подобный вопрос я как-то раз уже задавал, но так и не понял некоторые аспекты. Необходимо реализовать параллельное чтения большого кол-ва файлов, в каждом файле есть какая-то определенная информация, которую процессор возможно обработает быстрее чем само чтение и парсинг из этого файла. Для решения этой задачи я решил, что должна быть потокобезопасная очередь, какое-то кол-во потоков (например половина доступных аппаратной конкурентностью потоков) читает файлы и пишут в эту очередь, и потоки, которые берут из очереди (порядок не важен) данные и работают с ними. Но тут возникает несколько нюансов: 1) Если нет возможности параллельного чтения с жесткого диска, то те потоки, которые должны параллельно в очередь писать, будут работать по принципу тонкого горлышка, когда только один поток может производить основную работу (то есть прочитать из файла), конечно он может например после этого начать парсить текст, создать какой-нибудь объект и закинуть его в очередь (+- выйгрыш). Какое решение у такого рода проблемы может быть? Стоит ли тогда вообще сделать всего один читающий файлы и записывающий что-то в очередь поток? 2) А может стоит всё сделать очевиднее, пускай каждый поток и читает из файла, и парсит, и выполняет операции. Не будет никакой потокобезопасной очереди и никаких особых ограничений? Такое решение выглядит хоть и некрасиво, но проше. Только непонятно, будет ли оно оптимальным? 3) К вопросу из 1 нюанса, а можно ли с помощью C++ определить, есть ли возможность параллельного чтения с диска и получив ответ от системы, как-то подстраиваться под это. (например выполнять как я придумал выше в случае если можно, а в противном делать, используя 1 поток на чтение). Хотелось бы разбираться в best practice когда нужна параллельная обработка и множество данных лежит на диске, понимать что и как нужно использовать. Заранее благодарю! 0

@HamsterGamer 40 / 29 / 11 Регистрация: 21.06.2019 Сообщений: 201
	19.05.2021, 12:50 [ТС]
	nmcf, ну да, я же и не спорю, я просто не могу понять что тут параллелить. Много файлов с какими-то командами, быстрое исполнение этих команд. При чем чтение с диска в момент именно копирования с памяти диска в память оперативки - однопоточное, поэтому конечно непонятно какой выигрыш я получу если будет много потоков читателей (мб конечно если они прочитают файл и пойдут его обрабатывать (распарсят, выполнят операцию и снова пойдут читать какой-нибудь файл), то выигрыш и будет) Добавлено через 1 час 59 минут Ну неужели нет каких-то очевидных правил при такой проблеме с файловой системой? Или какого-нибудь способа узнать можно ли параллельно читать с диска? :c 0

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	19.05.2021, 13:38
	Чем тебе вариант 2 не нравится? 0

@HamsterGamer 40 / 29 / 11 Регистрация: 21.06.2019 Сообщений: 201
	19.05.2021, 14:12 [ТС]
	nmcf, ну потому что я не уверен, что эти потоки будут оптимальнее работать чем в 1-м случае. Потому что возникает вопрос, если все потоки будут пытаться дергать один диск, будет ли этот диск занят для одного потока пока тот не закончит читать файл или же из-за процессорных прерываний он будет менять потоки, при этом запоминая где текущий поток остановился и на какой строке, тем самым диск будет "крутиться" туда сюда в зависимости от того какой файл открывает текущий поток, который в данный квант времени выбрал шкедулер!? Ну как по мне, в таком случае чтение будет медленнее и затратнее, но параллелить нужно (таково задание), однако мне неочевидно как это распараллелить эффективно, наверное стоит попробовать всё и посмотреть бенчмарки, сравнить. Возможно в C++ есть способ определить RAID массив тут или чтение из какого-то облака (то есть то, что обеспечит параллельность физическую) или же это диск с возможностью лишь однопоточного чтения. Тогда вероятнее способ когда один поток читает, а остальные слушают - лучше, а если же всё-таки RAID-массив, то уже 2) или 1) пункты. Хотя 1-й мне кажется самым эталонным и поэтому хочется его попробовать в первую очередь протестировать. 0

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	19.05.2021, 17:35
	Там будет всякое кеширование ниже твоей программы. Если так интересно, сделай пробный вариант и посмотри. 0

@HamsterGamer 40 / 29 / 11 Регистрация: 21.06.2019 Сообщений: 201
	23.05.2021, 04:52 [ТС]
	Написал я наконец ту структуру, которую задумывал изначально, чтобы 4 потока читали из файлов и клали в очередь команды, а другие 4 потока брали команды из очереди и выполняли их. И протестировал этот способ со способом, когда есть лишь 1 читатель и когда каждый поток и читает и пишет. Результаты ниже (на 1000 файлов в директории). Почему CPU время для некоторых параллельных бенчей он вывел как 0 я хз. Compute1 - 4 читают из файла 4 выполняют операции Compute2 - 1 читает из файла 7 выполняют операции Compute3 - 8 и читают из файла и выполняют операции Вообще, думаю, 2 вариант может быть отличным, если операции реально долгие. Что-то такое я использовал когда писал приложение по поиску слов, в которых есть введенное пользователем слово. (брал по несколько десятков слов в ОЗУ под каждый из потоков и они уже искали там подходящие слова, вроде вышло быстро) Думаю стоит потестить только с чтением из файла, и мб завтра этим займусь. Миниатюры 0

@HamsterGamer 40 / 29 / 11 Регистрация: 21.06.2019 Сообщений: 201
	23.05.2021, 14:22 [ТС]
	Я ошибся в написании решения, когда 8 потоков и читает и пишет. У меня каждый из потоков в итоге обрабатывал все файлы, а вот уже с исправленным решением вывод по времени, и это всё выглядит, конечно, разрушающе по сравнению с моей теорией (писал потокобезопасную очередь с достаточно сложной реализацией напрасно :c ). Миниатюры 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 9005 / 4706 / 630 Регистрация: 04.12.2011 Сообщений: 14,003 Записей в блоге: 16
	23.05.2021, 17:43
	HamsterGamer, случай когда файлы размещены на разных дисках заслуживает отдельного анализа) 0