- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
protected static long chr2hex(char a)
{
switch (a)
{
case '0':
return 0L;
...................
case '9':
return 9L;
case 'A':
case 'a':
return 10L;
.....................
case 'F':
case 'f':
return 15L;
}
return 0L;
}
Follow us!
В обычный int может не поместиться?
А так я уже валяюсь от полного перебора алфавита и чисел.
причем буквы дальше F как бы должны вернуть 0
Вот так вот и рождается код, который потом в качестве хекс чисел принимает всякие chucknorris и zeleniy.
Сорри за хабр, но другую ссылку по теме искать влом: http://habrahabr.ru/post/173727/
bormand интерпретируется как #b000a0 = b0*красный + a0*синий.
Если браузер не сможет интерпретировать такой цвет, то он его проигнорирует.
Хуже будет, если придёт кто-нибудь с ником ffffff: его имя будет белым на белом.
хуй
Имхо, тоже говнокод.
> Char.IsDigit(a)
И сразу фейл.
В стиле си брать чары из массива по 4 и конвертировать их в intе пачками по 2 или 4. В 64-х битном режиме скорость и того больше.
К сожалению ни в жабе, ни в шарпе так стрелять нельзя. Чтоб быдло не стало БЕ3НОГNM
кстати, наброса ради, приведу канонiческую реализацию от CRT моей MSVC 9.1 понятное дело, что тут мегафункция, парсящая охулиард форматов и пацанам просто западло что-то сверхоптимизировать, но лично я для такой мегаузкой задачи, как конверт символа в ниббл написал бы статическую таблицу [256], в которой тупо в нужной ячейке лежит нужный результат
Малаца, хорошо зделали. Я только хтел сказать что не надо проверять верхние и нижние отдельно.
В ниббл сконвертить можно так
Или я ебанулся? Думаю кто-то уже должен был до такого додуматься.
http://ideone.com/yT0BM9
Парсинг - сложней. Нужно подрочиться с инвалидными значениями и нулями. Но тоже возможно.
На 64-битном MMX регистре можно перегонять int32.
А на SSE и вовсе 64-разрядные значения с явным профитом.
>m += (m<<2)+(m<<1)
fix:
Хотя можно еще улучшить. Можно еще флаг ввести, который будет отвечать за большие/маленькие, но я сходу простого способа без ветвлений не вижу.
это и есть - чар в ниббл
поставим четкие условия - надо из строки "67af" получить uint16_t 0x67af
В SSE-регистрах это криво, потому что должно быть выровнено по байтам (который минимальная единица адресации): 0x06070a0f.
Но сдвигами это фиксится на раз.
>поставим четкие условия - надо из строки "67af" получить uint16_t 0x67af
Если я привел наглядный пример, то думаю не составит труда его обратить. Или вы думаете что обратный процесс сильно сложней?
Как я уже сказал его могут усложнить только проверки диапазонов.
>лично я для такой мегаузкой задачи, как конверт символа в ниббл написал бы статическую таблицу [256]
Но мы говорим в общем как делают "в стиле С". Понятно что для именно этой задачи, с вероятностью 95% этот hex пойдет в буфер и на вывод (который в тысячи раз тормознутей), то оптимизация не особо нужна.
Я же говорю об общем подходе - "в стиле С".
наоборот, из буфера читаем символ
раз уж мы тут обсуждаем SSE и обработку пачками, очевидно, что данные лежат в символьном виде в оперативе в удобном для обработки виде, тысячи их
допустим все по 8 символов, которые превращаются uint32_t, если тебе удобней - по 4 символа, которые превращаются в uint16_t
нелегальных символов нет
это не по правилам - но допустим, что вообще всё только в нижнем/верхнем (ненужное зачеркнуть) регистре
вот мне праздно интересно, даст ли молотилка SSE вообще профит перед решением в лоб (арифметический char -> nibble, скажем return ch < 'A' ? ch - '0' : ch - 'A' + 10; плюс 8(4) сдвига аккумулятора на << 4)
вопрос не тебе, а он вообще, риторический
>что вообще всё только в нижнем/верхнем (ненужное зачеркнуть) регистре
Она понимает регистры. У Борманда судя по этому 0x20202020 - тоже.
https://ideone.com/L3Ktdg
>вот мне праздно интересно, даст ли молотилка SSE вообще профит перед решением в лоб
Да. Всего 8 комманд. Никаких ветвлений.
И обрабатываем сразу 16 байт.
Ну речь об том что задача чисто для I/O. А там, как известно, оптимизировать надо другое.
>что данные лежат в символьном виде в оперативе
Прикол в том, что если будем грести по 128 бит, aligned ясен пень, такие загрузки очень сильно ускорят процесс, чем брать и ложить по одному чару. Там по-моему немного скорость снижается, если брать не кратное 32.
А обычно его потом еще и расширяют на все 32 зуба бита. И даже замена ветвлений на cmovы не сильно поможет.
Это еще одна статья ускорения. Думаю с версией борманда ниже, молотить будет раз в 15-20 быстрее. Что, в целом, существенный рывок. И труЪ способ для сишника.
Разве что какой-нибудь кривой сетевой протокол, в котором все текстом.
Я видел такую конвертацию говношифрованного бинарника в текстовый вид.
Ну кстати sse тогда еще бОльшую службу послужит.
Можно прямо там и дешифровать.
Да и в целом способ-то универсальный. Так еще задолго до sse паковали.
Да всё то же. Буквы, цифры, сдвиги. Основная трудность равно и другие символы.
Ну и то что base64 невыровнен по 2^n.
Ну это придется компенсировать бОльшим блоком - загружать по 16 символов и конвертить их в 12.
С равно можно поступить тупо - последний неполный блок обработать наивным методом.
Если между символов нет энтеров и прочего мусора - вроде сложностей больше и нет.
помню как наткнулся на дичайшую подставу в бусте для base64 - где то в недрах boost.archive, вроде, наш сотрудник наткнулся на енкод- и декод-итераторы, заюзал их и был несказанно рад
а потом я разгребал эту багу - итераторы в бусте клали хер на возможную неполноту блока и тупо недоделывали буфер до конца
Оказалось что если начать делать, то нету ничего сложного.
Остальное битоёбство с выранвиваниями слишком очевидно чтоб его делать.
http://ideone.com/40Q0cH
если тут забайтоёбен перевод 6 битов -> 1 символ, то такая тема всяко проиграет табличной замене
смысл примерно в том, чтобы 3 байта пачкой забайтоёбить в 4 символа (или 12 в 16, если так будет круче), и взад, чтобы обогнать табличный мэтод
Ну блин само собой. Я уж думал после стольких обсуждений всем будет очевидно как расширить мой пример на пачку.
Вот думаю на декодингом.
Причем если сам декодинг - Hurt me plenty, то проверка валидности - Nightmare.
такая вундервафля ничего не обгонит, к сожалению :(
Да.
> на каждую часть натравить func
Расширить func. И натравить на все одновременно.
>потом собрать результат в 4-байтном целом
Он сам соберется.
Сделал типа рабочий кодер base64 для 64-битных слов.
https://ideone.com/4XHkj6
Вот как, блядь, нужно кодить, вот, быстро. Раз-раз-раз! Давай, кодь. Base64!
https://ideone.com/lLR7MB
выдает не то
(должен "TWFuIGlz")
пример взят из педовикии /Base64
Можно объединить его с expand (который сам по себе непоптимален), но мне влом.борманда проси у него лучше получается
https://ideone.com/cG5svp
xml и json сочли это преимущество сомнительным.
Правда наборы Š A хер так просто попарсишь.
ну так в &#x...; влезет то только целочисленное значение
туда не упихнуть 100500 байт бинарных данных
а уж целочисленное значение проще видеть глазами, понятное дело
причем получится-то хуже 2/1:
> provide a (hexa)decimal representation of the character's code point in ISO/IEC 10646
т.е. в среднем для распространенного двухбайтового значения получится около 6 байт результата
даже не просто бинарные данные - так только символы можно кодировать
Ну да. Говно. Плюс один: легче сходу читать эти коды. Ну типично для xml - читаемость как у бинарного, размер и эффективность как у текстового.
> получится-то хуже 2/1
Так еще и невыровненое.
>около 6 байт результата
Как и в json: \uABCD.
ну тут то максимум 6
а в xml - максимум 8 - &#xXXXX;
хорошо, прикид был неверный - в xml в среднем будет 7
Как и в json: \\uABCD
Декодинг base64 и самая хардкорная часть: проверка валидности.
http://ideone.com/xkizU4
2F: / - 51 63
Делается по аналогии с энкодом.
Кусок c extr.
https://ideone.com/L3Ktdg
А, всё понял.
>по идее даже короче получился:
7 комманд. Круто.
А у них получится без проверок, для одного символа примерно столько же.
Но с ветвлениями, лол.
А-а-а теперь я понял откуда лишняя комманда больше было.
>return hex & b1; //теор. это можно убрать.
Я чищу перед возвратом, а у тебя очистка совмещена с перемешиванием байтов.
> -а-а теперь я понял почему у меня на одну комманду больше было.
Нет. Лишняя команда была в lowcase.
У меня 9.
Кстати этот вариает самый очевидный. И наверно надо & 0x0F0F0F0F делать.
Не путь джедаев-байтоебов надеятся на lea.
Крут-крут. Я совсем сегодня плохо соображаю.
Я писал и думал как бы туда проверки впилить, но там адски, у нас три случая
a-0x30
00x1 - hex, который можно | сделать в 0011
0000 - цифра
Остальное - должно быть нулём. То есть надо верхние байты превратить в большую маску
Не подскажите ли чего он такого курит?
Очевидно толстых хвостатых манулов.
Ты тут недавно? Сначала было байтоебство. А ну да, именно ты и начал форсить тут хацкиль.
А кому он нужен? Я его тоже не курю. (только на уровне написать очередной коммент про AssParallel)
Знание явы - на 50% знание шарпа.
>для души в них совершенно ничего нет.
В SQL там свои приколы, но надо идти вглубь: планы запросов, расположения индексов и таблиц, схемы блокировок.
И каждый сервер - целая наука.
Со своими заморочками и граблями.
Не получается больше 8.