Не читал (нет необходимости) и ревью не делал (не платили), он есть неплохой шанс (субъективно > 75%) что автору и переводчику не удалось не протечь по тому страниц.
Кошмарная ахинея. Не только передернуто, но и буквально перевернуто с ног на голову.
В принципе сравнили разные поверхности. В качестве "уязвимостей" Debian посчитаны все проблемы во всех пакетах за все 20 лет. Для Windows тогда следует считать все проблемы во всем доступном софте.
Как один из самых давних, распространённых и поддерживаемых дистрибутивов Debian имеет одну из самых эффективных инфраструктур для отслеживания и устранения уязвимостей. Поэтому KPI в виде количества соответствующих записей в багтрекере показывает именно эту эффективность, а не "шарообразный уровень уязвимости".
Если ваш алгоритм требует определения для элементов больше отношения "a < b", то мерятся скоростью следует не c std::sort (универсальной сортировкой), а чем-то менее универсальным. В этом случае рекомендую этот пост — там Travis Downs ничего нового не придумал, но итеративно с танцами и песнями пояснениями и иллюстрациями дошел до хороших показателей для radixsort. Соответственно, хотелось-бы увидеть сопоставление результатов с вашим алгоритмом.
Кроме этого, при сравнении с std::sort следует измерять результаты для разных случаев (с разным распределением и упорядочиванием) исходных данных. В качестве заготовки могу предложить более-менее приемлемый тест и показать результаты (на всякий — сам тест критиковать не стоит, а просто сделать лучше/правильно и опубликовать).
Какие-то биндинги для питона есть, но вне opensource. Сделать их по мотивам LMDB-шных достаточно просто. Но сам я питоном не пользуюсь, а на LMDB-шные были какие-то нарекания. Поэтому не стал делать лишнего (кому надо — тот сделает, а я добавлю ссылку).
За счёт чего получили ускорение на 20%?
Корректнее сказать "до 20%" быстрее, так как во многих тестах до 99.9% времени занимает обмен с диском. Тем не менее, примерно такие результаты фиксируется бенчмарками оценивающими скорость работы самого движка (например, при размещении БД в tmpfs). Аналогичные результаты буду при больших/толстых транзакциях (с множеством апдейтов), т.е. libmdbx тратит меньше тактов CPU внутри себя.
Получено ускорение за счет переработки реализаций внутренних компонентов (например, списка грязных страниц и т.п.) и микро-оптимизаций. Но никакого простого ответа дать нельзя, отличий очень много. В частности, в MDBX всегда работает автокомпактификация и используетcя madvise() — поэтому "в долгую" libmdbx всегда выигрывает (нередко в разы).
С какой версией LMDB проводили последний бенчмарк?
Для бенчмарков используется ioarena, субмодуль LMDB там установлен на версию 0.9.24. Однако, в LMDB очень давно не было каких-либо изменений влияющих на производительность (только исправление багов и течей памяти), т.е. разнизы не будет с любыми версиями за последние 2-3 года.
Если будут еще вопросы, то лучше задавать в телеграм-группе (создана на днях).
Это вы про Fuchsia?
;)
Не читал (нет необходимости) и ревью не делал (не платили), он есть неплохой шанс (субъективно > 75%) что автору и переводчику не удалось не протечь по тому страниц.
Устроила эта рецензия = покупайте, вы нашли.
Ударим автопробегом по
бездорожью и разгильдяйствукоронавирусу!посмешитепорадуйте нас результатами.Пока вы этого не сделаете на ваши придумки не рационально обращать внимание.
Кошмарная ахинея. Не только передернуто, но и буквально перевернуто с ног на голову.
Адепты и противники git-flow ломятся в открытую дверь с разных сторон.
Уж лучше так, чем "хакать" мозг окружающих ;)
PCH и все его устройства должны быть переконфигурированы, как минимум enable-бит должен быть сброшен в configuration space.
h0t_max, или (неужели) sram можно читать/писать через jtag на этой стадии запуска?
ппц
Хм, а откуда вы без "балалайки" (или её аналога) физически возьмете payload для sram?
PCH будет пере-инициализирован со всеми его устройствами.
Вы ничего не должны, но я предлагаю проверить вашу сортировку простейшим набором тестов. Вам нужно:
CMakeи запуститьrunme;runmeи показать результаты.Для информации:
В том числе, видно как ведет себя "новый метод сортировки массива" от rela589n.
HabrArkady, вы покажите результаты
stresstestс вашим алгоритмом или не намерены этого делать?Нет.
Проблему обнаружили при внимательном чтении документации.
E2K
Для проигрывания "эксплоита" нужна примерно такая балалайка.
А с договорами — заходите, всегда будем рады )
Автору респект, но таки вспоминается "Сколько нужно программистов чтобы вкрутить лампочку..." :)
Спасибо.
На всякий дополню — добавлять оцениваемые сортировки лучше в stresstest и запускать его-же.
Если ваш алгоритм требует определения для элементов больше отношения "a < b", то мерятся скоростью следует не
c std::sort(универсальной сортировкой), а чем-то менее универсальным. В этом случае рекомендую этот пост — там Travis Downs ничего нового не придумал, но итеративно станцами и песнямипояснениями и иллюстрациями дошел до хороших показателей для radixsort. Соответственно, хотелось-бы увидеть сопоставление результатов с вашим алгоритмом.Кроме этого, при сравнении с
std::sortследует измерять результаты для разных случаев (с разным распределением и упорядочиванием) исходных данных. В качестве заготовки могу предложить более-менее приемлемый тест и показать результаты (на всякий — сам тест критиковать не стоит, а просто сделать лучше/правильно и опубликовать).Какие-то биндинги для питона есть, но вне opensource. Сделать их по мотивам LMDB-шных достаточно просто. Но сам я питоном не пользуюсь, а на LMDB-шные были какие-то нарекания. Поэтому не стал делать лишнего (кому надо — тот сделает, а я добавлю ссылку).
Корректнее сказать "до 20%" быстрее, так как во многих тестах до 99.9% времени занимает обмен с диском. Тем не менее, примерно такие результаты фиксируется бенчмарками оценивающими скорость работы самого движка (например, при размещении БД в tmpfs). Аналогичные результаты буду при больших/толстых транзакциях (с множеством апдейтов), т.е. libmdbx тратит меньше тактов CPU внутри себя.
Получено ускорение за счет переработки реализаций внутренних компонентов (например, списка грязных страниц и т.п.) и микро-оптимизаций. Но никакого простого ответа дать нельзя, отличий очень много. В частности, в MDBX всегда работает автокомпактификация и используетcя
madvise()— поэтому "в долгую" libmdbx всегда выигрывает (нередко в разы).Для бенчмарков используется ioarena, субмодуль LMDB там установлен на версию 0.9.24. Однако, в LMDB очень давно не было каких-либо изменений влияющих на производительность (только исправление багов и течей памяти), т.е. разнизы не будет с любыми версиями за последние 2-3 года.
Если будут еще вопросы, то лучше задавать в телеграм-группе (создана на днях).