LINUX.ORG.RU

Сообщения ly

 

давно не мерялись хэш-функциями, есть повод :)

Быстрее чем City64, xxHash, metrohash, mum-hash и т.д.

Однако, разыскивается комбинация cpu+gcc, где t1ha медленнее чем metrohash, xxHash, City64, mum, fasthash.

https://github.com/leo-yuriev/t1ha

$ ./SMHasher t1ha
--- Testing t1ha "Fast Positive Hash (The 1Hippeus project)"
...
Bulk speed test - 262144-byte keys
Alignment  7 -  4.733 bytes/cycle - 13540.24 MiB/sec @ 3 ghz
Alignment  6 -  4.731 bytes/cycle - 13536.62 MiB/sec @ 3 ghz
Alignment  5 -  4.732 bytes/cycle - 13538.12 MiB/sec @ 3 ghz
Alignment  4 -  4.732 bytes/cycle - 13537.49 MiB/sec @ 3 ghz
Alignment  3 -  4.731 bytes/cycle - 13534.95 MiB/sec @ 3 ghz
Alignment  2 -  4.732 bytes/cycle - 13538.86 MiB/sec @ 3 ghz
Alignment  1 -  4.730 bytes/cycle - 13532.10 MiB/sec @ 3 ghz
Alignment  0 -  4.931 bytes/cycle - 14108.62 MiB/sec @ 3 ghz
Average      -  4.756 bytes/cycle - 13608.38 MiB/sec @ 3 ghz
...
$ ./SMHasher metrohash64_1
--- Testing metrohash64_1 "MetroHash64_1 for 64-bit"
...
Bulk speed test - 262144-byte keys
Alignment  7 -  4.190 bytes/cycle - 11987.40 MiB/sec @ 3 ghz
Alignment  6 -  4.186 bytes/cycle - 11977.52 MiB/sec @ 3 ghz
Alignment  5 -  4.188 bytes/cycle - 11981.03 MiB/sec @ 3 ghz
Alignment  4 -  4.186 bytes/cycle - 11976.78 MiB/sec @ 3 ghz
Alignment  3 -  4.190 bytes/cycle - 11987.54 MiB/sec @ 3 ghz
Alignment  2 -  4.188 bytes/cycle - 11982.82 MiB/sec @ 3 ghz
Alignment  1 -  4.187 bytes/cycle - 11979.17 MiB/sec @ 3 ghz
Alignment  0 -  4.344 bytes/cycle - 12427.48 MiB/sec @ 3 ghz
Average      -  4.207 bytes/cycle - 12037.47 MiB/sec @ 3 ghz
...
$ cat /proc/cpuinfo | grep model
model		: 69
model name	: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz

$ gcc -v
...
gcc version 5.4.0

 , , ,

ly
()

kernel, sound/alsa использовать для данных - потыкайте мне

Камрады, вот никогда sound в ядре не программировал... А тут попросили помочь, и понеслось.

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

Ткните мне как это проще, а то все доки про написания драйверов, но из их не складывается картины как проще/минимальнее использовать sound-инфраструктуру в ядре для кастомного ввода-вывода.

Спасибо.

 , , ,

ly
()

Ишем тестировшика в Питере (HA, HL, ReOpenLDAP)

Linux, кластер ReOpenLDAP, плюс проприетарный софт на С++.

http://www.billing.ru/job/738

 , , , ,

ly
()

ReOpenLDAP: продолжаем развитие/ассенизацию, решаем что можно отрезать...

Комрады, снова приветствую.

По-немного мы продолжаем процесс и вот пришло время решить «что отрезать» от оригинала, чтобы обеспечить реальную (не на словах) тестирование и поддержку.

Как и ранее, дабы не увеличивать энтропию - ниже ссылка на более «профильный» форум с топик-мастером.

http://pro-ldap.ru/forum/index.php?topic=286.msg711#msg711

 , , , ,

ly
()

re-openldap iddqd idkfa

Комрады, приветствую.

Мы тут по-немного продолжаем битву с ассенизацию OpenLDAP.

Хотелось бы обсудить пару моментов. Дабы не увеличивать энтропию впустую - ниже ссылка на более «профильный» форум с топик-мастером.

http://pro-ldap.ru/forum/index.php?topic=286.msg693#msg693

 , , ,

ly
()

memory barriers для _всяческих_ компиляторов и архитектур

Комрады, мне вот приспичило memory barriers для кучи компиляторов, в том числе старых и тех что я даже не знаю где взять.

Посмотрите глазками, может что подскажите https://gist.github.com/leo-yuriev/ba186a6bf5cf3a27bae7.

Ну и share it по-возможности.

 , , , ,

ly
()

Да, в 10-100 раз быстрее по записи: OpenLDAP + LMDB

Комрады, речь о готовом рецепте увеличения производительности по записи для OpenLDAP (когда LMDB используется как бакенд хранения) и для самой «Lightning Memory-Mapped Database» (http://symas.com/mdb/). Не хотелось-бы углубляться в сравнения, но LMDB один из немногих вариантов позволяющий обслужить под миллион read-запросов и порядка 1-100К write-запросов (с этими правками).

Никаких чудес и бесплатного сыра, платить приходиться более редкой фиксацией данных на диске, либо ставить «RAID с батарейкой» (теперь в этом есть смысл). Грубо говоря, на диске фиксируется не каждая транзакция, а как настроите (периодически или по объему изменений). Если же будет write-back кэш «с батарейкой», то ускорение будет и при фиксации каждой транзакции.

Чтобы это работало пришлось допилить LMDB и немного OpenLDAP (aka slapd):

  • правка багов для консистентности периодических чекпоинтов.
  • LIFO-реклайминг (90% правок).
  • прочие мелочи, включая замену «минут» на «секунды» в чекпоинтах.

Из slapd.conf рецепт выглядит например так:

backend mdb
envflags writemap nosync lifo
checkpoint 0 1
Что в переводе: сквозная запись (которая теперь без глюков), сразу ничего не записывать, делать чекпоинты каждую секунду (БД консистентна на диске).

Фишка LIFO-реклайминга в гораздо большей вероятности записи одних и тех же секторов на диске, что дает возможность объединять такие операции если фиксируется не каждая транзакция или есть «RAID с батарейкой». В результате write perfomance действительно растет в обещанные 10-100 раз.

Правки относительно протестированы парой недель тестов и несколькими миллиардами транзакций. Багов, думаю, не больше чем исходно в LMDB и OpenLDAP.

Всё сделанное заслано в http://www.openldap.org/its/index.cgi/Incoming?id=7958, от того и пишу. Мой интерес протолкнуть это в mainstream, чтобы не поддерживать патчи локально. А у Symas Corp видимо сомнения проистекающие из стиля кодирования LMDB. Грубо говоря, и так не всегда понятно как оно работает, а теперь еще веселее (к гусарам просьба - не предлагать переписать LMDB).

Короче, если у кого есть интерес отпишите челобитную по последнему урлу, авось поможет.

p.s. Дабы не уличили в замалчивании: некую первую версию lifo-патча сделал dmitrii.fonariuk@gmail.com, я повторил с «чистого листа» поскольку были баги и в местах контакта код LMDB существенно изменился.

 , , ,

ly
()

Deep Packet Inspection — Большой Брат и Национальный Firewall

Event по обозначенной теме http://www.billing.ru/events/560

ly
()

Блин, внезапно - в Андроид захардкодили BEAST еще в 2010

С натяжкой, но можно так сказать.

Android is using the combination of horribly broken RC4 and MD5 as the first default cipher on all SSL connections... ... it replaced better ciphers which were in use prior to the Android 2.3 release in December 2010.

http://op-co.de/blog/posts/android_ssl_downgrade/

 , beast,

ly
()

kernel & futex = подстава от Ingo Molnár и Thomas Gleixner?

Ну или поясните мне...

Для FUTEX_LOCK_PI захардкодили ERESTARTNOINTR и CLOCK_REALTIME.

Использование CLOCK_REALTIME без возможности CLOCK_MONOTIME еще можно понять.

Но почему жестко ERESTARTNOINTR, и никогда EINTR?

Почему нельзя прервать ожидание на pi-фьютексе сигналом? Только потому что glibc дизайнят загадочные люди?

Как веслом по морде, всплыло на юнит-тестах :(

 , , ,

ly
()

Поставьте мне мозг на место: GPLv3 + shared memory

Было:
- есть код под GPLv3 (например вычисления);
- есть еще код под GPLv3 (различный транспорт);
- к этому добавлен main-модуль под GPLv3;
= тут все ясно и понятно, имеем проект под GPLv3.

Стало:
- к указанному GPLv3 проекту добавили код, реализующий транспорт через разделяемую память;
- координаты и формат данных в разделяемой памяти задаются в настройках/опциях, можно считать что работает интерпретатор или компилятор;
- все изменения исходников доступны;
= ну тоже понятно, имеем проект под GPLv3, в который внесены изменения, нарушений нет.

Туплю:
- есть проприетарная прога, которая создает именованный регион разделяемой памяти и производит с ним обмен;
- настройками двух проектов их можно «подружить», таким образом GPLv3 и не-GPL в каком-то смысле объединяются;
- обмен производится массивами (длина плюс линейно данные);
= вопрос, это нарушение GPLv3 или нет?

 , ,

ly
()

[git] План слияния + WebUI

Предположим:

  • У вас есть 3-10 репозиториев/проектов git, возможно даже всё живет в gerrit.
  • В каждом репозитории 5-50 веток, организованных примерно как http://habrahabr.ru/blogs/Git/106912/
  • В ветках идет работа, итерации, фичи, исправления и т.д.
  • Совсем в другой стороне есть план, со сроками и задачами.
  • Соответственно этот план имеет некую проекцию на структуру веток и их слияния.
  • Но сроки не всегда соблюдаются, коммиты идут постоянно и «невовремя», а ветки нужно мержить, да еще и видеть картину в целом чтобы как-бы чего не забыть...

Хочется иметь некую LAMPочку с помощью которой:

  • вводить изначальный план слияния веток, что и куда, к какой дате;
  • видеть treeview плана слияния со сроками;
  • видеть коммиты, особенно в побочные ветки после вливания последних в главные;

Готового не нашел. Кто знает про такое счастье?

 

ly
()

cmake - зависимости для сборки инструмента, как?

В проекте используется свой язык (оправдано). Соответственно, для этого языка в составе того-же проекта есть компилятор, в виде исходников.

Как cmake (@#$%!) объяснить, что сначала нужно собрать компилятор, а потом им компилировать другие сорцы.

Пока тупо внес путь к получаемому компилятору в зависимости custom-command.

Работает костыльно - cmake генерит часть make-файлов, но обламывается на поиске компилятора, считая его исходным текстом. Но запущенный make уже все разруливает, так как построение компилятора уже определено.

ly
()

[вакансия, москва] нужен помощник - инженер конфигурационного управления

Ведущий инженер конфигурационного управления (разработчик средств внутренней автоматизации)

git + gerrit + teamcity + сборки + hasher + тесты + ...

http://hh.ru/vacancy/3801680

ly
()

посоветуйте нетбук или ноут

Совета прошу так как реально нет времени серфить Инет, не пинайте.

Нужен субж под бубен (ubuntu), желателько с WiMAX (yota) и без большой головной боли.

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

Ноут в принципе тоже подойет, цена не главное. Но там железа больше и половина (как-правило и насколько мне извесно) работает только в mustdie.

С другой стороны, если ноут - то mustdie7 буду держать для starcraft'а. Но в основном linux. Бубен - не принципиально, просто жена привыкла.

Короче, все советы принимаются. Заранее спасибо.

ly
()

Cборка в chroot (покритикуйте)

Задача:

  • на одной машине собирать софт под несколько linux-систем. К примеру: rhel5-i386/x64, rhel6-i686/x84, alt5-i686/x64, ubuntu-i686/x64 и т.д.
  • результаты должны быть «нативные», т.е. с использованием хидеров и библиотек специфичных для каждой версии каждой ОСи.
  • архитектуры отличные от x86 пока не интересуют, что многое упрощает.

Cделано так:

  • 64-битная хостовая система с поддержкой 32-бит для userspace;
  • с каждой target-системы снят tarball-образ и развернут с обрезанием мусора;
  • при сборке создается chroot-песочница, куда монтируется:
    • корень target-системы в readonly без suid;
    • рабочий каталог для svn co & make;
    • tmp
  • make запускается в chroot c правами а-ля nobody;

Работает как задумано, но может что-то можно сделать лучше/проше?

ly
()

gold вместо ld для gcc 4.5.0

Кто-нибудь пробовал subj?

У то меня пока валиться при пересборке gcc после bootstrap. Причем именно из-за того, что gold гадит при сборке mpfr/gmp.

ly
()

Чудеса - увеличение cpu-usage в kernel

Процесс для обработки запускает (fork + exec) массу различных обработчиков. Время жизни обработчика мало (запустился, сделал что попросили, exit).

Все данные (которые доступны обработчикам и результаты) живут в tmpfs. Запускается тест, который крутит тестовую коллекцию по кругу.

Наблюдаем за этим делом через sar -X pid. Видим, что после запуска дочерние процессы (обработчики) потребляют скажем 20% процессора в режим ядра и 80% в usermode. Смотрим на это дело через три-четыре часа - видим почти обратное соотношение, примерно 80% в режим ядра и 20% в usermode!!!

Состав данных точно не меняется, всё идет по кругу. Система RHEL 5.5 со всеми апдейтами. В обработчиках ничего «волшебного», можно сравнить с tar или unzip.

Аналогичная хрень видна и для родительского процесса (по sar -x pid). Очень не хочется заниматься проктологией через SystemTap...

Какие будут идеи?

ly
()

кто-нибудь курит luabind ?

Подскажите как вернуть nil если привязка не через указатели?

Т.е. нужно чтобы в стек луа-машины добавлялось примерно как-бы так:

my_object.is_nil ? lua_pushnil() : lua_push(my_object.lua());

ly
()

Опрос - Распространённость айтишного саботажа

Коллега попросил содействия в сборе информации, желающим предлагается высказаться.

http://infowatch.livejournal.com/81339.html

ly
()

RSS подписка на новые темы