[ТЧ,ЧН,ЗП] Многоядерность, Используем два и более ядер |
Здравствуйте, гость ( Авторизация | Регистрация )
Сайт S.T.A.L.K.E.R. Inside / [ЗП] Параметры командной строки / Распаковщик ресурсов
[ТЧ,ЧН,ЗП] Многоядерность, Используем два и более ядер |
27.08.2015, 15:31
Сообщение
#61
|
|
Продвинутый геймер Репутация: 22 Группа: Участник Сообщений: 234 Награды: 3 Регистрация: 27.10.2010 |
|
 
|
|
|
|
27.08.2015, 16:44
Сообщение
#62
|
|
The One Репутация: 744 Группа: Участник Сообщений: 2715 Награды: 5 Регистрация: 05.12.2005 |
Хорошо, вопрос, будет ли работать, если сделать так - -StalkMen-, а почему нет, я что-то пропустил? Вот предложенный тобой случай: Сообщение отредактировал Neo][ - 27.08.2015, 16:46 -------------------- |
 
|
|
29.08.2015, 10:01
Сообщение
#63
|
|
Геймер Репутация: 86 Группа: Участник Сообщений: 128 Награды: 4 Регистрация: 05.05.2012 |
А то исходя из этого, должен быть dead lock нетЪ. взаимной блокировкой называется ситуация при которой несколько потоков ждут завершения работы (или освобождения ресурсов) друг друга, как в классической комедии, где двое никак не могут пройти через дверь, потому что очень вежливые) твой случай, если допустить, что поток один ждет завершения потока 2, а тот в свою очередь ушел в бесконечный цикл, взаимной блокировкой назвать нельзя, т.к. поток 2 может продолжать свою работу в цикле. -------------------- nop
|
 
|
|
04.11.2015, 13:10
Сообщение
#64
|
|
Опытный Геймер Репутация: 22 Группа: Участник Сообщений: 169 Награды: 2 Регистрация: 19.11.2010 |
Это что-то типа маленькой синхронизации выступает? Это неудачная попытка распараллелить вычисления на два потока в пределах одного кадра: предполагалось, что в каждом кадре первый поток посредством пары критических секций должен запустить параллельно себе второй поток (который выполнит часть задач рендера, обновит маркеры на карте, посчитает физику летящих пуль, обновит звуки и вызовет lua GC). На деле регулярно случались ситуации, когда второй поток вообще не получал времени на протяжении целых серий кадров. Человек, который это все писал, не понял, почему оно так получается, и решил проблему добавлением костыля в виде mt_Thread_marker. В итоге, первый поток регулярно и на протяжении целых серий кадров выполнял работу второго потока, в то время как тот спал. Фикс можно забрать -------------------- |
 
|
|
04.11.2015, 13:33
Сообщение
#65
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
Человек, который это все писал, не понял, почему оно так получается, и решил проблему добавлением костыля в виде mt_Thread_marker. Или, что скорее, ты не понял, что там происходит. Цитата В итоге, первый поток регулярно и на протяжении целых серий кадров выполнял работу второго потока, в то время как тот спал. Чем лучше твое решение: работу выполняет второй поток пока первый спит? Тоже на тоже, только еще расходы на переключение контекста и переходы в ядро и обратно? Цитата Фикс можно забрать Я вижу несколько проблем: - появилась ошибка синхронизации - нет остановки второго потока, он так и продолжает считать уже посчитанные данные; - заменены быстрые примитивы на медленные ядерные примитивы; - в случаях когда основной поток не нагружен добавилось лишнее переключение контекста. Замеры делались как "было" и как "стало"? На мой взгляд должно тормозить сильнее. Еще и глючить начать. Сообщение отредактировал abramcumner - 04.11.2015, 14:24 |
 
|
|
04.11.2015, 15:43
Сообщение
#66
|
|
Опытный Геймер Репутация: 22 Группа: Участник Сообщений: 169 Награды: 2 Регистрация: 19.11.2010 |
Чем лучше твое решение: работу выполняет второй поток пока первый спит? Лучше тем, что задачи второго потока всегда выполняются вторым потоком. Когда fps небольшой, работы у первого потока всегда предостаточно (OnRender + OnFrame), поэтому на практике к снижению производительности это решение не приводит. Появились глюки из-за несинхронизированного доступа к данным. Если там и есть глюки, то они есть с самого начала, потому что второй поток как выполнял свои задачи, так и выполняет. И да, замеры делались, ожидания подтвердились: изменений нет. upd: - появилась ошибка синхронизации - нет остановки второго потока, он так и продолжает считать уже посчитанные данные; Это почему? Сообщение отредактировал Flammable - 04.11.2015, 15:55 -------------------- |
 
|
|
04.11.2015, 16:08
Сообщение
#67
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
изменений нет. То есть это не фикс. - появилась ошибка синхронизации - нет остановки второго потока, он так и продолжает считать уже посчитанные данные; Это почему? Это моя ошибка - спутало название метода Event::Set |
 
|
|
15.12.2015, 01:26
Сообщение
#68
|
|
Опытный Геймер Репутация: 17 Группа: Участник Сообщений: 161 Награды: 3 Регистрация: 08.03.2015 |
Всем привет! Накопал немного инфы пока был в отключке)))
Вот хочу спросить у опытных людей Атрибут потока МТА при компиляции подымает производительность? К стате с наступающим новым годом))) Сообщение отредактировал Stalker_Monolit - 15.12.2015, 01:43 -------------------- |
 
|
|
Текстовая версия | Сейчас: 27.04.2024, 03:58 |