Проклятье процедурного программирования

[spamsink]

В данном случае, об егонный комитет по стандартизации, бессмысленный и беспощадный.

Если формировать объект типа std::string посимвольно, то память будет выделяться и копироваться кусками размером 1, 2, 4, 8 и т.п. символов, что хоть асимптотически и линейно, корысти в этом мало.

Впрочем, партия об этом подумала уже давно, и в классе-шаблоне std::basic_string отродясь есть метод reserve(size_type size) - причем это единственный способ управить размером памяти для каждого объекта каждый раз явно; до введения в шаблон дополнительного параметра min_alloc со значением по умолчанию, равным 1 (и с полезным на нашей практике значением порядка сотни-двух), эти архимеды, начиная то ли со Степанова, то ли со Страуструпа, не дотумкали.

Но ладно уж это! Убило меня то, что этот несчастный метод возвращает void даже в С++11!
Т.е. еще лет 10, чтобы было эффективно, нам придется писать не как людям,
return std::string().reserve(много).assign(нечто).append(кое-что);
а как на фортране полвека назад, с переменнымя. Или изобретать собственные классы-велосипеды.

Ну тупы-ы-ы-ые! И этим людям мы доверяем придумывать языки для heavy industrial usage?

Comments

[fatoff.livejournal.com]

You are so full of wisdom. I personally easily ignore all these imperfections by enjoying other definitely beautiful things in C++ 11 such as move semantics.

[spamsink]

...by enjoying other definitely beautiful things in C++ 11

Я пока только облизываюсь. To the point, these particular imperfections leave an impression of shoddiness.

[spamsink]

И что бы это значило? Какой смысл кастить объект только что из конструктора к тому же типу? Остальное, IMO, вообще за пределами добра, зла и синтаксиса языка.

[ormuz.livejournal.com]

Насколько я помню, в gcc stl строки были вовсе не такие простые, с copy-on-write семантикой и с нетривиальными оптимизациями
в том смысле, что reserve не может вернуть ничего путного, потому как ничего путного и не делает.

[ormuz.livejournal.com]

Посмотрел - зря вы
оно хитрое (_S_create), всегда страничку (4096) заранее аллоцирует - то есть то что вы хотите, вы на самом деле не хотите.

[spamsink]

От любого метода не убудет, если вместо void он вернет *this.

[spamsink]

Что это за реализация? У меня

std::string dotted_pair(const char * a, const char * b) {
        std::string ret;
        return ret.assign(a).append(1, '.').append(b);
}

работает в полтора раза медленнее, чем

std::string dotted_pair1c(const char * a, const char * b) {
        std::string ret;
        ret.reserve(256);
        return ret.assign(a).append(1, '.').append(b);
}

если длины a и b не более 100, в среднем 50.

[ak_47]

Обычно в имплементации std::string используется small string optimization, так что большинство юзеров благодарны уже и так. Далее, изменение готового стринга операция значительно более редкая, чем единоразовое создание стринга, который не меняется за свою жизнь. У вас задача несколько отличается от мейнстримной: во-первых, стринги подлинее будут; во-вторых, часто меняются. Вот для таких и сделали возможность подставить свой аллокатор и вытворять с памятью что угодно. Остальным 99% это всё не надо. И даже если раз в жизни надо, то перформанс ни разу не критичен.

Код вида return std::string().reserve(много).assign(нечто).append(кое-что); пишут далеко не все люди. Я считаю это весьма
некрасивым проявлением джаваизма, который, к сожалению, пролез в другие языки. Произошло это, в основном, благодаря двум факторам: а) понижение квалификации занятых в отрасли и б) появление auto completion в редакторах. Поэтому такую колбасу клепать стало легко и быстро. А в Индии время на код тратить не любят.

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

[spamsink]

Обычно в имплементации std::string используется small string optimization

Обычно - это где? И что такое small? 8 - маловато будет.

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

Откуда это известно?

подставить свой аллокатор и вытворять с памятью что угодно

Не что угодно. У std::allocator нет метода realloc, поэтому он не в состоянии прозрачно реализовать функциональность min_alloc. Если бы такой метод был, я бы им воспользовался.

И даже если раз в жизни надо, то перформанс ни разу не критичен.

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

Я считаю это весьма некрасивым проявлением джаваизма

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

А в Индии время на код тратить не любят.

Да, поэтому пишут спагетти-код из сотни строк с массой переменных, циклов, присваиваний и прочей лабуды, и потом много часов отлаживают off-by-one errors, вместо того, чтобы подумать 5-10 минут и написать полдюжины строк с полным пониманием происходящего, делающих ровно то же самое безошибочно by construction.

[ak_47]

Насколько я знаю, что у мелкомягких, что у ГНУтых, small string optimization это 16 символов. Я не помню уже точно, становятся ли они 16 символами для std::wstring или ужимаются до 8.

Насчёт хорошего кода я никогда не против. Но мне лично конструкции вида a().b().c()...z() читаются плохо. Я люблю разбивать. У С++ есть много косяков и std::basicstring не самый удачный класс в библиотеке. С этим согласен. Но не ужас ужас.

[vaddimka.livejournal.com]

а если слинковать с tcmalloc'ом или jemalloc'ом?

[spamsink]

То разница может уменьшиться, но не исчезнуть, поскольку в случае без reserve() последовательность значений capacity у string останется та же самая, а когда size() = capacity(), и добавляется еще один символ, приходится выполнять дополнительные машинные команды.

[spamsink]

Если small string optimization и была, то тогда, когда объект string был нетривиальный. Сейчас sizeof(string) == 8, т.е. это просто указатель, и всё хранится в пуле одним куском. В этом случае делать small string optimization, конечно, тоже можно, но - судя по последовательности значений capacity при посимвольном добавлении - не делается.

Я люблю разбивать.

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

[vaddimka.livejournal.com]

это понятно, просто любопытно насколько эти аллокаторы сгладят проблему
все равно, каждый раз делать такие микрооптимизации неэффективно
если уж заморачиваться, то со статическими буферами в thread local storage (все равно строка будет скопирована по возвращению)

[spamsink]

все равно строка будет скопирована по возвращению

В refcounted реализации - вовсе нет.

[lider.livejournal.com]

" для heavy industrial usage"

И пусть никоґда ґлаз не устанет смотреть на чужую тяжелую работу!!!

[spamsink]

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

[ormuz.livejournal.com]

действительно, странно.
Впрочем,

std::string dotted_pair2(char *a,char *b) {
  static char *t = new char[256];
  string s(t,256);
  return s.assign(a).append(1,'.').append(b);
};

не тормозит.

[spamsink]

Зачем такие мучения? Можно было проще: string s(256); но это отличается от просто reserve тем, что расписывает память нулями, а мне эта лишняя работа не нужна.

[ak_47]

У меня сейчас под рукой нет ГНУ посмотреть что там со стрингом. Но в Студии (т.е. от Dinkumware) стринг начиная как минимум с 2008 и по сей день имплементирует small string optimization. И размер стринга, соответственно, больше 8. Я сейчас проверил: релиз - 24, дебаг - 28 (для 32-бит кода). Для 64-бит билда: релиз - 32, дебаг - 40.

Трюк там в том что в стринге юнион, который хранит либо поинтер на буфер, либо массив на стеке до 16 элементов (включая '\0'). Я не знаю почему выбрали именно 16. Наверное достаточное количество стрингов попадает в этот интервал и оверхед не слишком значительный.

Насчёт того откуда известно что стринги редко меняются. Это anecdotal evidence из личного опыта. Какой-либо статистики на руках нет. Хотелось бы, конечно, увидеть менее голословные свидетельства. :)

[spamsink]

Я сейчас проверил: релиз - 24, дебаг - 28 (для 32-бит кода). Для 64-бит билда: релиз - 32, дебаг - 40.

Во времена оны в GNU было что-то похожее, и пользоваться стрингом было положительно невозможно. А сейчас, когда sizeof(string) == sizeof(void*), оно летает наравне с доморощенным решением.

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

[ak_47]

Если не секрет, то почему такие мучения от стринга больше чем sizeof(void*)?

[spamsink]

Потому что крупные объекты передаются по значению и возвращаются из функций гораздо менее эффективно, чем мелкие.

[ak_47]

Да, сурово у вас там. Обычно же всякие NRVO/RVO начинают применяться компилятором. Хотя, конечно, тоже будет оверхед.

Насчёт sizeof(string) == sizeof(void*), я доберусь до кода, посмотрю что там они сделали. Есть предположение что там хитрый финт ушами и на самом деле данных больше. Но это всё хозяйство упрятали именно для того, чтобы стринг в регистр помещался.

[fatoff.livejournal.com]

> Я считаю это весьма некрасивым проявлением джаваизма

На Java писал довольно мало, но, IMHO, в данном конкретном случае проявлением джавизма было бы использование StringBuilder. А это для конкатенаций и массовых перемещений символов как раз таки правильный подход, который STL неплохо бы перенять.

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

[http://users.livejournal.com/_navi_/]

Если ты такой у-у-умный, то почему памятник Пушкину ты до сих пор не в комитете? (Я на самом деле только наполовину шучу, я очень согласен с твоими взглядами на C++ :-) )

[spamsink]

Кто б меня туда взял?

Что-то я гуглением полного списка живых людей-членов комитета не найду, а из first-billed никого лично не знаю. Может, в полном списке кто из моих знакомых есть и лоббирования хватит?

[http://users.livejournal.com/_navi_/]

Я с год назад задавался вопросом, как в такие комитеты люди попадают (в контексте разговора про комитет по C++). Как мне объяснили люди не знакомые с вопросом напрямую (но вроде знакомые косвенно), было бы желание. Меня правда интересовало немного другое: откуда берётся в таких комитетах «юная кровь», и как поддерживается средний возраст: порог вхождения туда, по-моему, очень высок.

[e2pii1.livejournal.com]

<<
до введения в шаблон дополнительного параметра min_alloc со значением по умолчанию, равным 1 (и с полезным на нашей практике значением порядка сотни-двух), эти архимеды, начиная то ли со Степанова, то ли со Страуструпа, не дотумкали
>>

Это они сознательно не сделали: цель стандартной библиотеки - минимально-достаточная базовая функциональность, а не "все что угодно что может кому-то понадобиться". Это Страуструп в своей книге объясняет (и это смысленно чтоб библиотека имела обозримый размер). Делайте свой класс полезный в вашей практике.

А с reserve() возвращающим ссылку на объект Вы совершенно правы, это бы им стоило сделать.

[spamsink]

Делайте свой класс полезный в вашей практике.

Т.е. буквально "копируйте существующее стандартное решение и добавляйте к нему две строки, потому что кто-то когда-то решил быть чистоплюем". Это я считаю свинством.

[e2pii1.livejournal.com]

Но ведь многим не нужен этот "параметр min_alloc". И им изучая документацию придется затратить своё время на лишнюю для них статью. Не факт что ваша выгода от этой доп.функциональности перевесит эти совокупные потери времени.

[spamsink]

Многим не нужен и аллокатор, но он там есть. Добавить этот параметр к аллокатору - невелика потеря времени.

[e2pii1.livejournal.com]

аллокатор необходимая базовая функциональность, тем кому он нужен без него не обойтись легким написанием своего класса-надстройки

[spamsink]

Для добавления функциональности min_alloc легким написанием надстройки тоже не обойтись - нужно писать прокси-метод для каждого неконстантного метода исходного контейнера.

[e2pii1.livejournal.com]

Почему ?
Сделать свой класс derived from STL container и определить у него используемые вами конструкторы containerа с телом { reserve(min_alloc); }

[spamsink]

Это не будет корректно отражать желаемую функциональность.

std::string foo;
if (condition) foo.append(x).append(y).append(z);
return foo;

Если condition = false, foo.capacity() должна оставаться нулем.

[e2pii1.livejournal.com]

тогда наверно свой аллокатор придется делать (derived из STL аллокатора)

[spamsink]

В том-то и дело, что с существующим интерфейсом аллокатора это не поможет. Сейчас аллокатор не в состоянии ничего сообщить контейнеру относительно своей гранулярности. Если бы у аллокатора был метод realloc, то написанием собственного аллокатора проблема бы решалась (с некоторой не очень существенной потерей эффективности), но его нет.

[e2pii1.livejournal.com]

Да, вызовов mem_alloc()/new для 1,2,4,8... вероятно можно избежать захватив в своем allocator::allocate() минимум N и потом возвращая тот же буфер если просят allocate меньше N. Но перекопирований строки STL контейнером при росте через 2^k тaк не избежать.

[spamsink]

потом возвращая тот же буфер если просят allocate меньше N

Нет у аллокатора такого права.

[e2pii1.livejournal.com]

захватить 2^n+2^(n+1) и возвращать тo buf, тo buf+2^n

[spamsink]

allocator::allocate не в состоянии определить, с какой целью его вызывают. Во-первых, ненулевой хинт никто не обещает; во-вторых, нигде не сказано, что ненулевой хинт имеет какое-то отношение к realloc. Сказано лишь When it is not 0, this value may be used as a hint to improve performance by allocating the new block near the one specified.

[e2pii1.livejournal.com]

allocator::allocate(1) захватывает буфер длины 127 и запоминает его в allocator-объекте.
allocator::allocate(2^k, 0<k<7) возвращает буфер+(2^k)-1

[e2pii1.livejournal.com]

Можно просто сделать аллокатор оптимизированный под захват кусков размера 1,2,4,8... - захватывать сразу большие буфера для каждого из размеров и держать там список свободных блоков. Тогда каждый allocate() будет проходить за малую константу времени.
Если стандартный аллокатор уже так не реализован.

[spamsink]

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