LINUX.ORG.RU

Ларри говорит: «Не отдам спарки!»

 , ,


0

0

Вопреки прогнозам некоторых мировых аналитиков о том, что Oracle продаст железный бизнес Sun на сторону, Ларри Эллисон заявил, что он никому ничего не продаст и все оставит себе. Oracle собирается инвестировать в спарки, и работать вместе с Fujitsu, с которым ранее работал Sun. Он заявил, что разработка и железа, и софта позволяет создавать более совершенные системы (как это делает IBM), чем просто разработка софта, «вот почему телефоны Apple намного лучше, чем телефоны Microsoft».

Покупка компанией Oracle компании Sun (номера 4 на рынке) сделала их номером 2 на рынке хай-энд серверов. «Sun был очень успешен долгое время, продавая системы на базе спарков и соляриса, теперь мы туда добавим ПО Oracle и выведем эти системы на прежний уровень».

Лора ДиДио (аналитик ITIC) отметила, что Sun всегда разрабатывал отличное железо, но был слабоват в маркетинге, а Ларри великолепный маркетолог.

>>> ZDNet

★★★★★

Проверено: anonymous_incognito ()

Ответ на: комментарий от no-dashi

>Та что ви говорите?! Это вы про сравнение UltraSPARC T1 с Xeon?
У вас избирательная сообразительность.
Нет, это про ваш фундаментальный и самоцитируемый первый пост о CINT2006 Result в этом треде - там вы сравнили "якутов и немцев ,и сделали вывод о превосходстве китайцев" через пару страниц обсуждения.
А "сравнение UltraSPARC T1 с Xeon" - вы уже по прайсам типа как "делали".

>Так оно сейчас на сайте предлагается саном и HP, и не находится в >EOL. А теперь покажите, пожалуйста, _сейчас_ в продаже в продаже >указанную вами конфигурацию с Celeron (причем не second hand).


Ну вот ,cнова манипуляции:
UltraSPARC T1,T2 - бывают разные , но мы сознательно это будем игнорировать:)))
Это у Intel надпись на чипсете - всемирный бренд.
А у японцев реклама не такая назойливая.

зы:SUN тоже продает сервера и на Amd & Intel

elipse ★★★
()
Ответ на: комментарий от VIT

>> Да нинасколько, практически

>Вы бы хоть дискуссию то почитали - комментатор!

>В 5-6 раз. Нисколько...

Цыфри - в студию! Отфонарное "В 5-6 раз" - не цифры

Led ★★★☆☆
()
Ответ на: комментарий от Led

> Цыфри - в студию! Отфонарное "В 5-6 раз" - не цифры

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

ps:Офигеть , никогда не предполагал , что подобное придется еще доказывать.
Что "питоны' с мозгами у людей делают :))

elipse ★★★
()
Ответ на: комментарий от elipse

> Нет, это про ваш фундаментальный и самоцитируемый первый пост о CINT2006 Result в этом треде

Приведите SPECint и SPECfp оценивающие производительность для равных условий (равное количество копий и один и тот же тест). Заявления "а вот на сайте Sun написано что это круто" и "а вот у нас тормозит/летает" цифрами не являются.

SPECfp для ниагары есть, и там катастрофа. Сами найдете, или ссылкой кинуть? SPECint для ниагары отсутствует - только SPECint_rate.

Есть правда одно "грязное" сравнение SPECint_rate в неравных условиях (16 копий на интеле против 127 на спарке). Там по любому показателю интел быстрей в 10 и более раз, то есть за то время пока спарка крутит свои 127 копий, интел прогонит 8 раз по 16 копий, на выходе выдав больше выполненной работы и еще успев выспаться. Но для правдолюбцев заранее напишу - это действительно будет нечестное сравнение, поскольку масштабируемость по количеству одновременно выполняющихся задач - величина нелинейная. Цифры тут: Ниагара Т2+: http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080407-04060.html Xeon X5570: http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090330-06838.html

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

ЕМНИП для РС имеется такая вещь, как платы PCI-X, куда можно понавтыкать память. Оно вообще полезно на БД? Как у спарков с этим?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от no-dashi

Я уже все приводил тут . А вам персонально надо ?

Или в угоду вам ,надо "выпиливать" из спарка 4 ядра из 8 ,вырезать многопоточность ... и сравнивать с топовым интелом .

А вообще ,любой современный проц можно поставить в неадекватные условия

- это будет вина архиктектуры или персональная дурость тестера ?

elipse ★★★
()
Ответ на: комментарий от Led

> Цыфри - в студию!

Разговор закрыт (и по поводу 128 бит тоже). Спор ради спора мне не интересен.

Совет старшего товарища:"Прежде чем лезть в разговор, научитесь читать и ознакомтечь с контекстом разговора".

VIT
()
Ответ на: комментарий от elipse

> ps:Офигеть , никогда не предполагал , что подобное придется еще доказывать. > Что "питоны' с мозгами у людей делают :))

Я кстати тоже прибалдел. Тем более, что эти цифры уже приведены в дискуссии. Боюсь, что дело не в питоне. У нас тоже есть питонщики-перлщики. Так они такие глупости не спрашивают. Видимо просто элементарного образования Computer Architecture не хватает (ну или как это по-русски называется, Архитектура ЭВМ?)

VIT
()
Ответ на: комментарий от VIT

> Боюсь, что дело не в питоне.

Дело совершенно точно не в Питоне.

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

>> В 5-6 раз. Нисколько...

> Эта разница мгновенно нивелируется, когда речь начинает идти от объемах данных хотя-бы в 1 мегабайт. Какая разница сколько у вас регистров, если предстоит сделать in-memory sort с последующей группировкой и суммированием для 10 мегабайт? Все равно все упрется в шину данных. А если дело дошло до sort-on-disk, то будь то четырехрегистровая или сторегистровый процессор, все упрется в диск. И сколько проку от этих регистров, если у меня в dictionary cache 16 мегабайт?

Категорически не согласен. Контр-пример Linpack, объёмы побольше гигабайта на узел (ядро), а алогоритм специально строится блочным, чтобы хранить большее число промежуточных данных в регистрах. Стек же вообще не используется, вся программа - линейная. Другой пример - dgemm, впрочем Вы можете сказать, что это одно и то же.

Если речь идёт о диске, то CPU в любом случае стоит на stall. Ясно, что "процессор стоит одинакого на любоё частоте". Но в разговоре о производительности переключения контекстов обычно про диски не говорят.

Про сортировку - разговор особый. Обычно она тоже кэшуется на блоки.

VIT
()
Ответ на: комментарий от elipse

>> Цыфри - в студию! Отфонарное "В 5-6 раз" - не цифры > Да хоть вы уже не позортесь - это азы быстродействия и DSP процессоров.

При чём тут "DSP процессоры"?

>Дебагер x86 в руки, сами посмотрите и посчитайте такты.

Я посчитал: т.н. latency для PUSH/POP и для Intel'овских, и для AMD'шных CPU равно 3, идущие подряд, естественно, могут выполняться параллельно.

>Что "питоны' с мозгами у людей делают :))

А вот здесь соглашусь: больше питона даже бэйсик не тупит:)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>Разговор закрыт (и по поводу 128 бит тоже). Спор ради спора мне не интересен.

Я ошибся на счёт 128-битных float-регистров в K10: регистры-то есть, но комад арифметики для работы со 128-битными float нет, только команды для загрузки/выгрузки 128-битных значений.

>Прежде чем лезть в разговор, научитесь читать и ознакомтечь с контекстом разговора

Согласен. Я "недоознакомился". Вернее, ознакомился по источнику, которому, как теперь вижу, доверять нельзя было. Чтение официальноых спецификаций на набор команд K10 от AMD убедило меня, что я был неправ. Спасибо за ссылку, исходя из которой я в конце концов нашёл официальные PDF со спецификацией.

Led ★★★☆☆
()
Ответ на: комментарий от no-dashi

> Это не я сказал. По опыту выжимания производительности из информикса и оракла, сервер БД крайне редко упирается в CPU, и на 64-битных архитектурах слабым местом является I/O. Когда интелы были 32-битными, спарки имели заметное преимущество. Теперь увы, главное спарковское преимущество - размер адресного пространства процесса - кануло в лету.

Сюрприз - в этом мире есть задачи и помимо Оракла и Информикса. Вы, видимо слишком давно и много занимаетесь базамми данных. Дык иногда полезно вспомнить, что на них компьютинг не заканчивается.

>> Плюс, ваше утвердждение говорит о том, что вы не часто сталкиваетесь с неисправностями в системах на базе Intel

> Я вообще с ними не сталкиваюсь. Самая серьезная проблема была - глюкнувший RAID-контроллер (1 раз).

Ну а раз не сталкиваетесь, то зачем рассуждаете о том, о чем не имеете представления? Не дай бог столкнуться...

ZFSych
()
Ответ на: комментарий от VIT

>Про сортировку - разговор особый. Обычно она тоже кэшуется на блоки.

Потоковая - не больно-то кэшируется...

Led ★★★☆☆
()
Ответ на: комментарий от no-dashi

> Вам же сказали, что Интел сдувается, а SPARC кряхтит, но ворочается

А это ничего что операционки разные, и в них например те же самые I/O scheduler'ы разные? :-)

А это ничего, что в сравнении, на которое я давал ссылку, используется Solaris 10 u4 на той и на другой системах? Так что не катит аргумент :-)

ZFSych
()
Ответ на: комментарий от no-dashi

> Приведите SPECint и SPECfp оценивающие производительность для равных условий (равное количество копий и один и тот же тест).

Вот как раз таки условия, которые вы описываете, и будут сравнивать неизвестно что. Многопоточных процессоров имеет смысл главным образом SPECint_rate и SPECfp_rate...

> SPECfp для ниагары есть, и там катастрофа. Сами найдете, или ссылкой кинуть? SPECint для ниагары отсутствует - только SPECint_rate.

У первой Ниагары был один единственный модуль FPU, так что не удивительно. Этого, впрочем, никто и не скрывал. У второй Ниагары другая история - на момент выхода этот процессор показывал лучшую пропускную способность по вычислениям с плавающей точкой. Время, однако, не стоит на месте, и на смену одним лидерам приходят другие.

> Есть правда одно "грязное" сравнение SPECint_rate в неравных условиях (16 копий на интеле против 127 на спарке). Там по любому показателю интел быстрей в 10 и более раз, то есть за то время пока спарка крутит свои 127 копий, интел прогонит 8 раз по 16 копий, на выходе выдав больше выполненной работы и еще успев выспаться. Но для правдолюбцев заранее напишу - это действительно будет нечестное сравнение, поскольку масштабируемость по количеству одновременно выполняющихся задач - величина нелинейная. Цифры тут: Ниагара Т2+: http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080407-04060.html Xeon X5570: http://www.spec.org/cpu2006/results/res2009q2/cpu2006-20090330-06838.html>

Вот это как раз таки не такое уж и грязное сравнение - сравнивается пропускная способность двухчиповых систем в условиях, когда каждый поток занят полезной работой. Непонятно только, где вы там опять превосходство в 10 раз увидели. Для одного ~150, для другого ~250, то есть разница менее чем в два раза. Всего-навсего! А тактовая частота у интеля более чем в 2 раза выше. Так что не так уж и плохо вторая Ниагара здесь выглядит. А ведь есть и другие критерии оценки. Взять, например, крипто. Тут позиции второй Ниагары до сих пор прочны:

http://blogs.sun.com/bmseer/entry/ultra_fast_cryptography_on_the

По пропускной способности памяти Интели только-только начали подбираться к первой Ниагаре, у которой 3 года назад было 25Гб/с. У второй Ниагары еще больше - где-от 60+ ГБ/с, если не ошибаюсь.

Вы бы сходили, какой-нибудь SPECjbb или SPECjAppServer посмотрели. Более приближенные к жизни спеки все-таки. Ну по крайней мере к вашим любимым задам банных, господин no-dashi :-)

ZFSych
()
Ответ на: комментарий от Led

нет для регистровых push/pop будет 2 такта без учета задержек доступа к памяти и ширины операндов ,модели CPU Intel
А прикол еще и в ином будет:

Допустим ,все всегда по два такта - все двухместные регистровые команды
А с константами и трехместные - по три такта.

Тогда вычисление a = a + b + 5 на нектором мета ассемблере :)):

на трех регистрах и для трехместного сложения:
1.
mov c,#5 (3)
add a,b,c (3)
-------------
6 тактов

на трех регистрах и для двухместного сложения:
2.
mov c,#5 (3)
add a,b (2)
add a,c (2)
-------------
7 тактов

на двух регистрах и push&pop:

3.
push b (2)
mov b,#5 (3)
add a,b (2)
pop b (2)
add a,b (2)
-------------
11 тактов
note:
Для баланса стека команды push&pop в общем случае должны быть парными
или должна выполнятся коррекция указателя стека.


elipse ★★★
()
Ответ на: комментарий от elipse

>2. обойдемся без кулибинства , ok ?

ок:)

То, что в x86 многие команды могут выполняться параллельно (в т.ч. и из-за т.н. "переименования" регистров, "теневых" регистров - это тоже "кулибинство"?

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>1.LEA -- Load Effective Address

>2. обойдемся без кулибинства , ok ?

Кстати, врядли можно назвать "кулибинством" то, что описано в ЛЮБОМ, даже в самом древнем учебнике по x86-ассемблеру.

Led ★★★☆☆
()
Ответ на: комментарий от Led

>То, что в x86 многие команды могут выполняться параллельно (в т.ч. и >из-за т.н. "переименования" регистров, "теневых" регистров - это тоже >"кулибинство"?

ага , и это тоже
также и 4 ярусные кеши в 2 гига с водяным охлаждением ... и прочие костыли.
Так как эти штучки просто маскируют недостатки нативной архитектуры CPU.

elipse ★★★
()
Ответ на: комментарий от Led

>Кстати, врядли можно назвать "кулибинством" то, что описано в ЛЮБОМ, >даже в самом древнем учебнике по x86-ассемблеру.


Не факт ,что это будет делать компилятор.
Может напомнить сколько лет ушло на обуздание кулибинства и создание эффективных компиляторов для x86 ? :))

elipse ★★★
()
Ответ на: комментарий от elipse

Добавлю свои 2 копейки.

То что при обращении к памяти через push/pop посчитали latency уже хорошо. Теперь нужно пойти дальше и посчитать "time to retire", то есть время между инструкцией обновления регистра и время, когда регистр может уже использоваться. Обычно "time to retire" от 2 до 6 тактов, в зависимости от размера и типа обновляемого регистра. В большинстве случаев это надо мерять, поскольку реальное время исполнения будет также зависить от предыдущих и последующих инструкций.

Что касается "что в x86 многие команды могут выполняться параллельно", то load/store как раз не могут. Впрочем, х86 тут не причем. Проблема заключается в том, что для арифметики можно создать конвейерные АЛУ (что и делается для скрытия "time to retire"), то для load/store это сделать нельзя - шину то к кэш никто не дублирует. Если шина занята, то следующий outstanding request вызывает stall. Чтобы скрыть этот stall, обычно делают request-FIFO на какое-то (10-20) количeство запросов, после чего выполняюt flash всей очереди (от 10 до 20 clks).

VIT
()
Ответ на: комментарий от VIT

Короче, как не крути, а 5-6 раз разница набегает легко. Поэтому, больше регистров всяко лучше чем меньше ;).

VIT
()
Ответ на: комментарий от Led

> 4. lea a,[a+b+$5]

> Сколько тактов?:)

Поправьте меня, если я не прав, но мне кажется, что эта инструкция не загружает данные. Оне готовит адрес в регистре. Позже нужно будет использовать этот регистр в качестве адреса в инструкции типа

lea ax,[a+b+$5]

mov dx, ptr[ax]

Могу ошибаться.

VIT
()
Ответ на: комментарий от elipse

>Не факт ,что это будет делать компилятор.

Факт. Компилятор так и делает.

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>Теперь нужно пойти дальше и посчитать "time to retire", то есть время между инструкцией обновления регистра и время, когда регистр может уже использоваться.

В x86 регистров значительно больше, чем имён для них:) Пока регистр будет "обновляться", под его именем уже можно использовать другой.

Led ★★★☆☆
()
Ответ на: комментарий от Led

>> Теперь нужно пойти дальше и посчитать "time to retire", то есть время между инструкцией обновления регистра и время, когда регистр может уже использоваться.

> В x86 регистров значительно больше, чем имён для них:) Пока регистр будет "обновляться", под его именем уже можно использовать другой.

А данные откуда возьмете в "новом регистре"?

VIT
()
Ответ на: комментарий от VIT

>Короче, как не крути, а 5-6 раз разница набегает легко. Поэтому, больше регистров всяко лучше чем меньше ;).

Естественно. Разве кто-то с этим спорил? Вот только даже в тупом x86 регистром НАМНОГО больше, чем вам, возможно, кажется:)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>Поправьте меня, если я не прав, но мне кажется, что эта инструкция не загружает данные. Оне готовит адрес в регистре. Позже нужно будет использовать этот регистр в качестве адреса в инструкции типа

Поправляю. Вы неправы. Эта инструкция вычисляет "адрес" и помещает его в регистр. Я, конечно, ламер, но даже мне это было известно ещё в 80-ых из учебников Абеля и Джордейна:)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>А данные откуда возьмете в "новом регистре"?

Оно там "прозрачно" продублируется (отзеркалится) из "старого регистра"

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Естественно. Разве кто-то с этим спорил? Вот только даже в тупом x86 >регистром НАМНОГО больше, чем вам, возможно, кажется:)

http://www.logix.cz/michal/doc/i386/chp02-03.htm#02-03

А сколько должно казаться нам по вашему ?

elipse ★★★
()
Ответ на: комментарий от Led

>Поправляю. Вы неправы. Эта инструкция вычисляет "адрес" и помещает >его в регистр. Я, конечно, ламер, но даже мне это было известно ещё в >80-ых из учебников Абеля и Джордейна:)

:)))
4.2
ну освежим вам склероз манехо:
http://pdos.csail.mit.edu/6.828/2004/readings/i386/LEA.htm

lea ax,[a+b+$5] да, а и b тут не регистры - ну никак:))
еще как вычисляемый по месту ассемблирования макрос или выражение проканает.





elipse ★★★
()
Ответ на: комментарий от Led

> Поправляю. Вы неправы. Эта инструкция вычисляет "адрес" и помещает его в регистр. Я, конечно, ламер, но даже мне это было известно ещё в 80-ых из учебников Абеля и Джордейна:)

А данные где? Адрес то мне не нужен. Мне с данными работать нужно.

VIT
()
Ответ на: комментарий от Led

>>А данные откуда возьмете в "новом регистре"?

> Оно там "прозрачно" продублируется (отзеркалится) из "старого регистра"

А... Еще скажите "само" и "мнгновенно".

VIT
()
Ответ на: комментарий от elipse

Тут хитрость в том, что a+b+$5 может вычислить и макроассемблер. В любом случае, lea не является инструкцией - это динамический макрокод.

Вообще мне сдаётся, что Led слышал кое-где кое-как, но в деталях не очень разбирается. Регистры у него инопланетные, данные появляются "прозрачно" и "сами". Так только на бейсике можно программировать. Ну или базы данных там какие нибудь.

VIT
()
Ответ на: комментарий от VIT

>Тут хитрость в том, что a+b+$5 может вычислить и макроассемблер. В >любом случае, lea не является инструкцией - это динамический макрокод.

Ну, так как намек про кулибинство остался непонятным :))
Тут это не хитрость ,и в данном случае просто выкрутасы
- ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

elipse ★★★
()
Ответ на: комментарий от elipse

> Ну, так как намек про кулибинство остался непонятным :))

Никакого кулибинства тут и нет :). Впрочем, данных тоже.

> Тут это не хитрость ,и в данном случае просто выкрутасы - ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

Правильно. Но при чём тут "выкрутасы" - программист использовал "свёрку констант". К первоначальному обсуждению иммет точно такое же отношение, как "ответ 7, знаю без процессора" ;).

VIT
()
Ответ на: комментарий от VIT

> Никакого кулибинства тут и нет :). Впрочем, данных тоже.

Ну ,надо же было дать шанс одуматься человеку ? :))

elipse ★★★
()
Ответ на: комментарий от elipse

>lea ax,[a+b+$5] да, а и b тут не регистры - ну никак:))

>еще как вычисляемый по месту ассемблирования макрос или выражение проканает.

А откуда появился "ax"? В vm86-режиме - да, вариант с [a+b+$5] не прокатит, но в 32/64-битном - работает.

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>А данные где? Адрес то мне не нужен. Мне с данными работать нужно.

lea a, [b+c+#5]

Данные - в "a"

a == b+c+#5,

где a,b,c - регистры, #5 - константа.

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>А... Еще скажите "само" и "мнгновенно".

Само. "мгновенно" - не скажу, потому что это из той же оперы, что ваши "в 5-6 раз":)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>Вообще мне сдаётся, что Led слышал кое-где кое-как, но в деталях не очень разбирается.

Вы правы: это вам только "сдаётся":)

>Регистры у него инопланетные, данные появляются "прозрачно" и "сами". Так только на бейсике можно программировать. Ну или базы данных там какие нибудь.

Ну, я ведь сказал, что я ламер - куда мне до гуру, преподносящих регистровые окна как вершину процессорной логики:)

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>- ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

Нет. С точки зрения процессора - это одна команда: сложение двух регистров с константой и помещение результата в третьий регистр.

Led ★★★☆☆
()
Ответ на: комментарий от Led

>>Ну ,надо же было дать шанс одуматься человеку ? :))

>Ок, даю:)

Мне абсолютно не сложно (ок, не очень сложно:) признаться, если я прогнал и был неправ (что я сделал выше). А вам?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>С точки зрения процессора - это одна команда: сложение двух регистров с константой и помещение результата в третьий регистр.

Если непонятно на a/b/c-регистрах, предложенных eclipse'ом, держите "живой" пример:

lea eax, [ebp+ecx*4+12345678h] ;7 байт

(здесь немного сложнее - тут ещё и умножение (вернее, сдвиг, потому что умножать можно (AFAIR) только на 2 и 4 (ещё на 8 на x86_64) - потому и "целых" 7 байт (4 из которых занимает константа)

Led ★★★☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.