некруто же, платформозависимая хрень (на поверку спинлок, если склероз не изменяет) в эпоху 11-го стандарта!
эй, кто там делал сборку под х64, пришло время заюзать православные примитивы синхронизации!


профилировщик может в картинки?

Не вижу смысла тратиться на это, ибо все равно рендер намертво привязан к винде.
Если и буду заниматься МТ, то скорее всего только с фиберами

А то, да ты прав, spinlock
http://www.swedishcoding.com/wp-content/up...sing_fibers.pdf
Ну,а это еще сильный WIP:

Скрин с использванием в моем движке:

может стоит тогда начать с отвязывания рендерера от винды?

Если конечно у меня еще правильно работает... я сам еще не разобрался... библиотека без документации и примеров


Ты готов написать новый рендер с 0? - Я, нет. Я уже со своим затрахался вдовль.
Другое дело, заменить его на какую - нибудь либу

есть варианты?

https://github.com/bkaradzic/bgfx

Но автор GL4 версию не развивает активно(в данный момент)
https://github.com/bazhenovc/sigrlinn

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

-StalkMen-, word )


refuse, профилировщик профилировщику рознь


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

Neo][,

Второй скрин - откуда инфа о длительности?



(На мп серваке очень часто юзается)

-StalkMen-, это сделано специально для наглядности, чтобы исключить вопросы на подобии:


2-й поток не может не успеть, первый поток будет ждать на mt_csEnter


пока второй не выполнит работу и не освободит эту секцию:

Neo][,

Хорошо, вопрос, будет ли работать, если сделать так -


А то исходя из этого, должен быть dead lock

-StalkMen-, а почему нет, я что-то пропустил?

Вот предложенный тобой случай:

нетЪ. взаимной блокировкой называется ситуация при которой несколько потоков ждут завершения работы (или освобождения ресурсов) друг друга, как в классической комедии, где двое никак не могут пройти через дверь, потому что очень вежливые)
твой случай, если допустить, что поток один ждет завершения потока 2, а тот в свою очередь ушел в бесконечный цикл, взаимной блокировкой назвать нельзя, т.к. поток 2 может продолжать свою работу в цикле.

Это неудачная попытка распараллелить вычисления на два потока в пределах одного кадра: предполагалось, что в каждом кадре первый поток посредством пары критических секций должен запустить параллельно себе второй поток (который выполнит часть задач рендера, обновит маркеры на карте, посчитает физику летящих пуль, обновит звуки и вызовет lua GC). На деле регулярно случались ситуации, когда второй поток вообще не получал времени на протяжении целых серий кадров. Человек, который это все писал, не понял, почему оно так получается, и решил проблему добавлением костыля в виде mt_Thread_marker. В итоге, первый поток регулярно и на протяжении целых серий кадров выполнял работу второго потока, в то время как тот спал. Фикс можно забрать здесь, если кому-то интересно.

Или, что скорее, ты не понял, что там происходит.


Чем лучше твое решение: работу выполняет второй поток пока первый спит? Тоже на тоже, только еще расходы на переключение контекста и переходы в ядро и обратно?


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

Замеры делались как "было" и как "стало"? На мой взгляд должно тормозить сильнее. Еще и глючить начать.

Лучше тем, что задачи второго потока всегда выполняются вторым потоком. Когда fps небольшой, работы у первого потока всегда предостаточно (OnRender + OnFrame), поэтому на практике к снижению производительности это решение не приводит.

Если там и есть глюки, то они есть с самого начала, потому что второй поток как выполнял свои задачи, так и выполняет.
И да, замеры делались, ожидания подтвердились: изменений нет.
upd:

Это почему?

То есть это не фикс.



Это моя ошибка - спутало название метода Event::Set

Всем привет! Накопал немного инфы пока был в отключке)))
Вот хочу спросить у опытных людей Атрибут потока МТА при компиляции подымает производительность?
К стате с наступающим новым годом)))