Компания IBM решила последовать примеру компании ARM и заявила (http://www-03.ibm.com/press/us/en/pressrelease/41684.wss) о скором начале лицензирования архитектуры POWER сторонним производителям. IBM откроет все необходимые спецификации и предоставит производителям возможность лицензирования связанной с POWER интеллектуальной собственности, что даст возможность изменять дизайн чипа под свои задачи, по аналогии с тем как это происходит с ядрами ARM.
Для координирования развития и продвижения платформы POWER организован консорциум OpenPOWER (http://open-power.org), в который вошла группа компаний, заинтересованных в использовании архитектуры POWER. Кроме IBM в состав консорциума вошли компании Google, Mellanox, NVIDIA и Tyan. Среди задач консорциума, кроме всего прочего, отмечается разработка открытой прошивки, которая займется базовой инициализацией подобных чипов и управлением их низкоуровневым возможностями.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTQzMDM
Новость: http://www.opennet.ru/opennews/art.shtml?num=37641
Может кто кратко для не сведущих объяснить какие уникальные плюсы у этой архитектуры?
Для начала прочти это:
http://ru.wikipedia.org/wiki/RISC
как освоишь, пойдём дальше.
Ты так говоришь как будто бы RISC это что то хорошее. Сначала сузить набор команд, а потом поставить 10 процессоров для выполнения параллельного нахождения синуса, вот так находка, вот так прогресс, если вместо этого можно было сделать один процессор с кучей функций, и не заморачиваться с накладными расходами вызванными параллелизмом. Уже сейчас мы видим, что наиболее часто выполняемые последовательности инструкций объединяют в одну команду и называют это расширением набора команд. Будущее за процессорами с широким набором команд, по мне так самый оптимальный, это тот процессор, у которого система команд будет плясать от Си-рантайма, а не от ассемблерных кодов, как это было на заре процессоростроения. Представьте себе процессор, реализующий Си-рантайм, у которого по определению становится однозначно понятны требования к стэку, и к алгоритмам работы предсказывания ветвлений и копирований кэша, а также множество других вкусностей - вроде вычислений тригонометрических функций за один такт, и др.
главные редакторы должны, в первую очередь, осилить пунктуацию и синтаксис.
иначе это не главные редакторы, а клоуны из цирка "Шапито".
НО! клоуны, которые смешат, делают больше полезных дел, чем малограмотные "главные редакторы"
>Сначала сузить набор команд, а потом поставить 10 процессоров для выполнения параллельного нахождения синуса, вот так находка, вот так прогресс, если вместо этого можно было сделать один процессор с кучей функций, и не заморачиваться с накладными расходами вызванными параллелизмом.Смешались в кучу кони, люди...
Во-первых, набор команд и параллелизм ортогональны. Для задействования последнего необходимо только, чтобы сами алгоритмы могли быть распараллелены, набор команд совершенно неважен.
Во-вторых, чем сложнее набор команд - тем сложнее процессор, чем сложнее процессор - тем выше накладные расходы. Думаешь зря x86 внутри уже давно как RISC, а CISC набор наружу торчит только ради совместимости, на которой и делают бизнес Интел с МС? Не нужна была бы совместимость, давно бы уже IA32 пошел бы в топку.
>Будущее за процессорами с широким набором команд
То-то же сейчас CISC сохранилось в первозданном виде лишь на мейнфреймах, где совместимостью заморочены еще больше, чем в WIntel мирке, поддерживая один и тот же код порой пол сотни лет.
>по мне так самый оптимальный, это тот процессор, у которого система команд будет плясать от Си-рантайма, а не от ассемблерных кодов, как это было на заре процессоростроения.
Это Си-рантайм плясал от архитектуры PDP-11, а не наоборот. Сейчас все эти особенности не более, чем legacy. А ты предлагаешь вернуться посодомировать труп дедушки, еще больше окунувшись в старые костыли, вместо того, чтобы двигаться вперед.
>Представьте себе процессор, реализующий Си-рантайм, у которого по определению становится однозначно понятны требования к стэку, и к алгоритмам работы предсказывания ветвлений и копирований кэша
А что, Си у нас что-то говорит по поводу того, какая из ветвей будет выполнена с большей вероятностью? Мне вот всегда казалось, что это алгоитмами и входными данными обуславливается. И тебе разве не хватает возможностей выравнивания для того, чтобы укладывать данные в кэш?
Иди-ка ты спать, а то тебе завтра рано в школу. Нафантазировал тут, смотри, чтобы волосы на руках расти не начали.
> А ты предлагаешь вернуться посодомировать
> труп дедушки,
> еще больше окунувшись в старые
> костыли, вместо того,
> чтобы двигаться вперед.А ты дядя выпили из системы libc или msvcrt и двигайся дальше, без этих "кастылей" как вы выразились, вот тогда посмотрим кто был прав. Ещё посмотрите как пишут на ассемблерах интерпретаторы джавы, или вы думаете джаве или КуТэ не нужен Си-рантайм? Пробуйте и ищите!
> А ты дядя выпили из системыПредлагаю удалить Ваши комментарии, чтоб не так позорились. Вполне внятные ответы по существу предпочёл бы оставить.
>> А ты дядя выпили из системы
> Предлагаю удалить Ваши комментарии, чтоб не так позорились. Вполне внятные ответы
> по существу предпочёл бы оставить.Ты не предлагай. Ты молча удали. А в дискуссии вообще не лезь - это не функция модераста. Пойми уже это наконец.
> - это не функция модераста. Пойми уже это наконец.Почему же? Цель модератора - создание на ресурсе комфортной атмосферы для участников. Если абстрагироваться от глупых формалий. В этом плане очень хорошо когда модераторы держат обратную связь с читателями.
>>> А ты дядя выпили из системы
>> Предлагаю удалить Ваши комментарии, чтоб не так позорились.
>> Вполне внятные ответы по существу предпочёл бы оставить.
> Ты не предлагай. Ты молча удали.А там нет нарушения правил, просто человек обычно глупости не пишет. Поэтому именно предложил убрать написанные здесь в качестве услуги.
> А в дискуссии вообще не лезь - это не функция модераста. Пойми уже это наконец.
Соболезную модерастам, но я вообще-то здесь такой же участник, как и все, просто с незамедлительной отработкой "сообщений модератору".
Поскольку Ваших советов на эту тему не просил, будьте добры оставить их при себе.
>> А ты предлагаешь вернуться посодомировать
>> труп дедушки,
>> еще больше окунувшись в старые
>> костыли, вместо того,
>> чтобы двигаться вперед.
> А ты дядя выпили из системы libc или msvcrt и двигайся дальше,
> без этих "кастылей" как вы выразились, вот тогда посмотрим кто был
> прав. Ещё посмотрите как пишут на ассемблерах интерпретаторы джавы, или вы
> думаете джаве или КуТэ не нужен Си-рантайм? Пробуйте и ищите!Пока это наследие не мешает, пусть живет. но вот твое предложение отмотать время назад, пойдя на поводу у ошметков legacy-дизайна - верх глупости.
> Во-первых, набор команд и параллелизм ортогональны.И все-таки. В VLIW например параллельное выполнение группы команд - штатная фича. Поэтому различные куски алгоритмов могут быть явно параллелизованы там где с "обычным" процессором этот номер не пройдет и/или потребует уповать на то что оптимизаторы в железе "угадают". В результате начинаются костыли с предсказаниями, OOO, попытками програмеров угадать сколько у проча блоков выполнения по факту и прочий интересный миндфак, ... :)
VLIW относится к параллелизму на уровне инструкций, а не на уровне потоков выполнения. Так-то, и на IA32 инструкции, не зависящие друг от друга по данным, параллельно исполняются на конвеере. Но к многопоточности, где все упирается в возможность распараллеливания самих алгоритмов, это не имеет никакого отношения.
> Ты так говоришь как будто бы RISC это что то хорошее.Это просто логичное. CISC все-равно не выполняет напрямую сложные команды, разваливая их на простые микрооперации через uCode ROM и впихивая в RISC-образные блоки выполнения.
Напрашивается логичный вывод: оторвать uCode ROM и все что вокруг, сэкономив площадь кристалла. Ну это так, утрированно.
Code size matters. В том же ARM таки переползли на Thumb. В остальном, что CISC, что RISC всё более эквипенисуально - декодер команд в десктопных процах это не особенно большая часть кристалла. Разница сохраняется в embedded разного пошиба, но это камни не уровня ROWER.
> Code size matters.Когда как, когда как. Иногда лучше так, иногда - эдак. Очень зависит от сочетания параметров системы.
> В том же ARM таки переползли на Thumb.
Таки там не "переползли на Thumb" а сделали еще 1 набор команд на выбор. Хотя thumb2 в принципе достаточно удачный набор команд, сочетающий и достоинства как ARM так и Thumb режимов - неплохо придумано, да. Например вместо того чтобы каждой команде пришивать атрибуты условного выполнения (да, 32-битный ARM может условно выполнять каждую команду, что круто, но столько счастья обычно в реальных программах просто не надо) они теперь условное выполнение подшивают группе команд, что экономит место в структуре команды.
> В остальном, что CISC, что RISC всё более эквипенисуально - декодер команд
> в десктопных процах это не особенно большая часть кристалла.Как сказать? ARM кроме всего прочего славится тем что ARM-ядро по минимуму очень маленькое. А чем меньше схема и меньше там транзисторов, тем при прочих равных ниже токи утечки и максимальное потребление схемы в динамике. Конечно к A15 и прочим это уже менее применимо. Ну так их и не впихивают по 8 штук на кристалл мобилочного проца пока. Думаю легко заметить что запихивают или побольше слабых ядер, или поменьше более мощных.
А х86 - он просто бестолковый. Переусложнен как пиндец, не только ядро (в ущерб соотношению производительности и потребления, размеру кристалла и цене) но и в плане дизайна системы. Куча легаси барахла, сложная инициализация и куча обвязки. В результате системы на х86 - не самая приятная вещь на свете для тех кто хочет задизайнить кастомную систему. А еще цена. У интела в принципе нет цен которые могут позволить себе производители ARM, которые даже на сравнительно старых техпроцессах получаются с довольно приличными параметрами, а мизерный кристалл позволяет получить уйму чипов с одной вафли.
> Разница сохраняется в embedded разного пошиба, но это камни не уровня ROWER.
Насчет power'ов - да, уже менее однозначно. Но ARM вон в сервера лезет и надо сказать что заявленные параметры у них вполне себе симпатичненькие.
Размер кода (а точнее нагрузка на i-cache) важен всегда, без всяких так и эдак.И с этим у RISC процессоров таки есть проблем.
> Размер кода (а точнее нагрузка на i-cache) важен всегда, без всяких так и эдак.Ха-ха, бывают процессоры где память доступна сразу, без wait states :). Это конечно микроконтроллеры в основном, и там максимальная предсказуемость важна. За что там не лю всякие немеряные кэши и пайплайны в километр.
> И с этим у RISC процессоров таки есть проблем.
До некоторой степени - возможно. А у x86 (32-битного) программа вообще на половину состоит из push и pop, суммарный эффект от которых равен нулю. Как видим, глупые вещи можно делать и на CISC. На x86_64 с этим стало получше, но там и команды распухли до кучи... :).
> Ты так говоришь как будто бы RISC это что то хорошее.RISC -- это не просто "что-то хорошее", RISC -- это, не побоюсь этого слова, "наше всё".
CISC умер сразу после появления языков высокого уровня. В частности, в классическом CISC -- VAX -- в системе команд была команда, выполняющая линейную аппроксимацию функции по табличке из ОЗУ.
А теперь, внимание, вопрос: какой компилятор с гарантией так хорошо умеет анализировать код, чтобы задействовать эту инструкцию? Правильно, никакой. Таким образом, придётся описывать функцию системной библиотеки, которая на одной конкретной архитектуре будет делать одну конкретную операцию "чуть оптимальнее". И получается, что мы должны застандартизировать стопицот тыщ библиотечных вызовов, и всё только потому, что "где-то там что-то там" "чуть-чуть оптимальнее" работает.
Чем проще набор команд ЦПЭ, тем больше "глубина охвата" его кодогенераторами компиляторов, что в современном мире и требуется.
Больше архитектур, хороших и разных. Аккуратный такой кол прямо в сердце проприетарщины.
лол? все "популярные" архитектуры - проприетарщина, причем патентная
> Может кто кратко для не сведущих объяснить какие уникальные плюсы у этой
> архитектуры?http://gen.lib.rus.ec/search.php?req=Dandamudi+guide+to+RISC...
книжка с обзором ARM/MIPS/PowerPC, их схожих черт и отличий.
> Может кто кратко для не сведущих объяснить какие уникальные плюсы у этой
> архитектуры?POWER, так же как и SPARC64-это встроенные на уровне архитектуры процессора средства для построения "больших" smp, реализации функций отказоустойчивости аппаратной платформы серверов, "горячего" вертикального масштабирования, обновления, более развитая чем в x86 аппаратная составляющая виртуализации.Не получится на Xeon построить, например,
такое http://www-03.ibm.com/systems/power/hardware/795/specs.html
Но ниша такого узка и продолжает сужаться-пора осваивать жаждущие ARM-ов целины.
P.S не реклама.
Кратко.Power одна из первых 64-разрядных архитектур, появилась почти на год раньше, чем AMD SLedgeHammer. Средства аппаратной виртуализации на платформе Power тоже известны очень давно. Для сравнения — 64 бита и аппаратная виртуализация в ARM ещё только планируется в будущем году.
Соответственно, все грабли уже освоены, все процессы уже оптимизированы.
Кроме того, под Power существуют готовые мультипроцессорные решения от IBM, обкатанные годами — т.е. инфраструктура очень богата, наследие очень велико.
Вполне логично, что если ARM лезет в серверный сегмент, сделать некий ответный ход. Я не слишком верю в телефоны на Power, но сервера IBM-у нужны.
> Кратко.
> Power одна из первых 64-разрядных архитектур, появилась почти на год раньше, чем
> AMD SLedgeHammer. Средства аппаратной виртуализации на платформе Power тоже известны очень
> давно. Для сравнения — 64 бита и аппаратная виртуализация в ARM
> ещё только планируется в будущем году.а производительная фабрика вообще не планируется ггг
поэтому на p7 можно собрать 32-сокетовую single system
а на arm получится в буквальном смысле cluster fuck
годный только для того чтобы заменить задохлик какой-нибудь x86 с 0.15 утилизацией
только очень енвайронмент френдли и енерджи еффектив.> Соответственно, все грабли уже освоены, все процессы уже оптимизированы.
> Кроме того, под Power существуют готовые мультипроцессорные решения от IBM, обкатанные
> годами — т.е. инфраструктура очень богата, наследие очень велико.
> Вполне логично, что если ARM лезет в серверный сегмент, сделать некий ответный
> ход. Я не слишком верю в телефоны на Power, но сервера
> IBM-у нужны.бабки им нужны, они пыжатся уже не знают, на чем еще сэкономить, на чем заработать, а что продать. поэтому устраивают цирк типа powerlinux или вот это вот. не прокатило - ну чо, у нашего менеджмента в запасе еще много интересных идэй. а производство при этом сокращают, или людей в неоплачиваемый отпуск.
сервера им нужны. то-то они чуть не ухнули всю энтри ту медиум x86 серверную линейку леново. им нужна волшебная машинка, на которой можно печатать бабки.
> поэтому на p7 можно собрать 32-сокетовую single system
> а на arm получится в буквальном смысле cluster fsckТак там и не лепят single, как и на x86: http://www.mitac.com/business/gfx_servers.html
> им нужна волшебная машинка, на которой можно печатать бабки.
Это к соседям на другие три буквы.
>> поэтому на p7 можно собрать 32-сокетовую single system
>> а на arm получится в буквальном смысле cluster fsck
> Так там и не лепят single, как и на x86: http://www.mitac.com/business/gfx_servers.htmlиз ссылки я понял, что это что-то нечеловечески прекрасное, виабельное и аффордабельное, но подробностей проклятые буржуи как обычно не дают, не понятно, ни сколько памяти за сокетом, шаред не шаред, какой интерконнект. где-то почитать про эти митаки можно? а главное, к большему, чем показывать прекрасные результаты на каком-нито EP бенчмарке, оно способно? оракле какой-нибудь гонять на разделе или там прости господи не к ночи сказано веблоджик?
> из ссылки я понял, что это что-то нечеловечески прекрасное, виабельное и аффордабельное,
> но подробностей проклятые буржуи как обычно не дают, не понятно, ни
> сколько памяти за сокетом, шаред не шаред, какой интерконнект. где-то почитать
> про эти митаки можно?Та шут их знает, просто ничего более "надцатисокетного" армового вроде пока не пробегало (на calxeda, скажем); а на x86, по которым данных у меня побольше -- и у Вас предостаточно, полагаю.
> Соответственно, все грабли уже освоены, все процессы уже оптимизированы.Вот только с потреблением памяти (и размером бинарников, ну да то такое) в amd64 куда лучше сделали, чем в ppc64. Не на год.
Использую обе архитектуры, если что. :)
>> Соответственно, все грабли уже освоены, все процессы уже оптимизированы.
> Вот только с потреблением памяти (и размером бинарников, ну да то такое)
> в amd64 куда лучше сделали, чем в ppc64. Не на
> год.
> Использую обе архитектуры, если что. :)Для серверной платформы это не столь важно, а вот лёгкая параллелизация на сотни процессоров — куда интереснее.
Я собственно, поэтому сильно сомневаюсь как в телефонах на Power, так и в серверах на ARM.
> Для серверной платформы это не столь важно,А вот это опять же когда как. Меньше бинарник = чаще cache hit. А пропускная способность и время выборки накристального кэша на порядки ниже чем у системной оперативы.
> Вот только с потреблением памяти (и размером бинарников, ну да то такое)
> в amd64 куда лучше сделали, чем в ppc64. Не нас этого места подробнее можно, что в виду имеется?
>> Вот только с [...] размером бинарников [...] в amd64 куда лучше сделали, чем в ppc64
> с этого места подробнее можно, что в виду имеется?Гм, беру назад до выяснения:
$ dpkg -c coreutils_8.13-3.5_amd64.deb | fgrep bin/ls
-rwxr-xr-x root/root 114032 2013-01-26 23:07:42 ./bin/ls
$ dpkg -c coreutils_8.13-3.5_powerpc.deb | fgrep bin/ls
-rwxr-xr-x root/root 108720 2013-01-26 17:57:52 ./bin/ls
> Power одна из первых 64-разрядных архитектур, появилась почти на год раньше, чем AMD SLedgeHammer. Средства аппаратной виртуализации на платформе Power тоже известны очень давно. Для сравнения — 64 бита и аппаратная виртуализация в ARM ещё только планируется в будущем году.Вы, должно быть, имели в виду Power4, вышедший в 2001? Вообще-то, Power3 тоже был 64-разрядным, но это 1998. Как и PA-8000 (PA-RISC), как и Alpha 21264, процессоры того времени. Вроде бы, первым 64-разрядным процессором был R4000 от MIPS-а, выпущенный в далеком 1991-ом.
>Power одна из первых 64-разрядных архитектур, появилась почти на год раньше, чем AMD SLedgeHammer.А DEC Alpha разве не появились ещё до этого?
>>Power одна из первых 64-разрядных архитектур, появилась почти на год раньше, чем AMD SLedgeHammer.
> А DEC Alpha разве не появились ещё до этого?Так я и написал «одна из», а не «первая» :-)
Вот поэтому у ARM есть шанс, изучив опыт предыдущих, спроектировать архитектуру без создания граблей.
> Вот поэтому у ARM есть шанс, изучив опыт предыдущих, спроектировать архитектуру без
> создания граблей.Нет, конечно. Там уже и куча систем команд растущей сложности, и кривые SMP/PAE в "лучших" традициях x86. Т.е. плюсы есть, но не эти.
По сравению с VLIW(EPIC) никаких, по сравнению с x86, это все-таки настоящий RISC.
Вы так говорите как будто это что-то хорошее.
Не аргумент. ARM/MIPS тоже RISC - и что с того? Если что - я не считаю Power плохим, но вопрос "а чем хорош" - правомерен.
> По сравению с VLIW(EPIC) никаких,У VLIW есть фирменные грабли: сложно команды эффективно группировать. Компилятор должен писаться с нуля, с учетом этого факта. В мире где уже есть несколько развитых компилаторов, которые не в курсах этого момента VLIWам пришлось печально.
Ну то-есть чтобы VLIWу прогрузить блоки выполнения командами - надо поток команд специфично формировать. Ж@па состоит в том что ни 1 существующий компилер на это не рассчитан, а прикрутить "для галочки" к существующему компилеру - это может и приведет к технически валидному потоку команд. Но эффективность прогрузки блоков будет в ж@пе и производительность VLIW его обладателя в результате не впечатлит...
Теперь любая фирма может клепать свои чипы с ядрами Power.
Интересно а Puwer8 тоже будет лицензироваться?
Больше интересно, оно вообще живо до сих пор, что ли?
Когда будешь одминить что-то больше, чем localhost — спроси ещё раз.
Ггг. Уже. Хотя конечно до масштабов чего-то, где ещё жив power, явно не доходило. Вот меня и интересует, какие они, эти масштабы - и насколько оно живо. И какими системами представлено вообще на рынке...
> Ггг. Уже. Хотя конечно до масштабов чего-то, где ещё жив power, явно
> не доходило.Значит и не дойдёт, в то пространство, где пользуют power, идут со студенческой скамьи,
сначала много лет подмастерьями, потом, где-то лет через десять, назначаются мастерами.
и так не из-за сложности технологий в серверах ибм (всё проще, чем с x86/linux/bsd/windows)
а от степени важности задач, которые на паверах выполняются в денежном варианте оценки.
Вот меня и интересует, какие они, эти масштабы -
> и насколько оно живо. И какими системами представлено вообще на рынке...http://www.cnews.ru/top/2012/07/09/itdirektor_sberbanka_rask...
А... понятно. Ну да, всё проще... и косее.))Боюсь я, что если оно настолько редкое, то лицензируй это - не лицензируй, всем пофиг и денег от этого у IBM не появится.))
>IBM решила последовать примеру...неужели так плохо обстоят дела?
Скорее у ARM стало слишком хорошо. Крупный бизнес не любит любой монополизации кроме своей.
Омские линуксоиды не одобряют циничное название OpenPOWER, так как Open тут очень ограниченному кругу лиц и занедаром.
> Омские линуксоиды не одобряют циничное название OpenPOWER, так как Open тут очень
> ограниченному кругу лиц и занедаром.Поддерживаю. Хотя, с другой стороны, оне тама "разработка открытой прошивки" - может быть, именоо потому "OpenPOWER"?
OpenPOWER и LibrePOWER как-бы не одно и тоже.
Открытая архитектура IBM PC породила двух монстров: Intel и Microsoft.
Кто будет в этот раз?
Ничего не будет.
X его Z, остается прогнозировать, делать ставки и запасаться попкорном.
Как вариант, можно самому стать "монстром".
Она массу всего породила, включая Линукс (историю его создания помните?) И похоронила кучку товарищей, которые вели себя примерно как Эппл, тщательно стараясь закрыть пользователя в своей песочнице - разные там амиги, коммодоры и тому подобное. Спровоцировала технологическую гонку между проиводителями железа, заставила его более-менее унифицировать вплоть до корпусов... В общем, плюсы огромны, как у любого открытого стандарта.И на интел гнать тоже не стоит - они являются технологическим лидером в области создания микросхем уже невесть сколько лет и свою долю рынка имеют совершенно заслуженно.
Поздно. Просpали все маки.
Что-то повер совсем слилась. Раньше хоть в консольках держалась, а сейчас и те на х86 перешли.
> Что-то повер совсем слилась. Раньше хоть в консольках держалась, а сейчас и
> те на х86 перешли.Как было справедливо замечено выше, когда будешь админить что-либо круче localhost, приходь - потолкуем.
многие забыли про Zilog http://ru.wikipedia.org/wiki/Zilog Развивать это нужно было http://ru.wikipedia.org/wiki/Zilog_Z80 (как пример)
> Развивать это нужно было http://ru.wikipedia.org/wiki/Zilog_Z80 (как пример)Вопрос: куда?
А его и развивали (32-бит версию не хотите? http://en.wikipedia.org/wiki/Zilog_Z380). Да только особо не нужно никому оказалось.
> многие забыли про ZilogДа и болт с ним. На фоне ARM не так уж он и интересен.
Если AMD лицензирует и добавит наряду с ARM это чудо в будущие процессоры - вот это будет очень интересно.
было бы отлично. пожалуй только этим двоим (AMD + IBM) под силу свалить гегемонию intel.
Лучше пусть не сваливают, а постоянно слегка отдавливают пятки, Интел при этом очень хорошо шевелится и клепает новые технологии. А учитывая, что ресурсов на их разработку нужно много - выгодно, когда эти ресурсы сконцентрированы в одной компании.Понятно, что сотрудничество в рамках какого-то открытого проекта было бы лучше - но в ближайшее время это нам явно не светит.
> Лучше пусть не сваливают, а постоянно слегка отдавливают пятки,Ну вот по каким-то таким причинам конкуренция и требуется.
Отлично.
Да. Но не поздно? Хотя с бабками IBM, скорее всего, получится.
И чёже раньше не получалось?
Архитектуре сто лет в обед однако Ынтерей даже не качнула ...
из них 50 это всё бодро продавалось. IBM на Power наверное молилось и скорее всего даже памятник в кулуарах поставили.
> И чёже раньше не получалось?Наверное потому что они этого не делали. Они пекли свои power'ы в своем уголочке для себя и своих решений. Вполне себе катило. Но акулы бизнеса не были бы акулами бизнеса если бы насытились и перестали охотиться за новым баблом.
А пример ARM показывает как можно вообше не выпускать чипы и при том все-таки срубить кучу денег на лицензировании своих разработок окружающим.
Нет не получится!!!
У IBM лучшие технологии при худших маркетологах
(продовать она совсем не умеет).
Труп OS/2 кагбе подтверждае :(
> Труп OS/2 кагбе подтверждае :(И чего там такого уж технологичного? Хотя-бы относительно NT?
> И чего там такого уж технологичного? Хотя-бы относительно NT?Сравнивайте с современниками - 3.11 и 95. Третью и четвёртую полуось можно смело рассматривать как сервис-паки 2.11-й. Ничего там концептуально нового не было.
3.51 появилась позднее, обладала бо́льшими требованиями к ресурсам и
гораздо более хреновым GUI.Это если выпустить тот факт, что подобной интеграции системного командного языка (REXX в случае OS/2) и гуя, на мой взгляд, до сих пор нигде толком не достигнуто.
>> Труп OS/2 кагбе подтверждае :(
> И чего там такого уж технологичного? Хотя-бы относительно NT?Количество ошибок на тыщу строк кода, любопытное дитя. Ну и 3.51 в сравнении смотрелась как-то задумчиво совсем, а 4.0 -- вдобавок гниловато. Нижний порог RAM проще не сравнивать.
Почему-то никто не обратил внимание на такой интереснейший момент, что в этот консорциум тут же влезла NVIDIA. И это неудивительно, учитывая их проблемы с рынками и туманные перспективы. Их главный оплот, рынок игровой PC-шной графики меняется - всё больше народу использует встроенную графику (ну а на чём играть в браузерки, Sims и WoW?), где правят бал Intel и AMD, и где NVIDIA уже давно на обочине. Дискретные же видеокарты вытесняются в нишу для игровых маньяков, ибо мало кому нужны мощные игровые PC, когда есть консоли. Новые Playstation и Xbox выбрали AMD. NVIDIA мечется в панике: то лезут в рынок мобильных платформ, где и без них всё хорошо и конкуренция нехилая; то выпускают непонятно кому нужную мобильную игровую консоль. И тут появляется IBM с неожиданным подарком. Производительные десктопные процессоры - розовая мечта NVIDIA. Ну посмотрим.
Да какбы неплохо так мечется Nvidia-то. Вон, закрыла квартал с прибылью 96 лимонов [1]. На мобильном сегменте у нее все более-менее в порядке - Тегры продаются, в большинстве ноутов, включая Яббл, тоже стоят их камни. Карточки для десктопов продаются (да-да, в Кризис на интеграшке нормально не поиграешь). А для серверного рынка, где у нее сейчас теслы рулят и педалят, ей не повредит дополнительный козырь в виде собственных ядер Power. Вот за AMD как раз не так спокойно.[1] http://www.ixbt.com/news/hard/archive.shtml?2013/0810#id170696
Не стоит сравнивать игровую консоль с игровым ПК, не смотря на выход консолей нового поколения, они до сих пор не способны работать столь же производительно что и игровой ПК. Есть несколько критериев которые не позволяют консолям быть на том же уровням что и игровые ПК, а именно размеры консоли, энергопотребление, и тепловыделение. Чтобы сократить энергопотребление и тепловыделение надо уменьшить производительность видео карты ли процессора либо осваивать новый технологический процесс производства, что ведет к увеличению стоимость конечного продукта. Увеличить размер корпуса консоли возможно, но мало вероятно. Хотя увеличение позволило бы расположить более мощную систему охлаждения, и в таком случае возросла бы производительность, но вместе с тем возросло бы и энергопотребление, чтобы вызывало бы увеличение источника питания. Поэтому современным консолям никогда не стоять с в одном ряду с мощным игровым ПК.
если закрытый продукт пытаются открыть и впарить, значит, что-то не так в консерватории
если бы не арм, айбиэм бы наверно и пальцем не пошевелил
> если закрытый продукт пытаются открыть и впарить, значит, что-то не так в консерваторииТам то как раз все так: настоящие акулы бизнеса видят что конкурент рубит уйму деньжищь, распостраняется и начинает открывать новые горизонты. Серверный ARM с виртуализацией и прочая - это уже въезд на чужие территории, при том что параметры заявляются достаточно неплохие и как минимум из всякой облачной и микросерверной фигни ARM вполне себе может попросить многих других, а со временем и из более толстых ниш.
> если бы не арм, айбиэм бы наверно и пальцем не пошевелилНу да, их маркетологи тормозные. Сами инициативу проявлять уже не того.
Из серверных задач ARM может потеснить разве что атома и то если слонопотам будет смотреть в небо.
> Из серверных задач ARM может потеснить разве что атомаАтомы - вообще ни о чем. Оторвали х86 то что делало его быстрым. И получился форменный урoд. Cortex A15 (да, уже массово выпускаемый, еще 32-битный) обставляет атомы как с куста. Показывая ~треть производительности от core i3. Что с атомами сделает A50 - думаю достаточно легко догадаться.
При этом на ARM система намного проще, производитель SoC может оптимизировать чипы под целевые применения и прочая, целясь в различные рынки более адресно.
Из changelog'a GLIBC 2.18:
Support added for POWER8 platform. Implemented by Ryan S. Arnold.
Поздновато они проснулись... Это надо было делать, когда Apple спрыгивала с этой платформы. Тогда платформа Power была в авторитете.А сейчас... Будет 1001-я, мало кому нужная, умирающая платформа.
В embedded им с arm'ами не тягаться. Рынок рабочих станций катострофически схлопывается до сугубо профессиональных применений и PCюки там обосновались прочно. Тяжелые вычисления сейчас активно развиваются за счет мощных GPGPU.
POWER же будет cугубо нишевым решением. Если они конечно смогут найти ему нишу...
> Поздновато они проснулись... Это надо было делать, когда Apple спрыгивала с этой
> платформы. Тогда платформа Power была в авторитете.Тогда уж, это надо было делать _вместо огораживания платформы "для себя и друзей" с самого начала.
Но IBM-у-то виднее. Тепрь-то точно.</да>
> Это надо было делать, когда Apple спрыгивала с этой платформы.Да Джобса уже чуть ли не рады были послать с его крайне нишевыми требованиями (например, очень тонкой упаковки процессоров) и соответствующими тиражами.
Следующий шаг развития широко применимых программно-аппаратных платформ будет определяться возможностями распараллеливания в софте и максимальной эффективности реализации многопроцессорного выполнения в железе, как мне кажется. А вот когда и там упрётся -- будем вспоминать Непейводу :)