- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
for (size_t i = 0; i < 4; ++i) {
__m128 x0 = _mm_loadu_ps((const float*)blocks[0] + i * 4);
__m128 x1 = _mm_loadu_ps((const float*)blocks[1] + i * 4);
__m128 x2 = _mm_loadu_ps((const float*)blocks[2] + i * 4);
__m128 x3 = _mm_loadu_ps((const float*)blocks[3] + i * 4);
__m128 t0 = _mm_unpacklo_ps(x0, x1);
__m128 t1 = _mm_unpackhi_ps(x0, x1);
__m128 t2 = _mm_unpacklo_ps(x2, x3);
__m128 t3 = _mm_unpackhi_ps(x2, x3);
x[i * 4 + 0] = _mm_castps_si128(_mm_movelh_ps(t0, t2));
x[i * 4 + 1] = _mm_castps_si128(_mm_movehl_ps(t2, t0));
x[i * 4 + 2] = _mm_castps_si128(_mm_movelh_ps(t1, t3));
x[i * 4 + 3] = _mm_castps_si128(_mm_movehl_ps(t3, t1));
}
Follow us!
Похоже, что там и перебор придётся делать на SIMD, чтобы соответствовать.
По идее можно стартовать так:
aaaaaa@gmail.com
baaaaa@gmail.com
caaaaa@gmail.com
daaaaa@gmail.com
Следующим шагом будет:
aaaaab@gmail.com
baaaab@gmail.com
caaaab@gmail.com
daaaab@gmail.com
Но мы не можем запихать четыре емейла в один регистр. Нужно транспонировать матрицу.
Возьмём другую идею. Стартуем так:
aaaaaa@gmail.com
baaaaa@gmail.com
caaaaa@gmail.com
daaaaa@gmail.com
Следующим шагом будет так:
bbbbbb@gmail.com
cbbbbb@gmail.com
dbbbbb@gmail.com
ebbbbb@gmail.com
Потом стартовый шаблон меняют.
Всё равно ничего в голову не идёт...
Код, который я запостила в этом треде именно это и делает )))
Всего 8 команд у тебя на транспонирование 4х4 уйдёт. Ну плюс выгрузки-загрузки если нужны.
g++ -O3: 4 Mh/s;
clang++ -O3: 3,5 MH/s;
cl /O2: 3 MH/s.
Интеловская библиотека по идее не должна давать разные результаты, там большая часть на ассемблере. Значит, оптимизация поиска по мапе разная.
С какими ключами можно выжать самый быстрый код в gcc, в clang и в msvc? PGO чем-нибудь поможет?
Он иногда может делать только хуже, кстати.
Две идеи:
1. Сократил количество вызовов итератора по именам. Заранее нагенерировал несколько префиксов, а потом к каждому префиксу добавлял суффикс, возвращённый итератором (не через strcat, а тупо через memmove, потому что размеры мне известны).
2. Использовал PGO.
Всё-таки, можно что-то выжать, меняя алгоритмы подбора.
Да можно прям в буфере инкремент делать, чтобы совсем zero copy.
Тебе всё равно надо учиться делить пространство на регионы чтобы треды поддержать. Вот выдай каждому буферу свой регион с конкретным префиксом, суффиксом и диапазоном символов и пусть себе инкрементит.
Заодно suspend/resume можно организовать чтобы не начинать каждый раз с нуля.
Когда дошли до azzzzzz@mail.ru, нужно обновить строку до baaaaaa@mail.ru, т. е. выполнить инкремент одного разряда и сброс шести.
Если мы параллельно считаем суммы для строк с разными префиксами или с разными суффиксами, то мы одновременно будем выполнять одну и ту же рекурсивную проверку с инкрементами. А можно её сделать один раз на все префиксы/суффиксы и расклонировать результат. Так выходит быстрее.
Да, тоже норм подход.
Хотя инкрементится обычно один символ. Переносы амортизируются, в среднем это О(1).
Преобразованием системы счисления числового счётчика будет медленно, потому что там нужно выполнять дофига делений с остатком.
1024-- и я додумались только до рекурсивной проверки условия, когда разряд дошёл до последнего символа алфавита. При таком алгоритме проверять все разряды придётся редко.
Только что подумал ещё об одной идее: предварительно сгенерировать массив часто перебираемых подстрок. Например, трёхсимвольных комбинаций букв латинского алфавита всего 17576, трёхсимвольных комбинаций букв латинского алфавита и цифр всего 46656. Их можно закэшировать, тогда проверок будет меньше. Хотя, пожалуй, лучше взять четыре. Тогда каждая кобенация займёт 32-битный регистр.
Ставлю на инкремент при помощи таблички nextChar (и если старший бит стоит -- значит надо следующий тоже). Перенос амортизируется его редкостью, переход всего один.
Который я написал в ответ на этот говнокод https://govnokod.ru/20137
Но это уже только с самодельной реализацией md5 возможно.
Просто входные данные приходится немного препроцессить, чтобы слова упаковать по 8 в регистр (то самое транспонирование).
Если данные будут сразу лежать как надо, можно неплохо сэкономить.
Выходное транспонирование тоже по идее можно выкинуть, просто хеши будет чуть сложнее сравнивать и memcmp уже не прокатит.
uint8_t data[8][64]
Первый индекс номер блока, второй позиция в блоке.
Как оптимально для avx:
uint32_t data[16][8]
Первый индекс позиция в блоке, второй номер блока.
Приходишь с утра на работу, открываешь IDE на джаве. К вечеру оно наконец-то прогревается. Ты говоришь "just in time!" и идёшь домой.
Интересная вещь. Компилятор передаёт линкеру метаданные. По сути похоже на то, как выглядит линковка в языках, в которых модульная система была изначально.
Жалко, что на уровне языка модулей нет, а только архаичный препроцессор...
Блин, почти портировала на AVX, но что-то запуталась в транс-понировании матрицы 8х8... Кручу-верчу запутать хочу.
А подсматривать у интела как-то неспортивно.
https://github.com/intel/isa-l_crypto/tree/master/md5_mb
Интересно, а AVX сборка у тебя сравнима с интелом будет? Или их код лучше?
З.Ы. ideone чот криво настроено, avx не умеет.
std::unordered_set:
15 MH/s (37% на вычисление хеша, 60% на проверку по хешмапе)
std::unordered_set + 20-битная битмапа:
25 MH/s (74% на вычисление хеша, 20% на проверку по хешмапе)
Может быть у меня лапки?
По идее надо подобрать параметры так, чтобы для 68000 вставленных элементов (эталонные хэши) вореатность ложного срабатывания была где-то в районе 1e-6, плюс-минус пара порядков — чтобы на один мегахэш были единицы (помимо реальных совпадений) «выпаданий» из горячего цикла.
Видимо сама мапа не такая уж тяжёлая, чтобы её защищать ценой лишних кешмиссов.
А фильтр довольно жирный даже для 5% (19 бит).
В фильтре Блума 6 хэш-функций, размер фильтра — 2 в 19 степени.
Куда крутить?
С фильтром на 21 бит получил 3 промаха на миллион, а скорость стала только меньше.
Теория говорит, что для n = 68000 (количество элементов в фильтре) и e = 1e-6 (желаемая вероятность false positive) нужно k = -log2(e) ≈ 20 хэш-функций и m = -1.44*math.log2(e)*68000 ≈ 1951700 бит в фильтре.
В такой задаче фильтр Блума мешает, потому что тратится время на его расчёт.
– Jawa8, чтобы играть в Майнкрафт.
– Jawa16, чтобы играть в Майнкрафт, написанный на новых версиях Jawa (если играть на старых версиях Jawa, то можно соснуть СТРАШНЫЙ EXCEPTION).
– jawa6, если ты работаешь в БАНКЕ.
Т.е. софт, написанный на Jawa8, может не запуститься на Jawa16 и наоборот, какой пиздец! В итоге все россказни про единую виртуальную машину и экосистему оказались ЛОЖЬЮ, ведь нужно иметь ДЕСЯТКИ виртуальных машин... Это всё продиктовано жаждой наживы корпорастов из Jawa-корпорации: засрать всю свободную оперативную и энергонезависимую память виртуальными машинами, чтобы пользователь не установил другие программы.
Какой анскилл )))
У меня вот в коде ни одной лаллокации после того как инициализация пройдена.
+ Integer i = new Integer(42);
- int i = 42;
Я хочу еще с префетчем поиграться, как пи предлагал.
После вычисления хешей проверять не текущую пачку, которая только закончилась, а прошлую. При этом стратегически расставив префетчи так, что нужные регионы хешмапы к этому моменту окажутся в L1 и проверка пройдёт мгновенно.
З.Ы. Или вообще переплести проверку и рассчёт, не разбивая их на фазы. Во время расчета не нужна память, во время проверки не нужен проц. Вроде должно хорошо сочетаться.
У тебя для твоих процов нет эмулятора или профайлера умного чотбы показать кешмисы, занятость префетчера, ождание памяти итд
Так у тебя есть Витюня, или ты просто знаешь, как это работает?
arm'ы (Cortex M) безусловно сложнее, но тоже без фанатизма.
У современного камня всё так насрано внутри, что я вообще уже слабо понимаю что там происходит
http://bugmenot.com/view/intel.com
nereyex908:bsuL4CQm25AV! подошёл.
У меня в общем-то была учётка, я там какие-то курсы про fpga слушала. Но они посчитали, что я давно не захожу и ёбнули её.
У них на сайте много чего изменилось. Оригинальный «icl» и компилятор «Фортрана» они куда-то убрали, а вместо «icl» теперь предлагают скачать модифицированный «Шланг», правда, с интеловскими библиотеками.
Что он даёт, чего нет в perf?
Хотя борманд может наверное и с perf справиться.
vtune еще небось умеет читать всякую проприетарную питушню, про которую интел никому не рассказывает
Блядь, вот я дура... Кто ж прогресс замеряет одним атомарным счётчиком на все 12 тредов.
Заменила на 12 отдельных счётчиков, разнесённых на кешлайн. Сразу 250 Mh/s -> 440 MH/s (64% от теоретических 12 х 57 MH/s)
Надо std::map std::set всё-таки выкорчевать и заменить на что-то приличное.
https://github.com/martinus/robin-hood-hashing
А на что заменить упорядоченную карту, пока не знаю.
Хочется выбить какое-нибудь круглое число в духе 500 MH/s, выложить куда-нибудь и забить.
На Heap
А если у штеуда в процах был дебажный бэкдор, то давно уже была атака типа Spectre.
Напридумывали трёхбуквенных названий, из которых ничего не понятно.
Теперь 54 Mh/s (62% вычисление хеша, 37% генератор и проверка по мапе). 8 хешей параллельно.
12 тредов: 170 Mh/s
6 тредов: 125 Mh/s
4 треда: 105 Mh/s
3 треда: 92 Mh/s
2 треда: 77 Mh/s
1 тред: 54 Mh/s
С одной мапой и одним фильтром на всех 185 Mh/s
переодически стопает треды и записывает их стек трейс?
Отличное занятие для прохладного осеннего вечера...
Правда мне куду лень вспоминать.
Казалось бы, если у каждого треда своя питушня, то нет лишних взаимодействий и изолированный код проще писать и компилировать.
С отдельным счётчиком на каждый тред параллелиться стало считай в 2 раза лучше.
Ну и да, обращений в L3 было овердохуя из-за того, что я в очередной раз облажалась с размером кеша (6 х 256К а не 1.5М).
Детские ошибки, в общем.
какой GIL ))
https://github.com/1024--/voretions/blob/master/src/md/vorec-hist-2014-09-16.md
Генератор вореций можно обучить на сайте с большим количеством юзеров (я набрал кучу таблиц юзернеймов с разных сайтов). Да, будет неполный перебор, что-то можно пропустить, но зато будет шанс найти длинные логины.
Для начала попробовал тупо выбрать четырёхсимвольные слайсы изо всех юзернеймов «Говнокода». Их оказалось всего 45 тысяч (при полном переборе таких сочетаний было бы два с половиной миллиона).
Тупо сконкатенировав два таких слайса, можно получить два миллиарда восьмисимвольных кобенаций. А если применить вореции (марковские цепи), то можно найти вменяемое количество более длинных кобенаций.
Какая-то фантастика. Даже неоптимальный алгоритм с использованием std::string вместо сырых массивов даёт 12 Mh/s.
Обучил на юзернеймах «Говнокода». При ограничении на длину вореции 11 символов нашёл 542 емейла за очень короткое время.
Надо будет попробовать на чём-нибудь более сложном обучить.
А у StertorPidor локальная часть вообще 11-значная. Тупым перебором 11-значные комбинации я бы за год не осилил.
- обезьяны, но вероятность ввода осмысленного текста практически равна нулю
- коты, но они обычно зажимают одну клавишу
- остаются люди или боты, но для бота икарус не похож - выглядит слишком умным
Вот можешь почитать: https://acm.timus.ru/problem.aspx?space=1&num=1677&locale=ru
А есть исследования, доказывающие что петух не в состоянии пользоваться клавиатурой?
а зачем тебе? ты спиздил базу хешей и брутишь?
https://youtu.be/ahzyJH-aejU
Оказывается, владелец сайта настроил сервер так, что файлы с расширением .rar, .zip и ещё некоторые отдаются как binary/octet-stream или как соответствующий мимими-тип архива, а все остальные отдаются как text/html или text/plain. Сервер тома с расширениями .r01, .r02, .r03 и т. д. посчитал текстовыми и зачем-то заменил в них байты с кодом 0 на байты с кодом 0x20=32 (код пробела). В итоге распаковать такие файлы можно, только набрутив, какие из пробелов нужно поменять на символы с кодом ноль.
Он на лету перекодировал файлы.
Самое печальное, что он был установлен на серверах шаред хостингов до середины нулевых (когда проблемы кодировок уже и не существовало) и портил файлы
Это что-то про typescript?
хотя тут вообще много аутистов
ASD мне напоминает чувака, который делал TempleOS.
bormand
CHayT
j123123
JloJle4Ka
gost/ISO/PolinaAksenova (хотя тут под вопросом)
Вообще-то она няшка.
> JloJle4ka
Да и она тоже ничего.
С остальным согласен, можно утверждать.
> Да и она тоже ничего.
Да, ставить Gentoo и перебирать всякие полурабочие браузеры для аутистов это вполне норм.
Сначала нужно написать сайт, чтобы там выложить потом исходные коды: вдруг получится больше 100 строчек и не удастся захостить исходники на говнокоде.
Но я уже нахожусь в процессе, попозже всё будет готово. И можно будет «найти путь к безопасности в графе опасностей».
Собери еще свой процессор из транзисторов. Зачем: для сервера, на котором тот сайт будет работать.
Потом узнал про клеммы.
А паяю я до сих пор хуёво
А транзисторы из песка?
> макетки с дырками
Это же атсраномически дорого
Электрон не состоит ни из каких кварков или еще какой-то там хуйни, и кварки ни из чего не состоят. Но есть еще какая-то там теория струн, но это уже хуй знает
> наличие цветовой симметpии. Достаточно экспеpиментальных значений
> \alpha_s, явно yказывающих на наличие конфайнмента. Достаточно
> того, что ВСЕ адpонные массы можно паpаметpизовать всего лишь 7ю числами —
> 6 масс кваpков и значение \alpha_s в одной точке. И не только адpонные
> массы, а много чего ещё — пока что все теоpетические зависимости, полyченные
> из QCD, с экспеpиментом совпадают — а, следовательно, пpедставлением о
> кваpках МОЖHО ПОЛЬЗОВАТЬСЯ. Заметь, только подонки-фаллософы пиздят
> пpо «сyществование», «истинности», и томy подобнyю поеботинy. Hаyкy это не волнyет.
Ну так что?
Хороший тест )))
Что вообще значит "русскость"?
С одной стороны, между поляками, словаками, белорусами, украинцами, русскими нет чёткой границы.
С другой стороны, на западе Украины и на севере России можно встретить гены, свойственные финно-уграм (через территорию Украины в своё время прошли венгры, некоторые остались). На юге Украины и России можно встретить гены, свойственные тюркам. В Польше можно встретить ассимилировавших пруссов.
Ещё с одной стороны, Y-хромосому R1a можно встретить не только у славян, но и у таджиков и у киргизов. Поэтому вообще непонятно, какие гены считать основным признаком.
Ну понятно, опять маркетинговое наебалово. L2 тоже "256 KB per core" а не "1.5MB shared". Т.е. надо втиснуть все горячие данные в 256КБ а не в 1.5 метра на самом деле.
Выкинула нахрен std::unordered_set, подтюнила фильтр блума (2 теста по 20 бит).
440 MH/s -> 470 MH/s
Блин, ещё немножко...
В отношении майора Олега Панова, командира 78 отдельной роты спецназа ГРУ, и его заместителя, капитана Александра Ерушевича заведено уголовное дело о превышении должностных полномочий и насильственных действиях сексуального характера. Материалы дела опубликованы в Telegram-канале правозащитного проекта Gulagu.net.
Основатель проекта Владимир Осечкин уточнил «Тайга.инфо», что преступления происходили в районе Уссурийска в расположении подразделений 14 бригады спецназа Главного управления генштаба (бывшее ГРУ). Арестованы ли подозреваемые — неизвестно.
В обстоятельствах уголовного дела, которые опубликовал Telegram-канал, описываются несколько эпизодов с участием командиров. 6 января 2021 года Панов избил рядового, приказал ему раздеться догола, распорядился поставить военному клизму с водой и заставил приседать. После этого Панов заставил рядового лечь на стол животом и изнасиловал его шваброй. Ерушевич снимал происходящее на видео.
В августе 2020 года Панов, угрожая насилием, водил шваброй с надетой на черенок медицинской перчаткой «в области ягодиц и промежности» ефрейтора, которого к нему привели для «воспитательной беседы».
В период с 8 по 16 ноября 2020 года Панов требовал деньги от рядового «на нужды роты». Тот отказался, и командир приказал ему раздеться догола, связал и подвесил на дереве «в положении стоя с вытянутыми вверх руками». После этого Панов избил рядового веткой дерева, параллельно угрожая «применить к нему физическое насилие в виде прикрепления его полового члена к стволу дерева с использованием строительного степлера»