Адекватная замена для MS STL deque?, нужна замена в связи с багой в MS STL Опции

[kwisp]

Iron Bug,
попробовал твой пример в linux - память выше 5М не растет и очищается периодически. может все же это конкретная реализация так себя ведет.
конечно вектор при таком использовании будет оч медленно заполнятся - каждый push_back - куча лишних операций по перераспределению ,выделению, копированию.

[Iron Bug]

попробовал твой пример в linux

я пишу конкретно про MS STL
в линюксе проблем вообще нет. ну или редко и их быстро правят а мелкософт пока разродится с новой студией с этим патчем - сто лет пройдёт.

Сообщение отредактировал Iron Bug - 6.10.2010, 15:36

[kwisp]

я пишу конкретно про MS STL

я чет сразу не увидел

(Естественно, речь про MS STL, чтобы никто не понял неправильно).

хм...
MS STL - понятно, ну тут как говорится доверяй но проверяй. )

[Iron Bug]

ну тут как говорится доверяй но проверяй. )

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

Сообщение отредактировал Iron Bug - 6.10.2010, 15:51

[Алексей1153]

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

просто об этом надо заранее думать, вот и всё. Резервировать же можно кусками

Iron Bug, выполнил предложенный код. У меня на борту всего 640 метров озу, в момент начала запуска теста занято было 560 (смотрю диспетчером). Во время выполнения меняется от 560 до 562 , иногда прыгало до 568 - у меня ещё радива играет. Ничего не тормозит и память не жрётся, своп тоже молчит. Пробую в студии №6 , кстати.

Щас попробую в 2008

- во время запуска 631 , скачет 632... 635, без свопа, без тормозов

правда, это всё в дебаге было. Имеет значение ?

в релизе тоже память не жрётся

[Iron Bug]

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

просто об этом надо заранее думать, вот и всё. Резервировать же можно кусками

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

собственно, раз там всё равно баги, я планирую помаленьку перейти на опенсорцный STL и не парить себе моск. так оно надёжнее и ещё минус одна зависимость от мелкософта, который я терпеть не могу

Сообщение отредактировал Iron Bug - 6.10.2010, 22:19

[Алексей1153]

и ещё минус одна зависимость от мелкософта,

та ну, неспортивно

шутка.

[AD]

собственно, раз там всё равно баги, я планирую помаленьку перейти на опенсорцный STL и не парить себе моск. так оно надёжнее и ещё минус одна зависимость от мелкософта, который я терпеть не могу

Я немного чайник в этом. Тема крайне заинтересовала (есть проект, жутко страдающий из-за низкой эффективности). Пара вопросов: как именно перейти с MS STL на Open-Source STL? Чем они в плане возможностей будут отличаться в контексте данной проблемы?

Сообщение отредактировал AD - 7.10.2010, 7:59

[Iron Bug]

я пока не утверждала, что опенсорцный STL эффективнее (хотя скорее всего так оно и есть). но если в MS STL жёсткие баги, то использовать его просто нельзя. тут не до эффективности, когда прога валится с access violation.
сейчас вот как раз пытаюсь собрать один STL.

[AD]

Блин. Где собрать? Как подключить? Внешне отличаться он не будет?