По новой системе пока никаких особых впечатлений кроме возможости поставить Google Chrom и другой нужный софт… А вот винт радует… Явное увеличение скорости загрузки приложений… В общем, я доволен

Во вторник его отвезли в больничку. Не смотря на то, что дорога была близкая, ехал он долго. Четырежды хозяин останавливался, остужал двигатель и доливал холодной воды в радиатор. А сегодня его забрали, здорового и бодренького. Заправили полный бак бензина и поехали кататься. Кататься просто так, а не по делам. Видимо хозяин соскучился, ведь старый диван всегда лучше новой табуретки

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

Скачать скрипт можно тут: ipgeobase.php.gz.

Для работы скрипта нужен файл cidr_ru_block.txt из архива db_files.tar.gz. Запускаться скрипт должен в том же каталоге, что и cidr_ru_block.txt. После работы скрипта появляются 3 файла: ipgeobase-states.dat, ipgeobase-cities.dat, ipgeobase-ips.dat.

В ipgeobase-states.dat храняться области в формате [идентификатор области]\t[название области].
В ipgeobase-cities.dat храняться города в формате [идентификатор города]\t[идентификатор области]\t[название города].
В ipgeobase-ips.dat храняться диапазоны ip-адресов в формате [IP от]\t[IP до]\t[идентификатор области]\t[идентификатор города].

При повторном запуске скрипт начитывает данные из ipgeobase-states.dat и ipgeobase-cities.dat (если они есть). Таким образом, при появлении новых городов или областей, идентификаторы “старых” записей не изменятся. IP храняться в виде беззнакового 32-битного числа.

Как-то так, надеюсь кому-то мой труд облегчит жизнь

В одном месте на звонок не ответили, но перезвонили через 20 минут и, не представившись, спросили зачем звонили. Это было неожиданным, потому что на сайте был указан “многоканальный телефон”, а на деле оказался мобильный частного таксиста.

Вторым сайтом был www.500-50-50.ru. Вот эти ребята натурально удивили и порадовали. Приятная девушка приняла заказ. Секунд через 10 пришла SMS-ка о том, что заказ принят, с указанием куда и в какое время подать такси. Такси было заказано на 18:30. В районе 16:30 часов пришла SMS-ка с указанием модели машины, госномером, именем водителя и его мобильным телефоном. В 18:25 пришла SMS-ка о том, что такси ждёт у подъезда. Доехали без приключений. Через минуту после приезда пришла SMS-ка со “спасибками”, указанием стоимости поездки (290 рублей) и указанием что на накопительный счёт капнуло 14 рублей. В общем, молодцы, порадовали.

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

В результате получилась библиотека со следующим набором функций:

cor_list_t *cor_list_init(int size);
int cor_list_pool_expand(cor_list_t *l);
void cor_list_destroy(cor_list_t *l);

cor_list_init — инициализация списка заданного размера (минимальный размер установлен в 16 элементов). Каждый раз, при добавлении нового элемента, когда не останеться свободных, пул будет расширятся на заданный размер. Размер стоит подобрать так, чтобы операции расширения были как можно более редкими.

cor_list_pool_expand — расширение списка. Эта функция вызывается при вставке новых элементов, если свободных нет. Принудительно вызывать эту функцию не требуется.

cor_list_destroy — освобождение памяти, занятой списком.

Остальные функции работы со списком написаны в виде макросов, для увеличения скорости работы:

#define cor_list_insert_head(_pv, _l)
#define cor_list_insert_tail(_pv, _l)
#define cor_list_insert_after(_pv1, _pv2, _l)
#define cor_list_insert_before(_pv1, _pv2, _l)
#define cor_list_delete(_pv, _l)
#define cor_list_move_head(_pv, _l)
#define cor_list_move_tail(_pv, _l)
#define cor_list_first(_pv, _l)
#define cor_list_last(_pv, _l)
#define cor_list_next(_pv)
#define cor_list_prev(_pv)
#define cor_list_value(_pv)

cor_list_insert_head — вставка новго элемента (_pv) в начало списка (_l). _pv — это указатель, который указывает на встравленный элемент.

cor_list_insert_tail — вставка нового элемента (_pv) в конец списка (_l).

cor_list_insert_after — вставка нового элемента (_pv1) после элемента (_pv2) в списке (_l).

cor_list_insert_before — вставка нового элемента (_pv1) перед элементом (_pv2) в списке (_l).

cor_list_delete — удаление элемента (_pv) из списка (_l).

cor_list_move_head — перемещение элемента (_pv) в начало списка (_l).

cor_list_move_tail — перемещение элемента (_pv) в конец списка (_l).

cor_list_first — получение в _pv первого элемента в списке (_l).

cor_list_last — получение в _pv последнего элемента в списке (_l).

cor_list_next — получение в _pv элемента, следующего за элементом _pv. Т.е. в _pv передаётся текущий элемент, и в него же сохраняется следующий. Если достигнут конец списка, возвращается NULL.

cor_list_prev — получение в _pv элемента, предыдущего, по отношению к элементу _pv.

cor_list_value — получение значения элемента _pv.

Исходники: cor_list.h, cor_list.c.

Если кому-то пригодится, буду рад

Теперь о самом решении. Задача стоит в том, чтобы максимально быстро выбрать набор данных, удовлетворяющих некоторому набору признаков, представленных в виде битовой маски. Далее предполагается, что мы работаем со 128-битным регистрами sse.

Мои идеи крутились вокруг деления битовой маски на куски по 128 бит и последовательной проверки каждого слова на соответствие поисковой маске. В результате получается матрица размерностью ceil(размер битовой маски / 128) по ширине и длинной в количество записей.

Новая идея в том, что мы строим матрицу, где строке соответствует один бит из битовой маски, а в столбцах у нас записи. Таким образом, у нас одно слово описывает один бит у 128 записей. Получается, что за одну операцию мы проверяем один бит у 128 записей. Если у нас n бит в маске, то мы проверим 128 записей за n операций. По-моему красиво

Из плюсов вижу более компактное хранение (у нас не будет неиспользуемых бит в слове, если размер битовой маски не кратен 128) и большую скорость работы (мы проверяем только значимые биты, например, если у нас битовая маска 150 бит, то в первом варианте нам нужно 2 проверки на каждую запись, т.е. 256 операций на 128 записей, а во втором нам нужно 150 операций для проверки 128 записей). Из минусов вижу только более сложное формирование данных и поиска.

ИМХО красивая реализация

Всё началось с того, что решил подумать, как ускорить перебор среди элементов со множеством полей. Можно по каким-то полям сделать индекс, но покрыть индексами всё не получается. Таким образом, в некоторых случаях, придётся использовать тупой перебор.

Первое что приходит в голову для ускорения перебора — использование битовых операций. Сформировал маску и пошёл AND-ом по списку, красота. Но когда наткнулся на необходимость проверить что значение больше (или меньше) заданного, впал в ступор. Если диапазон значений меньше или равен количеству бит в целом, никаких проблем нет, а если диапазон шире, ступор.

Вот скажите, это я такой тупой, или стандартными логическими операциями нельзя проверить что одно число больше другого?

В архиве словарь aspell для русского языка в формате utf-8 и два скрипта, которые генерируют словоформы с разным форматом вывода. В результате получается порядка 1.3М словоформ.