Всем привет.

Стали смотреть на VC2015 и выяснилось, что новомодная реализация контейнеров (list, set/map, deq) — все в дефолтовом конструкторе аллоцируют по ноде на хипе.
Если честно, непонятно, зачем им это надо, поэтому вопросы:

1. Поднималась ли тема на этом форуме. Если да — ткните носом, в поиске не нашел.
2. Доводилось ли до MS что это нехорошая реализация? Если да — тоже просьба кинуться ссылочкой, т.к. в гугле соотв. багу на VC найти не удалось.
3. Есть ли, кроме буста, эффективные замены stl для VC2015? STLPort вроде скорее мертв, чем жив.

Спасибо!

Эта реализация в таком виде вроде еще с 2012 живет.

2. Кажется в блоге разработчиков кто-то высказывался по этому поводу. Но вообще хорошо бы в Connect тикет завести.
3. А вы уверены, что проблемы с эффективностью у вас именно из-за такой реализации контейнеров?
Целесообразность выделение памяти на куче весьма сомнительна, однако эти контейнеры выдают неплохую дебаг диагностику (за исключением самоприсваивания).
Из альтернатив — только boost.container и boost.intrusive. Для их визуализации кстати есть соотв расширение.

В плане производительности меня больше напрягает древняя проблема со множественным наследованием пустых классов и недостаточно хорошая оптимизация move семантики (типа make_unique).

VTT>Эта реализация в таком виде вроде еще с 2012 живет.

Начиная с 2005 там это. Но на оправдание не тянет... Хочется понимать причины.

VTT>2. Кажется в блоге разработчиков кто-то высказывался по этому поводу. Но вообще хорошо бы в Connect тикет завести.

А ссылочкой бы? Гугл в последнее время вообще непотребно ищет. Вот есть такая ссылка — но там только факты, никто в ms ничем не кидается.

VTT>3. А вы уверены, что проблемы с эффективностью у вас именно из-за такой реализации контейнеров?

Я уверен, что STL не должна иметь пессимистичную реализацию. А в данном случае это именно так (при том, что нормальная реализация всем известна и лучше по всем параметрам — даже по локальности контейнер->head).

VTT>Целесообразность выделение памяти на куче весьма сомнительна, однако эти контейнеры выдают неплохую дебаг диагностику (за исключением самоприсваивания).

Каким образом выделение head ноды на куче улучшает debug диагностику? Например, кинуть исключение в дефолтовом конструкторе — это ведь явно не улучшает?

Я вот тоже ни в чем не уверен. Может стоит спросить разработчиков?

AS>Каким образом выделение head ноды на куче улучшает debug диагностику? Например, кинуть исключение в дефолтовом конструкторе — это ведь явно не улучшает?

Никаким наверное. Я просто подчеркиваю, что дебаг диагностика у студийных контейнеров получше.
Во всяком случае выделение памяти для одной ноды погоды не делает.

Здравствуйте, Andrew S, Вы писали:

AS>3. Есть ли, кроме буста, эффективные замены stl для VC2015? STLPort вроде скорее мертв, чем жив.
Ну вот EASTL открыли код, а у них когда-то декларировалось, что даже в отладочной версии контейнеры не должны пессимизировать.

Что они выложили сейчас и в каком это виде (юзабельно ли в качестве drop-in замены STL) — не смотрел.

AS>>Каким образом выделение head ноды на куче улучшает debug диагностику? Например, кинуть исключение в дефолтовом конструкторе — это ведь явно не улучшает?

VTT>Никаким наверное. Я просто подчеркиваю, что дебаг диагностика у студийных контейнеров получше.
VTT>Во всяком случае выделение памяти для одной ноды погоды не делает.

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

Здравствуйте, Andrew S, Вы писали:

AS>2. Доводилось ли до MS что это нехорошая реализация? Если да — тоже просьба кинуться ссылочкой, т.к. в гугле соотв. багу на VC найти не удалось.

Напиши товарищу Stephan T. Lavavej, очень крутой чувак. Пилит STL в Майкрософт, общается с народом.

Здравствуйте, flаt, Вы писали:

F>Здравствуйте, Andrew S, Вы писали:

AS>>3. Есть ли, кроме буста, эффективные замены stl для VC2015? STLPort вроде скорее мертв, чем жив.
F>Ну вот EASTL открыли код, а у них когда-то декларировалось, что даже в отладочной версии контейнеры не должны пессимизировать.

F>Что они выложили сейчас и в каком это виде (юзабельно ли в качестве drop-in замены STL) — не смотрел.

Да, уже тоже смотрел. Непонятно, чем это лучше контейнеров буста — вроде, на первый взгляд, примерно то же.. Но у буста пользователей, я полагаю, на несколько порядков больше.

AS>>2. Доводилось ли до MS что это нехорошая реализация? Если да — тоже просьба кинуться ссылочкой, т.к. в гугле соотв. багу на VC найти не удалось.

Q>Напиши товарищу Stephan T. Lavavej, очень крутой чувак. Пилит STL в Майкрософт, общается с народом.

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

Здравствуйте, Andrew S, Вы писали:

AS>>>2. Доводилось ли до MS что это нехорошая реализация? Если да — тоже просьба кинуться ссылочкой, т.к. в гугле соотв. багу на VC найти не удалось.

Q>>Напиши товарищу Stephan T. Lavavej, очень крутой чувак. Пилит STL в Майкрософт, общается с народом.

AS>Спасибо за наводку. Посмотрим, что сначала ответят официально...

Qbit86 дело говорит, попробуйте спросить на https://www.reddit.com/r/cpp/ пользователь STL отвечает там на вопросы. Возможно, так будет быстрее чем через Connect.

AS>Делает. Конструкции, которые опционально получают данные, неожиданно становятся небесплатными. А уж возможность выкинуть исклюение при дефолтовом конструировании — это вообще неисчерпаемый источник багов. Ну и код это серьезно ухудшает. Для интереса завели багу авторам, посмотрим, что скажут.

У вас что, есть какой-то конкретный пример, когда из-за избыточного выделения памяти в дефолтном конструкторе заметно снижается производительность (и это поддается измерению)?
Миллионы пустых списков или мапов?

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

По мне так толерантность к самоприсваиванию создает куда больше проблем.

ЗЫ Создание ноды в дефолтном конструкторе еще коряво т.к. хранящееся значение никак не инициализируется.
Это вроде как правильно, так как иначе бы контейнер не мог содержать объектов с закрытым дефолтным конструктором.
Но по факту храниние мусора — это безобразие.

VTT>У вас что, есть какой-то конкретный пример, когда из-за избыточного выделения памяти в дефолтном конструкторе заметно снижается производительность (и это поддается измерению)?
Да.
VTT>Миллионы пустых списков или мапов?
Нет.

VTT>Насколько я знаю, ничего не запрещает выкидывать исключения в дефолтных конструкторах контейнеров.
VTT>Так что источником багов является предположение о невозможности их выкидывания.

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

VTT>ЗЫ Создание ноды в дефолтном конструкторе еще коряво т.к. хранящееся значение никак не инициализируется.
VTT>Это вроде как правильно, так как иначе бы контейнер не мог содержать объектов с закрытым дефолтным конструктором.
VTT>Но по факту храниние мусора — это безобразие.

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

Q>>>Напиши товарищу Stephan T. Lavavej, очень крутой чувак. Пилит STL в Майкрософт, общается с народом.

AS>>Спасибо за наводку. Посмотрим, что сначала ответят официально...

PM>Qbit86 дело говорит, попробуйте спросить на https://www.reddit.com/r/cpp/ пользователь STL отвечает там на вопросы. Возможно, так будет быстрее чем через Connect.

Поделюсь с общественностью текущими результатами расследования. Итак, Стефан ответил мне тут.
К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено, единственное, что можно хоть как-то принять — сохранить итератор end после swap-a, что не требуется стандартом. Аргументация пока в целом сводится к "ну вот так было сделано в Dinkumware и я не вижу причин это менять... А, и еще end итераторы после swap".
В общем, нам предлагают смириться и есть то, что положено. И у того, что нам положено, несколько странный вкус: свободно доступные компайлеры имеют адекватные реализации, а весьма платный — нет
PS Надеюсь, кланг под винду докрутят до вменяемого состояния, желательно с нормальным рантаймом и обработкой исключений на таблицах — и можно будет со спокойной душой мувнуться...

Здравствуйте, Andrew S, Вы писали:

Q>>>>Напиши товарищу Stephan T. Lavavej, очень крутой чувак. Пилит STL в Майкрософт, общается с народом.

AS>>>Спасибо за наводку. Посмотрим, что сначала ответят официально...

PM>>Qbit86 дело говорит, попробуйте спросить на https://www.reddit.com/r/cpp/ пользователь STL отвечает там на вопросы. Возможно, так будет быстрее чем через Connect.

AS>Поделюсь с общественностью текущими результатами расследования. Итак, Стефан ответил мне тут.
AS>К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено, единственное, что можно хоть как-то принять — сохранить итератор end после swap-a, что не требуется стандартом. Аргументация пока в целом сводится к "ну вот так было сделано в Dinkumware и я не вижу причин это менять... А, и еще end итераторы после swap".
AS>В общем, нам предлагают смириться и есть то, что положено. И у того, что нам положено, несколько странный вкус: свободно доступные компайлеры имеют адекватные реализации, а весьма платный — нет
AS>PS Надеюсь, кланг под винду докрутят до вменяемого состояния, желательно с нормальным рантаймом и обработкой исключений на таблицах — и можно будет со спокойной душой мувнуться...

Я с ним ругался по этому же поводу, в результате оказалось легче забить. Стёпа — очень умный человек, но очень упёртый. Ему не было аргументом ни поведение _всех остальных_ реализаций, ни примеры кода, которые по-другому практически не переписать. "All I care about is correctness."

Q>>>>>Напиши товарищу Stephan T. Lavavej, очень крутой чувак. Пилит STL в Майкрософт, общается с народом.

AS>>>>Спасибо за наводку. Посмотрим, что сначала ответят официально...

PM>>>Qbit86 дело говорит, попробуйте спросить на https://www.reddit.com/r/cpp/ пользователь STL отвечает там на вопросы. Возможно, так будет быстрее чем через Connect.

AS>>Поделюсь с общественностью текущими результатами расследования. Итак, Стефан ответил мне тут.
AS>>К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено, единственное, что можно хоть как-то принять — сохранить итератор end после swap-a, что не требуется стандартом. Аргументация пока в целом сводится к "ну вот так было сделано в Dinkumware и я не вижу причин это менять... А, и еще end итераторы после swap".
AS>>В общем, нам предлагают смириться и есть то, что положено. И у того, что нам положено, несколько странный вкус: свободно доступные компайлеры имеют адекватные реализации, а весьма платный — нет
AS>>PS Надеюсь, кланг под винду докрутят до вменяемого состояния, желательно с нормальным рантаймом и обработкой исключений на таблицах — и можно будет со спокойной душой мувнуться...

MW>Я с ним ругался по этому же поводу, в результате оказалось легче забить. Стёпа — очень умный человек, но очень упёртый. Ему не было аргументом ни поведение _всех остальных_ реализаций, ни примеры кода, которые по-другому практически не переписать. "All I care about is correctness."

Ну я еще чуточку поупираюсь, по другим каналам. Посмотрим, хотя, конечно, шансы минимальны.
Кстати, можете поделиться своими примерами? Больше не меньше.

Здравствуйте, Andrew S, Вы писали:

AS>К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено
Такой подход позволит увеличить частоту выделений и освобождений памяти, а у VS оно иногда полезно для поиска утечек и расстрела памяти (гарды) через CRT или сторонними средствами. Но согласен, такое стоило по-умолчанию оставлять только в дебаге.

AS>>К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено
V>Такой подход позволит увеличить частоту выделений и освобождений памяти, а у VS оно иногда полезно для поиска утечек и расстрела памяти (гарды) через CRT или сторонними средствами. Но согласен, такое стоило по-умолчанию оставлять только в дебаге.

Предлагаю переместить это в юмор.

Здравствуйте, Andrew S, Вы писали:

AS>>>К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено
V>>Такой подход позволит увеличить частоту выделений и освобождений памяти, а у VS оно иногда полезно для поиска утечек и расстрела памяти (гарды) через CRT или сторонними средствами. Но согласен, такое стоило по-умолчанию оставлять только в дебаге.
AS>Предлагаю переместить это в юмор.
не понял юмора

AS>>>>К сожалению, пока что весомых (на мой взгляд, конечно) аргументов там не приведено
V>>>Такой подход позволит увеличить частоту выделений и освобождений памяти, а у VS оно иногда полезно для поиска утечек и расстрела памяти (гарды) через CRT или сторонними средствами. Но согласен, такое стоило по-умолчанию оставлять только в дебаге.
AS>>Предлагаю переместить это в юмор.
V>не понял юмора

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

Здравствуйте, Andrew S, Вы писали:

V>>>>Такой подход позволит увеличить частоту выделений и освобождений памяти, а у VS оно иногда полезно для поиска утечек и расстрела памяти (гарды) через CRT или сторонними средствами. Но согласен, такое стоило по-умолчанию оставлять только в дебаге.
AS>>>Предлагаю переместить это в юмор.
V>>не понял юмора
AS>Вот и я. Поскольку это похоже на бородатый анекдот про девочку, которая пошла в лес и встретила волка.
Я сам выделения/освобождения памяти вставлял в ассерты и таким образом локализовал место лика, а ты мне про какую-то девочку и волка рассказываешь.