1) std::this_thread::yield аналогичен Sleep(0) и SwitchToThread. Выше на этот вопрос уже ответили.
2) А что не так с Windows? И задача была не 60, а 200 видеопотоков расжимать. Кстати, сейчас под линуксом тоже делаем аппаратный декомпрессор, пока его не удалось заставить более 16 потоков расжимать. Правда при этом задача, что нельзя ни драйвера никакие ставить дополнительные, ни чужой софт.
Вот думаю сейчас, что это связано с тем, что мы ещё и аппаратное скалирование делаем в случае необходимости, пока расжатый кадр находится в видеопамяти.
Да, в конце я к этому плавно подвёл. Атак я говорил про дефолтные тайминги, с которыми может столкнуться разработчик при написании/тестировании. А в реальности, да, работает в фоне какое другое приложение и всё, текущее разрешение таймера может быть любым.
Если честно, я уже не помню причин. В любом случае сейчас будем всё напрямую на Intel Media SDK переписывать (благо поддержку аналогичных чипов у nvidia и amd выкинули в силу их глюконутости), там всё по другому будет.
Да, в реальности 15-16 миллисекунд всегда было. Это и в тестах на Win Server'е видно. Но в разговорной среде почему-то говорилось 20, поэтому так и написал.
при пробуждении получает повышенный приоритет (на клиентских осях).
Ой, я был уверен, что на серверных всё так же с динамическим повышением приоритетов, как и в клиентских осях :-(. Надо будет себе на заметку взять провести тесты на эту тему.
SwithToThread просто отдаст остаток кванта времени другому потоку. Но это не поменяет время когда система начнёт планировать потоки на следующий квант. Т.е. это мало будет отличимо от Sleep(1).
Интересно. Waitable timer'ы используются, это гуд, но кода поднимающего разрешение таймера не видно. Т.е. как показывают тесты, на серверных операционках это спокойно может больше 10 миллисекунд отрабатывать.
Это загрузило бы процессор конкретно, а нам ведь надо с этими расжатыми кадрами ещё много что сделать. Подход на таймерах/слипах позволяет процессору это время выполнять другие потоки.
Проблема в том, что как я сказал у нас синхронный интерфейс декомпрессора. Т.е. сверху нам никто не даст следующий кард, пока мы не разожмём текущий. Собственно, как я уже говорил, у нас был выбор, либо перерабатываем архитектуру, чтобы самим расжимать асинхронно, либо пытаемся сделать меньший слип. Выбрали второе.
Это кривь только у вас в голове. Да, если, в компании настолько надёжный код, что тестирует разработчик на своей машине, то тут ничего не поможет. Ну хотят денег на тестировании съэкономить — пусть экономят.
И опять, в дебаге функциональность отлаживать проще: нет оптимизации, видны все переменные, куча дебажных проверок, в том числе на порчу кучи и т.д. При разработке только в релизе, часть проблем может оказаться не найдеными, да и время гораздо больше уйдёт. Да и вообще не верю я в разработку с /O2. Поэтому схема дебуг-релиз производит более надежные приложения. В принципе у нас в компании это очень хорошо видно. Один департамент в одной схеме работает, второй в другой (они не умеют дебаг собирать). Очень хорошо разницу видно.
Ну как бы события в виндоус посылаемые окнам они изначально. Так что, опять бред.
И причём тут ваш бред, по то что пришло или не пришло бы мне в голову? Я доказал, что вы писали бред. Не надо уводить разговор в сторону.
2) А что не так с Windows? И задача была не 60, а 200 видеопотоков расжимать. Кстати, сейчас под линуксом тоже делаем аппаратный декомпрессор, пока его не удалось заставить более 16 потоков расжимать. Правда при этом задача, что нельзя ни драйвера никакие ставить дополнительные, ни чужой софт.
Ой, я был уверен, что на серверных всё так же с динамическим повышением приоритетов, как и в клиентских осях :-(. Надо будет себе на заметку взять провести тесты на эту тему.
Не думал, что тут так много фанатов айфонов, что даже нельзя смешную историю рассказать про первые айфоны, чтобы карма не слилась :(
Это кривь только у вас в голове. Да, если, в компании настолько надёжный код, что тестирует разработчик на своей машине, то тут ничего не поможет. Ну хотят денег на тестировании съэкономить — пусть экономят.
И опять, в дебаге функциональность отлаживать проще: нет оптимизации, видны все переменные, куча дебажных проверок, в том числе на порчу кучи и т.д. При разработке только в релизе, часть проблем может оказаться не найдеными, да и время гораздо больше уйдёт. Да и вообще не верю я в разработку с /O2. Поэтому схема дебуг-релиз производит более надежные приложения. В принципе у нас в компании это очень хорошо видно. Один департамент в одной схеме работает, второй в другой (они не умеют дебаг собирать). Очень хорошо разницу видно.
Прекратите же уже бред нести :-(
И да, The Bat!, например, падает с потерей данных (а иногда и с потерей всей БД) в бесконечное число раз больше, чем Word.
У меня глюков нет, до того как вы на MFC с чего-то скакнули, в соседней ветке мы уже про Qt говорили.
И причём тут ваш бред, по то что пришло или не пришло бы мне в голову? Я доказал, что вы писали бред. Не надо уводить разговор в сторону.