>надо учитывать что такие железки как killcore, CUDA и пр... делаются под
>конкретные задачи если упрощенно,А еще 2 * 2 == 4, приколитесь?Кило ядер могло бы выступить как мультимедийный сопроцессор, крипто-сопроцессор (не для всех алгоритмов - не все хорошо параллелятся) или что-то подобное, разгружающее системный проц и ускоряющее вычисления.Как SPE у Cell.А вот general purpose проц под произвольные задачи из кило ядер - никакой, потому что на ряде задач которые не параллелятся он сильно сольет обычным.Восьмибитное ядро даже на 125MHz сольет с тааааааким треском допустим ARM11@400MHz что у юзера челюсть отвалится, когда какойнить заурядный ARM ту же задачу раз в 100 быстрее рюхнет, не говоря уже о навороченных монстриках типа х86 :)
>и можно долго пороть чушь про алгоритмы, про мощное ядро
Это не чушь.Долгое время подавляющее большинство систем (что мобильных, что десктопных) было однопроцессорными и потому подавляющее большинство софта делалось с допущением что процессор - один.Сейчас, в эпоху многоядерников это жестоко икается.Достаточно включить мозг и ... и просто посмотреть на бенчи.До сих пор даже игры которым скорость работы на вес золота не умеют нормально параллелиться.Ну а остальные программы - и подавно.Ессно, алгоритмы в итоге никто и никогда не задачивал на многопроцессорнеость. Умеет параллелиться небольшое количество софта, в основном - серверного (где многопроцессорность была уже давно). А вот попытки влоб заменить general purpose проц чем-то типа кила ядер - обломаются.У general purpose проца задачи - разные.И это может оказаться и 262 144 (если не вру) взятия SHA от предыдущего результата SHA чтобы RAR архив расшифровать.И хрен вы это распараллелите.А на *одном* *дохлом* ядре вы загнетесь ждать 262 144 прохода SHA.При этом в то время как ОДНО ядро будет упираться, остальные будут курить бамбук поскольку задача не распараллелилась -> обломайтесь типа :)
>(раньше ж оказывается не было многопроцессорных машин, а народ то
>не в курсе) и прочее....
Вы лучше скажите как ВЫ собираетесь параллелить циклический расчет SHA от предыдущего результата SHA от предыдущего результата SHA ... и так (в RAR) 262 144 раза.Чтоб брутфорсерам жизнь малиной не казалась.А на обычном проце это означает лишь задержку на 0.5 ... несколько секунд до начала распаковки на прогон циклов.Но это как раз в допущении что ядро - мощное.То же самое на пачке задохликов будет смотреться уныло.Задержка будет в десятки-сотни секунд.Пока один задохлик считает 262 144 циклов SHA.Распихать циклы на 1000 задохликов не катит: чтобы начать очередной цикл надо знать результат прошлого цикла.И распихивание хоть на миллион процов даст нулевой эффект.Один хрен они будут ждать пока очередной цикл отстреляется на ОДНОМ процессорном ядре.В итоге общая скорость выполнения такого алгоритма даже на проце с миллионом ядер будет как на ОДНОМ таком ядре.Все будет определяться только временем за которое одно ядро способно взять SHA и ... все :).Да, на 1000 задохликах вы в принципе можете запустить параллельно 1000 таких операций.Но время завершения каждой из них будет достаточно длительным.И обычному юзеру надо открыть архив и его не устроит ждать допустим 100 секунд для этого вместо 1 и для НЕГО такой проц будет полной ГАДОСТЬЮ.С другой стороны, любитель брутфорса запустив 1000 проверок на разный пароль на 1000 ядер (у юзера 999 из них ничего не делали) за 100 секунд получит результат для 1000 разных паролей (1000 операций параллельно, каждая завершается за 100 секунд).С точки зрения хацкера проц великолепен, потому что итог в 10 паролей в секунду для RAR - офигительный результат особенно для какой-то там мелочевки.Но заметьте, у хацкера более другая, потенциально параллелящаяся задача нежели у юзера и так знающего пароль архива :)
Disclaimer: RAR с его хитрым хэшированием пароля взят лишь как показательный пример и не более того.Алгоритмов где следующие действия зависят от предыдущих в природе дофига.Соотношения взяты из головы\с потолка и могут не коррелировать с действительностью(скорее всего я сильно переоценил в этом примере ядра Kilocore и на практике все будет даже намного печальнее).
P.S. кстати Интел в своем i7 в данный момент подобную проблему учел, сделав довольно забавную технологию - если нечто плохо параллелится и "лишние" ядра ничего не делают, а значит и жрут мало - раз так, можно резонно задрать частоту ОДНОМУ ядру на котором идет выполнение повыше и при этом по прежнему вписаться в общий тепловой баланс чипа.Раз тепла от соседей нет, значит своего можно и побольше нагенерить.Это одна из причин по которой i7 довольно сильно натягивает AMDшников в задачах которые не параллелятся.AMD крутит такие задачи на ядре в обычном состоянии, с стандартной для всех ядер частотой.А интель в таком случае турбирует одно ядро и (по прежнему влезая в заявленный TDP) выжимает больше, при прочих равных.Т.к. то самое "одно крутое ядро" становится временно даже еще круче.Данный фортель требует грамотного управления питаловом прямо самим процессором но интель это как видим осилил.АМДшникам да и остальным соответственно есть над чем подумать о том что можно подкрутить в general purpose процах чтобы они не тушевались и на не параллелящихся задачах.
