LINUX.ORG.RU

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

 , ,


0

0

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

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

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

>>> ZDNet

★★★★★

Проверено: anonymous_incognito ()
Ответ на: комментарий от tailgunner

>>> 640 регистров по 8 байт == 5120 байт. Как-то не впечатляет цифра...

>> Не фига себе не впечатляет!

> Блин, ну может ты объяснишь, почему она должна впечатлять? Это верхний предел архитектуры, только 1/16 из них доступна одновременно. Что должно впечатлять?

Нет, не буду. Попрограммируете арифметику на ассемблере лет 15, сами поймете, что даже 2 регистра в CPU на вес золота. А CPU вообще по-разному используются, а не только для Office и Firefox...

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

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

Времен Microchip, PIC и Atmel. 8080 - это был пример того, какое беспонтовое железо можно встретить в космоме :D

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

>> ещё пример использования регистровых окон - Nvidia GPU, любой с CUDA.

> Спецпроцессоры вообще приют всяких причудливых вещей :)

На этих "причудах" сегодня HPC кластеры делают. Я думаю достаточно иллюстраций для подтверждения Вашего же тезиса: "SPARC обогнал время лет так на 30!"

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

> Попрограммируете арифметику на ассемблере лет 15

10 не хватит? Правда, не стану врать - я не исключительно на ассемблере программировал :)

> поймете, что даже 2 регистра в CPU на вес золота

Когда они одновременно доступны.

P.S. на ассемблерах уже никто не программирует :)

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

>> Спецпроцессоры вообще приют всяких причудливых вещей :)

> На этих "причудах" сегодня HPC кластеры делают

Ну Earth Simulator вообще непонятно на чем сделан... Речь же о процессорах общего назначения.

> Я думаю достаточно иллюстраций для подтверждения Вашего же тезиса: "SPARC обогнал время лет так на 30!"

Это был вопрос. И кстати, лично я вынес из разговора отрицательный ответ на этот вопрос.

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

>640 регистров по 8 байт == 5120 байт. Как-то не впечатляет цифра, >даже если считать, что это прибавка к L1-кэшу данных. Они же не все >одновременно доступны, должны где-то храниться... И эти 5Кбайт - >архитектурный максимум (он вообще достигается где-нибудь?).

Бу га га

" прибавка к L1-кэшу данных" - какой там к чертям L1-кэш ? О чем вы ?
Команды регистр-регистр самые быстрые в любом CPU
и это "золотой фонд" быстродействия любого проца !
И на таком обьеме регистров и при не даунском порте компилятора & либ
много чего можно сделать практически в DSP режиме.
Во даете ,и Intel тут без внешней памяти данных уже никуда не годен.

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

>P.S. на ассемблерах уже никто не программирует :)

"Никто" - это ваш другой ник ? :))

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

>> Попрограммируете арифметику на ассемблере лет 15

>10 не хватит?

Это индивидуально ;).

> P.S. на ассемблерах уже никто не программирует :)

Ух уж эти сказочники...

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

> Речь же о процессорах общего назначения.

Странно. Значит я уже потерял нить разговора.

Я думал, что речь о регистровых окнах, точнее об их бузусловном преимуществе как средстве повышения производительности CPU. Про "общее назначение" (кстати, что это такое?), мне кажется никто ничего не говорил.

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

>> Я думаю достаточно иллюстраций для подтверждения Вашего же тезиса: "SPARC обогнал время лет так на 30!"

> Это был вопрос. И кстати, лично я вынес из разговора отрицательный ответ на этот вопрос.

Жаль. Значит я не нашёл правильных аргументов.

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

> " прибавка к L1-кэшу данных" - какой там к чертям L1-кэш ? О чем вы ?

Я о том, что, если одновременно доступна только малая часть окон, это значит. что остальное хранится в менее оперативной памяти. Каково быстродействие этой памяти - L0, L1, L2?

> ,и Intel тут без внешней памяти данных уже никуда не годен.

Ы. Да к черту Интел... И какая еще внешняя память - 5120 байт (архитектурный максимум суммы регистровых окон)?

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

> Жаль. Значит я не нашёл правильных аргументов.

Все нормально :))
Просто массовая техническая культура "несколько" снижается.
И шансы быть не понятым резко возрастают.


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

>> Жаль. Значит я не нашёл правильных аргументов.

>Все нормально :)) >Просто массовая техническая культура "несколько" снижается. >И шансы быть не понятым резко возрастают.

Да в том то и дело, что tailgunner, пожалуй один из немногих грамотных посетителей ресурса. А с детьми спорить мне вообще не резон ;).

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

>Я о том, что, если одновременно доступна только малая часть окон, это >значит. что остальное хранится в менее оперативной памяти. Каково >быстродействие этой памяти - L0, L1, L2?

1.Компилятор "знает" от критических секциях и доступных ресурсах
для CPU с виртуальной памятью это уникальные возможности и сегодня.

>Каково быстродействие этой памяти - L0, L1, L2?


Ну еще раз : это не имеет отношения к архитектуре CPU
Может рассматриваться как дополнительный способ ускорения доступа к внешней и дешёвой DRAM - это да.

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

>Да в том то и дело, что tailgunner, пожалуй один из немногих грамотных посетителей ресурса. А с детьми спорить мне вообще не резон ;).

Это да.
Но, он скорее "чистый" программер.

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

Ух ты какой шустрый. Может ты на интеловскую архитектуру еще и дрочишь? Спарк во-первых, открытая архитектура, а во-вторых, она не для игрушек создавалась.

alex-w ★★★★★
()
Ответ на: комментарий от iZEN

А я и не смешиваю, потому как Ensemble Studios - это подразделение МС, занимающееся разработкой игр. Вот как раз названные мною игры МСом были разработаны.

SoulStealer
()
Ответ на: комментарий от alex-w

Верно ,а любителям лозунгов про RIP:

http://www.atmel.com/dyn/products/product_card.asp?part_id=3178#DataSheets

Rad Hard 32-bit SPARC V8 embedded processor The implementation is based on the European Space Agency (ESA) LEON2 fault tolerant model.

The AT697E engineering models are available. The AT697E MCGA349 is available as well in military quality flow (QML-Q). Before the end of 2009, the AT697F processor flight models will be delivered tested to either QML Q & V or ESCC quality flows. This second version of the AT697 processor will have improved radiation capabilities, up to 300 krads, and will correct all the bugs described in the AT697E erratasheet. The AT697F version will be pinout compatible with the AT697E.

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

Чего вы спорите? В новости речь о том, что Ларри хочет пропихнуть комплексную систему, т.е. чтобы и железо свое, и Ось своя, и софт в придачу свой. А вы тут про архитектуру... Здесь про маркетинг надо думать :)

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

>Здесь про маркетинг надо думать :)

Свои бабки и заказы они и сами посчитают хорошо без нас :)))

>А вы тут про архитектуру...


Надеюсь , не все с позиции игровых приставок и домашнего радиоГубительства измеряется в этом мире ?
Иногда можно и архитектуру обсудить - так как SPARC "редкая птица" в желтой прессе.
:)

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

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

val-amart ★★★★★
()

Дело не в маркетинге. У Сана всегда была поддержка - говно.

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

> Иногда можно и архитектуру обсудить - так как SPARC "редкая птица" в желтой прессе.

Не иногда, а исключительно.

Так будут ли цифры, насколько обращение к регистрам быстрее обращений к закэшированной в самом быстром кэше например вершине стэка?

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

> Жаль. Значит я не нашёл правильных аргументов.

Предположу, что требуются цифры.

Например, насколько обращение к регистрам быстрее обращений к закэшированной в самом быстром кэше например вершине стэка?

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

Я не спорю с тем, что на спарках контекст переключается быстрее. Но это пожалуй единственное их преимущество. Во всем остальном они проигрывают тем же AMD. И кстати, вся эта тьма регистров вам недоступна, "резвиться" можно лишь в пределах регистрового окна. Попробуйте написать например рекурсию и посмотрите в какой кошмар скатится производительность когда регистры исчерпаются. А произойдет это очень быстро, окон то всего 8. А если еще параметры вызова в окно не умещаются. Одними регистрами сыт не будешь, нужна еще производительность а она у спарков околонулевая и похоже в SUN со мной согласны: http://www.sun.com/sunray/sunray270/specs.xml#anchor3

Для справки, раньше они в свои терминалы microSPARC IIep пихали.

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

Спасибо троим участникам дискуссии. Надеюсь, САН в надежных руках.

Cargo
()
Ответ на: комментарий от A-234

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

Эээ... я не знаю, какой у спарков файл регистров, но предположу, что кольцевой.

Почему вдруг кошмар? Придется делать *ровно то же*, что и без регистровых окон -- сбрасывать наборы регистров в стэк например. Разница будет только в том, что обычно сбрасывают свои регистры, а тут придется сбрасывать регистры функции на 8 уровней выше.

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

> я гораздо более интересное мнение видел по поводу покупки Sun. http://www.cringely.com/tag/hbase/ и с ним я более чем согласен

Нафига столько соплей?

$ curl http://www.cringely.com/tag/hbase/ | bzip2 | less -F
Оракл понимает, что место SQL займут аналоги google BigTable, и купил Сан, чтобы пока что удерживаться на плаву за счет продажи тюненных под (сановских) клиентов БД, а затем уже выпустить свой BigTable.

www_linux_org_ru ★★★★★
()

Вот еще нарыл http://groups.google.com/group/comp.arch/browse_thread/thread/31e4f0d4bcf5ff3...

<Ъ>
IF you have a good register allocator
AND IF you have "plenty" of registers

THEN you can allocate some of them as CALLEE_SAVE registers
and some as CALLER_SAVE registers, and you can have a reasonable
number of each flavor. In this case, you have enoughCALLER_SAVE
(i.e., scratch registers) that you can drastically reduce the
number of register save/restores that need to be done.
</Ъ>

tailgunner ★★★★★
()

Только одно не понятно - а нафига это надо Fujitsu, которая, если быть точным, и делает эти самые спарки, да и все сановские машины M-класса. У Сана своего большого процессора нет, больших машин - тоже... Будет интересно.

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

>Майкрософт выпускает помимо хороших клав и мышек также отличную >консоль и достойные внимания игры.
>Не зря Xbox360 пользуется популярностью и занимает 1-е место по >объемам продаж среди консолей.

гы
вот первая ссылка из гугла - http://www.pcnews.ru/news/xbox-360-ps3-wii-179212.html
Знаю 3 человек с боксом и у всех уже он ломался , у одного уже 3 раза .
Это типично для Микрософта - выпускать некачественную продукцию , но цели своей они конечно добились , потеснили Сони .

>Ну и не стоит забывать такие шедевральные на мой взгляд игры, которые >сделала МС, как Age Of Empires и Microsoft Flight Simulator.

МС тупо скупает производителей игр :-)

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

> Вообще, если Вы дома пишете диссертацию по ядерной физике, спарка -- самое то, что надо: 128-разрядная аппаратная плавающая арифметика к Вашим услугам!

In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that "long double" is to be aligned on 16 byte boundary. (c) man gcc

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

>недаром Оракл - вторая по величине софтверная компания планеты после МС.

На данный момент по капитализации-третья, после MS и Apple

vladdal
()

tailgunner, ты меня поражаешь. Как можно не понимать простой вещи, что чем больше регистров, то тем меньше работы со стеком. Однако для переключения контекстов все используемые регистры надо сохранять. Куда? В стек. Медленно. Регистровые окна - спасение. Это даже такие ламеры как я понимают, которые из ассемблеров знают только AVR assembler :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

> Как можно не понимать простой вещи, что чем больше регистров, то тем меньше работы со стеком.

Ты уже перестал бить жену, да или нет?

> Однако для переключения контекстов все используемые регистры надо сохранять. Куда? В стек.

Отлично. Теперь скажите, Капитан, сколько стоит команда переключения регистровых окон в SPARC по сравнению с сохранением использованных регистров на стек, куда сохраняются регистровые окна при переключении. Если они никуда не сохраняются, то у меня есть еще один вопрос - почему все регистры всех окон не доступны одновременно.

И почитай дискуссию по ссылке, которую я запостил.

tailgunner ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

> Куда? В стек. Медленно. Регистровые окна - спасение. Но это только такие ламеры как я так думают

Ну есть у тебя 16 регистровых окон и 24 нити. Какие твои следующие действия? Единственное что облегчают "регистровые окна" - это реализацию чего-то вроде hyperthreading, для всего остального они бесполезны из-за сопутствующих накладных расходов при количестве потоков более чем количество окон.

Существует три типа ресурсоемких задач: где все утыкается в ввод-вывод (СУБД, networking), где все упирается в объем данных (расчетные задачи) и тут регистры не спасут - данных слишком много, и где много однотипных мелких расчетов (кракать пароли). И количестов регистров может существенно продвинуть только третий класс задач.

Но вы фапайте дальше на регистры, не останавливайтесь...

no-dashi ★★★★★
()

> Если они никуда не сохраняются, то у меня есть еще один вопрос - почему все регистры всех окон не доступны одновременно.

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

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

> Ну есть у тебя 16 регистровых окон и 24 нити. Какие твои следующие действия? Единственное что облегчают "регистровые окна" - это реализацию чего-то вроде hyperthreading, для всего остального они бесполезны из-за сопутствующих накладных расходов при количестве потоков более чем количество окон.

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

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

>> Сейчас текущая версия -- церера.

а где можно почитать спецификации?
спасибо.

sda00 ★★★
()
Ответ на: комментарий от I-Love-Microsoft

>> Если они никуда не сохраняются, то у меня есть еще один вопрос - почему все регистры всех окон не доступны одновременно.

> А зачем тебе все сразу

Для патологических случаев и чтобы не нужно было окна переключать.

> Не буду дальше развивать тему, не специалист.

Большая часть специалистов как раз считает, что выигрыш от регистровых окон не стоит затрат.

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

> Существует три типа ресурсоемких задач: где все утыкается в ввод-вывод (СУБД, networking), где все упирается в объем данных (расчетные задачи) и тут регистры не спасут - данных слишком много, и где много однотипных мелких расчетов (кракать пароли)

Второй тип задач тоже упирается во ввод-вывод, только это ввод-вывод между памятью и процессором. И много регистров тут дают возможность не занимать шину памяти паразитным трафиком ради сохранения в памяти промежуточных результатов.

> Но вы фапайте дальше на регистры, не останавливайтесь...

Да на них уж 30 лет несколько поколений разработчиков архитектур фапает.

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

>> Жаль. Значит я не нашёл правильных аргументов.

>Предположу, что требуются цифры.

>Например, насколько обращение к регистрам быстрее обращений к закэшированной в самом быстром кэше например вершине стэка?

Да пожалуйста, любой программирующий такие цифры и сам знает для своего любимого процессора. Вот для, скажем, PowerPC 450:

регистры - 1 clk, L1 cache - 4 clks, L2 cache - 13 clks.

Для любимых многими здесь Оптеронов:

регистры - 1 сдлб L1 cache - 6 clks, L2 cache - 24 clks.

В среднем можно сказать, что разница в 5 раз. А что, если стэк "не совсем" в L1?

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

>гы
>вот первая ссылка из гугла - http://www.pcnews.ru/news/xbox-360-ps3-wii-179212.html

>Знаю 3 человек с боксом и у всех уже он ломался , у одного уже 3 раза .

>Это типично для Микрософта - выпускать некачественную продукцию , но цели своей они конечно добились , потеснили Сони .


Ваш пример не показателен, потому как у тех моих знакомых, у которых имеется Xbox360 (а их 6, если быть точным), он работает как часы уже больше года. Не стоит забывать, что под Xbox360 выпускается такая популярная среди ее обладателей игра, как Guitar Hero. Но мало того, что МС потеснила Сони, она в отличие от последней не несет существенных убытков, а наоборот, очень даже получает прибыль.

>МС тупо скупает производителей игр :-)


Одному я уже сказал и вам повторю. КОНКРЕТНО ЭТИ игры делала Ensemble Studios (еще здесь забыл кстати Age of Mythology), которая является ДОЧЕРНЕЙ компании МС. Так же, как и Сан теперь ДОЧЕРНЯЯ компания Оракла, и если продукт сделают в недрах бывшей Сан, он будет все равно считаться продуктом корпорации Оракл.

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

>недаром Оракл - вторая по величине софтверная компания планеты после МС.

>На данный момент по капитализации-третья, после MS и Apple


Тут ключевое слово - софтверная. Оракл пока что не выпускает собственного железа (или под собственной маркой), в отличие от яблока со своими маками и проч. Под железом тут тоже стоит понимать не мышки и клавы, которые выпускает МС, а компы, лаптопы, рабочие станции и т.д.

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

> И много регистров тут дают возможность не занимать шину памяти паразитным трафиком ради сохранения в памяти промежуточных результатов.

Ну давай, покажи нам всем, как ты оптимизируешь за счет количества регистров, например, взятие детерминанта матрицы 2048x2048.

no-dashi ★★★★★
()

> Ну давай, покажи нам всем, как ты оптимизируешь за счет количества регистров, например, взятие детерминанта матрицы 2048x2048.

Я понимаю, ты намекаешь на то что все равно всё не влезет. Ну так а промежуточные расчеты где хранить? Всяко лучше если регистров будет больше.

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

>> И много регистров тут дают возможность не занимать шину памяти паразитным трафиком ради сохранения в памяти промежуточных результатов.

> Ну давай, покажи нам всем, как ты оптимизируешь за счет количества регистров, например, взятие детерминанта матрицы 2048x2048.

http://www.anekdot.ru/an/an0004/s000416%3B10.html#6

tailgunner ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

> Я понимаю, ты намекаешь на то что все равно всё не влезет.

Вот тут есть замечательные объективные цифры, где сравнивается Core.i7 и UltraSPARC VII, и тот и другой четырехъядерники

Core i7 => http://www.spec.org/cpu2006/results/res2009q1/cpu2006-20090302-06605.html
UltraSPARC VIII => http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081023-05678.html

Я бы назвал результаты катастрофой и эпическим фэйлом для спарков.

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

>> Вообще, если Вы дома пишете диссертацию по ядерной физике, спарка -- самое то, что надо: 128-разрядная аппаратная плавающая арифметика к Вашим услугам!

> In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that "long double" is to be aligned on 16 byte boundary. (c) man gcc

На x86-64 в 128-разрядном поле содержится 80-разрядное интеловское вещественное число. Вспомните архитектуру процессора -- или почитайте описания. Именно этот режим gcc имеется в виду.

Насколько мне известно, в сановских компиляторах такой режим теперь не поддерживается. Зато в 31-й версии цереры появилась хорошая программная реализация полной 128-разрядной плавающей арифметики, сделанная из спарковой и чуть ли не соответствующая ей поразрядно. Надеюсь, что в следующей версии SSX её выдадут в сообщество, хотя за качество тестирования можно опасаться: уж больно своеобразный тип там занимается libm.

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