Сегодняшний мир — это amd64 (по-другому x64, или x86-64), armv7 и, в скором будущем, aarch64 (64-битный ARMv8). Всё остальное мертво, Джим. Никто не вкладывает достаточно денег и мыслительного труда в прочие архитектуры. В действительности, лишь небольшая часть людей в курсе существования остальной части экосистемы (mips, power8, ...), и все равно никому нет до них дела.
Поддержка устаревшей платформы на плаву — это весело, поскольку это напоминает тебе о 90-ых, когда существовал большой выбор «железных» платформ, с приблизительно одинаковым соотношением цены/мощности. В конце концов, дешевые PC убили практически всю конкуренцию, а рынок смартфонов дал ARM нездоровую долю рынка в мире встраиваемых систем.
Затем, спустя некоторое время, веселье подходит к концу, поскольку никто не пишет код, держа в уме твою платформу, — ведь она не считается достаточно мощной, а современные компиляторы больше ее не поддерживают (или они генерируют для нее нерабочий код, что на деле еще хуже). У твоей платформы есть аппаратные границы в несколько сотен MB физической памяти? Тебе не удастся запустить на ней веб-браузер или даже программу для просмотра PDF. Кто-нибудь все еще запускает testsuite из последней версии gcc на твоей платформе? Нет? Прости, чувак, но вот тебе «никель» (5 центов), сходи купи себе уже компьютер получше…
На деле, поддержка платформы в жизнеспособном состоянии — это настоящая командная работа. Она требует серьезных обязательств от проектов, являющихся «строительными блоками»: не слишком сильно «забагованного» тулчейна (as/ld/gcc), поддержки в флагманских проектах (emacs, python, X11, mozilla, libreoffice...), а также аккуратной и актуальной документации, доступной бесплатно.
Ни один из перечисленных пунктов не является истиной для всех платформ, исключая amd64, armv7 и aarch64.
Из-за всего этого стремление поддерживать «жизнь» какой-либо другой платформы — это на самом деле попытка плыть против течения.
Взгляни на все проекты всех бесплатных операционных систем: они реально поддерживают только amd64, armv7 и aarch64. Вот так вот! Иногда они притворяются, что поддерживают несколько экспериментальных платформ; или другие платформы, которые не тестировались годами и кросс-компилируются только потому, что они больше не self-hosted.
Конечно, ты все еще можешь встретить нескольких безумцев, готовых выполнить невероятный объем работы для предотвращения упадка их любимой платформы и умело создающих впечатление того, что эти платформы — все еще «пассажиры первого класса». Но эти ребята — те же самые люди, что были и десять лет назад. Рано или поздно, они устают и сдаются. Как, например, я.
Самое худшее во всем этом — это когда ты оглядываешься назад и понимаешь, что после всех этих лет, свободное ПО проиграло. Компаниям, занимающимся созданием не-свободного ПО, хватило достаточно ума и смекалки, чтобы поймать «импульс» разработчиков свободного ПО, направленный на работу над встраиваемыми платформами, и использовать его для того, чтобы максимально сократить собственные расходы на разработку ПО, получив при этом еще и позитивную реакцию прессы.
Таким образом, сегодня мы строим одноразовые системы, не учитывающие того, что ждет нас в будущем — поскольку, когда придет время, мы просто возьмем очередной модный SoC. Нет необходимости иметь всё то, что формирует архитектуру:
- видение будущего, позволяющее различным поколениям аппаратного обеспечения использовать одно и то же «железо» и софт;
- дизайн, позволяющий сегодняшнему ПО запускаться на «железе» завтрашнего дня до тех пор, пока изменения не слишком радикальны;
- целостность в выборе шин, процессоров, отображений адресного пространства (consistency in choices of busses, key chips, address maps);
- настоящего firmware, а не чего-то абсолютно отвратительного вроде EFI, который не может соревноваться даже со старым Open Firmware (IEEE 1275), которому уже больше 20 лет;
- надежные перечислители шин (reliably enumerable busses).
Нет, сэр, мы возьмем нынешний распоследний SoC, подключим несколько дополнительных устройств туда, где сможем найти дыру в адресном пространстве, засунем туда кастрированный u-boot и стабильное ядро Linux, — получите и распишитесь, ваша "платформа" готова. А люди и рады.
Я потратил 20 лет своей жизни, пытаясь продвигать правильный взгляд на свободное программное обеспечение, его ценности и его этику; сражался за него, всегда был активно вовлечен, старался показывать другим пример, и сегодня я чувствую так, словно все мои усилия были лишь пустой тратой времени, и ничего из того, что я сделал, не принесло пользы.
С этим трудно смириться, но лучше сдаться сейчас, чем продолжать попытки и только еще больше расстраиваться.
Комментарии (126)
dea
27.11.2015 05:29+1Статья говорит будто об архитектурах, а на самом деле это вопль о платформах. Ага, мир граблей велик в своем беспорядке, и кроме тулчейнов есть на свете много еще чего, друг Гораций.
Впрочем у изрядного количества людей всегда будет работа. И это успокаивает.
YuriPanchul
27.11.2015 07:31+9Как инженер микропроцессорной команды MIPS I6400, я не согласен с автором текста. MIPS не только не мертв, но и еще отгрыз у ARM назад несколько процентов рынка в прошедшие пару лет. Есть вещи, которых у ARM просто нет (например многопоточность на одном ядре — hardware-supported multithreading), а у MIPS есть, и при этом у MIPS стабильная экосистема, которая кстати включает для BSD некоторые забавные вещи — см. напр. github.com/sergev/qemu/wiki/LiteBSD%20Example
norguhtar
27.11.2015 08:18+1Очень специфичная хрень. Купить аналог Rasberry Pi весьма и весьма сложно.
spot62
27.11.2015 10:11+6половина, если не больше, SoC домашних роутеров — это MIPS. dev.openwrt.org/wiki/platforms
можно купить, поставить openwrt и упражняться.norguhtar
27.11.2015 11:14+1Я имею ввиду не купить в виде комплекта для разработки с большим числом коннекторов.
spot62
27.11.2015 15:11
Greendq
27.11.2015 20:06+5Ага, вотпрямщаз. Я с февраля жду — последнее сообщение от них — «вот завтра отправим» и далее тишина, все участники проекта сообщения игнорируют. 54 евро не прям вот такие деньги за 2 комплекта, чтобы сильно горевать, но больше я ни один российский проект по железу не поддержу.
RussianNeuroMancer
27.11.2015 22:03О, вы наверное в курсе — чем закончилась драма с разделением компании? Вроде же были люди, которые встречались с одним из разработчиков, видели готовые платы.
AllexIn
28.11.2015 14:53Есть люди, которые после разделения уже получили свой заказ… Да, пришлось почти год ждать. :)
Но плата есть и уже работает месяц в собранном устройстве.
AllexIn
28.11.2015 14:54А вы где заказывали? Просто за кикстартер и за заказы с сайта в итоге отвечают две разные компании.
Я заказывал на сайте, со мной связались месяц назад, уточнили адрес доставки и прислали.
Да, у них есть проблемы. Но это не значит что они всех кинули. Просто проблемы оказались достаточно большими чтобы не суметь их быстро решить.Greendq
01.12.2015 11:09С сайта заказывал. Проблема ещё усложняется тем, что попросил товарища оплатить, так как мою долларовую визу их процессинг не жрал, только рублёвая нужна была (там как раз шумиха с визой/мастеркардом для РФ была). В процессе переписки мне подтвердили, что да, есть такой получатель, всё клёва, буквально завтра отправим… и пинг пропал.
Меня, как пользователя, вообще не интересует, кто кого там внутри команды кинул и что не поделил. Для меня теперь вообще, всё, что связано с Black Swift — потенциальный кидос и попадос, до тех пор, пока меня не убедят в обратном.AllexIn
01.12.2015 11:37+1А я вам ничего про «кинули/не поделили» не говорил.
Есть проблемы. Их медленно, но разруливают. Платы медленно, но рассылают.
Я понимаю ваше недовольство. Сам в течении года возмущался, потому что думал что тупо кинули.
Но между «тупо кинули» и «возникли большие проблемы» — есть разница.
Если вы просто клиент, которому нужна плата — не понимаю зачем вы вообще в предзаказы в фирму без репутации полезли, если существует множество альтернативных плат сравниымх по функционалу и давно создавших себе репутацию.
Если же вы вписались в частности чтобы помочь отечественному продукты — не понимаю вашего возумщения, т.к. риски и возможные проблемы были изначально и вообще предзказ и краудфандинг таких вещей на том этапе который был год назад — это авантюра. Вы сами осознано влезли в авантюру, а сейчас воете о том что вас кинули.Greendq
01.12.2015 12:02Мне захотелось попробовать MIPS. Из-за того, что «известный обозреватель по железкам» Олег Артамонов участвует в проекте — рискнул заказать. Ну и вот…
А про проблемы у них в команде узнал не от вас, а по сообщениям, я вам эти слова и не приписывал.
r00tGER
01.12.2015 11:03Возможно, не видели ещё — geektimes.ru/company/unwds/blog/266676
Greendq
01.12.2015 11:11Видел. Попытка отмежеваться от «плохих» и выглядеть белыми и пушистыми. Не верю.
Alexeyslav
27.11.2015 12:32Упражняться не очень выйдет — на таком комплекте недоступны средства отладки и процесс изучения платформы происходит примерно как поклейка обоев в комнате через замочную скважину.
spot62
27.11.2015 15:09gdbserver и консоль отменили? или вам обязательно под bare-metal через jtag?
Alexeyslav
27.11.2015 15:34А как ещё загрузчик отлаживать? Или если ошибка в коде приводит к разрушению стека вместе с программным отладчиком…
spot62
27.11.2015 17:16универсально — через консоль. не все проблемы легко повторить при помощи jtag в пошаговом режиме
sashkin
27.11.2015 13:35+2Лет 5 назад 99% SOHO роутеров были на mips, сейчас далеко не столько и тенденция идёт в сторону уменьшения. В пользу arm. Просто факт. Так что автор оригинальной статьи прав – некоторые платформы уходят. Если на внедрённых везде где можно линуксах это не так заметно, то на менее распространённых платформах тенденция может ощущаться гораздо отчётливей.
achekalin
28.11.2015 01:43Микротик, как пример не совсем чтобы, если верить автору поста, мейнстримной архитектуры :)
Живут, и, похоже, знают, что будут делать дальше.
bolick
27.11.2015 14:40+8Как инженер команды, поддерживающей еще одну (еще менее известную в широких кругах архитектуру ARC, см. https://en.wikipedia.org/wiki/ARC_(processor)), соглашусь с Юрием в том, что не стоит делать выводы основанные лишь на новостях с «Первого канала».
В наши дни не только продолжают существовать давно известные архитектуры, причем, некоторые обретают второе дыхание (см. en.wikipedia.org/wiki/OpenPOWER_Foundation занимающейся активным развитием и продвижением решений на основе IBM Power), но и появляются новые архитектуры (пусть и не очень часто, см. www.kalrayinc.com/kalray/products/#processors).
Дело просто в том, что конкурировать с x86 на рынке лэптопов и c ARM на рынке смартфонов действительно очень тяжело ввиду разных факторов, а потому все большую популрность преобретают процессоры и платформы, заточенный под какие-то конкретные рынки или области применения. И обыватель как правило не знает, с каким процессором он имеет дело, подходя к холодильнику, включая телевизор или садять в автомобиль. Более того, неншние SoC-и (т.е. системы на кристалле) как правило содержат не одно процессорное ядро, а целый зоопарк ядер. В современных смартфонах (уж не говоря про лэптопы и десктопы) как минимум: основной процессор, на котором выполняется ОС, с ним в связке может работать сопроцессор обработки звука и/или видео, мониторингом и регулировкой питающих напряжений занимается еще один процессор, в контроллере экрана и сенсорной панели тоже про процессору… но на слуху только ARM и x86 :)
Да, немного обидно, что RPi можно купить в каждой булочной, а такую же платку на своей любимой платформе Х не купить ни за какие деньги, но это не умаляет важности других платформ и архитектур.anderston
27.11.2015 15:14Мне кажется, разработчика печалит то, что архитектур общего назначения от этого больше не становится. Что, к сожалению, приводит к тому, что костыли, которые в них неизбежно есть, становятся «проверенными практиками». Никто ведь не будет портировать что-то серьёзное на процессор для холодильника.
beeruser
27.11.2015 08:33+11Посыл статьи в том, что MIPS, PPC перешли в разряд second-class citizens.
Тулзы и прочее пилится лишь компаниями производителями (IMG/IBM) и отдельными волонтёрами.
Какой смысл в SMT для задач, которые потянет I6400?
Проще 4хA53 поставить, которые ещё и на большей частоте могут работать.
>> отгрыз у ARM назад несколько процентов рынка
Какого именно?
В любом случае продажи ARM процессоров пока что расли экспоненциально (12 миллиардов продано в 2014г)
https://en.wikipedia.org/wiki/ARM_Holdings#Mali_licensees
12 миллиардов это больше чем количество x86 процессоров в PC за всё время их существования.
petrovichtim
27.11.2015 15:07+5У меня на столе сейчас лежит 8 ARM устройств и только одно x86 под столом.
khim
28.11.2015 14:35+2Причём в том x86, что у вас под столом наверняка ещё парочка ARM-процессоров где-нибудь сидит…
grossws
29.11.2015 01:53+3Скорее ощутимо больше, чем парочка. Если только в hdd их обычно 2-3, хотя и со специализированными кусками. www.arm.com/markets/embedded/hdd-ssd.php
kinguru
01.12.2015 11:12+1Боюсь, что разработать ARM невозможно без x86, который под столом. Есть тулзы проектирования под ARM, кады?
ARM это исполнительные машинки, ширпотреб (телефон, планшет). x86 это рабочие лошадки для бизнеса, разработки. Под те же ARM.khim
01.12.2015 14:43Замените в вашем утверждении x86 на Alpha (да, кажется, Alpha, хотя могу путать, помню точно что там какой-то 64-битный процессор был), ARM на x86, сдвиньте по времени лет примерно так на 20 — и тоже получите абсолютно верное утверждение. Только… где сейчас та Alpha? Вот и x86 имеет неплохие шансы на движение в этом направлении — как бы сложно ни было это себе сейчас представить…
kinguru
01.12.2015 16:45Вопрос в том, почему же x86 лучше Alpha? Ведь именно поэтому они вытеснили Alpha, не так ли?
Мне кажется стоит учитывать не только сам процессор, но и его применение. И здесь выходят на свет законодатели в сфере софта. Возможно, это даже заслуга Microsoft. Поскольку большинство ПК работали и работают под Windows. Большинство софта работает под Windows.khim
01.12.2015 18:45+3Большинство софта работает под Windows.
Сие есть или уже неправда или «почти неправда». «Большинство софта» сегодня работают под Android и чуть меньше под iOS — ну или это случится через пару лет.
Возможно вы хотели сказать «большая часть „настоящего“, „профессионального“, софта работает под Windows»… ну так 20 лет назад это же самое можно было сказать про «big UNIX»… разница, конечно, в том, что мир «big UNIX»а был раздроблен, а WIntel — это единая платформа, что должно дать ей чуть больше устойчивости… поживём — увидим. Я не готов давать «руку на отсечение» и утверждать что через 20 лет Wintel перейдёт в разряд legacy… но вероятность такая есть, да.
erlyvideo
27.11.2015 12:36+1вот и меня удивило насчёт мипсов. Покажите мне упакованный в коробку ARM за $30 с 5-ю ethernet и я удивлюсь.
Все эти армы для тех, кто готов вкладывать деньги ещё и в упаковку. Я вот не готов, покупаю готовые роутеры для мелких задач, а там мипс.
Где почитать про это ваше чудо с мультитредингом?khim
28.11.2015 14:41+2Если вы рассмотрите процессоры для стиральных машинок, то вы там и не такую экзотику увидите. MIPSы в роутерах укоренились очень крепко, но даже оттуда их, скорее всего, скоро выдавят. А это была последняя ниша где процессор кого-то волновал.
Тут речь идёт не о законченных программно-аппаратных платформах (там может быть какая угодна экзотика), а о чём-то подо что выпускаются независимо программы и железо.
Роутеры сюда отнести можно с большой натяжкой, в любом случае.
SOLON7
27.11.2015 08:37-40Очень глупо! почему доля Windows намного больше чем Мак, потому что сама операционка стоит дешевле! И не надо покупать Мак при этом! Почему андроид больше рынка чем у того айфон блакбери итд! потому что андроид дешевле! Кто на рынок зашел первым тот и снял все сливки!
corristo
27.11.2015 13:40+6Операционка на Мак не стоит ничего ;)
entomolog
27.11.2015 20:10+2Вот только ставить её не на Мак лицензия не разрешает.
corristo
27.11.2015 20:11Зависит от законодательства страны.
entomolog
27.11.2015 20:36Разве? Вот выдержка из Apple's license agreement for OS X Mavericks
H. Other Use Restrictions. The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so.
Взято от сюда
Причем я говорю именно про легальность использования. То что все ставят хакинтошы и ни у кого с этим проблем нету — это отдельная тема.
splav_asv
27.11.2015 22:49Вроде бы в некоторых странах пункты договоров, противоречащих законодательству данной страны автоматически признаются ничтожными. И если в такой стране Apple в рамках данного соглашения передает право использования некому лицу, он может ставить данную ОС куда хочет полностью легально.
Могу ошибаться.
Goodkat
27.11.2015 23:01Кое-где в Евросоюзе можно использовать OEM-версии и подержанное ПО, так что полностью легальную лицензию винды можно купить на ебее в виде recovery-диска с лицензионной наклейкой или в виде просто наклейки, переустанавливать на неограниченное число компов (но строго по очереди — стёр на старом, поставил на новый), а потом — стереть со своего компа и перепродать лицензию дальше :)
Главное, чтобы в любой момент времени этот лицензионный ключик использовался только на одном компьютере, чтобы соблюсти условия лицензии.Londoner
28.11.2015 00:26Есть ссылочка на первоисточник?
Goodkat
28.11.2015 00:58Нет ссылочки, я сам как бы сам являюсь первоисточником, так как покупал так Windows, но могу погуглить за вас: lmgtfy.com/?q=oem+used+software+eu
Minras
03.12.2015 17:53У меня ссылки тоже нет, но по факту у нас в Голландии на местном аналоге Ибея так куча софта продаётся. Я себе винду 8.1 купил за что-то типа 15-25 евро, присматриваюсь к оффлайновому лайтруму за 18.
Goodkat
27.11.2015 22:55+5Раньше писали «non-Apple-labeled» — официальные наклейки с яблоком были в комплекте с каждым айподом, наклеил на хакинтош, вот тебе и Apple-labeled.
novoxudonoser
27.11.2015 13:57+2Юный неофит, успокойся и проходи дальше, пока ты не в состоянии понять о чём тут говориться.
sashkin
27.11.2015 14:04+5Вы наговорили глупостей. Не рассуждайте о том, в чём не разбираетесь.
> доля Windows намного больше чем Мак, потому что сама операционка стоит дешевле!
OS X уже который год раздаётся бесплатно. А до этого стоил смешных денег на порядок ниже Windows. А линукс так вообще от рождения свободен.
> Кто на рынок зашел первым тот и снял все сливки!
Мак появился раньше Windows в её каноническом виде. И?
Вы в руках у каких-то не соответствующих реалиям заблуждений. На разных рынках доля платформ/систем/ос разная. Если в вашем городе собрать из недорогих комплектующих ПК и поставить на него пиратскую Винду – это самое доступное решение и потому распространённое, то это не значит, что в той же Америке/Европе так же. И блекбери не проиграло потому, что айфон/андроид были дешевле.b3nd3r
27.11.2015 21:40-2> OS X уже который год раздаётся бесплатно. А до этого стоил смешных денег на порядок ниже Windows. А линукс так вообще от рождения свободен.
Бесплатного ничего не бывает. Стоимость операционки не складывается из положения звезд на небе, а включает в себя работу программистов, маркетологов и т.п., что включается в стоимость конечного устройства. Роллинг-модель обновления теперь есть и у Виндоус.
justaguest
28.11.2015 00:35И… в стоимость чего включается работа программистов, комьюнити, и т.п. GNU/Linux?
StreetStrider
28.11.2015 01:42В сэкономленные бизнесом деньги, которые потом попадают в добавочные стоимости их проприетарных продуктов.
justaguest
28.11.2015 01:47Хм… Я вас не понял. Вы хотели сказать «сэкономленные деньги вычитаются из стоимости проприетарных продуктов»? Нет, я могу предположить, что «добавляются» в том смысле, в каком можно складывать отрицательные числа, но интуиция мне подсказывает, что вы не об этом говорите.
StreetStrider
28.11.2015 16:16Нет, не вычитаются, а добавляются, потому что сами по себе несут ценность и могут входить в добавочную стоимость других продуктов, проприетарных или свободных, но т.к. производные свободные будут так же бесплатны, то я сузил до проприетарных.
mva
04.12.2015 20:591) свободное != бесплатное
2) а добавление цены продукту за счёт работы, сделанной кем-то другим, по-моему, называется наглость.
tyomitch
28.11.2015 13:24В стоимость коммерческих продуктов тех компаний, в которых эти программисты работают.
mva
04.12.2015 21:01Буду очень признателен, если Вы осмотрите мой профиль на гитхабе, количество «продуктов» (библиотек и софта), в который я контрибьючу и сопровождаю, а потом скажете в стоимость каких продуктов входит эта моя работа.
SOLON7
27.11.2015 08:40-23это больше вопрос того чья инфраструктура развита! Статья больше о рыночной экономике нежели об архитектуре, хотя тут и есть своя взаимосвязь!
Anvol
27.11.2015 12:16+3Еще один фактор, на мой взгляд, — фокус на конечном потребителе. Мы абсолютно правильно констатируем преимущества и недостатки платформ/шин/загрузчиков/ос. А голос остается за купюрой потребителя, который покупает то, что решает его проблему или удовлетворяет потребность за приемлемые деньги с необходимым качеством.
Раньше вопрос выбора правильной архитектуры напрямую влиял на возможности устройства. Сегодня же мы можем подключить телефон к телевизору по Wi Fi и стримать 1080p@60. И потребителю пофиг на кривой загрузчик и ошибки шины…Alexeyslav
27.11.2015 12:37А потом оказывается что платформа из-за шины или кривого загрузчика принципиально не сможет поддерживать 4К видео, и для того чтобы перейти на 4К прийдётся серьёзно переделывать саму платформу, адаптировать под неё уже написанный софт и т.д. а там БАХ — уже и 8К надо а платформа 4К уже впритык поддерживает… вот это и есть тупик в развитии.
Anvol
27.11.2015 13:04+2абсолютно верно. Инвестирует потребитель, будущее железа его вообще не интересует. Он лишь осознает, что в среднем через 2 года купит новый телефон. И вполне вероятно, что внутри него будет новый SoC, с абсолютно новой но не менее кривой шиной…
Viacheslav01
27.11.2015 14:45+2С другой стороны встает overenginering.
Alexeyslav
27.11.2015 15:40+2Он и сейчас стоит в полный рост… когда 8-ядерные процессоры используют для просмотра фильмов, сёрфинга в интернете и печати различных документов. Большая часть ресурсов и возможностей обычных ПК попросту простаивают и оказываются невостребованными.
Viacheslav01
27.11.2015 16:38+1Они по крайней мере появились с вполне конкретной целью, в результате эволюции. Да дома может что то и не надо, но в поф сфере оно пригодиться.
Я имел ввиду классический водоворот проектирования, когда на старте пытаются заложить все что можно и получается, что то настолько невообразимо крутейшее насколько и сложное. Но дорого и не нужно.
Alexey2005
27.11.2015 20:07+2Невостребованными? Да современный софт сожрёт сколько ни дай, и ещё попросит. Потому как фреймворки с песочницами жиреют день ото дня.
Два уровня виртуализации и пять слоёв абстракций — и вот уже простая веб-страничка в две картинки и два абзаца отжирает 4Гб памяти и 4 ядра из 8…
А Unity так разжирел, что уже и в 2Гб памяти не лезет. А разработчики, получив очередной кол за то, что их поделка в полтора полигона вылетает на девайсе с 2Гб памяти каждый раз, когда на устройство приходит SMS, плачутся — мол, тут от нас ничего не зависит, просто возьмите устройство помощнее.Alexeyslav
28.11.2015 20:58Это называется транжирство и непрофессионализм. Конкретно для выполняемых функций многие части компьютера рядовыми пользователями не используются.
А между тем, такая фундаментальная вещь как PCI-шина берёт свои корни со времён больших машин и прошла сквозь множество поколений компьютеров вплоть до сегодняшних дней.
viatoriche
27.11.2015 12:57+17Вероятно, не «некоему Джиму», а очень даже Джиму Кирку, капитану Энтерпрайз.
He's dead, Jim
saboteur_kiev
27.11.2015 16:51+2Скорость увеличения производительности снизилась в разы, поэтому у конкурентов появился шанс догнать текущих фаворитов, причем именно архитектурой, потому что текущая упирается в физические пределы и по размерам и по энергоконтролю.
Следовательно, хорошая архитектурная идея, которая потенциально масштабируется больше, чем текущие лидеры, может выстрелить.
А виртуализация сильно упрощает старт и миграцию.
Мне кажется, что рано сдался, ну или просто попал не в тот проект, который может конкурировать на текущем рынке. Развиваются же ардуины/распберри потихоньку.
orcy
27.11.2015 17:08Если смотреть на Android toolchains в NDK, то архитектуры там только растут:
arch-arm
arch-arm64
arch-mips
arch-mips64
arch-x86
arch-x86_64
Дальше моя диванная аналитика: из-за большого количество приложений производители телефонов будут поддерживать arch-arm и где-то arch-x86, просто чтобы не подставлять своих клиентов не работающими игорями на C++. Если x86 еще может легко перейти на x86_64 (consumer x86 на андроидах все равно экзотика), то перевести арм на 64 бита будет сложновато, только если поддерживать два ABI одновременно.
fshp
28.11.2015 00:56производители телефонов будут поддерживать arch-arm и где-то arch-x86, просто чтобы не подставлять своих клиентов не работающими игорями на C++
Вы же не думаете, что в одном устройстве одновременно и arm и x86?orcy
04.12.2015 13:07Во первых это вроде бы возможно, некоторые x86 планшеты вроде могут запускать arm-овский код (какой-то режим эмуляции: stackoverflow.com/questions/13005303/how-does-native-android-code-written-for-arm-run-on-x86). Но пытался рассуждать про другое, а именно будут ли производители телефонов на базе Android переходить на 64-битные версии arm и x86.
khim
04.12.2015 13:21Но пытался рассуждать про другое, а именно будут ли производители телефонов на базе Android переходить на 64-битные версии arm и x86.
А куда деваться? Ещё лет несколько можно пожить без 64 битов можно, но рано или поздно переходить придётся. Это не так страшно как кажется если не уподобляться придуркам, которые устроили всем «кузькину мать» в Linux'овых дистрибутивах — но это чисто некомпетентность дистрибутиводелов, ничего особо страшного тут нет. Сравните ужасы переходов в Linux и в Windows — и вы всё поймёте…orcy
04.12.2015 13:56Актуальность перехода на 64-бит на телефонах не слишком вроде высокая, адресация >2 Гб нужна меньше чем поддержка существующих приложений. Было бы конечно неплохо если бы производители ввели одновременную поддержку двух архитектур (32 и 64-битной) какое-то время.
justaguest
04.12.2015 16:07Бoльшая адресация памяти — на мой взгляд наихудший аргумент в пользу 64 бит, и все его удивительно упорно повторяют. Для ОС есть PAE, а приложений, использующих 4Ггб я вообще ни разу не встречал (конечно я не говорю о серверах — мы же о чем-то более близком к пользователю, верно?).
64 бита, это возможность делать расчеты с более высокой точностью без падения производительности — за счет большего размера регистра; плюс улучшение производительности за счет ?) большего числа регистров (хотя по АРМ я могу быть не прав, я не знаю их подноготную, так, по-крайней мере, на х86), и ?) лучших соглашений о вызовах, которые намного реже используют стек.orcy
04.12.2015 19:57> 64 бита, это возможность делать расчеты с более высокой точностью без падения производительности — за счет большего размера регистра
Если брать x86/x64 то вроде бы производительность плавающей точки будет примерно одинакова на SSE инструкциях. Насчет целочисленной арифметики не уверен, наверное x64 будет лучше, но ведь чаще всего int — это 32-бита.
> лучших соглашений о вызовах, которые намного реже используют стек.
Да, по крайней мере на windows с ABI у x64 стало получше.
С другой стороны тот же Кнут жалуется на 64-битные указатели (http://www-cs-faculty.stanford.edu/~uno/news08.html), т.е. когда программе не нужно больше 2Гб памяти, она все равно вынуждена использовать 64-битные указатели, что в два раза дороже по размеру, а значит хуже влезает в разного рода кэши процессоров.
justaguest
04.12.2015 15:55Эмм… А можно поподробнее, что за проблемы с переходом 32 > 64 в GNU/Linux? Я вот с самой первой установки использую х86_64, и единственная проблема, которая у меня вообще когда-либо возникала — когда для курсовой по оптимизациям надо было скомпилировать 32-битный wine (погонять в профилировщике), и я не мог поставить 32-битные девелоперские зависимости. Решилось посредством компиляции под lxc-tools.
khim
04.12.2015 20:24+1А можно поподробнее, что за проблемы с переходом 32 > 64 в GNU/Linux?
Изначально, когда x86-64 только появился куча дистрибутивов решила, что все разработчки просто ждут-недождутся возможности попортировать свой код на x86-64 и слелали чисто x86-64 дистрибутивы. Когда пользователи такого «чисто 64-битного дистрибутива» спрашивали «а как же Flash?» им отвечали «это — не наши проблемы, когда Adobe сделает — тогда и будет». Adobe, разумеется, неизменно отвечал что их 32-битная версия отлично работает, а если работчики дистрибутивов поломали совместимость, то пусть они её и чинят. Через какое-то время появился костыль и жизнь стала полегче, а ещё через какое-то время появился и 64-битный Flash.
Со временем, конечно, всё утряслось, но сколько людей за это время попробовола Linux, «обожглись» и вернулись на Windows — одному богу ведомо.
Сравните с MacOS или Windows, где все версии поддеживают практически все программы, плагины и прочее. Да, проблемы есть и там, но подход в принципе другой: разработчики этих операционок понимают, что опреционка сама по себе, в общем-то, никому не нужна, нужны программы, которые под операционкой работают — а значит разработчиков нужно холить и лелеять… в разумных пределах, конечно: да, можно одной-двумя не шибко популярными программами и пожертвовать если кто-то из разработчиков пользуется уж какими-то сильно недокументированными возможностями, но в общем и целом совместимость между версиями — это головная боль разработчиков операционок, разработчики программ ничего и никому делать не обязаны.
Dovgaluk
27.11.2015 21:20Таким образом, сегодня мы строим одноразовые системы, не учитывающие того, что ждет нас в будущем
А много ли «неодноразовых» систем кроме System 360 и IBM PC?
justaguest
27.11.2015 23:27+5Прошу прощения, просто я похоже единственный здесь, кто не понимает проблемы. Пожалуйста, объясните мне кто-нибудь, в чем сыр-бор? О какой поддержке речь — мы же не на ассемблере кодим, взял, скомпилировал с GCC, и вот приложение уже работает на другой архитектуре.
Нет, я могу предположить, что где-то могут быть закодены операции, предполагающие, скажем, 32-разрядность, но если они явно не используют, к примеру, int32_t, это чревато проблемами на 64 разрядных архитектурах тоже, и будет пофиксено независимо от поддержки, скажем 16-битной архитектуры (если таковая существует). Так же я мог бы предположить, что автор говорит про софт с закрытыми исходниками, но маловероятно, учитывая что он в число «поддерживаемых архитектур» внес АРМ и х86 — и существует очень мало приложений с закрытым кодом, поддерживающих обе.
Так в чем посыл то?entomolog
28.11.2015 01:15+1Так как автор — бывший разработчик OpenBSD, смею предположить, что речь идет все же больше о системном софте.
Ничего страшного в использовании int32_t как раз и нету, проблемы начинаются там где используется long. Например для 64-х битных платформ есть несколько моделей придставления типов данных: LLP64/IL32P64, LP64/I32LP64, ILP64 SILP64. На платформе win64, long длиной 32 бита, на большинстве unix-like систем — 64 бита. Но это все в принципе не проблема.
По своему скромному опыту, могу сказать, что на больших проектах даже переход с armv7 на aarch64, может быть очень болезненным. Проблемы начинаются тогда, когда:
- Есть оптимизации, которые зависят от выравниваний.
- Где-то есть всевозможные хитрых манипуляции с указателями, которых делают предположение, что они именно 32-х битных.
- Когда структуры в прямом виде пишуться/читаются из файла.
- Используюся различные ассмеблерные вставки, скажем для использования NEON.
- Используются сдвиговые операции.
В коде Хавока, есть место где вообще вручную правят vtable.justaguest
28.11.2015 01:26Я писал «не используют int32_t» — оно понятно, чистые int и long имеют лишь четко заданную нижнюю границу. То, что вы сейчас перечислили, забота компилятора, за исключением 1) манипуляций с указателями, в предположении от 32-битности, 2) прямое чтение структур из файла (ну это — кроме как по недосмотру — вообще детская ошибка, очевидно что надо выравнивание отключать), 3) ассемблерные вставки, 4) сдвиговые операции. Все перечисленное будет приводить к пробемам даже при миграции х86_32 > х86_64, не говоря уже об армах, следовательно автор все-таки говорил о чем-то другом.
entomolog
28.11.2015 01:45+3Да, автор писал о другом. Скорее всего о разработке системного софта, ведь, он бывший разработчик OpenBSD. Там то уж часто нужно весьма плотно работать с железом. Отсюда и проблемы с поддержкой платформ, особенно если, как писал автор, есть проблемы с: тулчейном, флагманскими проектами и документацией.
Я же в качестве примера написал, что проблемы возможны и с прикладным софтом, причем на ровном месте.
ну это — кроме как по недосмотру — вообще детская ошибка
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает. Причем внутри струкур находятся указатели, которые хранят оффсеты на другие структуры в файле. При чтении файла, к значению указателя добавляется абсолютный адрес и получаем указатель на струкуру в памяти.justaguest
28.11.2015 01:55+1Ах, спасибо, теперь понятно.
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает.
Ну это не отменяет элементарности этой ошибки :) Скорее всего движок был написан очень давними программистами, а те, кто работают сегодня, знают что для починки багов потребуется решить много проблем, в частности возможно сломается совместимость с форматами — поэтому они или их руководство не решаются туда лезть. Я думаю, рано или поздно им придется заняться этой проблемой. В частности потому, что графический движок — как раз таки софт, особенно заинтересованный в работе с размерами более 32-битных (я молча полагаю, их движок 32-битный, поскольку 64-битные ОС начали набирать свою популярность относительно недавно).
khim
28.11.2015 14:48О какой поддержке речь — мы же не на ассемблере кодим, взял, скомпилировал с GCC, и вот приложение уже работает на другой архитектуре.
Ну да. Работает. Пока не упадёт, да. Вам вообще такие слова как «memory ordering» знакомы? А табличку в Wikipedia видели?
Сейчас вопрос стоит так: либо выиграет ARM — тогда ещё есть шанс, либо выиграет x86 — и вот тогда уже всё. Совсем всё. Пока ARM впереди, так что автор рано панику разводит :-)
GamePad64
28.11.2015 19:16-1Есть ещё endianess, например, который у x86 и ARM разный. Если при маршаллинге, разработчик о нём не задумывается, то данные при парсинге превращаются в мусор.
khim
28.11.2015 19:28+3Вас кто-то в криостазисе несколько десятилетий продержал? Единственная «выжившая» big-endian архитектура — это IBM System z (в девичестве — IBM/360). Список исчерпывающий. Все остальные выжившие системы — либо little-endian (x86), либо переключаемые. Android, в частности, работает только с little-endian…
P.S. Как обычно я игнорирую встройку. Если у вас железо не предполагает отдельного от него выпуска программ, то у вас, с одной стороны, развязываются руки (и вы можете делать много вещей, которых «большие дяди» делать не могут), с другой — ну какая, нафиг, разница что у вас там с софтом если его никто кроме вас не делает и делать не будет?StreetStrider
28.11.2015 20:37Единственная «выжившая»
Ну дак статья и повествует про всякие маргинальные платформы, их состояние и про то, что они как бы не выживают.khim
28.11.2015 20:58+1Она рассказывает про то, что всякие MIPSы и POWERы — находятся между жизнью и смертью. И это так. Вроде как окончательно они ещё не умерли, но одной ногой они уже всяко в могиле.
А вот всякие 68k, SuperH и прочие всякие AVR32 и ColdFire уже сошли со сцены: теоретически они ещё выпускаются, но практически — только для всяких программно-аппаратных комплексов. Можно, конечно, вспомнить про всякие FireBee, но это настолько нишевой продукт, что это даже не смешно.
Big Endian умер. Аминь.tyomitch
29.11.2015 14:57В общем-то, Big Endian ARM скорее «одной ногой в могиле», чем «совсем ушёл со сцены».
Вот, например, неплохой обзор состояния дел.khim
29.11.2015 16:12Третий слайд: Very big, 100M+ LOC, legacy code, Big Endian only; Runs on MIPS and PPC CPUs, looking forward to ARM CPU adoption.
В этом смысле Big Endian вообще никогда не умрёт: в конце-концов люди до сих пор разрабатывают M68K-совместимое железо! Сегодня, прямо сейчас! Но это всё legacy. Как электрическая сеть постоянного тока: да, в Сан-Франциско ещё лежат кабели, вкопанные больше 100 лет назад и по прежнему питают лифты, но говорить о том, что DC-сети «живы» на этом основании как бы странно…
ToSHiC
28.11.2015 22:42+2Судя по комментариям, вы не единственный. Изначально у OpenBSD было 2 посыла:
это ОС, разработчики которой постоянно думают над безопасностью её ядра и компонентов,
это ОС, которая работает на самом разном железе.
И автор статьи страдает именно по поводу второго аспекта. И дело даже не в endianess (тут как раз всё элементарно), и не в размере лонга (тут тоже ничего сложного). Дело в тулчейне для сборки кода.
Чтобы скомпилировать любой код, вам нужны компилятор, ассемблер и линковщик. И у производителей разных нестандартных процессоров есть два варианта: писать/купить свой проприетарный компилятор, который, конечно же, будет поддерживать в лучшем случае С++03, а скорее всего какой нибудь С99, либо делать патчи для GCC/CLang. Причём во втором случае, как показывает практика, это будет древний gcc, просто потому что когда-то под него уже делали патч при разработке архитектуры ядра процессора, а потом переносить под свежие версии не имеет смысла.
А теперь смотрите, вот есть процессор мультиклет, про боль работы с компилятором можно прочитать прямо на хабре: http://habrahabr.ru/company/embox/blog/265059/.
Я недавно изучал вопрос создания прошивки под суперпопулярный bluetooth чип CSR BC4 (он стоит во всех модулях HC-01 и подобных), они предлагают пропатченный gcc 3.3.3 (который был зарелизен в 2004 году. 2004, Карл!), собственный проприетарный ассемблер и линковщик, которые есть только под винду. Хотя бы патч приложили, и с этим патчем gcc даже можно скомпилировать, если осилишь! Некоторые предлагают существенно более свежие версии компилятора, типа 4.2.
Отдельная боль — это сборка gcc с нужными патчами. Нельзя просто так взять и собрать gcc! Команда, которая делает его, гарантирует только то, что можно собрать версию N+1 с помощью версии N. ВСЁ. Когда я пытался собрать тот самый gcc с патчами от CSR с помощью довольно таки древнего gcc 4.4 (версия 5-летней давности), у меня сходу не получилось. К счастью, в просторах интернета получилось найти патч, который кто-то выложил лет 8 назад, когда так же мучался, и который делает нужную мне часть исходников gcc совместимой с веткой 4.х, и только тогда собралось.
Вот так смотришь на это всё и думаешь: да ну его нафиг, взял бы ARM — давно бы уже девайс прошивал, а так только получилось собрать компилятор.khim
28.11.2015 22:55+1Отдельная боль — это сборка gcc с нужными патчами. Нельзя просто так взять и собрать gcc! Команда, которая делает его, гарантирует только то, что можно собрать версию N+1 с помощью версии N. ВСЁ.
Вы какие-то ужасы про GCC рассказываете. Он собирается вообще чем угодно (разработчики только недавно начали использовать С++ — и то очень острожно). Разуеется только C компилятор, всё остальное собирается уже с помощью него. То есть вам нужно было собрать GCC 3.3.3 для Linux с помощью хоть GCC 5.2, а уж с помощью GCC 3.3.3 собирать свой кросс-компилятор. Всё.
Хотя что вы собрались делать с GCC 3.3.3 и современным софтом — для меня загадка. Какой-нибудь Chromium требует GCC 4.8+ и, в общем, он не одинок.
Причём во втором случае, как показывает практика, это будет древний gcc, просто потому что когда-то под него уже делали патч при разработке архитектуры ядра процессора, а потом переносить под свежие версии не имеет смысла.
Как это не имеет смысла? Вам софт под ваш процессор нужен или нет? Если нужен — нужно переносить, если не нужен — ну это дело ваше, зачем тогда вообще процессор делать если вы на нём ничего запускать не собираетесь?
Подход: «какой копилятор дадим, тот и будете пользовать» хорош для встройки, где весь софт пишется с нуля. Если вы хотите использовать уже готовые библиотеки — будьте добры озаботиться приличным компилятором.ToSHiC
29.11.2015 01:03+1То есть вот такую проблему http://www.linuxquestions.org/questions/linux-software-2/error-in-compiling-gcc-3-3-3-with-gcc-4-3-2-a-693559/ я сам придумал? Вот конкретно с 3.3.3 такая засада. Сейчас, кажется, они сделали хитрый бутстрепинг и стало получше, но проблемы могут возникнуть внезапно.
А дальше ваши вопросы про одно и то же, на самом деле. Вот есть bluetooth чипсет, очень популярный и недорогой, я хочу сделать под него свою кастомную прошивку. Что мне предлагает производитель? А он предлагает мне взять gcc 3.3.3 и не выёживаться. Мультиклет, как пишут по ссылке выше, вообще предлагает компилятор с поддержкой только C89. И команда OpenBSD пытается заставить свою ОС работать вот на подобных странных архитектурах. Именно про это пост, что производители железа не хотят вкладываться в развитие инструментов для разработчиков, а команды разработки gcc/clang не особо хотят поддерживать непопулярные платформы, потому что смысла большого в этом нету.khim
29.11.2015 02:50+1Вот конкретно с 3.3.3 такая засада.
Которая конкретно в 3.3.4 уже отсутствует.
Так что не надо про «можно собрать версию N+1 с помощью версии N и ВСЁ». Разработчики GCC довольно серьёзно относятся к совместимости. Я сам собирал GCC 4 с помощью GCC 2.95.
А вот в обратную сторону… ну что тут можно поделать? Нет, я понимаю — вы бы хотели бы чтобы любая версия GCC могла быть собрана любой другой версией GCC, но, извините, без машины времени тут никак не обойтись. Ошибки в старых версиях GCC можно поправить только выпуском новой версии — или у вас есть какое-то другое предложение?ToSHiC
29.11.2015 12:06Ну предложение то простое — чтобы производители железа портировали свои патчи в новые версии самостоятельно, благо популярных открытых компилятора всего два.
khim
29.11.2015 14:16+4Ну для этого они должны решить что они разрабатывают.
Проблема в том, что многие разработчики «железа» считают, что они до сих пор живут в мире, где железо поменять сложно, а софт — легко. Соотвтественно разработка софта идёт «по остаточному принципу».
Но с середины 70х этот мир начал стремительно сокращаться и к настоящему времени его, в общем, больше нет.
Что произошло в 70х? Появились персоналки и софт стал «трудно меняемым».
Нет, исправить одну программу по прежнему легче, чем железку. А как насчёт тысячи программ? Всё ещё готовы сражаться? Ну тогда получите миллион и умрите.
В современном мире у вас нет возможности выпустить чип и надеяться на то, что его будут использовать три с половиной исследовательских лаборатории. Вам нужны миллионные тиражи — иначе разработка не окупится. Так уж устроена современна литография.
А если у вас миллионные тиражи и вы разрешите ваше устройство программировать, то рано или поздно у вас будут миллионы программ — со всеми вытекающими (ну или не будет и вы таки умрёте, но странно начинать разрабатывать платформу сразу затачивая её под крах, не так ли?).
Отсюда и получилось это разделение на встройку и несколько «живых» платформ. Но и при этом даже и встройка начинает сейчас стремительно сокращаться! Повторно используемый код и там начинает рулить!
Но почему-то производители железа по прежнему считают, что главное — сделать железо. Я знаю только одну команду, которая так не считает. Это, как ни удивительно, МЦСТ со своим Эльбрусом. Они говорят: вам должно быть неважно, какая у нас архитектура (а она у нас супер-пупер замечательная), так как мы предоставляем x86 эмулятор.
Ну хоть так. Остальные же разрабатывают железо, а потом пытаются придумать — где они возьмут софт под это железо. А сейчас, вообще говоря, нужно делать наоборот.
Даже крупнейшие фирмы на эти грабли наступают. Itanic ведь именно поэтому же сдох! Причём там они думали над этим вопросом — просто ответ оказался неубедительным. А если о нём и вообще не думать???tyomitch
29.11.2015 15:15Ну хоть так. Остальные же разрабатывают железо, а потом пытаются придумать — где они возьмут софт под это железо. А сейчас, вообще говоря, нужно делать наоборот.
Тем не менее, новые аппаратные платформы каким-то образом появляются на свет.
Вот взять хотя бы amd64 и aarch64 из заголовка статьи. Обе сравнительно недавние. К тому моменту, когда они появились, — очевидно, софта под них ещё не было. Но в обоих эти случаях через несколько лет после появления платформы под неё начал выходить софт.
Чем AMD64 и AArch64 отличаются от всяких Alpha и Itanium, умерших во младенчестве — мне не понятно, честное слово.justaguest
29.11.2015 16:00Я бы не назвал, х86_64 недавней платформой, 13 лет немало времени для развития экосистемы — другое дело, что популярность она начала набирать сравнительно недавно, это верно. Но вообще это сравнение некорректное — на х86_64 по-прежнему работают приложения под х86_32, т.е. на момент появления 64-разрядной версии уже была куча готового софта. Добавление «родной» поддержки х86_64 — как только появились компиляторы — производилось под GNU/Linux потому что это было нетрудно, и под Windows по остаточному принципу. Поправьте меня если ошибаюсь, но полагаю, что под aarch64 та же ситуация с софтом.
Я не знаю истории с Alpha, но полагаю, что именно Itanium умер просто потому, что Intel плохо вкладывались в рекламу и продажи. Во-первых, я ни разу не видел его в магазинах, хотя, признаться, мне было бы интересно его купить просто из любопытства, и думаю ни мне одному (разумеется при разумной цене) — с софтом, спасибо FOSS, проблем не будет. Во-вторых, пока здесь не упомянули его, я даже и не знал, что он до сих пор существует! Я был абсолютно уверен, что после неудачи в районе 2002 года они прекратили производство — везде о нем расписывается в тонах R.I.P. И только сейчас я обнаружил, что последний выпуск был всего несколько лет назад. А все потому, что Intel не занимается его рекламой, конференциями, бенчмарками на нем, не упоминает его как бы между прочим в беседе на другие темы — такое ощущение, будто они его просто сделали, и забыли!khim
29.11.2015 16:48Я не знаю истории с Alpha, но полагаю, что именно Itanium умер просто потому, что Intel плохо вкладывались в рекламу и продажи.
Нет, нет и нет. Itanium умер потому что это была попытка продвинуть новую архитектуру в нишу, которая уже была занята другими архитектурами. Тут никакая реклама не поможет: софта-то нет!
То, что Itanium'ов вообще хоть сколько-то удалось продать — это просто фантастический успех рекламного отдела: она навешали просто мегатонны лапши на уши всяким HP и SGI, после чего те сами, добровольно убили свои собственные платформы, чтобы их место занял Itanium. Но даже это благородное самоубийство его, разумеется, спасти не смогло.
Во-первых, я ни разу не видел его в магазинах, хотя, признаться, мне было бы интересно его купить просто из любопытства, и думаю ни мне одному (разумеется при разумной цене)
Это вы процессор с кристаллом в 700mm2 хотите увидеть «по разумной цене»? Чисто для справки: AMD Radeon Fury X имеет кристал размером 600mm2, у GeForce GTX Titan — 560mm2…
Подержанный Itanium можно купить за весьма небольшие деньги, кстати, но новый? Intel — это всё-таки коммерческая компания, продавать что-то ниже себестоимости она если и будет — то недолго.
А все потому, что Intel не занимается его рекламой, конференциями, бенчмарками на нем, не упоминает его как бы между прочим в беседе на другие темы — такое ощущение, будто они его просто сделали, и забыли!
Так и есть. Часть Itanium'ов продаётся по долгосрочным контрактам, которые предусматривают не один год поддержки. Oracle пыталась «выскочить» — не удалось, Intel же понимал, что это безнадёга, так что какое-то количество процессоров ещё будет выпущено (может даже ещё одна модель будет, я не знаю как там контракты составлены), но это уже в чистом виде «жизнь после смерти».justaguest
29.11.2015 17:11Itanium умер потому что это была попытка продвинуть новую архитектуру в нишу, которая уже была занята другими архитектурами. Тут никакая реклама не поможет: софта-то нет!
Мне кажется, тут аргумент про софт звучит неубедительно, потому что на момент появления Itanium в нем имелась аппаратная эмуляция x86 архитектуры (да, я знаю, она была медленной, но она была), и очень быстро появились ОС под IA64, включая Windows.khim
29.11.2015 17:38+1да, я знаю, она была медленной, но она была
С практической точки зрения это значит, что её не было. «Проблему курицы и яйца» (которую отлично решала поддержка старых архитектур при появлении 80386 или AArch64) она не решала.
Одно дело — когда у вас есть отличный x86 процессор, который вы можете закупать миллионными тиражами игнорируя тот факт что в нём есть какая-то там «новая архитектура»: вы его будете покупать и использовать годами — пока, наконец у вас не появится парочка программ под «новую архитектуру» (сам личто участвовал в переходе на x86-64 в одной организации: до 2010 года примерно подавляющее большинство софта было 32-битным).
Совсем другое — когда у вас есть настолько дерьмовый x86 процессор, что использовать его как x86 процессор просто бессмысленно: при выполнении неоптимизированного под Itanium программного кода для x86 систем его производительность была в 8 раз меньше, чем у x86 процессоров на той же частоте (а частота у Itanium'а была, кстати, зачастую ниже, чем даже у бюджетных x86 процессоров того же года выпуска). При таком раскладе покупать этот процессор для x86 кода вы не станете, а значит — не станете его покупать и вообще, скорее всего: софта-то нет!
А раз этого процессора ни у кого нет, то с какого перепугу вдруг у кого-то может возникнуть желание писать под него софт?
Новая архитектура CPU может «выстрелить» только и исключительно когда открывается новый рынок. Лобовая атака бесполезна. Тот же ARM на рынке десктопов давно мёртв. Он может туда ещё вернуться — но это произойдёт потому, что он «зайдёт» с другого рынка (планшетов, данном случае). Itanium же пытались продвинуть на рынок северов «в лоб». Маркетологам памятник надо поставить за их усилия — но они были обречены с самого начала.
khim
29.11.2015 16:30+1Вот взять хотя бы amd64 и aarch64 из заголовка статьи. Обе сравнительно недавние.
Чего? Одной 37 лет, другой — 25 недавно стукнуло. Назвать архитектуру четвертьвековой давности «сравнительно недавней» — это вы чего-то объелись.
Почему-то W65C816S или 80386й никто не пытается представить как «новую архитектуру», а вот amd64 и aarch64, полученные по такому же принципу — да, новьё прям.
Тут как бы всё понятно: чтобы поддержать эти, с позволения сказать, «новые» архитектуры нужно было переделать одну программу (пусть даже большую и сложную) — ядро. Всё остальное — можно было делать постепенно. Как оно и произошло. Переход с Apple ][ на Apple IIGS тут ничем не отличается от перехода с AArch32 на AArch64… И то же самое было и при переходе на 32 бита на x86 или 64 бита на PPC! Однако эти переходы появлением «новой архитектуры» никто не называл!
К тому моменту, когда они появились, — очевидно, софта под них ещё не было.
Под архитектуру (если даже вдруг считать что amd64 и/или aarch64 — это таки новая архитектура) — не было. Под процессоры — было и ещё сколько! Просто-таки мегатонны софта!
Но в обоих эти случаях через несколько лет после появления платформы под неё начал выходить софт.
Начал выходит «нативный» софт, вы хотели сказать. Ну дык. Проблемы курицы и яйца ведь не было, так что какие проблемы? Сначала выпустили кучу железа, потом и софт подтянулся — то же самое было и с SSE и с NEONом.
Чем AMD64 и AArch64 отличаются от всяких Alpha и Itanium, умерших во младенчестве — мне не понятно, честное слово.
В момент выхода и Alpha и Itanium не имели ничего, что можно было бы на них пускать.tyomitch
29.11.2015 18:41+1Почему-то W65C816S или 80386й никто не пытается представить как «новую архитектуру», а вот amd64 и aarch64, полученные по такому же принципу — да, новьё прям.
Я считаю i386 новой архитектурой, потому что старый код она выполняла в отдельном 16-битном режиме, так же как x64 выполняет старый 32-битный код в отдельном режиме, и ARMv8 выполняет 32-битный код в отдельном режиме.
Смешивание режимов при этом допускается не всякое: ни amd64, ни aarch64 не позволяет запускать 64-битные приложения под 32-битной ОС.
Это существенно отличается от SSE/NEON, позволявшего добавлять новые инструкции в нужные места старого кода. При переходе на i386 / amd64 / aarch64 перекомпилировать приходится всю программу, и требовать для её работы новой версии ОС.
Тут как бы всё понятно: чтобы поддержать эти, с позволения сказать, «новые» архитектуры нужно было переделать одну программу (пусть даже большую и сложную) — ядро. Всё остальное — можно было делать постепенно. Как оно и произошло. Переход с Apple ][ на Apple IIGS тут ничем не отличается от перехода с AArch32 на AArch64…
Ну и в чём тогда была проблема при переходе на Itanium или Alpha? Windows для них поддерживала приложения x86 наравне с родными — старая архитектура точно так же эмулировалась, как 68k в Power Macintosh-ах. Но почему-то PowerMac взлетел, а Windows-IA64 потонул.khim
29.11.2015 20:37+2Это существенно отличается от SSE/NEON, позволявшего добавлять новые инструкции в нужные места старого кода.
А в чём разница? Нет, я серьёзно.
Без поддержи со стороны ядра вы ни SSE, ни x86-64 использовать не можете, а если поддержка есть — то и то и другое можно использовать там, где захочется.
Это не теория. Скажем Android x86 на сегодняшний день 32-битный (кроме ядра), но это не мешает libhoudini создать для себя пару сегментов, перейти в long mode и развести «маленький такой x86-64» посреди 32-битного процесса.
Ну и в чём тогда была проблема при переходе на Itanium или Alpha?
В том, что они плохо исполняли старый код. Медленно и со скрипом. Рассматривать их как x86++ было нельзя.
Но почему-то PowerMac взлетел, а Windows-IA64 потонул.
PowerMac взлетел только потому что Apple обладала монополией и не стала выпускать Mac'и с использованием 68060. Более того: даже 68040 на 40MHz использовался только в одной, весьма редкой, модели (Quadra 840AV)! Так что, с одной стороны, при переходе от несуперскалярного 68040 на 33MHz к суперскалярному PowerPC на 66MHz даже старые программы работали с приличной скоростью, а с другой — всем было однозначно объявлено: «PowerPC — это ваше будущее, жрите что дают».
Intel же не был в той позиции, чтобы заявить такое, так как во-первых всё-таки не всех производителей «больших» UNIX-систем убедили самоубиться (IBM, к примеру, «активно поддерживала» Itanium, но отказываться от POWER'а и не думала), а во-вторых AMD вовремя подсуетилась и выпустила процессор, который был заметно лучше, чем всё что в то время предлагал Intel (для Itanic'а по прежнему не было софта, а Xeon не мог эффективно поддерживать гигабайты оперативки). Если первое ещё были шансы пережить (небольшие, но были), то второе — обозначало, что вместо перехода на Itanium все перейдут на Opteronы. Intel этого допустить, понятно, не мог.tyomitch
30.11.2015 01:24-1Для использования SSE не нужна поддержка со стороны ОС.
«создать для себя пару сегментов, перейти в long mode и развести «маленький такой x86-64» посреди 32-битного процесса» — это не то чтобы новое изобретение: старинные штуки под названием «DOS extender» работали похожим образом. Но согласитесь, что такие выкрутасы намного сложнее, чем «просто добавить в старый код новые инструкции там, где они нужны, и больше ничего не трогать».
По всем остальным пунктам полностью согласен. Выходит, что успех/неуспех нового процессора в не меньшей степени, чем качествами самого процессора, определяется маркетинговой политикой и рыночной конъюнктурой.khim
30.11.2015 03:25+1Для использования SSE не нужна поддержка со стороны ОС.
Да шо вы такое говорите. А кто регистры дополнительные будет сохранять? Пушкин?
Но согласитесь, что такие выкрутасы намного сложнее, чем «просто добавить в старый код новые инструкции там, где они нужны, и больше ничего не трогать».
Разница в любом случае не качественная, а количественная. Для перехода в x86-64 нужно сделатьfar jmp, а для переключение в режим работы с MMX — вызвать инструкциюEMMS… так ли уже велика разница? И если разница междуfar jmpом иEMMSом так принципиальна, то куда вы отнесёте Thumb и ARM26? Это уже новые архитектуры или ещё нет?
Я боюсь что с вашими подходами один ARM превратится в дюжину разных архитектур… А вx86(с его всякими unreal mode) вы их сколько насчитаете?
Выходит, что успех/неуспех нового процессора в не меньшей степени, чем качествами самого процессора, определяется маркетинговой политикой и рыночной конъюнктурой.
Только всё наоброт. Если у вас есть новая ниша, которая, по тем или иным причинам, не может быть занята существующей архитектурой — у вас есть шанс. Если ниши нет — то уже неважно насколько хорош ваш процессор.
Интересным примером регулярно открывающейся «новой ниши» являются, к примеру, игровые приставки: так как люди редко покупают новую приставку, чтобы играть на ней в старые игры (для этого у них старая прис тавка есть), то здесь каждое новое поколение — это очередной шанс для очередной новой архитектуры. Но и то: предыдушее поколение было сплошь PowerPC, нынешнее — спрошной x86, так что, похоже, уже и тут груз существующих библиотек уже довлее настолько, что появление чего-то принципиально нового — весьма проблематично.
Скоро, возможно, откроется ниша для IoT (сегодня есть две крайности: либо всё делать в традициях «полноценной встройки» и не допускать никакой перепрограммируемости вообще, либо сувать в электрическую лампочку Android и 2GiB памяти… кажется что должно появиться что-то посредине), со временем, возможно, ещё какие-то ниши будут. Но везде и всюду рулит софт.justaguest
30.11.2015 05:23Просто к слову — на консолях использование отличных от х86 архитектур экономически выгодно, поскольку усложняет создание эмуляторов приставок, и повышает необходимые вычислительные ресурсы для их работы.
К примеру: если бы приставка была оснащена х86 процессором, то можно не использовать виртуальную машину — достаточно сделать для десктопов Wine-подобную оболочку, и игры будут работать почти без ущерба производительности.khim
30.11.2015 13:51+1Это теория, которая расходится с практикой чуть менее, чем полностью. То есть с одной стороны вы правы — достаточно сделать для десктопов Wine-подобную оболочку, и игры будут работать почти без ущерба производительности. С другой же…
Посмотрите на шестое поколение приставок: Dreamcast, PlayStation2, GameCube, XBox. У какой из них, по вашему мнению, самые убогие и ограниченные эмуляторы? Правильно: у XBox'а! Единственной приставки с x86 процессором. Именно из-за попыток создать «Wine-подобную оболочку»: у XBox'овских эмуляторов неплохая скорость и отвратительная совместимость. Все остальные эмуляторы тупо эмулируют железо — и это у них весьма неплохо получается (даже когда речь идёт о какой-нибудь PlayStation2 с её Emotion Engine, векторными юнитами и своим, особенным, Graphics Synthesizer'ом), а вот эмуляторы XBox'а пытаются изобразить из себя «Wine-подобную оболочку» и это не работает.
Неплохая, кстати, иллюстрация тезиса, о котором мы тут говорим, да?
Дальше. Всё седьмое поколение построено на основе PowerPC. Это, конечно, не X86, но не стоит забывать что Джобс неожиданно пластинку с PowerPC forever на Intel — наше всё в 2005м году. То есть уже предыдущее поколение приставок используют «стандартную» технологию с персоналок — правда не со стандартных персоналок, а с Mac'ов, но, тем не менее…
Про восьмое поколение и говорить не стоит: небольшая модификация приставки предыдущего поколения и две «персоналки в красивом ящике».
Да и все аркадные систмы Сеги, начиная с Sega Chihiro используют Intel'овские процессоры…
Как я уже сказал: были времена, когда каждое поколение приставок было «вновь открывающейся нишей», но, похоже, эти времена прошли: PlayStation3 была «последней из могикан». Все остальные приставки после 2005 года — это те или иные «перепевки» архитектуры PC… да и PlayStation3 можно назвать «новой архитектурой» с большой натяжкой: GPU и CPU у неё стандартные, только «ускоритель с боку» является некоей «инновацией»… не поддержанной софтом и потому никому не нужной: все разработчики его буквально прокляли и в большинстве игр его мощь попросту не используется.
tyomitch
30.11.2015 22:09Да шо вы такое говорите. А кто регистры дополнительные будет сохранять? Пушкин?
Ну значит, не-SSE-шная ОС позволяет запускать SSE-приложения по одному =)
А поддержка SSE в ядре ОС добавляет возможность запускать несколько SSE-приложений одновременно.
Если мне не изменяет память, первыми SSE-приложениями были 3D-игры; и вполне разумно было предположить, что пользователь не станет запускать одновременно несколько 3D-игр — а значит, поддержка SSE ядром ОС была необязательна.khim
30.11.2015 22:16+3Ну значит, не-SSE-шная ОС позволяет запускать SSE-приложения по одному =)
Не позволяет. Операционка должна не только сохранять регистры, но и сообщить процессору, что она это делает установив в единичку бит OSFXSR в CR4. Иначе SSE-инструкции не распознаются.
khim
30.11.2015 22:42+1И чтобы предупредить вашу следующую идею: для поддержки x86-64 не требуется полный редизайн ядра с ломкой всех драйверов. И это — снова не теоретические измышления: Mac OS X Tiger добавил поддержку x86-64 в минорном обновлении (10.4.4, если быть точным). Разумеется драйвера от предыдущей версии продолжали работать :-)
Так шта… нету между x86-64 и разными другими расширениями типа SSE или AVX512 никакой качественной разницы. Не-ту. Количественная — да, есть, это весьма серьёзное расширение, спору нет, но вся эта разница — количественная, «новой» существующую архитектуру это не делает. Ну или делает, но тогда у вас x86 распадётся на дюжину архитектур и ARM тоже (там вообще прикольно: архитектура, вроде как, одна, но разных видов ABI… вагон и маленькая тележка: OABI и EABI, hard float и soft float, уже упоминавшийся режим ARM26 — и это только из того, что «навскидку» вспомнилось) — что будет несколько… гхм… странно.grossws
01.12.2015 00:59ARM тоже (там вообще прикольно: архитектура, вроде как, одна, но разных видов ABI… вагон и маленькая тележка: OABI и EABI, hard float и soft float, уже упоминавшийся режим ARM26 — и это только из того, что «навскидку» вспомнилось) — что будет несколько… гхм… странно.
Не считая ещё особенностей использование инструкции ветвленияB/BX Rmпри младшем битеRmвыставленном в 0 или 1 ,)
tsafin
01.12.2015 13:26В-целом Вы правы («Без поддержи со стороны ядра вы ни SSE, ни x86-64 использовать не можете»), но в частности — не совсем. Ядро-ядру рознь.
Например, Vmware Workstation давно (начиная с Merom) мог запускать 64-разрядные виртуалки даже на 32-разрядных операционных системах Тут основополагающим фактором наличие аппаратной поддержки vmx и x64. а не помощь Windows или Linux.
То же самое про SSE/AVX — первична поддержка определенных инструкций в железе (заявленная через cpuid). Ядро операционной системы всегда стартует с выключенной поддержкой SSE (CR4.OSFXSR=0) ибо уж больно большой state надо тогда сохранять при переключении контекста. И это проблема разработчиков приложения (например, Adobe) найти дырочку, через какую возвести нужные битики в CR4 (9-ый, 10-ый и 18-ый :)) чтобы FXSAVE/XSAVE стали сохранять состояние SSE*.
И да, чтобы два раза не вставать, Вы не правы что это Intel развел HP на предмет использования Itanium — все было ровно наоборот. Itanum — это HP дизайн, и именно поэтому это HP платит Intel чтобы поддерживать это все и дальше.
Но Вы правы, что не взлетело это (в первую очередь) из-за плохой эмуляции x86. Ну и вовторую очередь из-за плохой/неудачной архитектуры EPIC/VLIW. Для которого всегда нужен очень сильный оптимизатор, которого, почему-то в нужный момент не оказывается для нужной операционной системы.
(Сделаю обобщение еще более дерзкое — все архитектуры VLIW [very-large instruction word] типа Itanium, Transmeta, Elbrus — неэфективные и не жизнеспособные в долговременном плане. Если только у вас нет бесконечно быстрого и бесконечно широкого канала в память. Но это уже совершенно другая история и offtopic)khim
01.12.2015 15:00Ну это вы уже в частности полезли. Понятно что когда я говорил про ядро я имел в виду kernelspace. Конечно еслы вас туда пустили (как VMWare), то вы можете наделать всё, что угодно. Ведь ваш драйвер после этого становится по сути частью ядра!
И дырочку вы никакую в этом смысла не найдёте: из userspace CR4 не правится!
А что касается HP и Itanium'а… там развод-таки был: насколько я понимаю Intel условием для участия в проекте всё-таки поставил постепенный отказ от PA-RISC'а. А что многие наработки из PA-RISC'а были использованы в Itanium'е — это уже другой вопрос. То есть фактически HP «развёл» Intel на участие в авантюре, связанной с EPIC'ом, а затем уже Intel «развёл» HP на отказ от развития PA-RISC'а (что логично: разрботчиков, в общем, в природе не так много, если бы все разрботчики PA-RISC'а продолжали разрабатывать PA-RISC, то кто бы мог перейти в команду Itanium'а?).
А насчёт «судьбы VLIW'а»… По большому счёту с VLIWом всё хорошо, на GPU он цветёт и пахнет, просто вот конкретно Itanium оказался «между двух огней»: на задачах, которые хорошо «ложатся» на GPU он просто откровенно «сливает» современным GPU, на задачах, которые ложатся плохо — сливает «обычным» процессорам почти всегда. Те крохи, которые остаются — его не спасут. Мог бы спасти принудительный перевод всех PC — но этот момент был упущен из-за того, что это — не x86 процессор, по сути, а эмуляция — была тормозной всегда…splav_asv
01.12.2015 18:54на задачах, которые хорошо «ложатся» на GPU он просто откровенно «сливает» современным GPU, на задачах, которые ложатся плохо — сливает «обычным» процессорам почти всегда.
С оставшейся стороны подпирает Xeon Phy. Хоть и «обычый» CPU, но не совсем.
Ivan_83
28.11.2015 09:16+4Я бы вообще сказал что всё за пределами х86 + х86_64 просто никакое = мёртвое.
Железки там не модульные в массе своей, вместо биоса всякие кастраты типа u-boot.
От железки к железке всё меняется и каждый раз нужно начинать всё с начала или с середины: те плаг-и-плей там нет, дрова под каждое устройство каждого чипа специфичные и тп.
Работать под не х86 вообще сплошной геморой:
1. Всё жутко слабое
2. Памяти обычно мало и нужно всё кросскомпилять
3. Хер какую переферию просто так подключишь
и с этим ничего не сделать, кроме как выбросить и взять такое же говно только чуть лучше
имеет смысл связываться только:
1. в образовательных целях
2. если ты производитель этого говна (арм/мипс) или покупаешь ведро по 5 копеек а продаёшь железки на них по «50» баксов/штука.
Те да, я тоже негодую по поводу одноразовых систем, потому что знаю не по наслышке сколько уходит на то чтобы там запустить ОС (не собрать готовый *врт/линух/бсд а сделать чтобы оно собиралось и запускалось), и как только ты заканчиваешь это железка уже отжила своё или скоро отживёт.
DmitrySpb79
28.11.2015 12:07+4Да, помню как в бытность программистом Windows Mobile приходилось собирать 3 версии, под ARM, MIPS и SH3 :) Устройства были Jornada SH3 и Casio E125.
Выглядел девайс примерно так:
Давно было… :)
tsafin
01.12.2015 14:19А кто-нибудь может мне объяснить причину этого наброса оригинального автора?
Я перечитал все комментарии здесь, оригинальное сообщение на pastebin («Дети, запомните, если вы хотите открыть дискуссию, никогда, никогда, это не открывайте на pastebin и gist!»), на редите, перечитал комменты на его оригинальный твит, и все равно не понимаю.
Имеем на входе такой контекст: Миод Валлат, давнишний разработчик OpenBSD (который не про новые архитектуры, и относительную популярность. про это FreeBSD, и который не про пыльные, старые, маленькие железки — про это NetBSD, а который про безопасность и правильную процедуру разработки). И он пишет что он разочаровался и уходит из OpenBSD, потому как никто уже не веселится с маргинальными железками (оставляем за скобками его опосредованный наброс на MIPS и Power, которые очень даже ок во FreeBSD). Если тебе хочется копаться со старьем — иди коммить в NetBSD. Никто слова плохого не скажет. Здесь же читается что-то другое, кроме некорректного наброса про современные архитектуры.
Мне так кажется (ни на чем не настаиваю, полностью мои спекуляции) что Миод просто устал и разочаровался в проекте OpenBSD. (Если даже денег на эксперименты с не x86/arm железками нет). Не удивлюсь увидев его в скорости в более сытном (но не намного) контексте FreeBSD…
С другой стороны, может мне кто-нибудь объяснить, а зачем вообще существует такое большое количество ответвлений BSD — FreeBSD, OpenBSD, NetBSD, Dragonfly? Почему они с такой легкостью плодят форки, и почему не умеют работать вместе? Чего они добились за это время живя по-отдельности? [Вопросы большей частью риторические]
Sptsh
прямо слезы наворачиваются :(
спасибо таким людям, как он…