bada
Только вернулся из командировки, завтра сяду писать для DTF разгромную статью (про STL в том числе). Поэтому если не против, давай немного отложим этот разговор.
Димка
ЫЫ. Предвещаю - в цензурных выражениях разгрома не будет.
Димка
с нетерпением ждем
bada
Пока что до статьи руки не доходят, но советую обратить внимание на развернутый мною холивар на DTF (http://www.dtf.ru/forum/thread.php?id=128420)
(это к вопросу про STL)
Димка
внимательно прочитал весь тред, сделал вывовд - меня вобще к консолям нельзя подпускать )))))
кстати есть какие-нибудь книжки для эффективного программирования под консоли?
Просто я приучен думать абстракциями - выделил сущноть -напиши интерфейс, есть набор элементов - юзай контейнер и тд., про память я даже и не задумывался.
Придетя переучиваться (((((
(ушел читать маерса)
bada
> внимательно прочитал весь тред, сделал вывовд - меня вобще к консолям нельзя подпускать )))))
Open mind. Это очень хорошо.
bada
>Димка
>внимательно прочитал весь тред, сделал вывовд - меня вобще к консолям нельзя
>подпускать )))))
>кстати есть какие-нибудь книжки для эффективного программирования под консоли?
>Просто я приучен думать абстракциями - выделил сущноть -напиши интерфейс, есть
>набор элементов - юзай контейнер и тд., про память я даже и не задумывался.
>Придетя переучиваться (((((
>(ушел читать маерса)
Русских книг по программированию для консолей AFAIK нету :(.
Рекомендую прочитать мою статью на DTF: http://www.dtf.ru/articles/read.php?id=4071
А также послушать доклад Ромы Арсенихина Акеллы с КРИ 2005 на www.kriconf.ru и (вот уже скоро) будут выложены доклады Крейта с КРИ 2006.
(правка: апичатки)
Димка
вобще решение писать на стл было в связи с тем, чтоб получить хоть какойто приемлемый результат за пол года человеку, который вобще пришел не из геймдева, который первый раз увидел консоль и cygwin, при отсутствии дебага и оффиц СДК и даже хоть какихто советов, или людей который хоть что то делали под консоли. Потому это было единственное объективное решение показать результат в обозримом будущем а не спустя 2 года.....
Я вобщем понял все направление разработки под консоль, надо переделывать конечно, но тока когда будут решены аналогичные задачи на не консоли и желательно с дебагером и VTune )))))
кстати мне книги можно и не на русском советовать, я и на аглицком не хуже понимаю )))
bada
Ну, смотря что называть "приемлимым результатом". Я не знаю лучшего способа фрагментировать физическую память, чем применять STL без предварительных reserve() :). В противном случае твоя игра проживет от нескольких секунд до нескольких минут, после чего умрет в агонии.
А STL с предварительным reserve() - это тот же boost::array или собственный массив фиксированного размера.
Акелла с этой проблемой трахалась - Арсенихин на КРИ 2005 подробно рассказывал. Я был в глубоком обмороке.
Димка
ну я честно не знаю, вот пока прототип не падает, даже бодро бегает, это тока я вокруг ношусь, пытаясь соломки подстелить :]
насчет фрагментации, вот я загрузил в начале все объекты через
GameObject * pObj = NULL;
....
if("SolidBlock" == className)
{
pObj = new SolidBlock();
}
....
if(pObj)
{
pObj->Load(pElem);
vecPtrGameObj.push_back(pObj);
}
в самом векторе - указатели, я вот непойму - как это ведет к фрагментации памяти путем стл? или я вот совсем тупой.....
кстати а что делает sceKernelTotalFreeMemSize ? что то оно все время одно число показывает не зависимо от загруженых ресурсов(1028096)
еще там из той же оперы всякие выделители памяти, тоже интересно послушать про них мнение
вот еще профайлер, который что то показывает, но как это заюзать - непонятно
интересно так же про gdb послушать, как его заюзать - тоже интересно
bada
Очень просто (про push_back)
for (int i=0; i<10000; i++) {
vector.push_back(0);
}
Дажее все зависит от реализации. Если вектор аллоцирует память вдвое, то ты получаешь следующую карту распределения памяти (. - свободно, X - занято):
[X...............]
[.XX.............]
[...XXXX.........]
[.......XXXXXXXX.]
И так далее. То есть в начале памяти образуется свободный пул.
В свое время очень много копий (от слова "копьё") сломали о то, что если вектор реаллоцируется на 1.5 размера, то есть теоретическая возможность, что новый вектор заюзает старое пространство. На самом деле это так, если более никаких аллокаторов не вызывается. Если есть хотя бы один аллокатор пусть даже от простейшего std::string, память будет распределяться точно таким же способом.
Итого. push_back() сократит тебе доступную память вдвое. Единственное спасение - резервировать память вначале. Но тогда это простой массив, и вся функциональность вектора тебе нафиг не нужна.
Димка
тоесть в моем случае это потеря пары десятков long int ? та нуууу не велика потеря ))))
bada
Ну если у тебя в программе только один вектор, в котором пара десятков long int, загружаемый при старте приложения, то действительно невелика потеря :)
Но что-то мне подсказывает, что одним только вектором дело не ограничивается.
Вот расскажи мне, что ты для хранения строк юзаешь? std::string?
;)
Димка
ааа...каюсь....юзаю...это тоже очень плохо?
я вот даже все что const char * str вижу делаю сразу String(str)
А я наоборот (да и KVaks тоже) :) Везде, где вижу std::string, с матюками перевожу в const char*.
Самый первый простой и синтетический пример:
extern void doSmth(const char* s);
int main(int argc, char* argv[])
{
DWORD timeStart1;
DWORD timeStart2;
DWORD timeEnd1;
DWORD timeEnd2;
DWORD count;
timeBeginPeriod(1);
timeStart1 = timeGetTime();
for (count=0; count<1000000; count++) {
std::string str("BlaBlaBlaBlaBlaBlaBlaBla");
doSmth(str.c_str());
}
timeEnd1 = timeGetTime();
timeStart2 = timeGetTime();
for (count=0; count<1000000; count++) {
char str[] = "BlaBlaBlaBlaBlaBlaBlaBla";
doSmth(str);
}
timeEnd2 = timeGetTime();
printf("vector: %i; array: %i\n", timeEnd1 - timeStart1, timeEnd2 - timeStart2);
return 0;
}doSmth(const char* s) - это пустая функция, которая определена в другом файле (только для того, чтобы не заинлайнилось). Время выполнения у меня на компьютере: vector: 375 ms, array: 21 ms.
Теперь заменим функцию на doSmth(const std::string& str). Время выполнения увеличилось. vector: 750 ms, строка - 375 ms. Впрочем, в первом цикле можно исправить ошибку, чтобы тоже стало 375 ms.
Это все так, для начала :)
Потом вопросы будут посложнее (это для MSVC 7.1):
Почему std::string str("BlaBlaBlaBlaBla") занимает 40 ms, а std::string str("BlaBlaBlaBlaBlaBla") - 375 ms (и дальше практически не растет)?
Каков sizeof(str)? Чур отладчик не запускать! Сколько реально занимает памяти std::string str("BlaBlaBlaBlaBlaBla")?
Ну и далее в зависимости от ответов :)
Тема в архиве.