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

Pzz>>Не знаю. Но правда очень медленно.

M>Ну, может быть из-за того, что в языках со сборщиком мусора в тот момент ничего не освобождается, а откладывается на неопределенный момент? Это намного лучше?

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

Я вообще не понимаю, почему у gcc такой тормозной аллокатор (у MSVC впрочем, говорят, еще хуже). Может никто особо не парился сделать его быстрым, считая, что в том нет особой нужды.

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

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

_>В C++ издавна есть зачаточные элементы статической интроспекции: оператор typeid. Т.е. уже давно мы можем без проблем получить на этапе компиляции информацию о любом типе. Однако для полноценной интроспекции в C++ как минимум нет возможности перечислить все члены класса/структуры. Что не позволяет сделать например универсальный сериализатор для произвольных объектов и ещё множество нужных вещей. Сейчас все эти вещи делают или каждый раз руками или через дикие метапрограммные костыли из Boost'а, которые надо ещё подключать на этапе создания каждого сериализуемого типа.

Ну вот перечислил ты. Нашел там поле типа std::string. Как ты его будешь в JSON превращать? Внутрь пойдешь итерировать, или заведешь у себя перечень стандартных типов? А если там будет не std::string, а строка из Qt, не помню, как она называется, с ней чего делать?

_>Полноценную реализацию статической интроспекции можно увидеть в языке D. Там без проблем можно написать например универсальную библиотечную функцию to_json(T t), которой можно передать скажем экземпляр пользовательского тип struct User {string name; int age}; и получить нормальный результат.

В D, поди, string — это примитивный тип, встроенный в язык, и никому в голову не придет написать десяток реализаций строк на темплейтах.

Pzz>>Ну т.е., к примеру, про std::string я, положим, могу и знать. А если там какая-нибудь Qt'ная строка, и еще какая-нибудь самодельная?

_>Строка Qt, если что, без проблем конвертируется в std::string. Хотя это к теме статической интроспекции никакого отношения не имеет. Это уже банальные рантаймовые дела.

Конвертится, конечно. Только откуда твой JSON'овый сериализатор знает, как ее туда конвертить?

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

Pzz>>>Когда ты размещаешь std::string на стеке, буфер-то еёйный все равно размещается в куче.
_>>Нет, не в куче. Ознакомься с такой темой как SSO в C++.
Pzz>Ну, это очевидная оптимизация, но как-то немного унылая.

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

Pzz>Много чего во внутренний буфер не влезет, и во всех строках с внешним буфером, внутренний буфер будет просто выброшенной памятью.

Так мы вообще то и говорили о случае множестве мелких короткоживущих данных. )

Но в целом да, упоминание SSO было небольшим лукавством (ну трудно удержаться, когда с тобой спорят люди, плохо представляющие себе предмет спора), т.к. подобная оптимизация очевидно есть не у всех сущностей. Однако для глобального решения этой проблемы в C++ давным давно есть универсальное решение, обходящее по производительности любые сборщики мусора и т.п. И я даже уже подробно говорил о нём, прямо в этой темке. Это кастомный аллокаторы (которые поддерживаются всеми нужными контейнерами STL), специализированные под конкретную задачу. Причём их не обязательно писать самому, а можно взять например из Boost'а или других подобных библиотек.

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

_>>Кэш как раз страдает в случае виртуальных функций (или просто указателей на функции, в случае языка C), потому как предсказатель плохо работает. А в случае линейного массива (что кода, что данных), всё гарантированно будет в кэше.
Pzz>Этот кэш, он маленьний. Даже на пентиуме маленький, а на арме совсем маленький.
Pzz>Ошибка предсказателя всего лишь отправляет в /dev/null результат нескольких спекулятивно вычисленных инструкций, а промах кэша вызывает обращение к памяти, а она медленная, зараза.

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

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

lpd>Современный С++ же код значительно усложняет, особенно мув-семантика, умные указатели(по сравнению с GC)
Шта?

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

lpd>"Лично мне С++17 абсолютно не нравится, по сравнению с С++98" — убедительный довод?
На С++17 можно писать точно такой же код как на С++98

Здравствуйте, kaa.python, Вы писали:

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

KP> И ты понимаешь, что используя C++ ты его ну никак не сделаешь.
Верно. Этот инструмент позволяет многое но требует понимания инструмента.
Но это не делает инструмент плохим.

KP> Вот вообще, никак, а с индусоустойчивым инструментом ты завершить продукт в срок и с ожидаемым качеством.
Особенно хорошо тут про ожидаемое качество, да.
Я видел результаты вот такого вот "в срок" на индусоустойчивом С#. Формально продукт был успешно завершён, а по факту весь проект отдали другим людям на полную переделку.

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

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

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


M>>Ну, может быть из-за того, что в языках со сборщиком мусора в тот момент ничего не освобождается, а откладывается на неопределенный момент? Это намного лучше?

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

Ага, и GC выжрет всю доступную память. Или — поймает низкую загрузку, начнёт гарбажить, а тут — опа — сервис снова понадобился, но нет, сорян, подождите, у нас тут мусор собирают


Pzz>у короткоживущей может и вовсе не дойти до освобождения, программа раньше завершится.

Вот поверишь, или нет, я тут как-то налабал кой-какой ДСЛ, там только работа со строками практически и используется. Ну, еще вектора строк, мапы строк, сеты строк, строк и структур классов, содержащих в т.ч. строки. Я точно не успеваю заметить, 0.3 секунды она отрабатывает, или 0.4. И мне на это наплевать. Потратил я месяца полтора, попутно отлаживая девайс и выхлоп этого генератора, который предназначен для девайса. На сишечке — я бы год писал бы, но так и не смог бы сделать стабильную программу. Другой язык — сомневаюсь, что за месяц смог бы что-то изучить так хорошо, чтобы написать такую тулзу на новом языке. В принципе, я еще на питоне пописывал, и на первой неделе разработки я еще сомневался, не стоило ли его взять. Но в дальнейшем я пришел к выводу, что выбор я таки сделал верный. По той простой причине, у питона после некоторого базового слоя работы со строками, который встроен в него, и который я накидал (пусть и не эффективно) за пару-тройку дней, преимущества как-то заканчиваются, а покрыть всё то, что мне плюсовый компилер сам находил и выдавал ошибки компиляции — тестами, которые тестировали бы динамический питоновский код — я бы упарился, и всё равно на выходе была бы тулза, которая регулярно бы вылетала и требовала правки. А сейчас я год уже живу с рабочим годным инструментом, изредка впиливая туда какую-нибудь новую фичу

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

_>>Т.е. если просто перекомпилировать код с C++98 на C++11, то он может стать гораздо эффективнее. Однако это увеличение гораздо менее важно, чем то, что принесла семантика перемещения в архитектурном плане.
lpd>Все-таки "гораздо эффективнее" это уменьшение отклика на 1%? а то и на 0.5%.

Какая разница насколько, если это было "на халяву" для программиста? )))

lpd>Насчет архитектурной роли перемещения ок. Я вообщем не спорю что это фича в теории интересная, но реальная польза только в искуственных hello-wordах.

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

_>>Ну ОК, давай напиши сущность с функциональностью unique_ptr, используя любые возможности C++98 (собственно можно хоть C++20 взять без семантики перемещения и это ничего не изменит).
lpd>И зачем мне такая радость как unique_ptr<>? Если не брать "hello world"ы, то в сколько-нибудь сложных программах владение памятью и ресурсами им часто не описывается. Проблемы кодеров не в том чтобы не забыть delete, а чтобы учесть редкие и не протестированные ветки исполнения кода(особенно при ошибках), возможные рейсы. Вот от подсчета ссылок польза бывает, но и для этого удобнее GC в большинстве случаев.

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

_>>Дело не в быстродействие, а в удобстве. На кой нужны все эти интерфейсы и прочая ересь, если при статическом полиморфизме компилятор всё равно всё проверит и даже более строго, чем с виртуальными функциями.
lpd>Это уже религиозный вопрос. Через 20 лет все окончательно забудут про С++, но и тогда фанатики будут кучковаться, городить лес из скобочек и разруливать все статически.

Вообще то язык Rust (единственный в данный момент реальный претендент на нишу C++) ещё более жёсткий в этом смысле.

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

_>>В C++ издавна есть зачаточные элементы статической интроспекции: оператор typeid. Т.е. уже давно мы можем без проблем получить на этапе компиляции информацию о любом типе. Однако для полноценной интроспекции в C++ как минимум нет возможности перечислить все члены класса/структуры. Что не позволяет сделать например универсальный сериализатор для произвольных объектов и ещё множество нужных вещей. Сейчас все эти вещи делают или каждый раз руками или через дикие метапрограммные костыли из Boost'а, которые надо ещё подключать на этапе создания каждого сериализуемого типа.
Pzz>Ну вот перечислил ты. Нашел там поле типа std::string. Как ты его будешь в JSON превращать? Внутрь пойдешь итерировать, или заведешь у себя перечень стандартных типов? А если там будет не std::string, а строка из Qt, не помню, как она называется, с ней чего делать?

Нуу ознакомься ещё и с этим https://en.cppreference.com/w/cpp/string/basic_string/to_string. И естественно тебе никто не мешает перегрузить эту функцию для любого числа своих типов.

_>>Строка Qt, если что, без проблем конвертируется в std::string. Хотя это к теме статической интроспекции никакого отношения не имеет. Это уже банальные рантаймовые дела.
Pzz>Конвертится, конечно. Только откуда твой JSON'овый сериализатор знает, как ее туда конвертить?

Если не будет нужной перегрузки (и при этом мы считаем это элементарным json типом, а не объектом/массивом), то естественно будет ошибка. Причём не в рантайме, а ошибка компиляции! Которую ты можешь элементарно исправить, добавив нужную перегрузку.

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

Pzz>Дело не в ненужных скрытых полях. Они и так, кстати, есть. Когда аллоцируешь объект с кучи, где-то там перед ним есть невидимая информация, необходимая для организации кучи (ссылки на предыдущий/следующий занятый кусок памяти, размер куска памяти и т.п.). Там же и нашлось бы место для сборщика мусора.

Эээ, во-первых, существует множество всяких аллокаторов, которые хранят информацию очень по разному. Во-вторых, 99% всех аллокаций в программах имеют размеры до 256 байт, а то и до 128, поэтому, те кто заморачиваются вопросом, подключают аллокаторы-пулы маленьких объектов, которым ничего дополнительного хранить не нужно, и кстати, строки при этом становятся практически бесплатными. В-третьих, я тут лет 10 назад заморочался и родил простой честный GC для С++ (ещё старого) и уже тогда понял, что 1. это уже боян, 2. это не нужно, т.к. правила по избежанию утечек в С++ ненамного сложнее, чем в языках с GC.

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

CC>Там банально давно уже просто вызывается системный HeapAlloc
CC>Думаю у гнуса то же самое.
CC>Никто давно не пишет какой то кастомный аллокатор для рантайма — юзают платформенный.

В линухе stdlib'овский malloc и есть платформенный.

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

Pzz>>у короткоживущей может и вовсе не дойти до освобождения, программа раньше завершится.

M>Вот поверишь, или нет, я тут как-то налабал кой-какой ДСЛ, там только работа со строками практически и используется. Ну, еще вектора строк, мапы строк, сеты строк, строк и структур классов, содержащих в т.ч. строки. Я точно не успеваю заметить, 0.3 секунды она отрабатывает, или 0.4. И мне на это наплевать.

И я вот как-то примерно в этом духе написал програмку. Так вот, она, зараза, 10 секунд отрабатывала. А когда я тупо задавил освобождение строк, стала укладываться в полсекунды. 10 секунд как-то несколько раздражает, когда програмку зовут из Makefile.

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

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

_>Нуу ознакомься ещё и с этим https://en.cppreference.com/w/cpp/string/basic_string/to_string. И естественно тебе никто не мешает перегрузить эту функцию для любого числа своих типов.

Угу. А потом выясняется, что to_string нужен один для JSON, другой для XML, третий для ASN.1, и все они разные.

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

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

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

M>Ага, и GC выжрет всю доступную память.

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

M>Или — поймает низкую загрузку, начнёт гарбажить, а тут — опа — сервис снова понадобился, но нет, сорян, подождите, у нас тут мусор собирают

Знаешь, чем протоколы, придуманные телефонистами, отличаются от протоколов, которые используются в интернете? Телефонисты всегда резервируют ресурсы с гарантией, в рассчете на самый плохой сценарий. А интернетчики, оптимисты, считают, что если рассчитывать на некий средний случай с небольшим запасом, то и так сойдет.

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

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

lpd>Это уже религиозный вопрос. Через 20 лет все окончательно забудут про С++, но и тогда фанатики будут кучковаться, городить лес из скобочек и разруливать все статически.

Не, не забудут. Про фортран-то с коболом еще до конца не забыли.

Но зато через 20 лет никого не будут удивлять проекты, в которых по 10 языков в одном проекте понамешано. И чистый C очень надолго останется с нами, как язык, функцию на котором можно позвать из любого другого языка.

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

Pzz>Но зато через 20 лет никого не будут удивлять проекты, в которых по 10 языков в одном проекте понамешано.

10 и сейчас не особо удивляет.


Pzz>И чистый C очень надолго останется с нами, как язык, функцию на котором можно позвать из любого другого языка.
Не С, а С API. Оно не удивляет, да.

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


Pzz>И я вот как-то примерно в этом духе написал програмку. Так вот, она, зараза, 10 секунд отрабатывала. А когда я тупо задавил освобождение строк, стала укладываться в полсекунды. 10 секунд как-то несколько раздражает, когда програмку зовут из Makefile.

Pzz>Кстати, аналог этой програмки, написанный на перле, отрабатывал за те же полсекунды, безо всякой нужды отламывать перловый аллокатор.

Как-то ты неправильно строки готовишь. У меня 700Кб кода работает со строками очень быстро. Да, тоже из мейкфайлапроекта вызывается раз по 5-10. Секунды три на всё про всё. И как я понимаю, основное время тратится на запуск процесса

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

Pzz>>Кстати, аналог этой програмки, написанный на перле, отрабатывал за те же полсекунды, безо всякой нужды отламывать перловый аллокатор.

M>Как-то ты неправильно строки готовишь. У меня 700Кб кода работает со строками очень быстро. Да, тоже из мейкфайлапроекта вызывается раз по 5-10. Секунды три на всё про всё. И как я понимаю, основное время тратится на запуск процесса

Там входной файл очень большой.