Здравствуйте, rg45, Вы писали:
R>Я, не мудрствуя лукаво, добавил функцию, которая выводит в конце минимальный и максимальный интервалы между буферами соседних элементов входной последовательности. И вот, выходит, что не используется SSO, строки здорово разбросаны по памяти...
Я уже не помню, но по-моему обычно строка имеет три size_t внутри, два из которых используется под SSO. Получается 2х8 = 16 сhar-ов или 8 wchar-ов (2-х байтных). Еще один камень в огород UTF-8
Здравствуйте, Videoman, Вы писали:
V>Я уже не помню, но по-моему обычно строка имеет три size_t внутри, два из которых используется под SSO. Получается 2х8 = 16 сhar-ов или 8 wchar-ов (2-х байтных). Еще один камень в огород UTF-8
V>Я уже не помню, но по-моему обычно строка имеет три size_t внутри, два из которых используется под SSO. Получается 2х8 = 16 сhar-ов
Можно упихнуть 24, если эксплоатировать то, что младший бит указателя не может быть единицей, но тогда operator[] получается тормозным.
Не помню, которая из реализаций такое использует.
Здравствуйте, Codealot, Вы писали:
C>Чтобы сложить символы в массив, никакой unsafe не нужен. Да и сам по себе он не более черный, чем указатели в C++, которые чуть менее чем везде.
Без unsafe каждое обращение к этому массиву будет существенно медленнее C++. В интенсивных алгоритмах это будет заметно. Примеры приводить честно лень.
Здравствуйте, σ, Вы писали:
σ>В который ассемблер смотрел? Все проверяют только один раз https://godbolt.org/z/jKvjjbbM8
MSVC. Clang, как раз, знаменит подобными высокоуровневыми оптимизациями за счет более человекочитаемой организации собственных исходников, куда подобное проще добавлять.
Но я сильно на глаз — вставил __debugbreak() в начале/конце функции и прошагал один раз в отладчике. Константу '0' увидел дважды, на что интуиция сказала, что код можно упростить.
Здравствуйте, rg45, Вы писали:
R>Да-да, трюк известный! Я его применял еще на заре своей деятельности как программиста. Но, помнится, как-то раз мне за такое надавали линейкой по рукам и сказали, что "битхаки нам тут не нужны". Мол, современные оптимизаторы (Visual Studio 5.0 ) и сами умеют выполнять такие преобразования, поэтому текст программы должен быть ориентирован на человека, в первую очередь. Можно сказать, травма детства
Ну в продакшне я бы такое тоже писать не стал. В реальном коде большинство тормозов из-за того, что набросанные на коленке алгоритмы с полиноминальной сложностью применяются там, где никто не ожидал более десятка элементов. Замена их на хорошие логарифмические дает такой прирост, что мама не горюй. А этот фокус рано или поздно кто-нибудь скопирует бездумно в signed-тип и получит баг на ровном месте.
R>Ну и соображение вдогонку: этот же самый финт можно проделать и в примере на C#. Так что, думаю, что это не та оптимизация, которая способна изменить баланс сил.
Не, это просто для примера, раз уж мы надрачиваем бенчмарки. Практической ценности тут мало, чисто побрюзжать седым ветеранам
Re[7]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rudzuk, Вы писали:
R>Не, вердикт тут другой: возьмутся два программиста решать задачу типичными средствами своего языка... Сисиплюсник потом долго будет пытаться "догнат и перегнат", а дотнетчик будет в Rise of Nations играть
Не, погромист со стажем осилит COM-like интероп (PInvoke+IUnknown без собственно COM) и будет делить код на числодробительное ядро на плюсах, и хорошо поддерживаемую логику на C#. После чего выпустит релиз и улетит на Гавайи
Re[8]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Quebecois, Вы писали:
C>>Чтобы сложить символы в массив, никакой unsafe не нужен. Да и сам по себе он не более черный, чем указатели в C++, которые чуть менее чем везде. Q>Без unsafe каждое обращение к этому массиву будет существенно медленнее C++. В интенсивных алгоритмах это будет заметно. Примеры приводить честно лень.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, Quebecois, Вы писали:
Q>>
Q>> for (auto d : wstr)
Q>> {
Q>> uint32_t number = (uint32_t)d - (uint32_t)'0';
Q>> if (number <= 9)
Q>> {
Q>> res = res * 10 + number;
Q>> }
Q>> else
Q>> {
Q>> throw std::out_of_range("'" + std::to_string(d) + "': Symbol is out of range");
Q>> }
Q>> }
Q>>
R>Да-да, трюк известный! Я его применял еще на заре своей деятельности как программиста. Но, помнится, как-то раз мне за такое надавали линейкой по рукам и сказали, что "битхаки нам тут не нужны".
Здравствуйте, Marty, Вы писали:
M>А можно ткнуть пальцем, где тут битхаки?
Преобразование отрицательной разности, получившейся при вычитании большего, числа из меньшего, в БОЛЬШОЕ положительное число. На самом деле, здесь даже и преобразований могло бы и не быть — просто интерпретация одного и того же набора бит, как числа со знаком и без. Ну, простой пример: вычитаем 2 из 1 и получаем четыре миллиарда.
Здравствуйте, σ, Вы писали:
σ> Так это при чтении в двухбайтовые сисярпые строки как раз приходится перекодировать, ведь 99.999% исходных данных это UTF-8 (JSON/XML/HTML…)
В сисиплюсах тоже придется всю эту вашу utf-8 по байтикам разбирать, ибо необходимость валидировать входные данные никто не отменял.
Здравствуйте, rg45, Вы писали:
M>>А можно ткнуть пальцем, где тут битхаки?
R>Преобразование отрицательной разности, получившейся при вычитании большего, числа из меньшего, в БОЛЬШОЕ положительное число. На самом деле, здесь даже и преобразований могло бы и не быть — просто интерпретация одного и того же набора бит, как числа со знаком и без. Ну, простой пример: вычитаем 2 из 1 и получаем два миллиарда.
А, увидел. Экономит одно условие по сравнению со знаковым number, так?
Я хз, по мне так норм Видимо, не попался мне человек с линейкой. Хотя, весьма вероятно, на новом месте быть мне нещадно битым
Здравствуйте, Marty, Вы писали:
M>А, увидел. Экономит одно условие по сравнению со знаковым number, так?
Так точно.
M>Я хз, по мне так норм Видимо, не попался мне человек с линейкой. Хотя, весьма вероятно, на новом месте быть мне нещадно битым
Ну, логика в этом есть. Здесь вот коллега приводил уже ассемблерный листинг, по которому видно, что современные компиляторы без труда выполняют такую оптимизацию, поэтому помогать им смысла мало, а лучше сосредоточиться на простоте и понятности кода.
--
Re[18]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали: R>Я говорил про последнюю, которая идет с 2022-й студией. Устанавливать все фреймворки, только для того, чтоб еще раз посмотреть, как шарп сольет, я не собираюсь, разумеется. Как и угадывать твои мысли.
c 2022 как минимум 3.1 core должна идти, если мне память не изменяет, или даже 5.0. А 6.0, по идее, должна была долететь с апдейтами.