Компания Red Hat подтвердила (http://www.theregister.co.uk/2009/12/18/redhat_rhel6_itanium... информацию о прекращении поддержки серверов на базе процессорной архитектуры IA-64 (Itanium (http://ru.wikipedia.org/wiki/Itanium)) в будущей ветке Red Hat Enterprise Linux 6. Поддержка серверов на базе процессоров Itanium в RHEL 5 будет сохранена в полном объеме. Время жизни RHEL 5 продлится до 2014 года, а по контрактам расширенной поддержки срок поддержки RHEL 5 для Itanium может быть продлен до марта 2017 года.
Основным производителем серверов на базе процессоров Itanium является Hewlett-Packard, позиционирующий для данного оборудования свою операционную систему HP-UX. Из других ОС Itanium поддерживают Tru64, OpenVMS, FreeBSD и NetBSD. Портирование на Itanium велось AIX и Solaris, но так и не было доведено до конца.URL: http://www.theregister.co.uk/2009/12/18/redhat_rhel6_itanium.../
Новость: http://www.opennet.me/opennews/art.shtml?num=24742
AIX на Itaniume??? наверное что-то никогда не вышедшее за пределы лабораторий.
Ну собственно на эту платформу было много надежды, поэтому ibm и занималась портом. Но как показал опыт итаниум первой реинкарнации это фейл. Вторые вроде ничего, но подмоченную репутацию никуда не деть.
Solaris на Itanium ?? что за бред?
А ещё для PowerPC есть!
А что еще кроме него в мейнстриме из RISC-процов осталось? Есть ненулевая вероятность прикапывания Sparcа, все остальные практически сошли со сцены (или ушли в область встраиваемых девайсов)
а если внимательно посмотреть?
"..., но так и не было доведено до конца...")
Разработка была прекращена в 2000 году
Жаль. Ну да ладно! Этот процессор у Интела, к сожалению, не удался. Но это поспособствовало укреплению позиций AMD году в 2005-м.
Почему к сожалению? Имхо, к счастью. Завалили Alpha с ХэПэшниками - тперь расхлёбывают. :)
>Этот процессор у Интела, к сожалению, не удался. Но это поспособствовало укреплению позиций AMD году в 2005-м.Вы только не забудьте написать Intel, HP, SGI, NEC, FUJITSU о том, что Itanium не удался :D Что касается AMD, то это вообще бред сивой кобылы - ничего, конкурирующего с Itanium AMD не производит и не собирается. Если Вы сдуру записали ему в конкуренты Opteron, то это как минимум глупо - аналог Оптерона это Xeon, но никак не Itanium.
Мне известно, что Intel делала этот процессор с конца 90-х годов. Но она очень тянула с его выпуском, а Opteron всё равно оказался лучше.
>Мне известно, что Intel делала этот процессор с конца 90-х годов. Но она очень тянула с его выпуском, а Opteron всё равно оказался лучше.Итаниумы впервые были представлены в 2001 году, сравнивать их с Оптеронами глупо, в отношении характеристик и ориентации между двумя этими решениями лежит огромная пропасть. Все равно, что утверждать, что Toyota Camry лучше самосвала Caterpillar.
>Все равно, что утверждать, что Toyota Camry лучше самосвала Caterpillar.И ведь социологический опрос покажет, что лучше. :)
PS: сегмент на итаниках есть, расширять не планируют.
ну-ну, скорей не сравнивать глупо.Если хорошо напрячь память, то Итаниум сперва ставился и на топовые WS - ну где же они теперь? Правильно, с появлением Opteron - Итаниум ушел в ж...
На сегодняшний день, рынок до 8 процессоров плотно занять x64, а если учесть и ядра, то и до 32-х. Да что там говорить, сам Intel вынужден был со своим коре вытеснять Итаниум, чтоб не слить amd!!!
Так что Итаниуму остается узкой сегмент 101-процессорных систем :), но и там тяжко - всякие power6 и sparc64.
Можно еще долго обсуждать не сбывшиеся мечты Итаниума, но да ладно.
>ну-ну, скорей не сравнивать глупо.Я уже приводил аналогию, что сравнение Opteron vs Itanium примерно из той же оперы, как сравнение седана и самосвала. Но как показывает практика, и такие деятели находятся:)
>Если хорошо напрячь память, то Итаниум сперва ставился и на топовые WS - ну где же они теперь?
Примерно там же, где и WS произведенные SGI на MIPS'ax и стоящие много килобаксов. Тенденция рынка, знаете ли, потребность иметь у себя на столе вычислительных монстров постоянно уменьшается. Гораздо проще перенести тяжелые вычисления на кластер или вообще аутсорсить при помощи модного ныне cloud-computing'a.
>Да что там говорить, сам Intel вынужден был со своим коре вытеснять Итаниум, чтоб не слить amd!!!
Никогда Intel не позиционировала Itanium как единственный процессор в своей линейке. И никогда не предрекала ему место на десктопе. Intel Core и Itanium находятся в двух непересекающихся плоскостях, поэтому Коре не вытеснял итаниум. А вот AMDшным десктоп-чипам дал жару, да и сейчас дает.
>Так что Итаниуму остается узкой сегмент 101-процессорных систем :)
Именно для таких сегментов он и создавался, ничего нового. Тут еще надо понимать, что в данный момент SMP и NUMA-системы в целом испытывают очень мощное давление со стороны кластерных систем, независимо от типов процессоров.
>но и там тяжко - всякие power6 и sparc64.
А думаете поверам и спаркам прямо так легко? :-D Я бы не стал утверждать, что те же спарки чувствуют сейчас себя сильно лучше итаниумов.
Ага, а если снять розовые очки?>>Так что Итаниуму остается узкой сегмент 101-процессорных систем :)
>Именно для таких сегментов он и создавался, ничего нового.Эх память, память. А я вот хорошо помню менеджеров Intel, они думали противоположное вам. :)) и я помню презентации еще середины 90х, ведь делать его начали одновременно с P6 :) и назывался он P7 :))))))) И был он предназначен для WS, но слил он тому же Opteron.
И коре для серверов не предназначался изначально, но жизнь заставила - ну не продавались Itanium-ы!!!
Да, сейчас софтверщики Intel подтянули программы, но поздно, поезд ушел. Да и сложное и дорогое это дело - тюненг под него.
>>но и там тяжко - всякие power6 и sparc64.
>А думаете поверам и спаркам прямо так легко? :-D Я бы не
>стал утверждать, что те же спарки чувствуют сейчас себя сильно лучше
>итаниумов.Да, намного, у него хороший рынок на сих пор, напомню - речь идет о фуджиках :)
Много решает имидж - "Intel<=>PC".
>Intel Core и Itanium находятся в двух непересекающихся плоскостях,
>поэтому Коре не вытеснял итаниум.Не напомните интеловские планы по 64-битной архитектуре "для небогатых", без килограмма меди на итанике?
>А вот AMDшным десктоп-чипам дал жару, да и сейчас дает.
Угу, только лучше б EM64T не родилось, а забашляли бы сразу за нормальную AMD64 с IOMMU и прочим HT.
>Тут еще надо понимать, что в данный момент SMP и NUMA-системы в целом испытывают
>очень мощное давление со стороны кластерных систем, независимо от типов процессоров.Надо же. Надо будет сказать кластерным системам, которые давно уж состоят по большей части из SMP-систем, которые нынче ещё и NUMA по совместительству. :)
>Надо же. Надо будет сказать кластерным системам, которые давно уж состоят
>по большей части из SMP-систем, которые нынче ещё и NUMA по
>совместительству. :)Ну скажите, ага. SMP и NUMA в этих кластерах не выходят за пределы отдельного unit'a, а в масштабах всей системы говорить об SMP не приходится. Посмотрите на всеми любимый top500.org, сколько там NUMA, и сколько там кластеров. Естественно, что имеет место объединение и комбинация различных подходов, но в конечном итоге кластеры преобладают.
>SMP и NUMA в этих кластерах не выходят за пределы отдельного unit'a,node'ы
>а в масштабах всей системы говорить об SMP не приходится.
Ну так SMP и близко не масштабируется к такому.
Я о том, что уровень применимости SMP (и отчасти NUMA) в кластерах ограничен тем, где ему удобнее всего -- узлом. Но никуда не девался. :)
>Если хорошо напрячь память, то Итаниум сперва ставился и на топовые WS
>- ну где же они теперь?Если напрячь память, то в WS ставились например и сановские спарки. Теперь вопрос, где эти WS теперь? А еще в топовые WS ставились PowerPC, которые из чувства долга клепала IBM, а еще в компьютеры производства Apple. Но Apple послала PowerPC куда подальше (и ничуть об этом не жалеет), да и рабочих станций от IBM тоже не особо видно (может и производят чуть-чуть, для галочки, как производили контроллеры для Token Ring). Так что не нужно выдирать факты из контекста, просто десктопные процессоры выросли настолько, что вполне способны быть сердцем мощных рабочих станций. И не надо тут как-то особенно выделять Итаниум, точно так же из рабочих станций "попросили" и поверы, и спарки.
>>Если хорошо напрячь память, то Итаниум сперва ставился и на топовые WS
>>- ну где же они теперь?
>
>Если напрячь память, то в WS ставились например и сановские спарки. Теперь
>вопрос, где эти WS теперь? ...И не надо тут как-то особенно выделять Итаниум, точно
>так же из рабочих станций "попросили" и поверы, и спарки.Здорово Кеп!!!
Что хотел-то сказать? что Итаниум опоздал лет на десять? так и ежу понятно.
Кстати, PowerPC G5 вполне продаются с Yellow Dog
>Что хотел-то сказать?То, что исчезновение в продаже рабочих станций на базе итаниума - ни разу не аргумент. Точно так же исчезли воркстейшены на спарках, мипсах и паверах. Сейчас их сменили младшие братья из десктопного сегмента. Ключевая мысль (для тех, кто в танке) : "Итаниум здесь ничем не отличается от sparc, mips, ppc, pa-risc etc. Рабочие станции теперь делают на процессорах классом ниже, которые сильно подросли в последнее время". И если Вы тут с усмешкой вопрошаете: "ой, ну и где же теперь WS на итаниуме?", то не забывайте спросить где же теперь WS на PowerPC, SPARC и MIPS.
>Кстати, PowerPC G5 вполне продаются с Yellow Dog
Не PowerPC G5, a PowerPC 970, который ставился в Apple Power Mac G5. Который уже давно не производится и не поддерживается Apple. А на eBay можно и не такое купить.
>: "Итаниум здесь ничем не
>отличается от sparc, mips, ppc, pa-risc etc. Рабочие станции теперь делают
>на процессорах классом ниже, которые сильно подросли в последнее время". И
>если Вы тут с усмешкой вопрошаете: "ой, ну и где же
>теперь WS на итаниуме?", то не забывайте спросить где же теперь
>WS на PowerPC, SPARC и MIPS.Вот-вот, для тех кто в танке. Есть совсем "маленькое" отличие от "sparc, mips, ppc, pa-risc etc" - они появились и отработали в 80-е & 90-е, в отличии от ... Который создавался как конкурент им на WS и SMB серверах (до 4х). Но маразматики из интел оказались в глубокий ж.... со своим P7/Merced/Itanium 1/Itanium 2 - поздно вышли на рынки.
А вот WS на PowerPC (не маки) и SPARC до сих пор понемногу выпускаются - софт-то заточен под них, и всё ещё работает.
Я же помню как клялись менеджеры интел - 64 на pc не бывать!!! для тех кому нужно 64-бита го-ту Itanium (то есть гони бабки). Но вышел amd64 и побежали лицензировать свой пеньтюх4. На ксеонах еще повыёб... , но тоже сделали 64 - а ведь это и был рынок Itanium-а.
А теперь core на пару с amd64 добивают IA64. И я думаю, что если sgi свои сервера переведет на новые core, то Itanium не жилец, один HP их не вытянет.
а вы тут сказки про замечательных проц нам травити.
>А теперь core на пару с amd64 добивают IA64. И я думаю,
>что если sgi свои сервера переведет на новые core, то Itanium
>не жилец, один HP их не вытянет.Как в воду глядел :))
Вот он пи... для Itanium-а: SGI Altix platform with 2,048 Intel Nehalem processors
Это они, core вместо Itanium-ов, и из этой нише выбивают.
>Мне известно, что Intel делала этот процессор с конца 90-х годов. Но
>она очень тянула с его выпуском, а Opteron всё равно оказался
>лучше.Это вообще разные вещи, разные процессоры в полном смысле этого слова....
Конкурент Itanium это Crusoe (должен был быть, но они повернули в сторону совместимости с x86)
А ещё есть Эльбрус 3M1, при своих 300MHz выдаёт порядка 4,5 GFLOPS.
> Конкурент Itanium это CrusoeЖаль что об этом забыли написать в инструкции к Crusoe, сами производители не догадались и в результате стали пихать его в ноутбуки...
>> Конкурент Itanium это Crusoe
>
>Жаль что об этом забыли написать в инструкции к Crusoe, сами производители
>не догадались и в результате стали пихать его в ноутбуки...Я смотрю остроумие прёт из Вас со всех щелей. Crusoe и Itanium действительно одного поля ягоды, другой вопрос, что Transmeta начала его позиционировать как конкурента х86. Так вот, по секрету Вам скажу, что Crusoe _эмулировал_ х86, точно так же как умеют это делать Эльбрус и Itanium. Внутри он самый что ни на есть VLIW-процессор, если Вы конечно знаете что это такое. Если не знаете, википедия Вам поможет.
>Так вот, по секрету Вам скажу, что Crusoe
>_эмулировал_ х86, точно так же как умеют это делать Эльбрус и
>Itanium.А заодно K6 и выше процы от AMD
>Внутри он самый что ни на есть VLIW-процессор, если Вы
>конечно знаете что это такое. Если не знаете, википедия Вам поможет.:-)
>>_эмулировал_ х86, точно так же как умеют это делать Эльбрус и
>>Itanium.
>
>А заодно K6 и выше процы от AMDВы здесь немного путаете:) Эльбрус, Итаниум и Крузо - это процессоры с VLIW архитектурой, которые транслировали х86 код в набор своих родных VLIW-инструкций. Что касается AMD К6, то набор х86 инструкций был для него "родным", по крайней мере не менее родным, чем для Пентиума. Вы, наверное, имеете ввиду трансляцию х86-инструкций в последовательность простых команд, которое выполняло RISC-ядро? Ну так идея эта не нова, и это справедливо по отношению к любому современному процессору, у интел RISC-ядро появилось еще в i80486. Исключения составляют микроконтроллеры и процессоры наподобие ARM.
>Вы, наверное, имеете ввиду трансляцию х86-инструкций в последовательность простых команд, которое выполняло RISC-ядро?Да, об этом.
>у интел RISC-ядро появилось еще в i80486.
Вот этого не знал. Удивлён. Спасибо, просвятили. Если не сочтёте за труд привести пруфлинк - вообще супер. Спасибо.
>Вот этого не знал. Удивлён. Спасибо, просвятили. Если не сочтёте за труд
>привести пруфлинк - вообще супер. Спасибо.Не затруднит:) Факт, в общем-то, общеизвестный, и описан везде, начиная от официальной документации и заканчивая луркморьем :-D Вот ссылочка посолиднее на описание от Intel:
http://www.intel.com/design/intarch/prodbref/272712.htm
На мухоморье ещё и про процессоры пишут? Странно, а я думал, там только желчь изливают напополам с аббривеатурами.
>http://www.intel.com/design/intarch/prodbref/272712.htmГде-то внутрях оно может и RISC но выглядит для програмера как галимый CISC с куцыми регистрами и без относительной адресации. В счет чего х86 программа состоит из охренительно полезных команд push и pop чуть более чем полностью :P а при загрузке исполняемого барахла в память долго и нудно педалятся релокейшны нужные сугубо потому что в дебильной архитектуре нет адресации относительно Program Counter-а.
>Где-то внутрях оно может и RISC но выглядит для програмера как галимый
>CISC с куцыми регистрами и без относительной адресации. В счет чего
>х86 программа состоит из охренительно полезных команд push и pop чуть
>более чем полностью :P а при загрузке исполняемого барахла в память
>долго и нудно педалятся релокейшны нужные сугубо потому что в дебильной
>архитектуре нет адресации относительно Program Counter-а.Да пусть внутри там хоть зеленые человечки с арифмометрами сидят, какая к черту разница, если работает это быстро? Существует много подходов к созданию вычислительных машин, Intel выбрала один, IBM - другой. И естественно, что внутренняя организация процессора оптимизирована под соответствующий тип исполнения (кстати, описанная Вами стековая организация не имеет к х86 никакого отношения, типичный пример стековой машины - это JVM. В х86 преобладают операции регистр-память). Intel (и AMD за компанию) решили делать свои процессоры так, в конечном итоге получился отличный процессор, а победителей не судят. Дошло до того, что один из самых верных потребителей PowerPC процессоров, небызызвестная Apple, дала отставку этому "чистопородному аристократу" голубых RISC-кровей (который всегда был предметом огромной гордости и презрения по отношению к простым PC-юзерам). В результате софт начал работать гораздо больше, и этому "уродцу с куцыми регистрами" хватило мощи еще и крутить в эмуляторе Rosetta код PowerPC-программ, да так, что народ открывал рты от приятного удивления.
А Вы можете хоть до посинения трындеть о том, как же там мало регистров общего назначения и способов адресации - грамотные люди просто улыбнутся, глядя на Ваш неуклюжий вброс, и не более того. Время, когда программисты писали софт на языке ассемблера прошло давным-давно, сейчас балом правят высокоуровневые языки и фреймворки, очень активно наступают скриптовые языки и виртуальные машины. НЕТ НИКАКОЙ РАЗНИЦЫ в количестве регистров процессора и механизмах адресации, когда программист пишет на C++ для какого-нибудь Qt, не говоря уже о java или .net. Существует очень-очень-очень узкий пласт программ, которые должны выжимать из железа по максимуму, но и они не пишутся на языке ассемблера по той причине, что современный оптимизирующий компилятор c/c++ генерирует код, на порядки лучший, чем это сделает человек. Поэтому все ваши язвительные доводы годятся разве что для холиворов двадцатилетней давности.
>>при загрузке исполняемого барахла в память долго и нудно педалятся релокейшны
>>нужные сугубо потому что в дебильной архитектуре нет адресации относительно
>>Program Counter-а.
> Да пусть внутри там хоть зеленые человечки с арифмометрами сидят, какая
> [...] разница, если работает это быстро?Не специалист, но насколько понимаю -- в AMD64 относительная адресация есть и действительно помогает по части "быстро" (в т.ч. компактности соответствущим образом оттранслированного кода), а вот интелы умудрились это угробить в своём а-ля китайском клоне. Правда, добавили linpack-friendly добавить-сложить (или как его там) и чуть ли не на этом одном выперли оптероны из HPC-сегмента, несмотря на все проблемы с FBDIMM и отдельным контроллером памяти.
>Дошло до того, что один из самых верных потребителей PowerPC процессоров,
>небызызвестная Apple, дала отставку этому "чистопородному аристократу"Вообще-то это IBM их в итоге послал с заумными требованиями типа очень тонких процессоров малыми партиями по сходной цене. Теперь с джобсовскими хотелками мучается Intel. :)
>В результате софт начал работать гораздо больше, и этому "уродцу с куцыми регистрами"
>хватило мощи еще и крутить в эмуляторе Rosetta код PowerPC-программ, да так,
>что народ открывал рты от приятного удивления.Graphing Calculator покрутите, пожалуйста.
>грамотные люди
Хех.
>Существует очень-очень-очень узкий пласт программ, которые должны выжимать
>из железа по максимуму, но и они не пишутся на языке ассемблера по той причине,
>что современный оптимизирующий компилятор c/c++ генерирует код, на порядки лучший,
>чем это сделает человек.Да, но. Когда человек представляет себе не только в общих чертах, но и в деталях работу кода на конкретной архитектуре, а также поведение этого самого компилятора -- результат может быть *намного* cache-friendly, скажем. И на этом одном иметь на порядок (или порядки) отличающуюся производительность.
>Поэтому все ваши язвительные доводы годятся разве что для холиворов
>двадцатилетней давности.Нет, не все. И не "разве что". И да, существенная часть Вашей язвительности ни тогда никуда не годилась, ни сейчас -- может, сэкономим? :)
>Вообще-то это IBM их в итоге послал с заумными требованиями типа очень тонких процессоров малыми партиями по сходной цене.Действительно, очень заумные, такие заумные, что аж уму непостижимо. Intel оказались более сообразительные и получили в результате эксклюзивный контракт на огромные деньги.
>Теперь с джобсовскими хотелками мучается Intel. :)
Это Вам Intel написал в слёзном письме, о том как он мучается?:)
> Когда человек представляет себе не только в общих чертах, но и в деталях работу кода на конкретной архитектуре, а также поведение этого самого компилятора -- результат может быть *намного* cache-friendly, скажем. И на этом одном иметь на порядок (или порядки) отличающуюся производительность.
Снова повторю, это было справедливо -дцать лет назад. На сегодняшний день лучше всех разбирается в тонкостях работы кэшей, конвееров, блоков предсказателей ветвлений нечто по имени Intel C++ Compiler. Ни один человек не справится с этой задачей лучше, пусть он хоть наизусть выучит все тома руководства Intel Software Developer's Manual. Если речь, конечно, не идет о какой-нибудь программе длиной в две инструкции. На хорошем сложном куске кода человек непременно проиграет машине, доказано многократно как собственным опытом, там и опытом множества других. Упираться в доказывании общеизвестного факта я не собираюсь :)
>Нет, не все. И не "разве что".
У Вас своё мнение, у меня своё. Я считаю, что фраза:
>выглядит для програмера как галимый
>CISC с куцыми регистрами и без относительной адресациив 2010 году - не более чем язвительный пшик. Количество регистров и способы адресации никак не сказываются на работе программиста, если только Вы - не разрабочик компилятора (вероятность чего весьма мала, учитывая то, что доля таких программистов среди всех остальных - очень и очень невелика). Но разработчики компиляторов ребята суровые и как-нибудь переживут. Что же касается всех остальных 99.99% программистов, то они ничего не заметят даже если в следующей версии процессора останется 1 регистр общего назначения и 1 способ адресации. Вернусь к уже упомянутому примеру - переезд Apple c PowerPC на Intel Core2 Duo, пусть даже и x86_64. Что было - типичный RISC процессор, с множеством регистров общего назначения, "правильной" адресацией и всеми другими благами. Что стало - "убогий куцый" процессор, с кучкой регистров. Вы думаете, что форумы разработчиков для Apple наполнились стонами и слезами, о том, как "убого для программера выглядит интеловский чип"? Ничего подобного, разработчики практически ничего не заметили, как писали на Objective-C (в основном), так и пишут, не парясь о регистрах. Немножко пришлось повозиться разработчикам драйверов, совсем чуть-чуть и только первое время, да и то, это было связано по большей части с новой MacOS X. При разработке драйверов под Windows так вообще, из ОДНОГО И ТОГО же исходника (естественно, в котором нет ни строчки на ассемблере) генерируется сразу 3 бинарника в 3 каталогах: x86, amd64 и ia-64. Вот Вам и "выглядит" для программиста.
>>Теперь с джобсовскими хотелками мучается Intel. :)
>Это Вам Intel написал в слёзном письме, о том как он мучается?:)Нет, IBM рассказал про свою часть.
>Снова повторю, это было справедливо -дцать лет назад.
Не-а. Сейчас зазор в производительности между индусом триальным и человеком с головой вырос просто катастрофически.
>На сегодняшний день лучше всех разбирается в тонкостях работы кэшей, конвееров,
>блоков предсказателей ветвлений нечто по имени Intel C++ Compiler.Особенно с маленьким патчиком, чтоб не тормозил на оптеронах. :}
>На хорошем сложном куске кода человек непременно проиграет машине,
>доказано многократно как собственным опытом, там и опытом множества других.Извините, а Вы кто? (без подковырок, просто явно не системщик)
>Упираться в доказывании общеизвестного факта я не собираюсь :)
Общеизвестные факты общеизвестным фактам рознь. Если бы у нас сидели с таким отношением, то масштабируемость кластеров на несколько _процентов_ лучше, чем Cray сотоварищи -- не вытягивали бы. А там каждый процент буквально дорогого стоит.
>У Вас своё мнение, у меня своё.
Да, конечно.
>Я считаю, что фраза:
>>выглядит для програмера как галимый
>>CISC с куцыми регистрами и без относительной адресации
>в 2010 году - не более чем язвительный пшик.Применительно к AMD64 это и впрямь передёргивание (опять же насколько понимаю).
>Количество регистров и способы адресации никак не сказываются на работе программиста,
>если только Вы - не разрабочик компилятора (вероятность чего весьма мала, учитывая то,
>что доля таких программистов среди всех остальных - очень и очень невелика).Ещё как минимум ядерщики и разработчики кода, который работает в глубоко вложенных циклах (например, libgmp).
>Ничего подобного, разработчики практически ничего не заметили, как писали на Objective-C
>(в основном), так и пишут, не парясь о регистрах.Напоминаю на всякий, что бывалые яблочные разработчики к прыжкам уже привычны -- сперва с 680x0 на PPC, а теперь с PPC на x86*.
>Немножко пришлось повозиться разработчикам драйверов, совсем чуть-чуть
>и только первое время, да и то, это было связано по большей части с новой MacOS X.Что-то мне припоминается, что Вы немного перегнули в другую сторону, но да неважно, а вспоминать или пойти в соседнюю комнату поинтересоваться у генерального эпловода конторы лень (и дёргать почём зря).
>При разработке драйверов под Windows так вообще, из ОДНОГО И ТОГО же исходника
>(естественно, в котором нет ни строчки на ассемблере) генерируется
>сразу 3 бинарника в 3 каталогах: x86, amd64 и ia-64. Вот
>Вам и "выглядит" для программиста.Ну так оно потом и работает. Не, как-то работает, не спорю. Обычно.
>Нет, IBM рассказал про свою часть.А при чем тут IBM? Я спросил у Вас, откуда Вам известна столь интимная информация о непосильных мучениях Intel с хотелками Джобса. Хотя, не удивлюсь, что Вы ответите аналогично - Intel рассказал :)
>Не-а. Сейчас зазор в производительности между индусом триальным и человеком с головой вырос просто катастрофически.
Теперь какого-то триальнрого индуса приплели... Разговор шел о сравнении человека с ассемблером в руках и современного оптимизирующего компилятора типа ICC. Откуда тут взялся индус - непонятно.
>Особенно с маленьким патчиком, чтоб не тормозил на оптеронах. :}
На оптеронах код работать быстро и не обязан. Этот компилятор использует уйму недокументированной информации о внутренеей архитектуре Intel'овских чипов, которую программист ни в одном руководстве не вычитает. И вот из-за этого у человека нет шанса построить код, который бы максимально учитывал все эти особенности, и более быстрый, чем тот, что построит всезнающий и закрытый ICC.
>Извините, а Вы кто? (без подковырок, просто явно не системщик)
Не знаю, что именно Вы подразумеваете под словом "системщик", но с программированием на ассемблере сталкиваюсь каждый день. В основном под ARM в системах жесткого реального времени, там действительно это оправдано. А вот под х86 как ни пытались, но более-или менее сложной задаче - ICC все далал гораздо лучше. Я повторюсь, на очень коротких фрагментах иногда имеет смысл использовать ассемблер или же использовать библиотечную и вылизанную до блеска реализацию. Но у человека практически нет шансов написать что-то нестандартное и более быстрое на ассемблере, чем это будет скомпилированный ICC кусок кода на Си.
>Общеизвестные факты общеизвестным фактам рознь. Если бы у нас сидели с таким отношением, то масштабируемость кластеров на несколько _процентов_ лучше, чем Cray сотоварищи -- не вытягивали бы. А там каждый процент буквально дорогого стоит.
Масштабируемость кластеров - тема очень специфическая, из неё трудно делать какие-то общие выводы. Этот как раз тот случай, когда использование ассемблера оправдано, я никогда и не утверждал, что ассемблер не нужен совсем :) Но речь изначально шла все-таки не о таких высоких материях ;)
>Ещё как минимум ядерщики и разработчики кода, который работает в глубоко вложенных циклах (например, libgmp).
Опять же - это список тех немногочисленных крайностей, которые я ни в коем случае не отрицаю. Что касается ядерщиков - тоже согласен, но с уточнением, что не просто ядерщики, а узкая их прослойка:) Большинство ядерщиков ничего на ассемблере не пишут, для них Си более чем достаточно.
>Напоминаю на всякий, что бывалые яблочные разработчики к прыжкам уже привычны -- сперва с 680x0 на PPC, а теперь с PPC на x86*
Вот именно, и ни в какой википедии Вы не найдете упоминания о двух мучительных периодах жизни разработчиков под Маки:) В этом собственно и смысл всей дискуссии в макро-масштабе: программистам по большому счету не важно какие используются регистры и способы адресации. Не абсолютно всем, но абсолютному большинству точно.
>Ну так оно потом и работает. Не, как-то работает, не спорю. Обычно.
Замечательно оно работает. Занимался этим лично, поэтому заявляю это с полной отвественностью за свои слова. Несмотря на то, что ничего по существу Вы и не возразили:)
"в AMD64 относительная адресация есть и действительно помогает по части "быстро""Относительная адресация нынче помогает разве в задачах виртуализации.
>Относительная адресация нынче помогает разве в задачах виртуализации.Угу, нишевый такой рынок. Тут скоро браузер небось будут в отдельную виртуалку засовывать. :)
>>Относительная адресация нынче помогает разве в задачах виртуализации.
>
>Угу, нишевый такой рынок. Тут скоро браузер небось будут в отдельную
>виртуалку засовывать. :)Рынок и нишевый, и ниша не слабая, но вот на общую производительность в целом процессор влияет все меньше и меньше. Отсюда и виртуализация. Мощность вычислительная растет, эту мощность чтоб не в пузомерки пустить, а с толком утилизировать, виртуализацию и назначили писком моды.
А не поленись-ка и глянь на чём собраны ТОП-10 суперкомпьютеров. Хорошо, ТОП-20. 30. 40. 50.
Сколько там (супер-пупер) Итаниума и сколько АМД? А?
Насколько мне известно поддержки Solaris PowerPC от SunMicrosystems нет. А вот Itanium-64 похоже на правду. Solaris хорошо переносится на 64-битные системы. Но чтобы убедиться нужно запустить на целевой машине sddtool(http://www.sun.com/bigadmin/hcl/hcts/device_detect.jsp).
Что вы несёте ?
солярис всегда 64-битныйна IA-64 Соляриса нет
вот новость за 2000-й год
http://news.cnet.com/Sun,-Intel-part-ways-on-Solaris-plans/2...
>солярис всегда 64-битныйЕщё скажите "был". :)
Я имел ввиду, что Solaris хорошо работает с 64-битными x86 архитектурами, например AMD64. Причем именно как 64 система, а не как 32-битная. в то время как IA-64 известна отсутствием поддержки 32-битных программ.
Вот HP не везет. Мало того, что доля на Unix рынке никак не растет по сравнению с IBM, так вот теперь еще и Red Hat такой штык в спину воткнула. Скоро даже откатчикам будет сложно продать свой несупердом.
>Вот HP не везет. Мало того, что доля на Unix рынке никак
>не растет по сравнению с IBM, так вот теперь еще и
>Red Hat такой штык в спину воткнула. Скоро даже откатчикам будет
>сложно продать свой несупердом.Может, Интелу не везёт? HP и Red Hat вроде как дружат крепко ещё.
>>Вот HP не везет. Мало того, что доля на Unix рынке никак
>>не растет по сравнению с IBM, так вот теперь еще и
>>Red Hat такой штык в спину воткнула. Скоро даже откатчикам будет
>>сложно продать свой несупердом.
>
>Может, Интелу не везёт? HP и Red Hat вроде как дружат крепко
>ещё.Перечитал второй абзац новости и всё понял.
да уж по поводу сопердома это точно, он совсем не супер :)
>да уж по поводу сопердома это точно, он совсем не супер :)да, хлам и обогреватель ещё тот...
итаниуму , к сожалению уже не с кем тягаться