И тут Остапа понесло....Это ж сколько добра можно на них положить!))
А не проще ли просто взять более объемные ссдшки ?))))
Я предложил ДУБОВОЕ решение, которое тем ни менее повысило бы производительность на многомерных системах точно, даже без виртуализации процессов.Нипонел. Допустим, мы пытаемся посчитать каждый плагин в своем потоке. Пока одно ядро считает первый плагин, остальные плюют в потолок, им пока нечего считать, так как выхода первого плагина нет.
Этим должна ось заниматься, а не DAW и вообще именно так она и должна делать. Попробуйте нагрузить максимально один поток и посмотреть за тем, какие ядра будут загружены. Ось будет гонять нагрузку между разными ядрами, на первый взгляд хаотично.разбрасывать расчет каждого последующего плагина на менее занятые ядра, а не тупо считать всю цепочку на одном, когда все прочие стоят
С помощью виртуализации ,АБСОЛЮТНО любую задачу можно распараллелить на все ядра
Нужно будет глянуть, спасибо!Этим должна ось заниматься, а не DAW и вообще именно так она и должна делать. Попробуйте нагрузить максимально один поток и посмотреть за тем, какие ядра будут загружены. Ось будет гонять нагрузку между разными ядрами, на первый взгляд хаотично.
Это @Dmitry Stepin обсуждает , а у меня несколько иные приоритеты и задачи, мне бы, в том же РиалТайме, с включённым рекармом для Лайва обработать 24 трека с большим кол-вом плагинов на каждом и при этом по максимуму загрузить 64 ядра/ 128 потоков нового Трейдрипера 3990Единственный вариант, когда это можно сделать, это запилить полупараллельный конвеер. Когда первый плаг берет первый чанк данных, мелет его, отдает второму плагу, а сам в этот момент берет второй чанк и начинает молоть его. Но в этом случае распараллеливание получается по горизонтали, а не по вертикали, а мы обсуждаем уменьшение нагрузки чтобы напихать побольше див в риалтайм.
Так уже есть 4 tb nvme от интелов )
matisse поддерживает pci 4.0 , 24 4.0 шины , это 48 3.0 )
дешманские ссд от адаты )?))
Если каждый плаг сам по себе умеет грузить только один поток, то я не вижу, как это сделать. Предрасчет, который я описал выше, поможет размазать нагрузку по свободным ядрам (если допустить, что DAW так умеет), но увеличит задержку кратно количеству предрассчитываемых чанков, что в вашей риалтайм ситуации тоже неприемлемо. В идеальной ситуации, когда эти 24 канала идут напрямую в мастер без всяких промежуточных шин, получится занять 24 потока.мне бы, в том же РиалТайме, с включённым рекармом для Лайва обработать 24 трека с большим кол-вом плагинов на каждом и при этом по максимуму загрузить 64 ядра/ 128 потоков нового Трейдрипера 3990
Я же написал как, а вы ответили, что именно так и должна, по идее работать сама Винда. Проверю.Если каждый плаг сам по себе умеет грузить только один поток, то я не вижу, как это сделать.
Об том и толкую.Обработка идет последовательно, сам хост передает последовательность байт стоящему следующим в цепочке плагину. Если даже будет поддержка плагина на нескольких ядрах - это синхронизируется с помощью семафоров и мутексов на уровне того же хоста.
Ну я погуглил тут, это чота ваще мимо. Начнем с того, что по запросу "parallelism by virtualization" в кавычках гугл не знает вообще ничего. Без кавычек статьи ищутся и сводятся к тому, что "давайте напихаем виртуальных машин на одну железку, тогда железка сможет выполнять больше задач от разных юзеров", что вроде бы как отчасти верно (на гетерогенных задачах, иначе просто запускаем многопоточный сервер по потоку на клиента и не парим мозг. то есть да, если мы имеем облачный сервер, на котором юзера планируют делать произвольные задачи отдельно друг от друга), но ваще не решает стоящую задачу распараллеливания расчета ЗАВИСИМЫХ данных. Потому что, повторяю, можно хоть увиртуализироваться - если расчет предыдущего шага зависит от следующего, параллельно посчитать не получится ни-че-го.А технология старая , parralelism by virtualization , погуглить ...
Все облачные вычисления так работают
Вы говорите о некорректности, однако на простой вопрос, подразумевающий конкретику о вашем сетапе - вы "напускаете туман" и "льёте воду", что совсем некорректно в профессиональной среде, потому и выглядят ваши заявления как чистейшая, мягко выражаясь, мистификация..у меня система, у которой 32 аналоговых входа и 500 аналоговых выходов, (поэтому и х. з. где-то выше), и это сильно не асахи 4490 или 93 по 300 рублей за штуку в устройствах по 150K,
Вот видимо только тогда, и только если у Интела к тому времени не будет 7 ггц и выше, и будет смысл перейти на АМД.И там у амд уже будет 5 ггц и выше ....
Золотые слова!Да уж... Отсутствие конкуренции расслабляет. Интел совсем расслабилась, но АМД опять подкрался незаметно. Поглядим через год, выигрывают пользователи)
это потолок для текущей технологии, все может измениться.вообще 5.2 потолок