На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
Страницы: (2) 1 [2]  все  ( Перейти к последнему сообщению )  
> Помогите подобрать правильный шаблон проектирования, , который позволяет порождать много инстансов одного класса.
    Цитата JoeUser @
    Вот и я говорю - написано одно, а так ли это на самом деле?

    И конечно же сам Мейерс этим вопросом не задавался :crazy:
      Цитата OpenGL @
      И конечно же сам Мейерс этим вопросом не задавался

      А тут задавайся, не задавайся, а на уровне только языка всех возможностей аппаратуры и операционной системы - не поднять.
      Мейерс же рассуждает как реализовать ту или иную фичу в рамках Стандарта С++.
        Цитата Wound @
        В одном потоке запускается хрень(FileScanner), которая ищет все файлы в директории и поддиректориях по указанным расширениям, и пихается путь к найденному файлу в очередь, а потом запускаются несколько потоков, которые должны эту самую очередь выгребать и обновлять каждый файл, в зависимости от типа файла.

        Потенциально опасная и неприятная ситуация.
        На первый взгляд она не заметна, но она есть.
        ---
        В такой архитектуре заложен вероятностный исход с точки зрения
        производительности. А именно:
        1. Предположим, 1-й поток начал обрабатывать первый файл.
        Головки жёсткого диска поехали в направлении расположения файла 1 на диске.
        2. Прошёл системный квант времени. 1-й файл был достигнут, началась работа
        но она не была закончена.
        3. 2-й поток получил время для обработки 2-го файла.
        Головки жёсткого диска поехали в направлении расположения файла 2 на диске.
        И вот тут, по не счастливому стечению обстоятельств, файл оказался
        "очень далеко" с точки зрения позиционировании головок. А также
        с точки зрения фрагментаци 2-го файла.
        4. За предоставленный квант времени 2-й поток не успел обработать
        2-й файл и головки поехали в направлении 1-го файла.
        ---
        В результате огромное время будет тратиться на электро-механические операции
        и производительность может сильно снизиться. Особенно, если добавить ещё
        n потоков и n обрабатываемых файлов.
          Цитата ЫукпШ @
          В такой архитектуре заложен вероятностный исход с точки зрения
          производительности. А именно:

          А как в винде все это работает? :huh:
          Ну типа если открыть диспетчер задач, то можно увидеть хренову тучу запущенных программ. Из них добрая половина так или иначе работает с файлами, одна программа пишет лог в одну директорию, вторая программа пишет лог вообще на другой диск, третья в кэш данные скидывает, четвертая из кэша что то загружает.
          Но я подумаю над этой ситуацией. У меня загрузка файла в одном месте, т.е. файл грузиться целиком в память, потом он закрывается, и сним происходит дальнейшая работа, потом, когда нужно - он сохраняется.
          Очередь у меня хранит пути к файлам, но в принципе не составит особого труда запихнуть туда структуру, которая будет загружать файл и отдавать содержимое парсерам.

          Добавлено
          Ну и вроде как std::async может решить эту задачу. Так как у библиотеки есть вся картина происходящего.
          Сообщение отредактировано: Wound -
            Цитата Wound @
            А как в винде все это работает? :huh:

            ЫукпШ не учитывает небольшого нюанса - различные ухищрения как в плане аппаратной оптимизации работы отдельного HDD, так и при объединении носителей в массивы. Чтение-запись работают не так примитивно.

            И, тем не менее, ЫукпШ кагбэ намекает: "Киля, выдели в своей проге отдельный поток 'читатель-писатель' на каждый отдельный носитель. И загружай его заданиями от потоков 'считателей'. Ибо носитель не может выполнять несколько операций одновременно" :lol:

            Чисто ИМХО :popcorn:
              Цитата Wound @
              А как в винде все это работает? :huh:

              А наудачу. Принципиально никак не лечится.
              Это потенциальная проблема для любой много-потоковой системы.
              Всё проявится наиболее сильно в слабых, низко-производительных случаях.
              Скрытый текст

              Однажды я такое видел - неудачно запущенный набор программ работал 3 часа.
              На системном уровне лечится просто применением всё более совершенных аппаратных средств.
              Твердотельные диски - это шаг вперёд.

              Формально, конечно, ты прав. Система предоставляет нам набор услуг, мы ими пользуемся.
              Как она решает проблемы внутри не наше дело.
              Но всё-так лучше учитывать несовершенство аппаратных и программных средств.
              Если есть уязвимое место, зачем непременно туда колоть острым ?
              Например - поручи работать с файлами одному потоку и всё.
              Где и как ты получаешь выгоду от много-потоковой обработки файлов ?
              Обязателен ли этот вариант или можно обойтись одним потоком ?

              Добавлено
              Цитата JoeUser @
              Чтение-запись работают не так примитивно.

              Когда-то я тоже так думал.
              Что-то не так у Виндус с кэшем.
              Вот только недавно чистил старые коды для Виндус - раньше я думал, "что там кэш есть" и всё такое..
              Понадеялся, так сказать.
              Не знаю, что там имеется, но после встраивания "кэша" в тело программы (как это я обычно делал в DOS)
              скорость работы увеличилась на 2 порядка (в сто раз).
              Сообщение отредактировано: ЫукпШ -
                С управлением памятью у винды беда. Часто замечал, что винда для ускорения обмена с диском отдаёт почти всю память под кеш, для чего выгружает часть программ в своп, в результате интенсивность обращений к диску увеличивается и она дополнительно освобождает память под кеш, выгружая программы в своп, и так, пока система колом не встанет, поскольку у всех активных программ ошибки страниц так и бегут. При том, что сами программы к диску не обращаются, и памяти занимают много меньше наличной физической.

                Добавлено
                И, похоже, не лучше обстоит дело с приоритетами задач.

                Однажды так случилось, что на рабочей станции по удалёнке запустили две копии приложения. Обеим копиям требовалось под 90% наличной памяти, причём они бегали по всей памяти довольно случайно. Я решил притормозить свою копию, чтобы вторая выполнилась, пока я на работе, а потом моя работала. Залез в диспетчер задач и поставил своей низший приоритет (Idle-режим). И вдруг обнаружил, что моя задача стала утилизировать около 80% процессорного времени (это имея пониженный приоритет-то). Пришлось её вообще приостановить. Постепенно моя задача вытеснилась в своп, та задача быстро просчиталас и завершиласьь. Я свою возобновил и пошёл домой. В результате обе задачи утром оказались просчитаны. А так боюсь пришлось бы до обеда ждать, и то не факт, что завершились бы.
                  amk, это все "кофейная гуща".
                  Основной вопрос, надеюсь, без возражений? ... "Как загрузить по максимуму самое медленное устройство?" Ога???
                  SergI, все расписал правильно, имхо.
                    Цитата JoeUser @
                    "Как загрузить по максимуму самое медленное устройство?" Ога???
                    Как, как? Открыть одновременно несколько десятков файлов и дёргать из них в случайном порядке по нескольку байт. Час-другой глядишь, оно и рассыпется. Или хотя бы сервоусилители привода головок сгорят к чертям.
                      Скрытый текст
                      amk, злой ты! Не любишь механику :scratch:
                        JoeUser, я стараюсь больше одного файла за раз не открывать. Винда и без меня постарается диск убить досрочно.
                          Цитата amk @
                          JoeUser, я стараюсь больше одного файла за раз не открывать.

                          Ну "открыть" - это еще не значит выполнить I/O.
                          А вот многопоточная работа с файлами - тут действительно вопросы.
                          0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                          0 пользователей:


                          Рейтинг@Mail.ru
                          [ Script execution time: 0,0388 ]   [ 17 queries used ]   [ Generated: 28.03.24, 11:12 GMT ]