- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
template<class _CharType>
bool check_arith(const _CharType* str)
{
for(; *str ; ++str)
for(unsigned long long j = 0x6165696F7579ull; j; j >>= 8)
if(((j & 0xFF) | 0x20) == (*str | 0x20))
return true;
return false;
}
absolut 15.03.2012 09:53 # 0
TheCalligrapher 15.03.2012 10:07 # +1
absolut 15.03.2012 10:47 # 0
defecate-plusplus 15.03.2012 11:44 # +3
но во первых такие вещи надо делать как функцию isvowel, которую затем было бы удобно применить к тому же std::find
и во вторых я бы 100 раз подумал, стоит ли быть умнее компилятора в оптимизации
может быть в лоб { c |= 0x20; return (c == 'a' || c == 'e' || ... ); } не так уж и плохо получилось бы, а если уж настолько важна скорость, то статическая таблица была бы лучше решения в топике
TarasB 15.03.2012 13:17 # 0
Я сначала подумал, они сделали аналог паскалевского set, завели 32-байтный массив, символизирующий множество из элементов типа из 256 значений, а тут перебор в лоб.
Тупо.
gooseim 15.03.2012 14:08 # −1
TarasB 15.03.2012 14:49 # −2
На самом деле там если множество константа и оно просто устроено (что можно 4 сравнениями обойтись), то там таки перебор.
gooseim 15.03.2012 15:25 # 0
Но здесь такой трюк не пройдет, потому что может быть не char, а еще и wchar_t и даже теоретически еще что-то большее.
TarasB 15.03.2012 15:35 # 0
defecate-plusplus 15.03.2012 15:35 # 0
для всего остального - мастеркард return (arg < 'z' ? isvowel<char>(arg) : false);
defecate-plusplus 15.03.2012 15:37 # 0
gooseim 15.03.2012 15:41 # 0
мой комментарий не к этому относится
gooseim 15.03.2012 15:39 # 0
Точнее плохой. Потому что хороший код это std::string::find_first_of и тому подобное.
TarasB 15.03.2012 15:42 # +1
case c of
'A', 'B', ...
ну ты понял. И пофиг, какой там тип, компилятор это чётко расчехлит.
Ну и минусовать при культурном споре - это говнотон.
gooseim 15.03.2012 15:48 # −1
Про минусовку - согласен. Если минусовать, то надо объяснять хотя бы почему ты это сделал.
TarasB 15.03.2012 15:53 # 0
var S: WideChar;
case S of
'a', 'b', '0'..'9': writeln('относится');
else writeln('не относится');
end;
При этом внутренности этого case будут скомпилированы в как можно более оптимальный код, с таблицами или бинарными деревьями, в зависимости от ситуации.
TarasB 15.03.2012 15:59 # 0
defecate-plusplus 15.03.2012 16:11 # 0
провёл тест
сейчас покажу результаты
gooseim 15.03.2012 16:21 # 0
TarasB 15.03.2012 16:27 # 0
И там тоже есть хитрая битовая таблица.
gooseim 15.03.2012 16:33 # 0
defecate-plusplus 15.03.2012 16:31 # +3
3.14159265 15.03.2012 16:42 # 0
Всё как и ожидалось: битовая таблица - православна, сишный кейс - говно.
Приведенный в топике код - полное говно.
3.14159265 15.03.2012 15:49 # 0
Я не понял. Объясни пожалуйста.
3.14159265 15.03.2012 15:29 # +1
Lol'd hardly.
>завели 32-байтный массив, символизирующий множество из элементов типа из 256 значений
Всё правильно - проставить при инициализации единицы где нужно и возвращать бит по адресу.
Kirinyale 15.03.2012 14:37 # 0
> стоит ли быть умнее компилятора в оптимизации
Иногда - стоит... На днях ковырял код видеоплеера - переписал красивый и понятный цикл в жуткое говнополотно с дублированием кода (избегал делений), стало работать примерно в 4 раза быстрее (инфа от VTune Amplifier).
Но ЗДЕСЬ?.. Что это за проект, в котором проверка гласных букв требует обязательной оптимизации? :)
TarasB 15.03.2012 14:50 # 0
Kirinyale 15.03.2012 14:56 # 0
После переписывания никаких пересчётов индексов нет вообще, зато появилась куча вспомогательных переменных и 90% дублирование кода внутренних циклов.
Пример мог бы запостить, но длинновато выйдет.
TarasB 15.03.2012 14:59 # 0
Kirinyale 15.03.2012 15:02 # 0
TarasB 15.03.2012 15:35 # 0
Kirinyale 15.03.2012 16:05 # 0
3.14159265 15.03.2012 15:33 # 0
I bet it was YV12.
Kirinyale 15.03.2012 16:05 # 0
3.14159265 15.03.2012 16:12 # 0
>две имеют размер вдвое меньший
Это chroma то есть цветовые компоненты.
>чем третья
это luma - яркость.
Так вот цветовые компоненты обычно пакуют в одну переменную и обрабатываются их пачками ибо так быстрее.
Kirinyale 15.03.2012 16:21 # 0
Да, оно и есть. Только почему-то libtheora (декодируем ogv) их никуда не пакует, а возвращает в раздельных буферах. Вот и приходится по обоим гулять.
Ну или я опять чего-то недопонял.
3.14159265 15.03.2012 16:49 # +1
Так может там вызов такой. Стопудов можно задать output colorspace.
libavcodec (который хавает всё что угодно) куда угодно конверт (ибо там есть специальный модуль), хоть в RGB, хоть обратно в YUV.
Рекомендую взглянуть на libswscale http://svn.perian.org/ffmpeg/doc/swscale.txt
Kirinyale 15.03.2012 16:56 # 0
Kirinyale 15.03.2012 14:59 # 0
for (int i = 0; i < buffer.y_width * buffer.y_height; ++i)
{
int row = i / buffer.y_width;
int col = i % buffer.y_width;
int yShift = buffer.y_stride * row;
int uvShift = buffer.uv_stride * (row / 2);
uint8 y_ = *(buffer.y_ + yShift + col);
int8 u = 128 ^ *(buffer.u + uvShift + (col / 2));
int8 v = 128 ^ *(buffer.v + uvShift + (col / 2));
int r = y_ + ((175 * v) / 128);
int g = y_ - ((89 * v + 43 * u) / 128);
int b = y_ + ((222 * u) / 128);
frame_[4 * i + 0] = clampToUInt8(b);
frame_[4 * i + 1] = clampToUInt8(g);
frame_[4 * i + 2] = clampToUInt8(r);
}
TarasB 15.03.2012 15:37 # 0
И ещё у меня никогда в подобных циклах скорость не упиралась в деление на два. У меня всё упиралось в запись в память (которое frame_).
Видимо дело было в одинарном цикле и делении кадый пиксел.
Kirinyale 15.03.2012 16:07 # 0
TarasB 15.03.2012 16:10 # 0
А после них - память. А сдвиг - 1%. Так что ты зря наговнокодил.
Lure Of Chaos 17.03.2012 10:49 # 0
Kirinyale 17.03.2012 11:54 # 0
gooseim 15.03.2012 16:42 # +2
defecate-plusplus 15.03.2012 17:38 # 0
1) Loc то передали, а попользоваться забыли
2) привязка к std::basic_string, хотя алгоритм спокойно принимает Sequence
3) многовато to_lower_copy - наверняка с what можно пооптимальней
gooseim 15.03.2012 20:36 # 0
2) нельзя, т.к. find_first_of исключительно метод класса std::basic_string
3) ваш вариант в студию
gooseim 15.03.2012 17:39 # 0