LINUX.ORG.RU

Вычисление количества символов в строке

 


0

5

Задача: Без каких-либо циклов необходимо определить длину строкового представления беззнакового целого

С++11 x86_64, решение закрытое, затачивается под конкретное железо, переносимость не нужна

Пример:

1234567 -> «1234567» num_chars = 7

Текущее решение:

num_chars = log10(x) + 1;

Что не устраивает:

70 процентов латенси на кодирование числа с предварительным определением длины занимает вычисление логарифма, что мне совершенно не нравится.

Все что мне нужно, расчет по unsigned количества символов в будущей строке. Какие нибудь соображения?



Последнее исправление: beastie (всего исправлений: 2)
Ответ на: комментарий от westtrd

Так это всё-таки float а не int? У него тоже есть стандарт. Как раз 19 цифр.

В общем глупостями занимаешься. Почитай стандарт на используемые типы и успокойся.

anonymous
()
Ответ на: комментарий от anonymous

FIX регламентирует float явно.

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

В принципе, на суть решения это не влияет.

westtrd
() автор топика
Ответ на: комментарий от gh0stwizard

P.S. А чем ТС не устроил strlen() ?

Тем, что на входе unsigned, а на выходе нужна строка.

andreyu ★★★★★
()
Ответ на: комментарий от pS

Что за царь?

Пользователь с именем по шаблону $Carb.*^, superhackiller1997, а также, когда забанили в очередной раз, анонимус. Детектится в основном в тредах по С по фразам «кукарекал», «нулячий»/«занулю», «обосрался» и т.п. Успел отличиться, кроме рядового тупизма, заявлениями о том, что float десятичный и еще несколькими подобными эпиками.

Pavval ★★★★★
()
Ответ на: комментарий от westtrd

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

anonymous
()
Ответ на: комментарий от westtrd

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

И загоняется в отсилы 10гигабитный порт. Причем тест.

Цикл-то есть, но он только на вывод в конкретное место, без всяких побочных дел.

Есть циклы с побочными делами? что это?

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

Врёшь. А с какого бадуна ты взяла, что копироваться будет память?

Если ты кукарекаешь о llatency, то это минимальные буфера - т.е. это к памяти не имеет никакого отношения.

И да, обычно это делается не в хипе, а в собственных аллокаторах на hugepages

Датычё, собственный аллокатор? hugepages.

Кодирование/запись в сеть - это чисто последовательные load/store.

Топовое железо - это 64записи 4к страницы, не беря всякие стлб. Т.е. 256кб. 30тактов при 2.7ГГЦ, при средней длине выхлопа 10байт - это 11нс на 10байт. Т.е. 1.1нс на байт - это 288358,4нс - т.е. 0.28МС.

Т.е. держать даже буфер в 256кило даёт latency в четверть милисекунды. Т.е. ты обосрался.

Далее, dtlb мис бесплатен при последовательном обращении.

Далее, hugepages юзают для random access в гигабайтах, чтобы на mem latency не наслаивался dtlb мисс. В гигабайтном буфере у тебя latency больше секунды.

Далее, hugepages нахрен не нужны и ты обосрался в очередной раз. Судя потому, что там в метровых страницах кол-во записей в раза 2ниже - значит трансляция там сложнее. Т.е. вероятнее всего dtlb хит в метровую страницу будет дороже. Иди бенчи.

Да, много чего тут интересного

И почему-то ты вырос нулёвым балаболом, который в теме разбирается на уровне обезьяны. Что-то здесь не так.

anonymous
()
Ответ на: комментарий от anonymous

В гигабайтном буфере у тебя latency больше секунды.

Попроси маму купить тебе компьютер вместо калькулятора.

anonymous
()

Попроси маму купить тебе компьютер вместо калькулятора.

Рили? Твоего буфера даже для слежения за контекстом не хватает - попроси маму купить себе новый мозг.

И ты не заметил там уточнение «у тебя», а не вообще.

У пацана буфер заполняется со скоростью 3такта на байт, при ТТ 2.7. Давайте поможем питушку посчитать время заполнения гигабайтного буфера.

anonymous
()
Ответ на: комментарий от westtrd

Решение в итоге перешло на табличный вариант, но серьезно модифицированный.

О да, кукарекающий о «кешах пацан» форфан увеличил буфер до килобайта.

В чем заключается «серьезная модификация»?.

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

Полезно.

Сделано для 64 бит.

Т.е. даже что такое size_t и зачем ты не знаешь. Зачем для 64бит size_t?

size_t idx = 63 - __builtin_clzl(value);

Каждый такт. Просто полезен пацан. Ты просто вставил __builtin_clzl(), о котором тебе кто-то сказал и даже не удосужился погуглить. Просто бездарность.

(value >= tbl[idx][1])

А как же branch prediction? Оператор ?: Как же так? Чтож ты сразу поклал и на branch prediction и на «вытесненияизкеша»?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.