Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Компания IBM ведет переговоры о покупке Sun Microsystems, opennews (?), 18-Мрт-09, (0) [смотреть все] Не знаю почему, но я почемуто подумал о MySQL Возможно для нее будет опять пере, просто Я (?), 13:37 , 18-Мрт-09, (1) // А я об OpenOffice Может его наконец приведут в порядок , Аноним (-), 13:44 , 18-Мрт-09, (2) // Здесь много о чём можно думать - продуктов много хороших от Sun а , deboon (?), 13:53 , 18-Мрт-09, (3) // СТОП MySQL - это не Sun овский продукт Вы что то путаете То что Sun купила Му, просто Я (?), 14:08 , 18-Мрт-09, (5) в жабе все дело в интерпрайзной жабе -D, vitek (??), 14:11 , 18-Мрт-09, (7) Именно так , Щекн Итрч (ok), 15:37 , 18-Мрт-09, (16) А я о NetBeans - очень нехотелось бы чтобы его закрыли впользу конкурирующего пр, Ivan (??), 17:14 , 18-Мрт-09, (22) // 1IBM жутко неповоротливая компания и очень негибкая Мир уже сто раз изменится,, IGX (?), 02:18 , 19-Мрт-09, (41) // Есть немного, но не беспорно Полный бред Чего только стоят их HI-END решения К, x (?), 07:48 , 19-Мрт-09, (43) Про AIX тока смешить не надо До солярки ему ой как далеко в плане прозрачности , Pavel (??), 10:25 , 19-Мрт-09, (53) Ну смотря, что называть прозрачностью С Solaris опыт работы маленький, работал , x (?), 11:01 , 19-Мрт-09, (55) Это ты хорошо загнул, мощно Внушаить ODM это конечно могучий концепт Но сми, Михрютка (?), 11:51 , 19-Мрт-09, (58) Да, просто к слову - , x (?), 13:07 , 19-Мрт-09, (60) С POWER не работал Особенностей не знаю Сказать могу лишь то, что для высокопр, IGX (?), 14:24 , 19-Мрт-09, (63) Не говорите ерунды , Щекн Итрч (ok), 20:47 , 19-Мрт-09, (73) Судя по тому как развивается Eclipse этого не скажешь, евг (?), 04:48 , 19-Мрт-09, (42) Ога IBM уже купила Informix в свое время , Fylhtq (ok), 13:31 , 23-Мрт-09, (86) Ловлю свою челюсть по столом А на самом деле, а нужно ли IBM, с его PowerPC, AI, alex (??), 14:07 , 18-Мрт-09, (4) // Под Linux я подразумеваю интересы IBM в развитии этой ОС и соответственно, огром, alex (??), 14:09 , 18-Мрт-09, (6) // на java у ibm очень многое завязано и не только у них кстати посмотрим е, vitek (??), 14:14 , 18-Мрт-09, (8) Sun - это опыт команды Star OpenOffice и права на MySQL и MaxDB, если я не ошиба, Jay (??), 14:45 , 18-Мрт-09, (12) Java полюбому развивать будут, в IBM эта весчь в почете Вероятно вслед за ней н, Александр (??), 14:38 , 18-Мрт-09, (10) // ага, и ZFS под GPL откроют , fresco (??), 18:14 , 18-Мрт-09, (26) // А нафига им ZFS, у них прекресная собственная реализация LVM JFS2 , x (?), 07:52 , 19-Мрт-09, (44) да нет в той реализации ничего прекрасного, fresco (??), 09:50 , 19-Мрт-09, (48) А ты засвети, чем ZFS лучьше по сравнению с той реализацией , x (?), 11:03 , 19-Мрт-09, (56) устал уже рассказыватьудобством использования, производительностью, масштабирова, fresco (??), 11:23 , 19-Мрт-09, (57) Все это в равной степени относится и к LVM JFS2 для AIX не будем забывать, что , x (?), 13:03 , 19-Мрт-09, (59) 1 для AIX -- я готов поверить, хотя кода не видел 2 объективных тестов произв, fresco (??), 15:27 , 19-Мрт-09, (65) спорный вопрос зато на линух btrfs ложится отлично я бы её к релизу вообще, vitek (??), 16:53 , 19-Мрт-09, (70) Судя по тому как IBM купила компанию Rapport Incorporated, и после этого kilocor, Аноним (21), 17:05 , 18-Мрт-09, (21) // Скорее всего - его время просто не пришло Сейчас софт еще не готов к такому проц, User294 (??), 17:24 , 18-Мрт-09, (23)   // Результаты сравнительных тестов говорят совсем обратное http smoking-room ru d, Аноним (21), 17:44 , 18-Мрт-09, (24)   Если просто ВКЛЮЧИТЬ МОЗГ, то будет понятно что эффективно параллелятся не все а, User294 (??), 20:40 , 18-Мрт-09, (30)   надо учитывать что такие железки как killcore, CUDA и пр делаются под конкрет, anonymous (??), 22:24 , 18-Мрт-09, (34)   А еще 2 2 4, приколитесь Кило ядер могло бы выступить как мультимедийный со, User294 (??), 13:36 , 19-Мрт-09, (62)   Про шифрование Я не знаю конечно как это реализовано в самом раре, но как така, Читатель (?), 16:58 , 19-Мрт-09, (72)   Не катит, там ключ шифрования строится из результата 262 144 циклов SHA насколь, User294 (??), 11:38 , 20-Мрт-09, (80)   Все сочинение не осилил, но суть понял Основная проблема - синхронизация Только , Читатель (?), 00:45 , 22-Мрт-09, (85)   gt оверквотинг удален Подпишусь на твой бред Интересное сравнение приводишь , iZEN (ok), 19:43 , 28-Мрт-09, (88)   Расчет самих SHA-2 и SHA-1 параллелится Достаточно посмотреть на сами алгоритмы, anonymous (??), 02:15 , 20-Мрт-09, (76)   И сколько удается достичь на практике Кило дохлых ядер там все-равно не достигне, User294 (??), 13:18 , 20-Мрт-09, (81)   Даже если не умеет - есть одновременно сотня клиентов и их запросы обслуживаются, Kaiser (ok), 04:45 , 20-Мрт-09, (77)   Да я все это прекрасно понимаю - не думайте, что мозг только у вас работает - не, Аноним (21), 22:30 , 18-Мрт-09, (35)   Включите мозг Паролей много, каждый пароль можно перебирать на своём ядре, хоть, www2 (??), 10:19 , 19-Мрт-09, (52)   Я думаю будет тоже самое, что было когда-то с решениями DEC Compaq Помните Их к, x (?), 08:00 , 19-Мрт-09, (45) Заголовки поправльте SUBJ - Кстати, по слухам, тс-с-с никому не говорите, Andrey Mitrofanov (?), 14:21 , 18-Мрт-09, (9) // ну это же круче, чем пхп -D, vitek (??), 15:46 , 18-Мрт-09, (17) А может, еще операционку на брейнфаке под все это сделать Ессно опенсорц На б, User294 (??), 16:21 , 18-Мрт-09, (20) А что будет с ZFS А вдруг ее под GPL вывалят , Аноним (-), 14:42 , 18-Мрт-09, (11) // Некоторых больше интересует люстра вот Ау, Юра Уманец Дело есть, тебе писали т, Michael Shigorin (ok), 15:00 , 18-Мрт-09, (13) // он вроде как ушел из sun, fresco (??), 09:56 , 19-Мрт-09, (49) Тогда ждем порт в линукс, metallic (?), 15:04 , 18-Мрт-09, (14) // Да ну его нафиг, лучше БТР работающий , User294 (??), 15:29 , 19-Мрт-09, (66) опен соляра рип and only linpuks everywhere sucksss , аноним (?), 15:25 , 18-Мрт-09, (15) // сделали бы нормальное комьюнити, не зависящее от одной компании, жил бы дальше , vitek (??), 15:50 , 18-Мрт-09, (18) Вот теперь троллюги от санок на своей шкуре заценят почему зависимость от одного, User294 (??), 16:07 , 18-Мрт-09, (19) Как вы думаете, на каких продуктах будет смена лицензии , chemtech (?), 18:03 , 18-Мрт-09, (25) // Я думаю, что ни на каких Оптимизм здешних комментаторов изрядно веселит Вы что, b (?), 19:08 , 18-Мрт-09, (27) // да успокойтесь вы нахрен не нужна уже ZFS в Linux года 3 назад очень бы пригод, fresco (??), 09:58 , 19-Мрт-09, (50) // 1 да и только , User294 (??), 13:28 , 20-Мрт-09, (82) если это случиться в чём я лично сомневаюсь , то на все как минимум одно слово, vitek (??), 20:32 , 18-Мрт-09, (29) да обломится скорее всего у них не осилят но если внезапно осилят это будет , dry (?), 19:28 , 18-Мрт-09, (28) // жесть у меня, например, на особенностях солярки завязаны мои собственные комм, Аноним (21), 21:23 , 18-Мрт-09, (31) // Так было с Tru64, когда ее HP заменил в пользу HP-UX, так видимо будет и с Solar, x (?), 08:05 , 19-Мрт-09, (46) Слух о моей смерти был сильно преувеличен Марк Твен , linked (ok), 22:00 , 18-Мрт-09, (32) // ага -Dно он уже и правда умер , vitek (??), 22:39 , 18-Мрт-09, (37) Угу Бог умер сказал Ницше, Ницше умер сказал Бог , northbear (??), 09:46 , 19-Мрт-09, (47) // Что сказал Ницше, слышали в его время живущие, а что сказал Бог, никто не слышал, bAlex (?), 23:03 , 20-Мрт-09, (83) http top rbc ru economics 12 02 2009 280173 shtml на счету у Sun Microsystems , IGX (?), 22:34 , 18-Мрт-09, (36) Кстати, VirtualBox тоже хороший продукт , Аноним (-), 22:44 , 18-Мрт-09, (38) // да, продукт отличный если его закроют, заменить будет нечем бесплатных ал, Voviandr (??), 13:12 , 19-Мрт-09, (61) Интересно, почему эта новость в мининовостях , а не на главной Довольно таки з, fa (??), 23:52 , 18-Мрт-09, (40) ладно, чего разошлись-то микрософт, вон, yahoo уже год покупает -- и что , fresco (??), 10:02 , 19-Мрт-09, (51) Даешь Solaris на железе pSeries , Pavel (??), 10:28 , 19-Мрт-09, (54) Тут еще надо вспомнить про серверные системы Все-таки ж Sun свои пять копеек , DerNews (?), 15:50 , 19-Мрт-09, (67) // Линк на цифры http online wsj com article SB123735970806267921 html The deal w, DerNews (?), 15:58 , 19-Мрт-09, (68) Меня больше безспокоит не судьба открытых поектов Sun - ибо даже у IBM рука лрог, atx (?), 16:28 , 19-Мрт-09, (69) // Во-о-о-т и чего в сане т2 так дорого стоят то где экспансия на рынок , vitek (??), 16:57 , 19-Мрт-09, (71) ну и хрен с их спарком как в прочем с айбиэмовским повером работая в телеком, Аноним (74), 01:10 , 20-Мрт-09, (74) // эолюция клетки споры -D, vitek (??), 01:20 , 20-Мрт-09, (75) Не знаю, уровень обсуждаемого телекома, но есть еще и банковская сфера, есть еще, x (?), 06:50 , 20-Мрт-09, (78) // и слава богу , fresco (??), 09:40 , 20-Мрт-09, (79) // Наблюдал в одной конторе стойку набитую слимами от IBM На вопрос PowerPC AIX -, bAlex (?), 23:17 , 20-Мрт-09, (84) Блэйды не всем по карману, небольшие конторы предпочитают 1U 2U А Sun, как и HP, sky (??), 15:39 , 23-Мрт-09, (87) 1,4,9,11,15,25,28,32,36,38,40,51,54,67,69,74

Сообщения

[Сортировка по времени | RSS]

	23. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от User294 (??), 18-Мрт-09, 17:24
	>Судя по тому как IBM купила компанию Rapport Incorporated, и после этого >kilocore вообще исчезло с горизонта Скорее всего - его время просто не пришло.Сейчас софт еще не готов к такому процессору.А потому такой процессор просто будет неконкурентоспособен против одного или нескольких мощных ядер на том же количестве кремния.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от Аноним (21), 18-Мрт-09, 17:44
	Результаты сравнительных тестов говорят совсем обратное! http://smoking-room.ru/data/pnp/kilocore.html http://www.3dnews.ru/tags/Kilocore http://www.telesys.ru/wwwboards/mcontrol/1302/messages/23169... http://www.membrana.ru/articles/technic/2006/04/05/190100.html http://www.mobile-review.com/articles/2006/april-itogi.shtml К многоядерникам софт готов, к GPU с неодним streaming multiprocessors - CUDA, VDPAU и все такое тоже уже используется... а к kilocore неготов? ;) Не смешите меня... Но после покупки - спустя год даже сайт разработчиков прикрыли: http://www.rapportincorporated.com/kilocore/kilocore.html Успел пару тройку pdf-ок затянуть - вот и вся информация что осталась от него... А технология еще как востребована - она просто революционная - и корпорации-монстры забеспокоились о таком конкуренте! И исход очевидный и закономерный в нашем мире...
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от User294 (??), 18-Мрт-09, 20:40
	>Результаты сравнительных тестов говорят совсем обратное! Если просто ВКЛЮЧИТЬ МОЗГ, то будет понятно что эффективно параллелятся не все алгоритмы.Алгоритмы где следующая часть рассчетов зависит от предыдущей тупо не параллелятся вообще.Как минимум без кардинального пересмотра подхода.А когда у вас не параллелящийся алгоритм окажется на кучке задохликов, проц с одним или несколькими мощными ядрами в такой ситуации порвет всех как тузик грелку.Ибо ОДНО дохленькое ядро kilocore будет должно побить мощное ядро, а с этим - опаньки.Пока что на 2-4 ядра то софт нормально не перенесли еще весь.Да и некоторый не перенесут вообще т.к. хреново параллеолится. >К многоядерникам софт готов, к GPU с неодним streaming multiprocessors - CUDA, >VDPAU и все такое тоже уже используется... а к kilocore неготов? >;) Не смешите меня... Просто включите мозг и подумайте о том что бывают алгоритмы которые не параллелятся. Например: WinRAR да и 7zip используют такой фокус для торможения брутфорса: берется хэш пароля, от него еще раз хэш.От него еще хэш ... и так XXX XXX раз. И, кстати, это - не параллелится, потому что не зная прошлый результат вы не можете начать следующее хэширование. На мощном проце при штатном юзеже никаких проблем.Задержка в полсекунды которые мощное ядро молотит это при создании архива - ну совсем не проблема.А вот брутфорс срывается - перебор 2 паролей в секунду на том же процессоре выглядит с точки зрения хацкера крайне уныло и неперспективно :).А теперь представим что вместо одного мощного ядра - тысяча маломощных.Поскольку чудес не бывает, каждое конкретное ядро будет в сотни раз слабее.А теперь представьте себе паузу при создании архива уже не в 0.5 секунды а допустим 200 секунд.Как, круто, да?И вот таких алгоритмов, которые хрен распараллелишь - есть.Потому что десятками лет было "одно мощное ядро".А не "сотня задохликов". Заметьте, на GPU и многие ядра спихивают то что параллелится.Да, видео декодировать в кучу потоков фигня вопрос.А вот что не параллелится ... с ним то что делать?Юзеров не устроит слив в сотни раз.А чтобы впихать тыщу ядер на кристалл каждое придется сделать примитивным и медленным.В итоге как только попадается не параллелящийся алгоритм - такой чип круто сливает "крутому ядру" или "несколько сравнительно крутых ядер".Потому что скорость будет равна скорости 1 ядра.Вот как *сопроцессор* (как SPE в Cell) оно могло бы и рулить.Но сопроцессор - отдельный чип, оно денег стоит и потому никому не надо, без него выкрутятся.А вот как general purpose молотилка оно не катит. >А технология еще как востребована - она просто революционная Чего там революционного?Графические процессоры и т.п. уж давно что-то такое из себя и представляют.И у революционеров есть свои проблемы.Все многопроцессорные потуги налетают на тот факт что некоторые алгоритмы просто последовательные а потому им до балды на число ядер :) >- и корпорации-монстры забеспокоились о таком конкуренте! >И исход очевидный и закономерный в нашем мире... Ой, ладно вам.Вы просто представьте себе выполнение на ОДНОМ, ВОСЬМИБИТНОМ ЯДРЕ навороченного но не параллелящегося алгоритма.И тогда вы поймете какие будут морды у обладателей данного чипа в некоторых ситуациях.Это как Cell - в некоторых задачах крут но в general purpose выполнении программ (наиболее интересном юзерам) - совершенно зауряден и неказист.Да, он может на SPE обсчитывать забойные графические эффекты или MD5 ломать с ускорением по числу SPE.А вот обычные программы выполнять - скорость как у одного PPE, однопроцессорного и все такое и баста :P.Посему загрузив на PS3 линух с точки зрения юзера получаем хиленькую и не ахти какую системку.Килокоры данный тип проблем ессно тоже касается.Айбиэм сначала вроде хотели развивать направление но видимо просто не осилили.Под такой проц надо совсем другой софт.Писаный с нуля и по совсем иным принципам.Где его такой взять?Они под Cell то програмеров со скрипом находят...
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от anonymous (??), 18-Мрт-09, 22:24
	>>Результаты сравнительных тестов говорят совсем обратное! > >Если просто ВКЛЮЧИТЬ МОЗГ, то надо учитывать что такие железки как killcore, CUDA и пр... делаются под конкретные  задачи если упрощенно, и можно долго пороть чушь про алгоритмы, про мощное ядро(раньше ж оказывается не было многопроцессорных машин,  а народ то не в курсе) и прочее....
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от User294 (??), 19-Мрт-09, 13:36
	>надо учитывать что такие железки как 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 процах чтобы они не тушевались и на не параллелящихся задачах.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от Читатель (?), 19-Мрт-09, 16:58
	Про шифрование... Я не знаю конечно как это реализовано в самом раре, но как такая мысль: первый вариант: файл разбивается на блоки, и т.о. получить хорошее ускорение? Другой вариант: Много файлов и каждый обрабатывается в своем ядре. третий вариант: поставить ядра друг за другом цепочкой. Я не готов с полной увереностью сказать про шифрование, но 1. если используется блочное шифрование, но там изначально все разбито на блоки. И каждый блок вполне себе может шифроваться на своем ядре. 2. Если используется поточное шифрование, то для получения лавинного эффекта можно распределить вычисления между ядрами, выстроив их последовательно, а именно ядро №001-024 - выработка ключевой последовательности ядро №025-128 - само шифрование. А если вспомнить принципиальные схемы, то там обычно несколько входов (разные ядра) и один выход (ядро последней итерации). Во всем написанном мною для меня как программиста не сталкивавшимся толком с многоядерностью только одна проблема: как организовать взаимодействия между потоками.Что в прочем не является сверх проблемой, для алгоритмического решения. С.У. Читатель
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от User294 (??), 20-Мрт-09, 11:38
	>Я не знаю конечно как это реализовано в самом раре, но как >такая мысль: Не катит, там ключ шифрования строится из результата 262 144 циклов SHA (насколько я понял их механику).Это было надо чтобы подгадить брутфорсерам.За счет такого подхода тысячи PPS упали до 1...несколько PPS на мощном проце :).При легитимном юзеже для юзера почти незаметно: на обычном более-менее мощном general purpose проце мощности пня 3 или выше это - лишь маленькая пауза до начала работы с архивом.Полсекунды (плюс-минус лапоть) юзер подождет до начала распаковки\упаковки.Но оно так на МОЩНОМ ядре.А на ДОХЛОМ юзер будет ждать пропорционально дольше пока оно отпедалит 262 144 цикла.И эти циклы не параллелятся потому что для начала очередного надо знать результат предыдущего.Итого вот так в лоб - все определяется скоростью выполнения на даденом ядре одного цикла SHA.Может быть можно разнести на несколько ядер сами циклы, но это довольно сомнительно, да и нет там ничего на 1000 процов.И вот подобных алгоритмов - есть.В сжатии, шифровании и прочем результат часто зависит от предыдущего, что здорово мешает распараллелить все это дело (ждать предыдущий результат - придется и толку с распараллеливания будет ноль). Или вот например еще: как вы представляете себе распараллеливание ARCFOUR (как достаточно простой для понимания алгоритм) шифрующего непрерывным потоком?Я вот так сходу вижу только очень извращенские методы не дающие к тому же выигрыша в скорости в лоб, только n-разовое повышение *пикового* throughput'а по числу ядер весьма дорогой ценой (заранее обмолотить ядрами поток до нужной позиции и ждать там своего часа после чего втопить обсчет своего сегмента) при *средней* скорости потока - как на одном процессоре (каждое ядро будет доходить до определенной позиции потока со скоростью 1-процессорной системы и в случае непрерывного потока на пределе возможностей CPU все это даст ровно нулевой выигрыш vs 1 ядро - оно за то же время и так домолотит поток до той же позиции:P) >первый вариант: файл разбивается на блоки, и т.о. получить хорошее ускорение? Пауза до начала шифрования\дешифрования на прогон 262 144 циклов SHA чтобы просто получить из пароля ключ никуда не денется.И юзеру придется ждать пока эти циклы прогонятся.Чем дохлее ядро - тем дольше.А поскольку не параллелится вот так сходу - ждать придется именно столько и никак иначе.Итого на расшифровку 5кБ архива уйдет 100 секунд на SHA циклы + крохи на все остальное.На проце с мощным ядром 0.5 секунды + какая-то мелочь.Как вы думаете, что выберут юзеры?Правильно - они не будут переться от проца с множеством дохлых ядер в таких ситуациях.И поверьте, это встречается много где :) >Другой вариант: Много файлов и каждый обрабатывается в своем ядре. А паузу в допустим 100 секунд это не уберет :P >третий вариант: поставить ядра друг за другом цепочкой. А что это даст?Если такой алгоритм распихать на много ядер - закончится тем что одно молотит а остальные ждут результатов с того которое молотит.Потом следующее молотит а остальные ждут с него результат.И т.п. - скорость будет как на одном ядре. Кстати вы верно заметили что разбивка на блоки... но как вы понимаете, в эпоху однопроцессорных систем МАЛО КТО ГРЕЛ МОЗГ ЭТИМ ВОПРОСОМ.Поэтому полно форматов данных, протоколов, алгоритмов и стандартов которые сделаны не так и потому - нифига не параллелятся. >Я не готов с полной увереностью сказать про шифрование, но >1. если используется блочное шифрование, но там изначально все разбито на блоки. Да, в одной из его инкарнация можно выиграть.Только это самый поганый вид шифрования.Если вы шифруете все блоки одним ключом, очевидно что 2 одинаковых блока на входе == 2 одинаковых на выходе.Что позволяет хацкерам узнавать много нового о том что вы там пихаете.Никогда не видели как имеючи 2 картинки зашифрованных AESом чуваки восстанавливали контуры изображения путем нехитрых математических действий над двумя шифрованными вариантами? :).А в случае если key scheduling как-то завязан на предысторию, параллелимости настает каюк - из-за предыстории как раз :) >И каждый блок вполне себе может шифроваться на своем ядре. Вот только результат этой вот независимости - полное дерьмо как то утечка информации о структуре данных в шифрованном потоке.Одинаковые блоки на вход дают одинаковый результат на выход.И если вы послали 5 Кбайт нулей, атакующий легко может стать в курсе что вы послали именно 5Кбайт нулей.По пачке одинаковых пакетов.А уж если он свой plaintext может впарить - вообще труба, т.к. можно заранее пропихать сюжетно интересные пакеты и посмотреть как они в шифрованном виде выглядят.После чего иметь неплохое представление о том что в шифрованном потоке летает.Не полное но - достаточно неслабое. >2. Если используется поточное шифрование, то для получения лавинного эффекта можно >распределить вычисления между ядрами, выстроив их последовательно, а именно >ядро №001-024 - выработка ключевой последовательности Ну вон тот же arcfour - прост как топор.Слабо себе представляю как несколько тривиальных действий распихнуть на несколько процов.Там оверхед синхронизации будет больше чем просто смолотить всю операцию на 1 ядре (а что вы собрались параллелить в перестановке 2 байтов в массиве? :D). >ядро №025-128 - само шифрование. У того же arcfour например шифрование сводится аж к целому XOR псевдорандомной последовательности с последовательностью данных.И что вы там параллелить собрались?Это быстрее генерации псевдорандомной последовательности а ее генерацию вы хрен с два запараллелите - а там особо нечего параллелить - все просто как топор, 2 числа в массиве переставить :).Итого - вот так влоб от 103 процессоров будет нулевой выигрыш.С ксоркой справится и один а генереж псевдорандома вы имхо не запараллелите :). В алгоритмах типа AES и подобных вас ожидает подстава в том что результат следующего раунда зависит от прошлого.Тоже фиг с два вот так в лоб запараллелишь - 1 ядро будет молотить раунд а остальные пардон будут ждать когда оно смолотит.Ничегонеделая :P.И как вы представляете в результате припахивание к этой операции 20 процессоров?Побить на независимые блоки?См.выше :P.А если они зависимые - параллельносьти не получится.Из-за зависимости как раз - придется ждать пока кто-то домолотит до нужного места чтобы узнать результат и начать обмолот с этого места.И поскольку само "ядро" алгоритма параллелится туго - ждать придется скорее всего столько же сколько при выполнении этого алгоритма на 1 ядре.За счет хилости отдельно взятого ядра есть шанс слить классическим 1...несколько ядерникам.С другой стороны - если расшифровку вынести на одно ядро, шифровку на другое, туда сбагрить компрессию, туда декомпрессию, вон тот гребет прерывание 1, а вон тот - прерывание 2, вон тот - занимается I\O с вон той периферией, ... - такая мелочь по сумме выполняемых задач может 1-ядерник и обойти.Если повезет.А если не повезет - сольет с треском.Ну вот потому такое и не делают.Как максимум - IBM с его Cell, который штука ядреная но - для специфичных задач.Да, ему фигня вопрос H.264 в реалтайме с HD качеством давить с его кучкой SPU.И там где раньше над этим пахала большая пачка прожорливых ксеонов может стоять один Cell, если софт оптимизнуть.Но пачка ксеонов намного быстрее выполняла general purpose задачи в ОС чем этот Cell :P.А на мобильных устройствах и т.п. задачи все-таки ближе к general purpose чем специальным.Ну вот кило ядер и оказалось мало кому надо.Может когда и запихнут как сопроцессор-акселератор, типа как произвольные вычисления на GPU на десктопах но - не более того.Именно основным процессором ему не бывать, по крайней мере - не сейчас.Вот видимо айбиэмщики поперлись от крутости а прикрутить реально никуда не осилили.Т.к. для декода H.264, кодирования с камер в жпег и т.п. у чипмэйкеров уже давно есть свои железки-акселераторы, кому надо крутую графику - есть видеочипы или встроенное ускорение. А больше "мобильщикам" ничего и не надо особо.Они думаю просто не хотят платить денег айбиэм за неочевидные выигрыши :) (выигрыш от кила ядер очевиден только узкой прослойке хакерофф на которых никто не ориентируется ессно :D) >Во всем написанном мною для меня как программиста не сталкивавшимся толком с >многоядерностью только одна проблема: как организовать взаимодействия между потоками. Самое плохое - что попытка разнести простые и быстрые операции (в шифровании, хэшировании и т.п.) как раз уткнется в то что синхронизация затормозит все больше чем получится выигрыш :).Процы обычно быстры в выполнении команд а вот с внешним миром взаимодействие медленнее (айбиэмщики по этой причине воткнули для SPU довольно приличную локальную память чтобы SPU могли достаточно долго и независимо молотить без вмешательства "дирижера", но на килограмме ядер большую память каждому ядру не выделишь...).Кстати из подобных по структуре чипов - есть конторка Parallax которая делает довольно извращенные микропроцессоры с подобной структурой так что айбиэм скупивший кило ядер - не единственные кого приперло поизвращаться с экстремальными подходами.Конечно ядер не 1000 но для мелкого чипа embedded класса многоядерность как у параллакса весьма неслабая :) >Что в прочем не является сверх проблемой, для алгоритмического решения. В теории - да :) а на практике когда процы быстро только инструкции молотят а I\O с внешним миром заметно медленнее - выигрыш от разнесения простых операций может не получиться а достаточно большие блоки вычислений могут параллелиться не всегда.Ну вон распараллельте тот же ARCFOUR?Я сломав мозг придумал только как получить пиковую производительность в N раз.При СРЕДНЕЙ - как у одного ядра практически :D.Не больно супер-дупер, да?С другой стороны - это плохо для VPN сервера и т.п. - где одно толстое соединение которое потребно шифровать как можно быстрее.А если это торрент клиент где соединений 100 а каждое из них не очень крутое, каждое можно независимо распихать (де)шифроваться на свой процессор без каких-либо проблем :).Но это - потому что повезло и есть чему параллелиться.Есть много случаев где "не повезло", что и сдерживает появление многоядерников и многопроцессорников на десктопах и в мобильном сегменте.Реально большие количества ядер востребованы пока разве что на серверах т.к. там есть чему параллелиться.Ну собссно серваки с 4 проца по 4 ядра в серверах не редкость.Это конечно не кило ядер но уже кое-что :).На серверах все-таки нужны не ядра-задохлики как в килограмме ядер а полновесные ядра.И их пока удается впихивать все-таки не тысячами :)
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от Читатель (?), 22-Мрт-09, 00:45
	Все сочинение не осилил, но суть понял. Основная проблема - синхронизация. Только распаралелить я кажется предлагал циклы, что должно компенировать время синхронизации. При использовании предыдущего блока, ключа и текущего блока я бы предложил воспользоватся общим кешем. При последовательном расположении камней, остальные будут ждать только во время старта. Т.е. когда первый результат передается следующему камню, берется следующий бок и начинается уже его обработка. Т.о. будут задействованы одновременно будут задействованы 1-2-3-4-5-6-6-6-6-5-4-3-2-1 камней. Что не дает выйгрыша во времени при обработке малых объемов, но дает его при больших.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от iZEN (ok), 28-Мрт-09, 19:43
	>[оверквотинг удален] > >При использовании предыдущего блока, ключа и текущего блока я бы предложил воспользоватся >общим кешем. > >При последовательном расположении камней, остальные будут ждать только во время старта. >Т.е. когда первый результат передается следующему камню, берется следующий бок и начинается >уже его обработка. Т.о. будут задействованы одновременно будут задействованы 1-2-3-4-5-6-6-6-6-5-4-3-2-1 камней. > >Что не дает выйгрыша во времени при обработке малых объемов, но дает >его при больших. Подпишусь на твой бред. Интересное сравнение приводишь. :)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от anonymous (??), 20-Мрт-09, 02:15
	Расчет самих SHA-2 и SHA-1 параллелится. Достаточно посмотреть на сами алгоритмы. Циклический расчет может нет, не могу сказать как это сделано в rar с защитой от перебора  но от что-то тесты говорят что rar на много-ядерных/много-поточных системах работает быстрее от 1.3-1.5 раза. Что-то тестеры делают не так.... И упирая на последовательность алгоритмов вы упираете на их конечные результаты. Ваш приведенный пример с rar. Один пароль от другого, а распараллелить получение пароля - это как? Да программ написанных бездумно и опирающихся на халяву по производительности от Intel/AMD много, но сколько лет назад появилась HT(первая ласточка)? Не могу утверждать но я уверен что что-то подобное было и раньше у SUN, IBM и HP. Просто оно не было ширпотребом. Да и для многопроцессорных систем ПО было как бы и раньше. По всяким CUDA, kilocore - А теперь представим что надо обрабатывать данные от 100-200 датчиков одновременно? Кто шустрее будет, 100 но по 8 или 10 но по 64? Тут приводили тесты выше. Не надо сравнивать процессоры общего назначения и спец назначения. Не благодарное занятие. Либо сравнивать на идентичных задачах.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	81. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от User294 (??), 20-Мрт-09, 13:18
	>Расчет самих 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 проц.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от Kaiser (ok), 20-Мрт-09, 04:45
	> Умеет параллелиться небольшое количество софта, в основном - серверного (где многопроцессорность была уже давно). Даже если не умеет - есть одновременно сотня клиентов и их запросы обслуживаются в разных потоках (вероятно и в разных процессах).
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	35. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от Аноним (21), 18-Мрт-09, 22:30
	Да я все это прекрасно понимаю - не думайте, что мозг только у вас работает - не переживайте так... Если вы внимательно читали по ссылкам - то могли видеть что разработчики позаботились и о компиляторе, и о языке программирования (asm C) и о многом другом... Вопрос не в том кто кого перегонит - вопрос как раз в том - где пременить эти возможности и тогда следует вопрос о пересмотре архитектуры вцелом... Ну и опять же не в этом проблема... Я килокоре как пример привел к данной ситуации... Если уж ничего не получилось с проектом - то почему бы не написать об этом тоже - а в ответ тишина (это я на счет килокоре...)... на power.org кстати тоже притихли... Я не говорю что килокоре круче всех и вся - но, в четко опреледенных, задачах - лучшего пока не видно с учетом показателя производительность/мощность потребления... И есть опасения в том, что прикупив другую конторку, измениться(если не прикратится) направление развития некоторых проектов, купленных заочно вместе с компанией...
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	52. "Компания IBM ведет переговоры о покупке Sun Microsystems"	+/–
	Сообщение от www2 (??), 19-Мрт-09, 10:19
	>Например: WinRAR да и 7zip используют такой фокус для торможения брутфорса: берется >хэш пароля, от него еще раз хэш.От него еще хэш ... >и так XXX XXX раз. И, кстати, это - не параллелится, >потому что не зная прошлый результат вы не можете начать следующее >хэширование. На мощном проце при штатном юзеже никаких проблем.Задержка в полсекунды >которые мощное ядро молотит это при создании архива - ну совсем >не проблема.А вот брутфорс срывается - перебор 2 паролей в секунду >на том же процессоре выглядит с точки зрения хацкера крайне уныло >и неперспективно :) Включите мозг. Паролей много, каждый пароль можно перебирать на своём ядре, хоть там YYY YYY раз от него хеш берётся.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема