Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.147.66.178] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
И конечно же сам Мейерс этим вопросом не задавался |
Сообщ.
#17
,
|
|
|
Цитата OpenGL @ И конечно же сам Мейерс этим вопросом не задавался А тут задавайся, не задавайся, а на уровне только языка всех возможностей аппаратуры и операционной системы - не поднять. Мейерс же рассуждает как реализовать ту или иную фичу в рамках Стандарта С++. |
Сообщ.
#18
,
|
|
|
Цитата Wound @ В одном потоке запускается хрень(FileScanner), которая ищет все файлы в директории и поддиректориях по указанным расширениям, и пихается путь к найденному файлу в очередь, а потом запускаются несколько потоков, которые должны эту самую очередь выгребать и обновлять каждый файл, в зависимости от типа файла. Потенциально опасная и неприятная ситуация. На первый взгляд она не заметна, но она есть. --- В такой архитектуре заложен вероятностный исход с точки зрения производительности. А именно: 1. Предположим, 1-й поток начал обрабатывать первый файл. Головки жёсткого диска поехали в направлении расположения файла 1 на диске. 2. Прошёл системный квант времени. 1-й файл был достигнут, началась работа но она не была закончена. 3. 2-й поток получил время для обработки 2-го файла. Головки жёсткого диска поехали в направлении расположения файла 2 на диске. И вот тут, по не счастливому стечению обстоятельств, файл оказался "очень далеко" с точки зрения позиционировании головок. А также с точки зрения фрагментаци 2-го файла. 4. За предоставленный квант времени 2-й поток не успел обработать 2-й файл и головки поехали в направлении 1-го файла. --- В результате огромное время будет тратиться на электро-механические операции и производительность может сильно снизиться. Особенно, если добавить ещё n потоков и n обрабатываемых файлов. |
Сообщ.
#19
,
|
|
|
Цитата ЫукпШ @ В такой архитектуре заложен вероятностный исход с точки зрения производительности. А именно: А как в винде все это работает? Ну типа если открыть диспетчер задач, то можно увидеть хренову тучу запущенных программ. Из них добрая половина так или иначе работает с файлами, одна программа пишет лог в одну директорию, вторая программа пишет лог вообще на другой диск, третья в кэш данные скидывает, четвертая из кэша что то загружает. Но я подумаю над этой ситуацией. У меня загрузка файла в одном месте, т.е. файл грузиться целиком в память, потом он закрывается, и сним происходит дальнейшая работа, потом, когда нужно - он сохраняется. Очередь у меня хранит пути к файлам, но в принципе не составит особого труда запихнуть туда структуру, которая будет загружать файл и отдавать содержимое парсерам. Добавлено Ну и вроде как std::async может решить эту задачу. Так как у библиотеки есть вся картина происходящего. |
Сообщ.
#20
,
|
|
|
Цитата Wound @ А как в винде все это работает? ЫукпШ не учитывает небольшого нюанса - различные ухищрения как в плане аппаратной оптимизации работы отдельного HDD, так и при объединении носителей в массивы. Чтение-запись работают не так примитивно. И, тем не менее, ЫукпШ кагбэ намекает: "Киля, выдели в своей проге отдельный поток 'читатель-писатель' на каждый отдельный носитель. И загружай его заданиями от потоков 'считателей'. Ибо носитель не может выполнять несколько операций одновременно" Чисто ИМХО |
Сообщ.
#21
,
|
|
|
Цитата Wound @ А как в винде все это работает? А наудачу. Принципиально никак не лечится. Это потенциальная проблема для любой много-потоковой системы. Всё проявится наиболее сильно в слабых, низко-производительных случаях. Скрытый текст Однажды я такое видел - неудачно запущенный набор программ работал 3 часа. На системном уровне лечится просто применением всё более совершенных аппаратных средств. Твердотельные диски - это шаг вперёд. Формально, конечно, ты прав. Система предоставляет нам набор услуг, мы ими пользуемся. Как она решает проблемы внутри не наше дело. Но всё-так лучше учитывать несовершенство аппаратных и программных средств. Если есть уязвимое место, зачем непременно туда колоть острым ? Например - поручи работать с файлами одному потоку и всё. Где и как ты получаешь выгоду от много-потоковой обработки файлов ? Обязателен ли этот вариант или можно обойтись одним потоком ? Добавлено Цитата JoeUser @ Чтение-запись работают не так примитивно. Когда-то я тоже так думал. Что-то не так у Виндус с кэшем. Вот только недавно чистил старые коды для Виндус - раньше я думал, "что там кэш есть" и всё такое.. Понадеялся, так сказать. Не знаю, что там имеется, но после встраивания "кэша" в тело программы (как это я обычно делал в DOS) скорость работы увеличилась на 2 порядка (в сто раз). |
Сообщ.
#22
,
|
|
|
С управлением памятью у винды беда. Часто замечал, что винда для ускорения обмена с диском отдаёт почти всю память под кеш, для чего выгружает часть программ в своп, в результате интенсивность обращений к диску увеличивается и она дополнительно освобождает память под кеш, выгружая программы в своп, и так, пока система колом не встанет, поскольку у всех активных программ ошибки страниц так и бегут. При том, что сами программы к диску не обращаются, и памяти занимают много меньше наличной физической.
Добавлено И, похоже, не лучше обстоит дело с приоритетами задач. Однажды так случилось, что на рабочей станции по удалёнке запустили две копии приложения. Обеим копиям требовалось под 90% наличной памяти, причём они бегали по всей памяти довольно случайно. Я решил притормозить свою копию, чтобы вторая выполнилась, пока я на работе, а потом моя работала. Залез в диспетчер задач и поставил своей низший приоритет (Idle-режим). И вдруг обнаружил, что моя задача стала утилизировать около 80% процессорного времени (это имея пониженный приоритет-то). Пришлось её вообще приостановить. Постепенно моя задача вытеснилась в своп, та задача быстро просчиталас и завершиласьь. Я свою возобновил и пошёл домой. В результате обе задачи утром оказались просчитаны. А так боюсь пришлось бы до обеда ждать, и то не факт, что завершились бы. |
Сообщ.
#23
,
|
|
|
amk, это все "кофейная гуща".
Основной вопрос, надеюсь, без возражений? ... "Как загрузить по максимуму самое медленное устройство?" Ога??? SergI, все расписал правильно, имхо. |
Сообщ.
#24
,
|
|
|
Цитата JoeUser @ Как, как? Открыть одновременно несколько десятков файлов и дёргать из них в случайном порядке по нескольку байт. Час-другой глядишь, оно и рассыпется. Или хотя бы сервоусилители привода головок сгорят к чертям. "Как загрузить по максимуму самое медленное устройство?" Ога??? |
Сообщ.
#25
,
|
|
|
Скрытый текст amk, злой ты! Не любишь механику |
Сообщ.
#26
,
|
|
|
JoeUser, я стараюсь больше одного файла за раз не открывать. Винда и без меня постарается диск убить досрочно.
|
Сообщ.
#27
,
|
|
|
Цитата amk @ JoeUser, я стараюсь больше одного файла за раз не открывать. Ну "открыть" - это еще не значит выполнить I/O. А вот многопоточная работа с файлами - тут действительно вопросы. |