Профилировщик для FPC

Bupyc · Сообщение **Bupyc** » 18.04.2008 19:54:55

Cheb, всё зависит от решаемой задачи. Заметь, я даже не пытался утверждать, что в мой пример даёт максимальную точность измерений в любой ситуации. Естественно, когда речь идёт о ловле миллисекунд, способ с GetTickCount совершенно не подходит. Когда такая точность не нужна (в задачах, которыми я занимаюсь, именно такая ситуация), можно пользоваться GetTickCount и не заморачиваться.

Что касатается грамотности/безграмостности, то, хочу заметить, что ветка называется "Профилировщик для FPC", а не "Грамотность/безграмотность отдельных пользователей форума", так что imho было бы логичнее подобные высказывания оставить при себе ...

@!!ex · Сообщение **@!!ex** » 18.04.2008 20:14:32

*vmr
Я бы не стал опираться на опыт разработчиков Xenus'a.
Xenus - Это САМАЯ ДЕРЬМОВАЯ реализация динамической подгрузки уровня, которую я видел. НЕ тормозит только ан многоядерных машинках.
У вас GTA:SA тормозит, когда вы едите летите на самолете из одного конца карты в другой? Xenus тормозит, когда вы идете пешком(утрирую).
Там как бы верные и полезные вещи говорят, но практической пользы от них - 0.

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

Cheb · Сообщение **Cheb** » 18.04.2008 20:46:06

Для полного просветления читать "То, что вам никто не говорил о многозадачности в Windows"

Я её раз десять читал.
Но кто когда про TimeBeginPeriod вспоминает?

Эта функция все-то навсего возвращает значение системной еременой Время ее выполниения -- ничтожно

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

А вообще замер колчества тиков проца - стремное дело:
* процессоры имеют привычку менять свою частоту (Cool&Quiet например)

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

* Операционка имеет привычку перекидывать потоки с ядра на ядро. А у каждого ядра может быть свой счетчик тиков....

А). В таком случае мой метод даст откровенно бредовый результат, и всё сразу будет ясно.
Б). И как часто это происходит? Ей что, делать больше нечего, как потоки туда-сюда двигать?
Хотя то, что я замерял, никогда не длилось больше 50 милисекунд.

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

Что касатается грамотности/безграмостности, то, хочу заметить, что ветка называется "Профилировщик для FPC", а не

Всё равно останусь при мнении, что GetTickCount для профайлинга никаким боком не годится - хоть нач асти меня режьте.

@!!ex · Сообщение **@!!ex** » 18.04.2008 20:49:59

Я так понимаю, здесь все game developer'ы???
В принципе логично... кому еще нужны профилировщики, как не ГДшникам.

)

Bupyc · Сообщение **Bupyc** » 18.04.2008 22:38:01

Cheb писал(а):Всё равно останусь при мнении, что GetTickCount для профайлинга никаким боком не годится - хоть нач асти меня режьте.

Понимаешь, может быть так, что в момент выполнения профилируемого кода, нить, в которой меряется время выполнения, будет переведена в спящее состояние, или проц переключится на выполнение какой либо задачи с более высоким приоритетом. Соответственно результат может быть искажён. Так что, твой способ тоже весьма сомнителен.
В любом случае, нужно понимать, о профилировании каких задач мы говорим. Одно дело, если речь идёт о задачах реального времени или близких к ним, и совсем другой вопрос, если требований реального времени нет. Точности GetTickCount при этом хватает за глаза.

*vmr · Сообщение *vmr » 21.04.2008 14:58:32

@!!ex
И причем сдесь ксенус???

Cheb
>Но кто когда про TimeBeginPeriod вспоминает?
Значит где-то по ссылкам. Но точно помню что это Лут говорил

>Но это-таки *вызов*, с передачей управления, переключением конвейера, и т.д. А мой вариант - несколько машинных команд, безо всяких ветвлений.
И на сколько наносекунд он быстрее?

Вобщем спорить по поводу точности я не собираюсь.

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

@!!ex · Сообщение **@!!ex** » 21.04.2008 18:18:43

*vmr,
автор этих статей - один из прогеров Ксенуса.
Статьи учат тому, КАК надо делать распараллеливание.... при том, что человек их написавший распаралеливание делать не умеет... чему яркий пример - Ксенус.

*vmr · Сообщение *vmr » 21.04.2008 19:21:51

@!!ex
Извени, но ты ведешь себя как маленький ребенок.
А то что автор является прогером Ксенуса я знаю

@!!ex · Сообщение **@!!ex** » 21.04.2008 19:25:54

*vmr
Я готов согласиться с тем, что я веду себя как ребенок, в случае логичного обоснования. ну и? Обоснование какое?

Я уже обосновал свою точку зрения:
Автор учит тому, чего сам не умеет => доверия статье 0.

*vmr · Сообщение *vmr » 21.04.2008 19:41:08

Ну все... начались переходы на личности, оффтоп и меряние конечностями...

@!!ex
>Автор учит тому, чего сам не умеет => доверия статье 0.
А своя голова зачем? Чтоб только доверять/не доверять? Слушать/не слушать?

Видимо ты еще не трудо устроился или же имеешь малый опыт работы на предприятии..... посему и не знаеш как оно бывает......

Вот я например прекрасно знаю все недостатки и проблемы своей программы. Но исправлять все это я не буду -- устал уже с начальством ругатся. Устал объяснять как все плохо. Доказывать что действительно надо вносить исправления. Начальство ж не считает сколько там недоработок и тормозов. Работает и хорошо!
Начальство считает только затраты и будущую прибыль.
Все! Всего остального для него просто не существует. Все остальное его не волнует. Главная цель -- прибыль.
И это при том что программу пишу только один я. А не куча программистов, которые еще и к тому же меняются (текучесть кадров).

И судить уровень скиллов программера по программе, которая не является воплощением его идей, его душой, его собственностью....

*vmr · Сообщение *vmr » 21.04.2008 19:50:31

@!!ex писал(а):Кстати, подугрзку уровней выносить в отдельный поток на одноядерной машину глупо. Проще выделять время основного потока на загрузку уровня и самому контролировать количество потраченого на загрузку времени. А в потоки надо выносить вещи, которые реально жрут ресурсы, это позволит очень нехило увеличить скорость работы на многоядерках.

Очень не согласен.
Но это уже оффтоп

@!!ex · Сообщение **@!!ex** » 21.04.2008 20:18:38

*vmr писал(а):Ну все... начались переходы на личности, оффтоп и меряние конечностями...

Вроде я стараюсь не переходить на личности. Всего лишь высказал точку зрения. Обоснеовал и ждал тогоже.

*vmr писал(а):@!!ex
>Автор учит тому, чего сам не умеет => доверия статье 0.
А своя голова зачем? Чтоб только доверять/не доверять? Слушать/не слушать?

Своя голова чтобы читать Рихтера... уж у него то о потоках все по делу написано.

Просто вы так упирали на то, что эта статья - истина в первой инстанции, что удержаться и не поспорить было делом сложным.

)

*vmr писал(а):Видимо ты еще не трудо устроился или же имеешь малый опыт работы на предприятии..... посему и не знаеш как оно бывает......

http://free-lancers.net/users/AllexInTheDark/

Тут только те проекты, где я - лид. Есть еще пара проектов(Maelstrom, например) где я был обычным прогером. Кстати, Maelstrom - как ОТЛИЧНЫЙ пример использования многопоточности. Там вообще все идеально синхронизированно. Очень жаль, что в то время я не понимал как это важно и не копался в сорсах... а сейчас к сорсам путь закрыт естесвтенно... Надо будет поговорить с прогеррами, как же они делали то??

*vmr писал(а):Вот я например прекрасно знаю все недостатки и проблемы своей программы. Но исправлять все это я не буду -- устал уже с начальством ругатся. Устал объяснять как все плохо. Доказывать что действительно надо вносить исправления. Начальство ж не считает сколько там недоработок и тормозов. Работает и хорошо!
Начальство считает только затраты и будущую прибыль.
Все! Всего остального для него просто не существует. Все остальное его не волнует. Главная цель -- прибыль.
И это при том что программу пишу только один я. А не куча программистов, которые еще и к тому же меняются (текучесть кадров).

А как же тестирование?
Мы сейчас проект вылизываем, я уже устал баги править.

(
Хотя(тьфу-тьфу-тьфу) сегодня вроде закончили с багами.. все поймали,

)

*vmr писал(а):И судить уровень скиллов программера по программе, которая не является воплощением его идей, его душой, его собственностью....

Есть такая фраза "А судьи кто?"(С)
Так вот, хочется узнать на чем автор основывался, когда писал свой труд... Там единственная ссылка - на Ксенус. По нему и судим. ИГра отличная, мне нравится. Даже Gold версию купил. но подгрузка уровней - слабое место этой игры.

@!!ex · Сообщение **@!!ex** » 21.04.2008 20:22:05

*vmr писал(а):Очень не согласен.
Но это уже оффтоп

Мы уже давно оффтопим. Буду очень благодарен, если развернете мысль, для общего развития.

*vmr · Сообщение *vmr » 22.04.2008 02:02:10

Все, меряние конечностями началось... ))

@!!ex писал(а):Своя голова чтобы читать Рихтера... уж у него то о потоках все по делу написано.

Ну Рихтер -- это святое

@!!ex писал(а):Просто вы так упирали на то, что эта статья - истина в первой инстанции, что удержаться и не поспорить было делом сложным.

У вас есть какие либо замечания к статье? Или неточности?

@!!ex писал(а):Тут только те проекты, где я - лид

Эх, не люблю я лидов....

@!!ex писал(а): Кстати, Maelstrom - как ОТЛИЧНЫЙ пример использования многопоточности.

Да, но вы не знаете как именно работают потоки в ОТЛИЧНОМ примере....

@!!ex писал(а):А как же тестирование?

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

Насколько я понимаю вы не делали огромных проектов, на разработку которых уходят годы. Я делал(ю)(правда годы на одного программиста. Т.е. меня

). Потому понимаю.
У вас есть ТЗ, вы его окончили в строк, протестировали и забыли.
А что делать когда ТЗ нет? Или оно неполное, или неохватывает все нюансы (как в Ксенусе)?

*vmr · Сообщение *vmr » 22.04.2008 02:19:27

@!!ex писал(а):Мы уже давно оффтопим. Буду очень благодарен, если развернете мысль, для общего развития.

Все очень просто

@!!ex писал(а):Кстати, подугрзку уровней выносить в отдельный поток на одноядерной машину глупо. Проще выделять время основного потока на загрузку уровня и самому контролировать количество потраченого на загрузку времени. А в потоки надо выносить вещи, которые реально жрут ресурсы, это позволит очень нехило увеличить скорость работы на многоядерках.

Во первых непонятно как вы будете "контролировать количество потраченого на загрузку времени".
Во вторых, где вы видели потоки, которые не "реально жрут ресурсы"?

В системе сотни потоков. Что они делают большую часть времени? Они ждут. Ждут события.
Пока они ждут - работают другие потоки.
А если другие потоки тоже ждут? Или их просто нет?
Тогда просто простаивает проц -- он нифига не делает.

Что делает игра когда отправила всю геометрию на GPU? Она ждет. Ждет пока не наступит момент VSync, или пока не освободится push-buffer или пока не отрисуется n-ый предыдущий кадр. Что в это время делает проц?
1. Нифига не делает - ожидает (в однопоточном приложении)
2. Грузит уровень в другом потоке.

--------------------------------------------------
А вот чтоб определить где именно простаивает проц нужен хороший профайлер.
Неужели никто кроме gprof ничего не знает? Из беспланых.