Форумы MixGalaxy.ru

SD » 15 дек 2008, 22:00

Панику отставить!

**ARkaine** » 15 дек 2008, 22:33

Аткрыл Омерику?

Фруктовая архитектура - по-определению гавно, это очевидно даже тем, кто его ниразу не пользовал. :lol:

SD » 15 дек 2008, 22:39

Отличный комментарий!

**=DRiNK=** » 15 дек 2008, 22:58

зета грузиццо через враппер, о котором в хелпе клянутся, что он труъ многотредовый модуль, а выходить - жёпь? :?

**ARkaine** » 15 дек 2008, 23:01

SD, спасибо. Я рад, что ты заценил.

Если серьезно, то как-то на форуме Петеленых прочёл примерно такую фразу:
Фрукт, как секвенсор, не рассчитанный на работу с железным оборудованием (software only), даже не обладает функцией фриз трека. Абсурд.

И я с этим согласен. :invent:

SD » 15 дек 2008, 23:10

=DRiNK= писал(а):зета грузиццо через враппер, о котором в хелпе клянутся, что он труъ многотредовый модуль, а выходить - жёпь? :?

Да нет, наоборот, тупо несколько зет как раз на 4 ядра разорвутся равномерно. А вот эффекты как-то не очень.

**TContinental** » 15 дек 2008, 23:54

ты хотел сказать

SD писал(а):трансцонтинентятины

SD » 16 дек 2008, 00:12

**=DRiNK=** » 16 дек 2008, 00:18

харэ срацца, Вы же в мундирах !

SD » 07 фев 2009, 08:01

Панику отставить!
Тестовый проект в моём первом сообщении был сделан на одних цитрусах.

А вот как выглядит загрузка цомпутера проектом из 3x surge, 2x ultra analog, 3x synth1, 1x ms20, 1x Zynadsubfx, 7x waves ssl channel stereo, 1x oxford reverb, ну и остального по мелочи.

Раскидано по ядрам неидеально, но, всё же, выгода от трёх и более ядер есть.

Одно но: если использовать вст-генераторы. Если основная загрузка проекта от обработок, то тут уже не так всё просто: миксер, видимо, к одному потоку привязан, но некоторые обработки добавляют свои потоки. Но не все.

**Ar Klaf** » 07 фев 2009, 12:12

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

Раньше все плуги и проги писались под одно ядро и их распоточивание в расчёте на то, что кто-то будет юзать многопроцессорную систему для написания музыки вместо железа, было неоправданным. Несмотря на то, что некоторые VST делались многопоточными, в итоге это лишь отнимало процессорное время на одноядерниках. А у Фруктов движок сами знаете какой. Его ещё предстоит переписать полностью, прежде, чем он станет очень хорошим в вашем понимании.

**ak630** » 07 фев 2009, 13:34

SD писал(а):Раскидано по ядрам неидеально, но, всё же, выгода от трёх и более ядер есть.

Идеально никогда не будет... То что на картинке это на 5 с плюсом разделение...
Я наблюдал за реальными задачами которые писались спецом под многопроцессорность типа оракла и прочего и каждый день имею счастье лицезреть - все равно очень криво процессоры нагружает.

Это связано видать с тем что сама платформа IBM PC не очень расчитана на многопроцессорность... точнее она там через "нашлепки" организована
Так как вопрос совместимости стоит.

SD » 07 фев 2009, 15:30

Идеально никогда не будет... То что на картинке это на 5 с плюсом разделение...

Ну, эта же картина на три ядра была бы ещё красявше. А если загружать одинаковыми синтезаторами в большом количестве, получится полностью равномерная загрузка.

Я наблюдал за реальными задачами которые писались спецом под многопроцессорность типа оракла и прочего и каждый день имею счастье лицезреть - все равно очень криво процессоры нагружает.

Смотря какие задачи и какие процессоры. Если с гипертредингом, например, то виртуальные ядра вряд ли получится загрузить по полной. Да и от шин тоже зависит. Может, упёрся ваш оракуль в пропускную способность памяти или шины обмена процессоров, вот и не распараллеливается. Вообще, масштабируемость - непростая вещь.

Это связано видать с тем что сама платформа IBM PC не очень расчитана на многопроцессорность... точнее она там через "нашлепки" организована
Так как вопрос совместимости стоит.

Нууу, очень смелое утверждение.

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

Скорее, даже добавляет задержку, что более критично. Но это уже зависит от разработчиков, говорят, в цубасе миксер распараллелен.

**ak630** » 07 фев 2009, 19:10

SD писал(а):
Это связано видать с тем что сама платформа IBM PC не очень расчитана на многопроцессорность... точнее она там через "нашлепки" организована
Так как вопрос совместимости стоит.
Нууу, очень смелое утверждение.

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

**ak630** » 07 фев 2009, 19:19

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

Что касается бытовых железок пока - это все в достаточной степени "эмуляция" таких процессов.
Самый большой плюс в 2-4-х ядерности что не тратится время на загрузку нового конента задачи по сравнению с однопроцессорностью.. Это ощутимо если скажем выполняются 2 или 4 процесса довольно долгое время - там да набегает....
Если процессов очень много и они короткие, то выигрыш начинает нивелироваться...

ну впрочем это для другого форума тема...

SD » 07 фев 2009, 19:54

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

Дак ну это же сейчас в части пц-архитектур(у амд к8 и старше и нехалем) так и реализуется.

Что касается бытовых железок пока - это все в достаточной степени "эмуляция" таких процессов.

А видеокарта - это не бытовая железка?

**ak630** » 07 фев 2009, 20:02

[quote="SD"]Дак ну это же сейчас в части пц-архитектур(у амд к8 и старше и нехалем) так и реализуется.
[quote]

Ну да. Всего-то лет 15 понадобилось чтобы прийти к IBM System 360 70 года выпуска

**ak630** » 07 фев 2009, 20:05

SD писал(а):А видеокарта - это не бытовая железка?

Хороший вопрос. Там как раз-таки вычисления более детерминированы, заранее известны - поэтому проще...
Кстати я писал уже здесь что Nvidia опубликовало API, с помощью которого процессор видяхи можно использовать для произвольных вычислений. А процессоры нынче там весьма нехилые....

SD » 07 фев 2009, 20:12

Это я писал, лол :lol:

Форумы MixGalaxy.ru

Многопоточность фрутилупса. Точки над и.

Многопоточность фрутилупса. Точки над и.

Кто сейчас на конференции