Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Не сгущайте красок. При любой многозадачности мьютексы прекрасно работают до определенного уровня загрузки, и лишь после нее начинается лавинообразный рост коллизий.
В кооперативной однопроцессорной (одноядреной) многозадачности ожидающий на мьютексе поток освободит ресурс, что позволит с большой вероятностью отдать (рано или поздно) процессор обратно потоку, который захватил мьютекс. А при правильном написании кода, т.е. если не будет ожидающих сигналов/хендлов операций в промежутках между захватом и отпусканием, то поток, захвативший мьютекс, никогда не будет неожиданно вытеснен. С коллизиями столкнулись именно при насильном вытеснении потоков и именно в защищённом режиме, бо в плоском режиме переключение потоков было достаточно дешевым.
ЕМ>Это ж, по сути, классическая система массового обслуживания
Которые, по-классике, пишутся не на мьютексах, а на семафорах и атомарных (lock-free в мультипроцессорной конфигурации) операциях.
Мьютексы — это дешевый механизм обеспечения сериализации доступа к ресурсу для случая, когда "облом подумать". ))
V>>переключение потока дорогое еще для потока, который вытесняют V>>Который поток ставят — его дорого ставить ЕМ>Все эти оценки "дорого-дешево" имеют смысл только в отношении удельного веса в общей совокупности затрат.
Разумеется.
Стоимости промаха TLB в инете есть — можно оценивать.
Но лучше всего гонять конкретные сценарии в тестах в различных техниках исполнения, конечно.
ЕМ>Если все остальное уже оптимизировано, и на первое место вылезли затраты на переключение — значит, их действительно пора оптимизировать.
Угу. Например, мы обслуживаем скоростную диспетчеризацию из сотен/тысяч источников.
Тут переключения контекстов могут отожрать до 95% всех тиков, если каждый источник обрабатывается отдельным потоком ОС.
ЕМ>Но, если мы сейчас прикинем вес затрат на переключение на фоне веса затрат, создаваемых типичным современным софтом, нам потребуется неслабый микроскоп, чтоб их разглядеть.
Если мы говорим об эффективности и реалтайме, то обычно и платформы используются соответствующие.
С/С++ или тот же дотнет в специальном "оптимизированном" режиме написания кода, чтобы не дёргать GC на каждый чих и вообще с уменьшенной суммарной косвенностью графа объектов.
ЕМ>Так что об этих затратах уместно говорить в контексте какой-нибудь специализированной промышленной системы, софт под которую или писан с нуля квалифицированными кадрами
Никак не отвыкну от привычки думать, что софт, требующий хоть какую-то эффективность, и должен писаться "квалифицированными кадрами". ))
Т.е. с целевым образованием и хотя бы 3-5тилетним опытом именно в области эффективного программирования.
ЕМ>Если же взять навскидку произвольную систему общего назначения, от которой ожидается realtime в плане той же мультимедии, то затраты на переходы в режим ядра, переключение контекста и подобное — одни из последних кандидатов на оптимизацию.
Ну-ну-ну... ))
Этот "софт общего назначения", для случая мультимедиа, построит граф узлов в каком-нить DirectShow или прочих OpenAL и скажет этому графу "старт!"
А далее будет работать охрененно вылизанные подкапотные вещи использованной либы — кодеки/фильтры, источники и приёмники сигналов и т.д.
Т.е., задача прикладного кода сводится лишь к построениях графа из готовых кубиков и конфигурированию его.
Но мы-то обсуждаем "кишки". ))
V>>Т.е., lock-free гарантирует, что в каждый момент времени хотя бы один поток продвигается в своём исполнении. ЕМ>Да, но только если это lock-free одновременно и для потоков, и для их общих ресурсов.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Собственно, из-за этого в процессах появлись потоки. На уровне потоков все шустрее. ЕМ>Там разница лишь в том, что процесс выделен в качестве контейнера для потоков. Классическая модель UNIX просто совмещает процесс, как контейнер, с единственным потоком в нем. В отношении планирования/диспетчеризации никакой разницы нет.
При переключение потоков контекст процесса не переключается, в отличие переключения процессов.
Если об этом речь.
S>>как оно на уровне процессов, а не потоков я не в курсе. ЕМ>Если мы про винду, то в ней в планировании участвуют исключительно потоки. Процесс представляет собой лишь "расширенный контекст" (адресное пространство, ресурсы, общие свойства и т.п.).
Ну когда-то же происходит переключение процессов, на поток из другого процесса? Вот тогда это долго.
S>>Возможно дейстивительно поэтому в ядре lock-free и не взлетает, т.к. на уровне процессов это крайне сложно, если вообще возможно. ЕМ>В смысле? Что именно "не взлетает" и "крайне сложно"?
lock-free алгоритмы в ядре. Легко сделать сильно неочевидный баг. В ядрах все должно быть максимально просто.
Здравствуйте, vdimas, Вы писали:
V>Тут переключения контекстов могут отожрать до 95% всех тиков, если каждый источник обрабатывается отдельным потоком ОС.
Какой смысл для каждого источника создавать поток? Выделенный поток имеет смысл, если он работает с источником бОльшую часть времени. Если же он преимущественно спит, то такое раздувание количества потоков и является основной причиной затыков.
V>Никак не отвыкну от привычки думать, что софт, требующий хоть какую-то эффективность, и должен писаться "квалифицированными кадрами". ))
Мне тоже сложно думать иначе, но подход "возьмите молоток побольше" уже давно преобладает везде, кроме совсем уж критичных участков. И даже там изо всех сил пытаются упрощать и послаблять.
V>А далее будет работать охрененно вылизанные подкапотные вещи использованной либы — кодеки/фильтры, источники и приёмники сигналов и т.д.
И кто ж их охрененно-то вылижет? Да, кто-то и посейчас тщательно следит за использованием ресурсов, но большинство ж, сидя на топовом железе, вообще ни разу не тестирует свои поделия на более слабом. "У меня работает — значит, и у других будет".
Кстати, тот же DirectShow можно считать достаточно оптимальным лишь для типовой потоковой обработки, не требующей особой динамики. При попытке собрать таким образом какой-нибудь блок эффектов для гитары сразу станет грустно. Именно поэтому и родили в свое время предельно упрощенный и аскетичный ASIO.
Здравствуйте, Sharov, Вы писали:
S>При переключение потоков контекст процесса не переключается, в отличие переключения процессов.
Переключение контекста процесса как раз значительно проще — для этого всего-то нужно перезагрузить несколько регистров (в том числе MMU). Там потери в основном на перезагрузки кэшей, но это происходит и при работе потоков без переключения. Во многих случаях переключение между двумя потоками одного процесса может перетряхивать кэши сильнее, чем между двумя потоками из разных процессов.
S>lock-free алгоритмы в ядре. Легко сделать сильно неочевидный баг. В ядрах все должно быть максимально просто.
Когда реально нужны оптимизация/функциональность, в ядро тащат все, что требуется.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>При переключение потоков контекст процесса не переключается, в отличие переключения процессов. ЕМ>Переключение контекста процесса как раз значительно проще — для этого всего-то нужно перезагрузить несколько регистров (в том числе MMU). Там потери в основном на перезагрузки кэшей, но это происходит и при работе потоков без переключения. Во многих случаях переключение между двумя потоками одного процесса может перетряхивать кэши сильнее, чем между двумя потоками из разных процессов.
Это уж как напишете. При переключении процессов это всегда происходит, а потоков зависит от реализации.
Здравствуйте, Евгений Музыченко, Вы писали:
V>>Тут переключения контекстов могут отожрать до 95% всех тиков, если каждый источник обрабатывается отдельным потоком ОС. ЕМ>Какой смысл для каждого источника создавать поток? Выделенный поток имеет смысл, если он работает с источником бОльшую часть времени. Если же он преимущественно спит, то такое раздувание количества потоков и является основной причиной затыков.
Вопрос был про стоимость переключений контекстов — я привёл известный сценарий, показывающий эту стоимость.
V>>Никак не отвыкну от привычки думать, что софт, требующий хоть какую-то эффективность, и должен писаться "квалифицированными кадрами". )) ЕМ>Мне тоже сложно думать иначе, но подход "возьмите молоток побольше" уже давно преобладает везде, кроме совсем уж критичных участков. И даже там изо всех сил пытаются упрощать и послаблять.
ОК.
Но в теме о реалтайме это оффтоп, ИМХО.
V>>А далее будет работать охрененно вылизанные подкапотные вещи использованной либы — кодеки/фильтры, источники и приёмники сигналов и т.д. ЕМ>И кто ж их охрененно-то вылижет?
Разработчики в этой области, вестимо.
Область-то специфическая. ))
ЕМ>Да, кто-то и посейчас тщательно следит за использованием ресурсов, но большинство ж, сидя на топовом железе, вообще ни разу не тестирует свои поделия на более слабом. "У меня работает — значит, и у других будет".
Да ну не...
DirectShow, DirectSound или всякие speex вылизаны очень даже неплохо.
Оно ж всё вылизывалось еще для техники 90-х как по общей архитектуре (путям прохождения/обработки данных), так и по публичному АПИ, суть которого сводится к конфигурированию/настройке общего графа устройств + обработчиков.
ЕМ>Кстати, тот же DirectShow можно считать достаточно оптимальным лишь для типовой потоковой обработки, не требующей особой динамики. При попытке собрать таким образом какой-нибудь блок эффектов для гитары сразу станет грустно.
Ес-но, из блоков DirectShow блок эффектов не собирают. ))
Подход был отродясь другой — весь блок эффектов представляет из себя один узел фильтра DirectShow.
Задача этого фильтра — обработать порцию данных по входу, положив результат по выходу.
Примитивнейшее и эффективное АПИ.
И уж прояви себя через эффективный матан между входом и выходом! ))
ЕМ>Именно поэтому и родили в свое время предельно упрощенный и аскетичный ASIO.
Э, нет! ))
ASIO — это дыра не через софтовый драйвер, а через нагромождения в железе.
Ведь основные фильтры/микшеры/массивы_микрофонов и прочие приблуды живут в DSP звуковых микросхем, поэтому ASIO был придуман, чтобы обойти именно этот аппаратно-программный конвейер, получив данные прямо от, считай АЦП (или из пакетов USB 3.0) и отправив их обратно в буфер ЦАП (или прямо в буфер пакетов USB 3.0), минуя всяческую обработку ср-вами ОС и драйвера, как оно есть для ЛЮБЫХ подключенных звуковых устройств.
Не зря ASIO — это опциональная фича драйвера конкретной звуковой микросхемы или платы (в т.ч. внешней).
И не зря эта фича достаточно редка в "обычном" железе.
Устройства ввода и вывода в полноценном ASIO захватываются в исключительном режиме и не доступны аудио-системе Windows, т.е. ползунок громкости и прочие вещи на них не влияют.
Это как бы параллельная вселенная, не связанная с подсистемой аудио виндов, оно может крутиться независимо друг от друга, что я и делал — проигрывал музыку заднего фона обычными проигрывателями Windows, а гитару подключал через внешнюю USB-картейку по входу и выходу, и далее на выходе простой микшер, куда подключен обычный звуковой выход компа и звуковой выход внешней картейки, а с микшера уже на усилок.
Здравствуйте, vdimas, Вы писали:
V>Но в теме о реалтайме это оффтоп, ИМХО.
Если бы. Всегда ж у нанимателя есть выбор — искать квалифицированного и опытного разработчика, или взять первого мало-мальски подходящего.
ЕМ>>И кто ж их охрененно-то вылижет?
V>Разработчики в этой области, вестимо. V>Область-то специфическая. ))
Я Вас умоляю. Работаю в этой области уже три десятка лет, реально вылизанный софт встречается очень редко. Даже у самих MS в звуковой подсистеме полно косяков и откровенных багов, которые не правятся десятилетиями, поскольку мало кого сильно напрягают — в большинстве случаев можно как-то выкрутиться.
V>DirectShow, DirectSound или всякие speex вылизаны очень даже неплохо. V>Оно ж всё вылизывалось еще для техники 90-х
Сам движок DirectShow действительно не слишком поменялся, но его никогда не позиционировали именно на реактивность. Его главное назначение — собрать граф, который будет гнать непрерывный стабильный поток, не предполагающий более быстрых изменений, чем ручные регулировки. Типовая задержка от входа до выхода там обычно в сотни миллисекунд, тщательной настройкой можно стабилизировать на нескольких десятках, но сгородить на нем ту же обработку голоса, при которой не слышно задержки, на стандартных фильтрах не получится.
Ну а DirectSound в Vista и вовсе превратился в тыкву, и теперь работает даже не через более-менее приличный WASAPI, а через самый древний и тормозной MME, поэтому даже для эффектов в играх годится едва-едва.
V>Ес-но, из блоков DirectShow блок эффектов не собирают. ))
Я про законченную конструкцию, в виде ящика с динамиком, в который втыкается гитара.
V>весь блок эффектов представляет из себя один узел фильтра DirectShow. V>Задача этого фильтра — обработать порцию данных по входу, положив результат по выходу.
Вот типичный фильтр DirectShow использует буферизацию в десятки-сотни миллисекунд, и это чаще всего не управляется.
V>ASIO — это дыра не через софтовый драйвер, а через нагромождения в железе.
ASIO — это прежде всего API, примитивный и убогий. Через что он будет работать, определяется исключительно реализацией. Но даже самые лучшие реализации ASIO работают через софтовые драйверы, ибо напрямую к железу их никто не пустит.
Есть реализации ASIO даже поверх MME, чтоб хоть как-то завести ASIO-only софт с адаптером, для которого нет драйвера ASIO. А есть реализации MME непосредственно через драйвер ядра, минуя промежуточные уровни звуковой подсистемы.
V>Ведь основные фильтры/микшеры/массивы_микрофонов и прочие приблуды живут в DSP звуковых микросхем, поэтому ASIO был придуман, чтобы обойти именно этот аппаратно-программный конвейер
Кому Вы это объясняете? ASIO появился, когда я уже довольно плотно работал со звуком на PC, поэтому я хорошо помню всю эту историю. Единственной целью его разработки была тупо альтернативная работа с железом в обход стандартной виндовой звуковой подсистемы, которая тогда была чуть менее убога, и ориентирована прежде всего на обычный потоковый звук без выкрутас. К тому времени уже был DirectSound, но он был почти полностью заточен под воспроизведение, ибо предназначался в первую очередь для игр и эффектов, а запись в нем была предельно примитивная — возможно, ее предусмотрели просто "на всякий случай", без явных перспектив.
К тому времени чуть не каждый производитель мало-мальски серьезных звуковых карт городил для них свой API, с которым работали "родные" программы и некоторые "дружественные", но этот зоопарк никого не устраивал. Так что единственное, чем отличался API от Steinberg — это простота, достаточно полная документация, и доступный SDK. По уровню сложности ASIO примерно на том же уровне, что и плагины для WinAMP или Foobar2000. Но это было единственное, что на тот момент имелось сколько-нибудь универсального, и индустрия быстро на него подсела (явно не без содействия Steinberg). Ну а потом что-то переделывать было уже поздно, да никто и не горел желанием.
V>получив данные прямо от, считай АЦП (или из пакетов USB 3.0) и отправив их обратно в буфер ЦАП (или прямо в буфер пакетов USB 3.0)
Все это уже почти тридцать лет нетрудно проделать стандартными средствами KS, только удобнее.
V>минуя всяческую обработку ср-вами ОС и драйвера
А вот хрен-то там. Типичный звуковой адаптер обрабатывает поток, состоящий из кадров, в которых отсчеты всех каналов идут подряд, ибо это естественное представление цифрового потокового многоканального звука. В потоках ASIO подряд идут отсчеты каждого из каналов. Поэтому ASIO эффективно работает только с адаптерами, которые сами работают с набором одноканальных потоков, а не с одним многоканальным. Когда драйвер ASIO работает с типичным адаптером, он сам перекладывает отсчеты туда-сюда в промежуточной памяти. Сейчас это, конечно, не занимает столько времени, сколько в 90-х, а тогда это было вполне ощутимым при малых размерах буферов.
V>как оно есть для ЛЮБЫХ подключенных звуковых устройств.
Что значит "для любых"?
V>Не зря ASIO — это опциональная фича драйвера конкретной звуковой микросхемы или платы (в т.ч. внешней).
В каком смысле "не зря"? Написали драйвер ASIO — фича появилась, не написали — ее нет. В этом нет никакой философии, не стоит воспринимать это все с таким восторгом.
V>И не зря эта фича достаточно редка в "обычном" железе.
В железе "этой фичи" вообще нет, и быть не может. Максимум, что может быть в железе — это та самая аппаратная обработка совокупности одноканальных потоков, чтоб избавить от этого драйвер.
V>Устройства ввода и вывода в полноценном ASIO захватываются в исключительном режиме и не доступны аудио-системе Windows
Устройства KS, внезапно, ведут себя точно так же, но при этом являются стандартными для Windows.
V>Это как бы параллельная вселенная, не связанная с подсистемой аудио виндов
Господи, что за пафос... Как же вам всем засрали мозги, подавая примитивное поделие под видом революции...
V>оно может крутиться независимо друг от друга, что я и делал — проигрывал музыку заднего фона обычными проигрывателями Windows, а гитару подключал через внешнюю USB-картейку по входу и выходу, и далее на выходе простой микшер, куда подключен обычный звуковой выход компа и звуковой выход внешней картейки, а с микшера уже на усилок.
То же самое, внезапно, Вы могли бы сделать с любыми стандартными устройствами Windows, только задержки были бы побольше — за счет той самой универсальности и "невылизанности".
Здравствуйте, Евгений Музыченко, Вы писали:
V>>Но в теме о реалтайме это оффтоп, ИМХО. ЕМ>Если бы. Всегда ж у нанимателя есть выбор — искать квалифицированного и опытного разработчика, или взять первого мало-мальски подходящего.
Если тебе всё это время хотелось поговорить о несовершенстве этого мира — то я заранее согласен.
Но моё мнение по этому поводу куда как более категоричное, мне им лучше не светить лишний раз. ))
А то набегут "истерички" плеваться в "снобов".
Здравствуйте, vdimas, Вы писали:
V>Ну, не зря же программа Время начинается на цифровых телеках/приставках примерно на пол-секунды, а то и секунду позже, чем на аналоговых... ))
V>Там приличная буферизация именно для таких целей.
Там видео поток не mjpeg, Для сжатия на стороне сервера нужно минимум пару секунд в буфере иметь, а лучше больше. а то не сожмёшь видео. Телевизор же поток мгновенно показывает.
При любой многозадачности мьютексы прекрасно работают до определенного уровня загрузки, и лишь после нее начинается лавинообразный рост коллизий. 
