Comments 50
Вы это чего? зачем в 21 вере MD5 хэш брутфорсить? нормально подбирается коллизия в течении десятков минут с помощью md5coll. Или это была чисто теоретическая задачка?
-5
Чисто теоретическая. Показать на примере два подхода к распаралелливанию задачи.
+2
Можно за несколько минут создать 2 текста с одним md5 хэшем, но подобрать коллизию к заданному тексту или хэшу так просто уже нельзя.
0
UFO just landed and posted this here
может быть виндошная реализация omp умней чем линуксовя, но вам явно не хватает объявления private(strHash, stream) в прагме, без этого могут встречаться ситуации, когда пароль никогда не будет найден
«платить» за критическую секцию все равно придется
«платить» за критическую секцию все равно придется
+1
Запускал под виндой, проблем не было. Не исключаю, что я что-то упустил, но я не вижу проблемы. Объявление переменных strHash и stream происходит внутри тела цикла, т.е. они, если я правильно понимаю, для каждого потока будут своими. Вот если бы я вынес их объявление за тело цикла, тогда бы пришлось использовать private(strHash, stream). По моему как-то так.
0
может быть виндошная реализация omp умней чем линуксовя, но вам явно не хватает объявления private(strHash, stream) в прагме
В статьях по ссылкам выше:
По умолчанию общими являются все переменные, за исключением переменной цикла, которая является индивидуальной. Память можно объявить как индивидуальную следующими двумя способами.
* Объявите переменную внутри цикла (внутри директивы OpenMP) без ключевого слова static.
* Укажите индивидуальное выражение в директиве OpenMP.
И там же пример с комментариями:
// This works. The variable temp is now private #pragma omp parallel for for (i=0; i < 100; i++) { int temp; // variables declared within a parallel construct are, by definition, private temp = array[i]; array[i] = do_something(temp); }
Так что вроде все верно и логично, если переменная объявлена внутри цикла, она по умолчанию приватная, если снаружи, общая.
+3
Я с первого прохода по коду (глазами) не углядел, где там маппится, а где редъюсится. Я правильно понял, что решает в данном случае всего лишь прагма на цикл?
Ещё было бы интересно узнать, возможно ли как-нибудь так же просто, параллелится за пределы одного сервера.
Ещё было бы интересно узнать, возможно ли как-нибудь так же просто, параллелится за пределы одного сервера.
0
Да, добавляем прагму на цикл и получаем параллельное выполнение.Происходить это будет следующим образом (на примере первой итерации):
0
Извиняюсь, почему-то вставка текста привела к отправке коммента.
Current password: 8250000 Elapsed time: 0 sec.
Current password: 8500000 Elapsed time: 0 sec.
Current password: 8000000 Elapsed time: 0 sec.
Current password: 8750000 Elapsed time: 0 sec.
Т.е. первый цикл начал работу с 8000000, второй 8250000 и т.д. Насчет на разных серверах не скажу, не сталкивался, хотя тоже интересно.
Current password: 8250000 Elapsed time: 0 sec.
Current password: 8500000 Elapsed time: 0 sec.
Current password: 8000000 Elapsed time: 0 sec.
Current password: 8750000 Elapsed time: 0 sec.
Т.е. первый цикл начал работу с 8000000, второй 8250000 и т.д. Насчет на разных серверах не скажу, не сталкивался, хотя тоже интересно.
0
можно. с помощью mpi
+1
Cluster OpenMP (ru preview, eng download), но лучше и вправду MPI, для большего контроля.
0
зачем делать многопоточную программу, когда можно параллельно запустить 2 однопоточные?
при этом только нужно разделить входные данные, чтобы дважды их не обрабатывать
при этом только нужно разделить входные данные, чтобы дважды их не обрабатывать
+4
Это просто «синтетический» пример, необходимость многопоточных вычислений может возникнуть, например, в 3D редакторе, при рендеринге изображений.
0
да, вы предлагаете тогда запускать запускать 100 программ когда нужно 100 трэдов? и сто лишних дескрипторов процессов повиснут где то в памяти ядра… не стоит забывать, что context-switch между трэдами одного процесса и между процессами происходит в десятки раз быстрей
0
нафиг переключаться? делим задание на 100 отдельных частей и каждому процессу назначаем отдельное задание, какие еще переключения?
0
каких только извращений не придумает человек, лишь бы не использовать языков с нативной многопоточностью
+2
эрланг, например )
0
К сожалению, для некоторых задач, таких как брутфорс, Erlang проигрывает чистому C в 20-60 раз. Мне однажды было проще написать на С однопоточную прогу и запустить 8 процессов на моей 8-ядерной рабочей телеге, чем ждать, когда закончит работать Erlang. Да, можно было бы на других компах запустить процессы, но согласитесь, это получается, что ~50 компов нужно, чтобы уравновесить.
P.S. Я использовал Erlang HiPE, обычный по понятным причинам даже не рассматривал.
P.S. Я использовал Erlang HiPE, обычный по понятным причинам даже не рассматривал.
+1
а как насчет Java?
В арифметике Java даже превосходит С++. И не слушайте вы этих школьников «жаба тормозит!!!!1111111111111111111111»
В арифметике Java даже превосходит С++. И не слушайте вы этих школьников «жаба тормозит!!!!1111111111111111111111»
-6
С Java никогда дела не имел и предубеждений против неё нет. Может, она и лучше была бы. Ведь очень неплохая библиотека JTS(JTS Topology Suite) написана именно на ней, а мы в своей работе используем её порт на C++ — GEOS.
Но сейчас у нас уже в обработке данных C/C++, Python и всяческие скрипты на shell/bash/perl. Уже планируется использовать Erlang. Ещё одного языка нам с коллективом 8 человек не потянуть.
Но сейчас у нас уже в обработке данных C/C++, Python и всяческие скрипты на shell/bash/perl. Уже планируется использовать Erlang. Ещё одного языка нам с коллективом 8 человек не потянуть.
0
Ява тормозит.
+2
что-то я количественных оценок быстродействия не встретил. А так — rainbow tables в руки и вперёд.
+1
а можно использовать OpenMP без Visual Studio
я сторонник Unix технологий
>При этом вычисление пароля вторым методом, на моем компьютере, выполнялось значительно быстрее.
желательно такие заявления подтверждать цифрами. что стоит запустить таймер перед вычислениями и остановить после.
И еще посторить 10-100 итераций для усреднения…
Зато наглядно.
я сторонник Unix технологий
>При этом вычисление пароля вторым методом, на моем компьютере, выполнялось значительно быстрее.
желательно такие заявления подтверждать цифрами. что стоит запустить таймер перед вычислениями и остановить после.
И еще посторить 10-100 итераций для усреднения…
Зато наглядно.
+2
UFO just landed and posted this here
недавно встретил задачку(не помню уже где): есть 2^128 md5 хешей, требуется найти число прообразов
-1
Хотелось бы все таки разницу в цифрах увидеть.
+1
Извините, но статья практически ни о чем. Да, есть explicit thread creation, есть OpenMP, а еще есть Threading Building Blocks, Parallel Pattern Library, GPGPU, SIMD-оптимизация. Если уж показывать разные варианты, то не в стиле A vs. B, особенно если учесть что задачка весьма специфичная, а не обобщенная (как например умножение матриц).
+1
UFO just landed and posted this here
Согласен, код можно заставить быстрее и без многопоточности. Но если уж нам достался 2-х, 4-х и т.д. процессор почему бы не использовать его на всю катушку.
0
Кроме счета на видюхе есть технология MassCore — отнимает у винды несколько ядер в пользование проги, на них больше нету context-switch и считать намного веселее, особенно если написать чтобы в кеше все уместилось.
0
Предлагаю внести stringstream stream внутрь тела цикла в функции _WorkerThread.
Потому что оператор << добавляет данные в поток.
Так что в конце там оказывается очень динная строчка.
Кроме того, delete [] хорош к месту, в функции _WorkerThread должен быть простой delete.
Потому что оператор << добавляет данные в поток.
Так что в конце там оказывается очень динная строчка.
Кроме того, delete [] хорош к месту, в функции _WorkerThread должен быть простой delete.
+1
а еще openmp кроссплатформенный метод.
0
Sign up to leave a comment.
Использование OpenMP для распараллеливания вычислений