Бенч конкатенации подразумевал добавление 1 символа 100000 раз в цикле. C++ и SDS тащат за счет геометрического роста capacity, а у меня malloc() на каждое расширение. Даже в документации напрямую указано, что так делать нельзя, надо делать одну точечную и большую.
std::string тоже позволяет сделать reserve(size), а вас альтернативы как бы нет.
Хотелось бы комментария, чем обосновано ваше решение. Потому, что я вижу тут следующее: - предположим мы на 64 битной системе, форма хранения числе - LE - sso_len ложится на capacity, причём это последний байт всей структуры - последний байт всей структуры - самый младший байт capacity - флаг 0x80 = 128, т.е. если мы выделим 128 байт под буфер для длинной строки (или любое другое число байт где нужный бит будет установлен в 1), мы спутаем её с короткой?
исходя из вашей же табличке сравнения я не могу сделать такого же вывода - хеш вы считаете неправильно, в отличии от std::string - в операции конкатенации проигрываете на три порядка - исходников бенча для std::string не видно
А как вы различаете SSO строки от длинных в вашей структуре? Хеш от указателя считать такое себе. Т.е. две одинаковые строки будут иметь разный хеш? Поведение, мягко говоря, нестандартное. Цифры бенча на гихабе конечно интересные, в операции сложения вы проиграли std::string на три порядка, а это, мне кажется, наиболее частая операция над строками.
Реализация проверок осуществляется во время компиляции. Пока таблица собирается целиком и проверяется на пропущенные пары при запуске, тоже перед main.
Взаимоисключающие утверждения.
В планах перенести сборку таблицы в свой компоновщик.
Больше похоже на правду. Мне вот сложно представить полноценную проверку на этапе компиляции с раздельной компиляцией. В статье мало технических деталей как это устроено внутри и для чего нужен аж целый компилятор для этого, если это может быть реализовано в C++ библиотеке.
Всё это, конечно, делается и на голом C++: unordered_map с ключом из пары type_index и методами для регистрации. Локализация правок будет та же. Только компилятор не будет проверять покрытие всех пар, конкретные типы придётся привести к базовому и в каждом обработчике кастовать обратно вручную — компилятор эти касты также не проверяет. В ППП за этим следит компилятор.
На C++ можно тоже через таблицу реализовать, а с шаблонами не надо в обработчиках ничего кастовать. Проверить таблицу можно во время запуска приложения (перед main), например. А как в вашем ППП-компиляторе реализована проверка?
Ваш барьер не поможет! Представьте, что поток прочитал флаг и увидел false, далее он хочет заснуть на cv, но в это время другой поток ставит флаг в true и вызывает notify, вот только первый поток не успел встать в очередь cv и пропустит этот notify.
Использовать wait без придиката можно, а вот менять состояние без блока нельзя. Баг именно в этом. Это грозит тем, что потоки ожидающие флага forceExitFromWaiting никогда не проснутся, хотя флаг = true.
Вы не поняли как работают условные переменные. Ваш метод releaseThreadsWaitingItems содержит баг - нельзя менять состояние которое синхронизируется через CV без блока мьютекса. Использовать атомарную переменную бессмысленно.
Я глубоко в ваш код не копал, но выглядит так, что можно из строкового выражения сделать диапозон с input_iterator (генерировать значения на лету для случая преобразователей чисел в строки или ленивых генераторов). Так получится полная совместимость с C++20 ranges и всеми её плюшками. Ну и то что я озвучил выше, на этой основе можно реализовать.
Ещё можно развить идею и не конкатенировать строковое выражение в одну строку а, например, записывать выражение в файл, или дать возможность итерации по такой "строке".
Нет, не перепутаны. Автор пишет про 20 кратное замедление на пустых тасках. Замечание, впрочем, было не про это. Я же говорю про то, что автор заявляет одно, а собирает метрики про совсем другое. Да, измерить производительность тоже интересно, но куда более важно получить метрики про то, для чего это все затевалось.
Вы написали, что преимущество вашего решения это гарантия времени выполнения и предсказуемость, а измерили пропускную способность где полностью проиграли более общему решению.
std::string тоже позволяет сделать reserve(size), а вас альтернативы как бы нет.
Хотелось бы комментария, чем обосновано ваше решение.
Потому, что я вижу тут следующее:
- предположим мы на 64 битной системе, форма хранения числе - LE
- sso_len ложится на capacity, причём это последний байт всей структуры
- последний байт всей структуры - самый младший байт capacity
- флаг 0x80 = 128, т.е. если мы выделим 128 байт под буфер для длинной строки (или любое другое число байт где нужный бит будет установлен в 1), мы спутаем её с короткой?
исходя из вашей же табличке сравнения я не могу сделать такого же вывода
- хеш вы считаете неправильно, в отличии от std::string
- в операции конкатенации проигрываете на три порядка
- исходников бенча для std::string не видно
А как вы различаете SSO строки от длинных в вашей структуре?
Хеш от указателя считать такое себе. Т.е. две одинаковые строки будут иметь разный хеш? Поведение, мягко говоря, нестандартное.
Цифры бенча на гихабе конечно интересные, в операции сложения вы проиграли std::string на три порядка, а это, мне кажется, наиболее частая операция над строками.
Взаимоисключающие утверждения.
Больше похоже на правду. Мне вот сложно представить полноценную проверку на этапе компиляции с раздельной компиляцией.
В статье мало технических деталей как это устроено внутри и для чего нужен аж целый компилятор для этого, если это может быть реализовано в C++ библиотеке.
На C++ можно тоже через таблицу реализовать, а с шаблонами не надо в обработчиках ничего кастовать. Проверить таблицу можно во время запуска приложения (перед main), например. А как в вашем ППП-компиляторе реализована проверка?
Ваш барьер не поможет! Представьте, что поток прочитал флаг и увидел false, далее он хочет заснуть на cv, но в это время другой поток ставит флаг в true и вызывает notify, вот только первый поток не успел встать в очередь cv и пропустит этот notify.
При чем тут это?
Использовать wait без придиката можно, а вот менять состояние без блока нельзя. Баг именно в этом. Это грозит тем, что потоки ожидающие флага forceExitFromWaiting никогда не проснутся, хотя флаг = true.
Вы не поняли как работают условные переменные. Ваш метод releaseThreadsWaitingItems содержит баг - нельзя менять состояние которое синхронизируется через CV без блока мьютекса. Использовать атомарную переменную бессмысленно.
Потому что в ином случае все выражение не имеет никакого смысла, оно невалидно, ерунда, чушь, как ещё объяснить - я не знаю.
Что вы мне хотите этим сказать?
Уверенность в том, что X не равен нулю нам даёт тот факт, что X находится в знаменателе. Иначе все выражение не имеет смысла.
Встречались, только при чем тут они?
Что? Если в знаменателе стоит x то он не может быть нулем, следовательно мы всегда можем сокращать на x. Иначе, все выражение не имеет смысла.
Я глубоко в ваш код не копал, но выглядит так, что можно из строкового выражения сделать диапозон с input_iterator (генерировать значения на лету для случая преобразователей чисел в строки или ленивых генераторов). Так получится полная совместимость с C++20 ranges и всеми её плюшками. Ну и то что я озвучил выше, на этой основе можно реализовать.
Ещё можно развить идею и не конкатенировать строковое выражение в одну строку а, например, записывать выражение в файл, или дать возможность итерации по такой "строке".
Поясните, как смещение не будет инвалидировано если удалить элемент расположенный в середине плоского контейнера?
Нет, не перепутаны. Автор пишет про 20 кратное замедление на пустых тасках. Замечание, впрочем, было не про это. Я же говорю про то, что автор заявляет одно, а собирает метрики про совсем другое. Да, измерить производительность тоже интересно, но куда более важно получить метрики про то, для чего это все затевалось.
Вы написали, что преимущество вашего решения это гарантия времени выполнения и предсказуемость, а измерили пропускную способность где полностью проиграли более общему решению.