форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от opennews on 18-Мрт-09, 13:37

"Report: IBM is in talks to buy Sun Microsystems (http://www.infoworld.com/article/09/03/18/Report_IBM_is_in_t...)" - компания IBM ведет переговоры о покупке Sun Microsystems. По неофициальным данным в предложении IBM фигурирует цифра в 6.5 миллиардов долларов. В настоящий момент уровень рыночной капитализации Sun оценивается (http://finance.yahoo.com/q/ks?s=JAVA) в 3.7 миллиардов долларов, т.е. IBM предложила выкупить акции по двойной цене. За год цена акции Sun упала (http://www.google.com/finance?q=JAVA) с 17 до 4 долларов за штуку, в 2007 году стоимость акции составляла 25 долларов. URL: http://www.infoworld.com/article/09/03/18/Report_IBM_is_in_t... Новость: http://www.opennet.me/opennews/art.shtml?num=20798

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от просто Я on 18-Мрт-09, 13:37

Не знаю почему, но я почемуто подумал о MySQL. Возможно для нее будет опять переломный момент. Кто его знает, что получится из этого?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Аноним (??) on 18-Мрт-09, 13:44
	А я об OpenOffice. Может его наконец приведут в порядок.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от deboon on 18-Мрт-09, 13:53
	>А я об OpenOffice. Может его наконец приведут в порядок. Здесь много о чём можно думать - продуктов много хороших от Sun'а.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от просто Я on 18-Мрт-09, 14:08
	СТОП! MySQL - это не Sun'овский продукт. Вы что то путаете. То что Sun купила Мухуль, это не означает, что MySQL ее. Теперь ребята пляшут под Sunовскую дудку и это печально. И сразу вспоминаются недавние события об уходе нескольких человек из MySQL. Апдейты стали выходить реже. Так что на Мускуловком примере как раз все наоборот.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 18-Мрт-09, 14:11
	в жабе все дело. в интерпрайзной жабе. :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Щекн Итрч (ok) on 18-Мрт-09, 15:37
	>в жабе все дело. в интерпрайзной жабе. :-D Именно так.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Ivan (??) on 18-Мрт-09, 17:14
	А я о NetBeans - очень нехотелось бы чтобы его закрыли впользу конкурирующего продукта от IBM - Eclipse. Я Netbeans очень люблю. Да и развите Java в руках IBM, боюсь, замедлится.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от IGX on 19-Мрт-09, 02:18
	>Да и развите Java в руках IBM, боюсь, замедлится. +1 IBM жутко неповоротливая компания и очень негибкая. Мир уже сто раз изменится, а IBM этого даже не заметит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 07:48
	>>IBM жутко неповоротливая компания и очень негибкая Есть немного, но не беспорно! >>Мир уже сто раз изменится, а IBM этого даже не заметит. Полный бред!!! Чего только стоят их HI-END решения! Какая там максимальная тактовая частота в продаваемых решениях ITANIUM от INTEL ? Сравните с решениями на POWER6 от IBM!? А с AIX вы не работали!? Одна из самых качественных коммерческих Unix систем. Да много можно перечислять, чего фигней страдать! В общем, не знаете, лучьше не говорите!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Pavel (??) on 19-Мрт-09, 10:25
	Про AIX тока смешить не надо. До солярки ему ой как далеко в плане прозрачности. Да и поодержка у IBM у нас по-крайней мере слабовата. По железу вроде ничего, а по софту - полный отстой. Имеем p595, если что.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 11:01
	>>До солярки ему ой как далеко в плане прозрачности. Ну смотря, что называть прозрачностью? С Solaris опыт работы маленький, работал с HP-UX, с Tru64, про прочее вообще молчу. Так вот на мой вкус, самый концептуальный, качественный, продуманный и интуитивный интерфейс коммандной строки, именно у AIX. Касательно возможностей системы, то здесь в принципе думаю, они все, более менее ходят рядом друг с другом. >>Да и поодержка у IBM у нас по-крайней мере слабовата. Хуже чем у HP, поодержки еще не видел, когда общаешься с их поодержкой такое чувство, что тебя по определению считают уродом! Вообще, касательно поддержки, покупайте железо у партнера, с железом будет и поддержка. Не знаю, лично у нас сейчас все достаточно оперативно и качественно. >>По железу вроде ничего, а по софту - полный отстой. Касательно софта, опять же бред! А вот касательно железа, наоброт те же блейды нам показались более качественными от HP. >>Имеем p595, если что. Имеем, если что p595 на POWER6, у вас никак еще POWER5+!?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Михрютка on 19-Мрт-09, 11:51
	>Ну смотря, что называть прозрачностью? С Solaris опыт работы маленький, работал с >HP-UX, с Tru64, про прочее вообще молчу. Так вот на мой >вкус, самый концептуальный, качественный, продуманный и интуитивный интерфейс коммандной строки, именно >у AIX. Это ты хорошо загнул, мощно. "Внушаить." ODM это конечно могучий концепт. Но смит, да, полезная тулзовина, тут я согласен. по крайней мере защищает неустойчивую психику от того, через какую жопу приходится делать некоторые вполне тривиальные вещи. >Имеем, если что p595 на POWER6, у вас никак еще POWER5+!? уй, че, ядрами померяться предлагаешь :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 13:07
	>>уй, че, ядрами померяться предлагаешь :) Да, просто к слову :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от IGX on 19-Мрт-09, 14:24
	>Какая там максимальная тактовая частота в продаваемых решениях ITANIUM от INTEL ? >Сравните с решениями на POWER6 от IBM!? С POWER не работал. Особенностей не знаю. Сказать могу лишь то, что для высокопроизводительных вычислений альтернатив сейчас достаточно, включая ПЛИС и видеопроцессоры, что, возможно, дешевле. >А с AIX вы не работали!? Одна из самых качественных коммерческих Unix систем. Может быть IBM AIX и качественная. Может быть она даже уровня Sun Solaris. Но даже к Solaris, несмотря на открытость ее исходников, интерес не сильно увеличивается. И проблема здесь в основном Linux. Не предоставляют UNIX-динозавры той гибкости, открытости, переносимости, поддержки, интенсивности развития, которые есть у Linux.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Щекн Итрч (ok) on 19-Мрт-09, 20:47
	>>Да и развите Java в руках IBM, боюсь, замедлится. > >+1 >IBM жутко неповоротливая компания и очень негибкая. Мир уже сто раз изменится, >а IBM этого даже не заметит. Не говорите ерунды.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от евг on 19-Мрт-09, 04:48
	Судя по тому как развивается Eclipse этого не скажешь
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Fylhtq (ok) on 23-Мрт-09, 13:31
	>Не знаю почему, но я почемуто подумал о MySQL. Возможно для нее >будет опять переломный момент. Кто его знает, что получится из этого? > Ога. IBM уже купила Informix в свое время.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от alex (??) on 18-Мрт-09, 14:07

*Ловлю свою челюсть по столом* А на самом деле, а нужно ли IBM, с его PowerPC, AIX и Linux, DB2 и брендом IBM эта покупка, пусть широкоизвестной, но сейчас убыточной компании Sun с (Sparc, Solaris/Opensolaris и Mysql)? Это просто вопрос, знатоков просьба ответить, а не кидаться помидорами. Они правда будут развивать направления Sun?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от alex (??) on 18-Мрт-09, 14:09
	Под Linux я подразумеваю интересы IBM в развитии этой ОС и соответственно, огромные финансовые и иные вложения в эту ОС.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 18-Мрт-09, 14:14
	на java у ibm очень многое завязано. и не только у них кстати... .... посмотрим. ещё не сказали своего слова ораклы, сапы,... мс..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Jay (??) on 18-Мрт-09, 14:45
	Sun - это опыт команды Star/OpenOffice и права на MySQL и MaxDB, если я не ошибаюсь. Думаю, все это очень пригодилось бы IBM в ее работе над коммерческим Lotus'ом. Они уже перепахали первый OOo в Symphony. Плюс куча другой интеллектуальной собственности. Плюс какая-никакая, а все же доля на рынке.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Александр (??) on 18-Мрт-09, 14:38
	Java полюбому развивать будут, в IBM эта весчь в почете. Вероятно вслед за ней не пропадет и Glassfish. Вот судьба NetBeans внушает некоторые опасения. MySQL, думаю, тоже будет на плаву, слишком уж эта тема популярна, чтобы ее вот так сразу слить, тем более что с DB2 она вроде не конкурирует. OpenSolaris скорее всего загнется потихоньку, ибо полюбому не успела раскрутиться как следует, так что IBMу будет проще развивать свои Linux-наработки, возможно перетащив в них какие-то куски соляриса.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 18-Мрт-09, 18:14
	ага, и ZFS под GPL откроют :)))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 07:52
	А нафига им ZFS, у них прекресная собственная реализация LVM+JFS2.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 19-Мрт-09, 09:50
	да нет в той реализации ничего прекрасного
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 11:03
	А ты засвети, чем ZFS лучьше по сравнению с той реализацией?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 19-Мрт-09, 11:23
	устал уже рассказывать удобством использования, производительностью, масштабированием. на русском языке материалы есть по архитектуре обоих решений -- при желании можно разобраться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 13:03
	>>удобством использования, ..., масштабированием. Все это в равной степени относится и к LVM+JFS2 для AIX (не будем забывать, что этот LVM, только концептуально тоже самое, что LVM в Linux или HP-UX). >>производительностью Не думаю, что есть какие либо объективные тесты доказывающие, что ZFS более производительна, платформы на которых они работают не пересекаются.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 19-Мрт-09, 15:27
	1. для AIX -- я готов поверить, хотя кода не видел. 2. объективных тестов производительности вообще в природе нет. вместо этого есть объективный анализ архитектуры и прогнозирование поведения той или иной программы в данных условиях. здесь JFS сдает довольно серьезно -- для многих типовых ситуаций (поучится анализу поризводительности можно по монографиям Кнута) 3. по удобству администрирования, на мой взгляд, даже btrfs от ZFS отстает. не говоря уже про все остальное.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 19-Мрт-09, 16:53
	>3. по удобству администрирования, на мой взгляд, даже btrfs от ZFS отстает. не говоря уже про все остальное. спорный вопрос... зато на линух btrfs ложится отлично... я бы её к релизу вообще в ext5 переименовал бы. :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Аноним (??) on 18-Мрт-09, 17:05
	Судя по тому как IBM купила компанию Rapport Incorporated, и после этого kilocore вообще исчезло с горизонта - с трудом вериться о благих намерениях, тем более IBM-цы явно дали понять, что мы, мол, вас с патрохами купили - и теперь будем делать с вами что захотим...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	80. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от User294 (??) on 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"
	Сообщение от Читатель on 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) on 28-Мрт-09, 19:43
	>[оверквотинг удален] > >При использовании предыдущего блока, ключа и текущего блока я бы предложил воспользоватся >общим кешем. > >При последовательном расположении камней, остальные будут ждать только во время старта. >Т.е. когда первый результат передается следующему камню, берется следующий бок и начинается >уже его обработка. Т.о. будут задействованы одновременно будут задействованы 1-2-3-4-5-6-6-6-6-5-4-3-2-1 камней. > >Что не дает выйгрыша во времени при обработке малых объемов, но дает >его при больших. Подпишусь на твой бред. Интересное сравнение приводишь. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от anonymous (??) on 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? Тут приводили тесты выше. Не надо сравнивать процессоры общего назначения и спец назначения. Не благодарное занятие. Либо сравнивать на идентичных задачах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от User294 (??) on 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) on 20-Мрт-09, 04:45
	> Умеет параллелиться небольшое количество софта, в основном - серверного (где многопроцессорность была уже давно). Даже если не умеет - есть одновременно сотня клиентов и их запросы обслуживаются в разных потоках (вероятно и в разных процессах).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

	45. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 08:00
	Я думаю будет тоже самое, что было когда-то с решениями DEC/Compaq. Помните!? Их купил в свое время HP. И что теперь!? Развитие Alpha-платформы закрыли. Развитие Tru64 Unix закрыли (сами HP-шники ругаются по этому поводу). Да, в итоге, еще и собственные RISC-решения закрыли в пользу Itanium-решений! Возможно тоже будет и с SUN, с их SPARC и с их Solaris. Закроют в пользу решений POWER и AIX. Меньше конкурентов на рынке - больеше сектор влияния, вот и все! :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Компания IBM **опять** ведет переговоры о покупке Sun"

Сообщение от Andrey Mitrofanov on 18-Мрт-09, 14:21

Заголовки поправльте: $SUBJ $-)) Кстати, по слухам, ...тс-с-с! никому не говорите!...  следующая версия жабы будет написана на рексе, переписанном на руби, запущенном под джейруби внутри томкошки с помощью закрытой версии ОткрытогоОхвиза_огра!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Компания IBM **опять** ведет переговоры о покупке Sun"
	Сообщение от vitek (??) on 18-Мрт-09, 15:46
	ну... это же круче, чем пхп? :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Компания IBM **опять** ведет переговоры о покупке Sun"
	Сообщение от User294 (??) on 18-Мрт-09, 16:21
	>Кстати, по слухам, ...тс-с-с! никому не говорите!...  следующая версия жабы будет >написана на рексе, переписанном на руби, запущенном под джейруби внутри томкошки >с помощью закрытой версии ОткрытогоОхвиза_огра! А может, еще операционку на брейнфаке под все это сделать?Ессно опенсорц :).На брейнфаке все можно опенсорцным делать не мучаясь жабой:)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от Аноним (??) on 18-Мрт-09, 14:42

А что будет с ZFS? А вдруг ее под GPL вывалят???

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Michael Shigorin (ok) on 18-Мрт-09, 15:00
	>А что будет с ZFS? А вдруг ее под GPL вывалят??? Некоторых больше интересует люстра вот. Ау, Юра Уманец!  Дело есть, тебе писали три месяца тому.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 19-Мрт-09, 09:56
	он вроде как ушел из sun
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от metallic on 18-Мрт-09, 15:04
	>А что будет с ZFS? А вдруг ее под GPL вывалят??? Тогда ждем порт в линукс
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от User294 (??) on 19-Мрт-09, 15:29
	>Тогда ждем порт в линукс Да ну его нафиг, лучше БТР работающий =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от аноним on 18-Мрт-09, 15:25

(опен)соляра рип?;( and only linpuks everywhere. sucksss.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 18-Мрт-09, 15:50
	сделали бы нормальное комьюнити, не зависящее от одной компании, жил бы дальше... может даже какой-нибудь альт-солярка бы появился.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от User294 (??) on 18-Мрт-09, 16:07
	>(опен)соляра рип?;( and only linpuks everywhere. sucksss. Вот теперь троллюги от санок на своей шкуре заценят почему зависимость от одного вендора-suxx.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от chemtech on 18-Мрт-09, 18:03

Как вы думаете, на каких продуктах будет смена лицензии?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от b on 18-Мрт-09, 19:08
	Я думаю, что ни на каких. Оптимизм здешних комментаторов изрядно веселит. Вы что, думаете, что IBM - это такой большой, добрый и богатый друг FOSS? Лососните тунца, ребята. Где исходники DB2 под одобренной FSF лицензией? Где исходники AIX? Lotus? Rational? Informix? IBM привержена FOSS тогда, когда ей это выгодно. Для чего ей релицензировать ZFS под GPL - чтобы бесплатно усилить позиции Novell и Hed Rat на рынке хранилищ данных?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 19-Мрт-09, 09:58
	да успокойтесь вы. нахрен не нужна уже ZFS в Linux. года 3 назад очень бы пригодилась. теперь поздно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от User294 (??) on 20-Мрт-09, 13:28
	>теперь поздно. +1 да и только =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 18-Мрт-09, 20:32
	если это случиться (в чём я лично сомневаюсь), то на все. как минимум одно слово (сразу после (с)) измениться. ну и пессимистам. коверкать названия (Hed Rat) - оно конечно круто... в определенных кругах. да и говорить, что IBM не поддерживает линух может только профан. всякие AIX, Lotus, Rational, Informix - инырпрайзные продукты. кто-то жалуется на отсутствие? jfs, eclipse,... масса ещё чего, не говоря о вложениях средств... да java открыли не из-за Бразилии. :-D роль же zfs несколько переоценена (и на рынке хранилищ данных тоже). про люстру выше уже писали. про openoffice, mysql, java, glassfish, netbeans... хм, у оо уже есть форк, мускул стал популярен до сан (и будет после), netbeans тоже, java "уже почти" открыта и имеет альтернативы. сан была классной конторой... но политику её я не понимаю последнее время.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от dry on 18-Мрт-09, 19:28

да обломится скорее всего у них. не осилят. но если внезапно осилят... это будет событие даже не масштаба покупки mysql ab сановцами и trolltech нокиями. это про будет поистине полный, самый что ни на есть настоящий - Пи. потому что сановцы хоть и уроды, но чего ожидать от ibm совершенно не понятно. что будет с openoffice, mysql, java, glassfish, netbeans... никто не знает. опенсорс сообщество получит либо союзника, котором нельзя было и мечтать, либо убийцу массы отличных продуктов. а судя по тому, что ibm ничем особенно не прославилась в плане поддержки открытых технологий (ну разве что тем, что не подает патентные иски - но это отдельная опера), то походу получим мы с большой вероятностью второе. жуть в общем чего будет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Аноним (??) on 18-Мрт-09, 21:23
	жесть... у меня, например, на особенностях солярки завязаны мои собственные коммерческие продукты... неужели все приехали ? мда...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 19-Мрт-09, 08:05
	>жесть... у меня, например, на особенностях солярки завязаны мои собственные коммерческие продукты... >неужели все приехали ? >мда... Так было с Tru64, когда ее HP заменил в пользу HP-UX, так видимо будет и с Solaris, когда его, IBM заменит на AIX.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от linked (ok) on 18-Мрт-09, 22:00

Слух о моей смерти был сильно преувеличен. Марк Твен.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 18-Мрт-09, 22:39
	ага... :-D но он уже и правда умер.....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от northbear (??) on 19-Мрт-09, 09:46
	Угу... Бог умер сказал Ницше, Ницше умер сказал Бог...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от bAlex on 20-Мрт-09, 23:03
	>Угу... Бог умер сказал Ницше, Ницше умер сказал Бог... Что сказал Ницше, слышали в его время живущие, а что сказал Бог, никто не слышал...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от IGX on 18-Мрт-09, 22:34

>IBM ведет переговоры о покупке Sun Microsystems. По неофициальным данным в >предложении IBM фигурирует цифра в 6.5 миллиардов долларов. В настоящий момент >уровень рыночной капитализации Sun оценивается (http://finance.yahoo.com/q/ks?s=JAVA) в 3.7 миллиардов долларов... http://top.rbc.ru/economics/12/02/2009/280173.shtml "на счету у Sun Microsystems Inc сейчас порядка 2,6 млрд долл., и эксперты говорят, что компания может стать лакомым кусочком для Hewlett-Packard Co, IBM, Dell Inc или Cisco." В связи с этим сумма в 6.5 миллиардов кажется смешной, особенно если вспомнить покупку компании ATI компанией AMD за 5.4 миллиардов. Sun, мягко говоря, покрупнее и поценнее, чем ATI. >IBM предложила выкупить акции по двойной цене. За год цена акции >Sun упала (http://www.google.com/finance?q=JAVA) с 17 до 4 долларов за штуку, в >2007 году стоимость акции составляла 25 долларов. Да кого, кроме спекулянтов, интересует цена акций, формируемая самими же спекулянтами, тем более сейчас, когда все акции свалились ниже некуда... IBM просто хочет нахаляву заполучить Sun. Надеюсь, Sun останется Sun'ом, а IBM найдет другие варианты для своего развития. Если для Sun их продукты - это их бизнес, что означает, что они заинтересованы в интенсивном развитии своих продуктов, то для IBM по большей части продукты Sun - это балласт, от которого IBM в случае покупки Sun будет избавляться. Очень уж не хочется терять столько всего интересного, сделанного и поддерживаемого Sun'ом.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от Аноним (??) on 18-Мрт-09, 22:44

Кстати, VirtualBox тоже хороший продукт.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от Voviandr (??) on 19-Мрт-09, 13:12
	>Кстати, VirtualBox тоже хороший продукт. да, продукт отличный ! если его закроют, заменить будет нечем ;(((( бесплатных альтернатив я не знаю. надежда на то, что у ibm нет конкурирующего продукта, и потому его не закроют.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от fa (??) on 18-Мрт-09, 23:52

Интересно, почему эта новость в "мининовостях", а не на главной. Довольно таки знаковое событие, даже если это пока только переговоры

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

51. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от fresco (??) on 19-Мрт-09, 10:02

ладно, чего разошлись-то. микрософт, вон, yahoo уже год покупает -- и что?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

54. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от Pavel (??) on 19-Мрт-09, 10:28

Даешь Solaris на железе pSeries !!!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

67. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от DerNews on 19-Мрт-09, 15:50

Тут еще надо вспомнить про серверные системы. Все-таки ж Sun свои "пять копеек" в лице 10% рынка имеет, а IBM - около 30% с мелочью. И с учетом 27-29% у HP, понятно желание IBM прикупить еще "чуток", чтобы поосновательней закрепиться на рынке серверных решений. Хотя, думаю, и на рынке ПО IBM своего не упустит, найдя что-нибудь интересного у Sun. Кстати, что там с антимонопольной службой США? Вопрос: пропустят ли?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от DerNews on 19-Мрт-09, 15:58
	Линк на цифры: http://online.wsj.com/article/SB123735970806267921.html "The deal would strengthen IBM's position as the world's largest server maker. According to the research firm IDC, IBM had 31.4% of the market last year; H-P was second with 29.5%, and Dell third with 11.6%. Sun ranked fourth, at 10.6%."
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

69. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от atx on 19-Мрт-09, 16:28

Меня больше безспокоит не судьба открытых поектов Sun - ибо даже у IBM рука лрогнит их прикрыть... (имхо), а судьба ленейки серверов xFire на SPARC, и судьба самих SPARС'ов...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 19-Мрт-09, 16:57
	Во-о-о-т! и чего в сане т2 так дорого стоят то? где экспансия на рынок?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

74. "Компания IBM ведет переговоры о покупке Sun Microsystems"

Сообщение от Аноним (??) on 20-Мрт-09, 01:10

ну и хрен с их спарком как в прочем с айбиэмовским повером ... работая в телекоме наблюдаю торжественное заселение этой отросли виндовс и линукс на интеле ... так что пускай покупает ... было время когда телеком и sun + sparc + соляра были едины ... а вот ibm за почти 10 лет в телекоме не наблюдал ... эволюция знаетели

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от vitek (??) on 20-Мрт-09, 01:20
	эолюция клетки... споры? :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от x on 20-Мрт-09, 06:50
	Не знаю, уровень обсуждаемого телекома, но есть еще и банковская сфера, есть еще билинг у сотовых операторов и многое другое. В ближайшие годы, винда даже в самых радужных снах не осилит этой сферы. Hi-End решения работающие под Linux тоже пока не видел, хотя с учетом решений виртулициации допускаю, что такое может встречаться. Не будем забывать, что у IBM есть еще и Z-серия. Пологаю, не кадый телекомовец знает, что это такое? Но и на это есть рынок и что самое интересное, виндоусу в этом секторе делать нечего!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от fresco (??) on 20-Мрт-09, 09:40
	> В ближайшие годы, винда даже в самых радужных снах не осилит этой сферы. ... > Но и на это есть рынок и что самое интересное, виндоусу в этом секторе делать нечего! и слава богу!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от bAlex on 20-Мрт-09, 23:17
	Наблюдал в одной конторе стойку набитую слимами от IBM. На вопрос PowerPC/AIX? - ответили Intel/CentOS... Возникла мысль, что IBM опустилась до уровня производства коробков... Потом подумал, что это наверное какой-то китайский IBM... Прочитав эту новость подумалось, что на месте тех слимов могли стоять блэйды от SUN...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "Компания IBM ведет переговоры о покупке Sun Microsystems"
	Сообщение от sky (??) on 23-Мрт-09, 15:39
	>Наблюдал в одной конторе стойку набитую слимами от IBM. На вопрос PowerPC/AIX? >- ответили Intel/CentOS... > >Возникла мысль, что IBM опустилась до уровня производства коробков... Потом подумал, что >это наверное какой-то китайский IBM... > >Прочитав эту новость подумалось, что на месте тех слимов могли стоять блэйды >от SUN... Блэйды не всем по карману, небольшие конторы предпочитают 1U/2U. А Sun, как и HP, и IBM, уже давно опустилась до уровня производства коробов для продукции в нижнем ценовом сегменте. Думаете, какие чипсеты стоят в AMD-серверах от Sun? Nvidia Nforce. Это обычное PC-железо, но в гламурно-ынтырпрайзных корпусах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]