я тоже это заметил, думаю вот те раз))) с чего бы? Походу поэтому для pyramix лет 10 назад в v7 рекомендовали не включать Hyper-Threading, чтобы избежать проблем с производительностью или стабильностью. Сейчас кстати может и иначе)
Собираем PC топовой конфигурации. (18 онлайн)
- Автор темы fakeitback
- Дата начала
Мы видимо о разных проблемах говорим. Я говорил о недогрузке ДАВ, при этом проц на уровне 30-40-% загрузки. Дав же считает, что загружно 100% и заикается. Распараллеливание тут не при чём, это уже вы сами выдумали. Мой метод лечения заключается в том, что описано выше, по пунктам. Решение работало у всех, у кого была подобная проблема. У меня же лично эта проблема была на всех камнях, и на amd и на intel. Ядра не загружены, а дав уже заикается. Возможно актуально только для s1, особым перфомансом они не славятся.Вы описали то что себе вообразили , но воображение и реальность - разные вещи
Единственный способ разгрузить DAW , для конкретного плагина
(в локальных условиях)- , это если его автор "вдруг " , решит его распаралеллить ) и то , если только в том случае если позволяет задача плагина .. , например распараллелить мастер лимитер - невозможно )
потому что он обсчитывает все что находится до него , а все это работает на одном ядре )
А вот вст синт , например Diva , - можно
в нелокальных условиях , отдельная машина , с vienna ,asio grid)
все эти ограничения идут от самой архитектуры фон неймана )
Вот в дивных процессорах будущего , когда у нас будет отдельный контроллер IO и память отдельная ) на каждое ядро ) там будет все сказочно
предположим у тебя сервер с 18 процессорами
как помнишь, вводом и выводом данных занимается ядро операционной системы
так вот, ядро операционной системы дает команду процессору 1 вычитать хулиард байтов из какого-то устройства ввода-вывода
а результат отдать в пользовательское пространство в ОЗУ, чтобы 17 процессоров могли эти данные преобразовать
упрощенно, градусник ASIO - это скорость чтения-записи хулиарда байтов
если он красный, а 17 процессоров зеленые, значит, скорость появления данных у 17 процессоров ниже их возможностей процессинга
DAW и OS отслеживают разные метрики, первая - скорость подачи холодной воды, вторая - количество горячей воды
ферштейн?
А к чему собственно этот спор? Типа от добра не ищут добра? Я подсказал действующий способ, и уже второй человек что то хочет мне доказать. Причём каждый увидел что-то своё, как я понял либо вообще не имея подобной проблемы, либо не проверив решение - то есть присоединяя какую то голую теорию, чего-то там, из рубрики «сам программст». В jbrige всё написано, как и для кого этот режим, и по какому принципу он работает. Фу такими быть.предположим у тебя сервер с 18 процессорами
как помнишь, вводом и выводом данных занимается ядро операционной системы
так вот, ядро операционной системы дает команду процессору 1 вычитать хулиард байтов из какого-то устройства ввода-вывода
а результат отдать в пользовательское пространство в ОЗУ, чтобы 17 процессоров могли эти данные преобразовать
упрощенно, градусник ASIO - это скорость чтения-записи хулиарда байтов
если он красный, а 17 процессоров зеленые, значит, скорость появления данных у 17 процессоров ниже их возможностей процессинга
DAW и OS отслеживают разные метрики, первая - скорость подачи холодной воды, вторая - количество горячей воды
ферштейн?
А слушать опытных дядек - это пойти вырубить плаги, потому что по их мнению это работать не может?))) это уже дедовщиной попахивает))ты - глупец, не слушаешь умных опытных дядек
фи таким быть
@Okchuvachok, проблемы однопоточной и многопоточной производительности DAW на этом форуме изучаются много лет. Споры, сравнения... Jbridge много лет как мёртв, но есть две огромных темы про софтовые "костыли" - Vienna Ensemble Pro и Audiogridder. В каких случаях помогает, в каких не очень...
Но тут приходит новичок с погонялом гопника с района и начинает, брызжа апломбом, учить жизни всех подряд, изрекая нечто бородатое.
Ну и как к вам будут относиться? Сами-то осознайте...
Но тут приходит новичок с погонялом гопника с района и начинает, брызжа апломбом, учить жизни всех подряд, изрекая нечто бородатое.
Ну и как к вам будут относиться? Сами-то осознайте...
Вам что в лоб, что по лбу ) Вроде всё разъяснили максимально подробно. То что вам daw показывает это не загрузка проца. Перечитайте ещё раз что ли.
Не, правильный вопрос - как мне к этому относиться. И как со стороны выглядит подобное: обсуждение ника - конструктив? Нет. Это попытка оскорбления. Обвинение в том, чего небыло - «учёба жизни». А если человек спорит с реальностью, то есть в обход фактов, приводя мнимые аргументы (причём такой человек не один, а их как минимум несколько) - какой вывод я должен сделать?) Вопрос риторический. В моём представлении профессионал так себя не ведёт.
@Okchuvachok, ну всё, началась демагогия..
Вам Зерокул не поленился и расписал всё до мелочей, несмотря на то, что на форуме это уже сто раз обсуждалось. Но вы видимо всерьёз полагаете, что здесь не знают о существовании джейбриджа и его возможностях ) Лучше б спасибо сказали и призадумались
Вам Зерокул не поленился и расписал всё до мелочей, несмотря на то, что на форуме это уже сто раз обсуждалось. Но вы видимо всерьёз полагаете, что здесь не знают о существовании джейбриджа и его возможностях ) Лучше б спасибо сказали и призадумались
Третьим впишусь. Я уже оставлял в этой теме объяснение, что такое asio-метер - https://rmmedia.ru/threads/55972/page-70#post-2902812
И почему нагрузить проц на 100% на практике невозможно - https://rmmedia.ru/threads/112861/page-143#post-2926813
Отсюда должно быть понятно, что вынос в жбридж никак не может уменьшать нагрузку на asio, ибо нам надо скопировать буфер во внешний обработчик, прожевать там и скопировать обратно. То есть сделать все ровно то же самое плюс копирование данных. Время на обработку буфера от этого никак не может уменьшиться.
Такие приседания могут быть полезны чтобы изолировать падучие плагины - процесс с плагином упал, а хост продолжает жить, так как он в своем процессе. Но трейдофф в увеличивающихся расходах на передачу данных.
Я в свое время для себя понял так - hypertreading позволяет без переключения контекста ядра рассчитать второй поток на том же ядре, пока первый поток ждет чего-нибудь, чаще всего пока подъедут данные из памяти. Если в силу каких-либо причин кеш используется плохо, ядро долго стоит в ожидании и второй поток ускоряет общий расчет. Если данные хорошо укладываются в кеш (к чему в высокопроизводительных вычислениях мы стремимся всегда и везде), то этот второй поток начинает драться с первым за вычислительные блоки ядра и общий расчет становится медленнее.
Тут еще надо понимать что в этой же самой очереди к процу помимо ASIO , стоят все процессы и драйверы операционной системы )
так что какой нить торрент , с раздачей миллиона мелких пакетов ) и с постоянной небольшой но ощутимой нагрузкой на проц - точно так же , может вызывать щелчки asio ) ..или антивирь с проактивным режимом , (постоянно сканирующий какие то файлы)
Или windows search - с индексацией )
и чем меньше буфер - тем выше шансы
так что какой нить торрент , с раздачей миллиона мелких пакетов ) и с постоянной небольшой но ощутимой нагрузкой на проц - точно так же , может вызывать щелчки asio ) ..или антивирь с проактивным режимом , (постоянно сканирующий какие то файлы)
Или windows search - с индексацией )
и чем меньше буфер - тем выше шансы
Последнее редактирование:
HT до сих пор величайший прикол столетия)))
Сколько лет прошло, с его появления - нет идеальной работы HT во всех ОС/daw/плагинах.
А для низкой latency так и подавно рекомендуют его выключать при отладке системы.
Видимо где-то оно всеже работает.
Ниже кстати Pyramix 7.1 Release Notes с четким указанием выключать HT.
Страница 9 (Pyramix V7.1 Known Issues)
«Hyperthreading is supported for MultiCore processors only, since Pyramix V6.1, but Merging
recommends that you disable the Hyperthreading for the moment.»
Zildjian
На самом деле софтовый хак есть , и у меня даж прокатывало так с первыми версиями NDSP ( когда там один плаг с включенным оверсемплингом ) просто грузил на малой задержке одно ядро процессора практически на 70 процентов и асиометр шкалил )
в чем нить типа process hacker или system informer , открывался процесс s1 , и его дочерние процессы , находилась там дллка NDSP (одна из )
и ей вручную повышался приоритет с below normal до high )
и сразу загрузка асиометра падала аж до 25 процентов ...
Но полагаю , это был косяк разработчиков плага , потому что скажем у новой версии того же плага (x) - там уже сразу приоритет дочерний highest )
electrical
Это реально оч стабильная хрень ) вообще неубиваемая ) поэтому на них оч много всяких концертных площадок , вещательных центров , и т д , годами работает )когда мы с Сашей Олейником и Димой разрабатывали ip audio pro , их главный разраб с мной связывался , оч сильно их заинтересовал Димин протокол ) сетевой ) с меганизкими задержками ) ...до 0.3 мс ....
Последнее редактирование:
Рипер в таких случаях вылетает наглухо.
А вот битвиг изолирует процесс с возможностью его перезагрузки.
возможен такой вариант:
есть плаг который распараллеливается на 8 потоков. Он знает об этом и сообщает своему хосту.
Но хост решает ( может в силу какой-то преднастроенной стратегии распределения потоков, или из-за криволапости погромиздов) что хрен тебе а не 8, жри 1. - Все, плаг работает в 8 раз дольше.
Вынос в Jbridge позволяет жрать столько потоков, сколько есть в аппаратной доступности, в результате плаг работает до 8 раз быстрее, и быстрее доставляет результат обратно в хост - и видно более низкий асиометр
Чтобы такого не было - надо переписывать все корневые движки DAW на мультипоточную парадигму. А это фактически дорого и опасно.
А сами движки едут практически в неизменном состоянии со времен однопоточных парадигм с кучей гнилых костылей внутри.
плаги так не умеют вроде как, вернее вст\ау\аах форматы не подразумевают такой функциональности.
Тобишь хочешь паралелиться - мучайся сам внутри своего плага
вроде в clap такое собирались завезти но не следил за их движениями особо.
слабо верю что массово будут в корень переписывать плагины под немейнстримовый формат.
Сама по себе поддержка clap никакого особенного выигрыша не даст же, надо код считай заново написать чтоб эффективно плагин раскидать на паралельные вычисления, если это вообще возможно для данного конкретного плагина
Нас спасёт только более тонкий техпроцесс, чтобы грядущие процессоры умели в 7, 8 и более гигагерц! Ну и руки программистов тоже должны бережнее относиться к нашим процам, а не как вот это всё, когда одна инстанция сжирает 10 процентов буфера..
Не спасет, точнее недостижим
) на текущем кремнии ..... (только под жидким азотом ))) ....А это еще более фантастичные мечты )
А распараллеливание каждого плагина это вообще фантастика. Люди скорее научатся летать через всю Вселенную, используя кротовьи норы, чем распараллеливать какой-нить спецкрафт с оверсемплингом, висящий на посыле, который идёт на другой посыл ещё..
Dmitry Stepin
Верно, поэтому будем продолжать куковать ))
погромизды вон с ue5 справиться не могут , а там в играх бюджеты по полмиллиарда ) щас )
что там говорить о каком то музсофте (где бюджеты и заработки откровенно говоря унылые ) даже по меркам IT , единицы реально умеют кодить нормально , типа Реймунда Дратвы .......
или парней из Блюкэт ...
вообще объективно и мы конечно зажрались ) раньше вон сраный гиперсоник фризили , с тремя дорогами , потому что не тянул древний пень ))) и ризон все юзали , потому что он меганежручий был ....
А щас в проекте плагины с синтами хрен посчитаешь , устанешь )) а хочется ж еще .......больше и больше )
Последнее редактирование:
Помню испытал дикий восторг, когда ризон по ревайеру подцепился к пятому кубу.)) Даже и фризить не надо было