>Расчет самих SHA-2 и SHA-1 параллелится. Достаточно посмотреть на сами алгоритмы.И сколько удается достичь на практике?Кило дохлых ядер там все-равно не достигнет особых успехов, ИМХО.Потому что межпроцессорная синхронизация потребует времени и врядли получится огромный выигрыш vs просто обмолот инструкций на одном проце.Сие конечно зависит от соотношений скоростей обмолота инструкций ядрами и латентности I\O с соседними процами но я абсолютно уверен что распихать SHA на 1000 ядер будет неэффективно.В тепличных условиях (тормозное ядро но мизерная латентность обмена между ядрами) - ну может удастся сам SHA на несколько задохликов впихнуть.На сильно много не удастся, синхронизация убьет весь выигрыш.Но несколько задохликов не сделают 1 мощное ядро упиханное на той же площади кристалла что и весь килограмм ядер.Пока эти задохлики будут тасовать данные в своих 8-битных регистрах (они будут заниматься в основном этой тасовкой на современных алгоритмах ориентированых на 32-64 бита :P) и синхронизироваться, единичное 32...64 бит ядро просто будет на каждый такт обмолачивать приличный кусок алгоритма.Без особых извратов с программированием этого и прочая.
>rar на много-ядерных/много-поточных системах работает быстрее от 1.3-1.5 раза.
Это *сжатие* работает быстрее.И может, распаковка.А оно вполне себе параллелится.А не старт шифрования.Который в раре малозаметен на мощном проце (мелкая пауза в начале работы с шифрованным архивом на доли секунды, которая однако приводит к падению скоростей брута до едва ли считанных PPSов на мощном проце).Эта пауза однако будет совсем не мелкой на проце из 1000 дохлых ядер (1000 навороченных ядер на кристалл впихивать не научились :P).
>Что-то тестеры делают не так....
Все они делают правильно.Сжатие и распаковку можно распихать на несколько процов.Шифрование как минимум вынести в отдельный поток - тоже.Это не отменяет грабли у проца с зиллионом хилых ядер что на генерацию из пароля ключа шифрования уйдет куда больше времени чем у 1 или нескольких мощных ядер и это будет не доли секунды а довольно дофига времени.
>И упирая на последовательность алгоритмов вы упираете на их конечные результаты.
Все получается особенно плохо если раунд алгоритма (тот же рассчет SHA допустим) на проце отстреливается быстрее чем синхронизация (для х86 это не редкость, для килограмма ядер - не факт).Тогда потуги распараллелить теряют смысл.На кило ядер в принципе наверное можно распихать SHA на несколько задохликов учтя тотальную тормознутость индивидуального задохлика и возможность сделать низкую латентность в I\O между ними.Но все-равно обычное ядро впиханное на ту же площадь кристалла порвет этих задохликов.Потому что 1 раунд на слишком много задохликов вы не распихаете а задохлики сами по себе - убогие.Ну а следующие раунды цепляются за результат предыдущего и не могут быть начаты пока не известен результат прошлого раунда.Итого большая часть задохликов будет просто ничего не делать при работе с такими алгоритмами.Но площадь кристалла то они занимают.И вместо бездействующих задохликов могло бы быть 1 или несколько достаточно крутых ядер ;)
> Ваш приведенный пример с rar. Один пароль от другого,
? мой пример был про их чудный алгоритм торможения брутфорса.Когда ключ шифрования вычисляется как нечто типа 262 144 итерации SHA от пароля.Т.е. берется SHA от пароля, от результата этого - еще раз SHA, от этого результата - еще раз и так далее.И очередной раунд зависит от результата предыдущего.Как максимум можно попытаться распараллелить сам SHA в пределах раунда но 1000 процов там явно не смогут одновременно над ним работать.Не над чем просто - с учетом задержек на синхронизацию в лучшем случае 1 раунд SHA можно распихнуть на несколько ядер при условии что латентность обмена между ними сравнима с временем выполнения команд а вот само выполнение команд - крайне дохлое, так что распараллеливание раунда начинает иметь какой-то смысл.И то - на сильно много задохликов 1 раунд не раскидается (а что там 1000 ядер делать то?).
>а распараллелить получение пароля - это как?
В RAR?Получение ключа из пароля за 262 144 цикла SHA?Да по сути почти никак.Ну может сам раунд SHA со скрипом удастся распихать на несколько задохликов вместо 1 и что-то на этом выиграть.На 1000 - распихать не удастся(чего им там в 1000 ядер делать то в одном раунде?).В итоге - такие процессоры часто будут находиться в состоянии "один рубит а семеро в кулак трубят", что и является их проблемой.Такие могут себя показать только на некоторых видах алгоритмов специально подогнаных под них.Данную проблему как видим наши предки описали много лет назад ничего не зная о процессорах вообще :)
>IBM и HP. Просто оно не было ширпотребом.
...и потому большая часть программ, алгоритмов, форматов данных и протоколов просто плевать хотели на то что там умеет не-ширпотреб...
>Да и для многопроцессорных систем ПО было как бы и раньше.
Да.Всякое там серверное ПО и т.п. - там многоядерность была давно.И то - в лоб на килограмм ядер такой софт не прокатит - он делался в допущении "N крутых ядер".А не "килограмм задохликов" ;)
>По всяким CUDA, kilocore - А теперь представим что надо обрабатывать данные
>от 100-200 датчиков одновременно? Кто шустрее будет, 100 но по 8
>или 10 но по 64?
Зависит от математики.Если надо что-то с 64-бит точностью, 100 по 8 сольет 10 по 64 т.к. будет тасовать регистры только, на что уйдет немеряно оверхеда, от которого 64 избавлены напрочь =).А на 8-битной математике - все ессно будет наоборот.
А 200 датчиков... где их столько заwire'ино на 1 проц?Это какой-то экстремальный случай, я такого не видел.Это просто непрактично: 200 датчиков в 1 месте никому не надо.А тянуть 200 проводов к одному процу на большое расстояние - вы заманаетесь однако.В таких системах городят сеть (шину) с малым числом проводов и там где надо - небольшие процы-ноды с разумным числом датчиков и проводов.В итоге - да, может процессоров и больше, но кремний - дешев.А вот длинный кабель из 200 проводов равно как и их протяжка - не очень.
Кроме того, датчики обычно достаточно медленные сущности и с пачкой датчиков обычно без проблем управляется одно 8-битное ядро на вшивом десятке МГц.Правда 200 датчиков на один проц я НИ РАЗУ не встречал.Это изврат, конкретный такой =)
>Тут приводили тесты выше. Не надо сравнивать процессоры общего назначения и спец
>назначения. Не благодарное занятие. Либо сравнивать на идентичных задачах.
Вот я и думаю что при всей забавности идеи айбиэмщики не смогли пока найти таких задач где их кило ядер бы выступало вопиюще хорошо и было востребованно.Максимум чего они реально сделали - это Cell.Штука неплохая но специфичная и не очень интересная как general purpose проц.
