Комментарии 128
прямо слезы наворачиваются :(
спасибо таким людям, как он…
спасибо таким людям, как он…
Статья говорит будто об архитектурах, а на самом деле это вопль о платформах. Ага, мир граблей велик в своем беспорядке, и кроме тулчейнов есть на свете много еще чего, друг Гораций.
Впрочем у изрядного количества людей всегда будет работа. И это успокаивает.
Впрочем у изрядного количества людей всегда будет работа. И это успокаивает.
Как инженер микропроцессорной команды MIPS I6400, я не согласен с автором текста. MIPS не только не мертв, но и еще отгрыз у ARM назад несколько процентов рынка в прошедшие пару лет. Есть вещи, которых у ARM просто нет (например многопоточность на одном ядре — hardware-supported multithreading), а у MIPS есть, и при этом у MIPS стабильная экосистема, которая кстати включает для BSD некоторые забавные вещи — см. напр. github.com/sergev/qemu/wiki/LiteBSD%20Example
Очень специфичная хрень. Купить аналог Rasberry Pi весьма и весьма сложно.
половина, если не больше, SoC домашних роутеров — это MIPS. dev.openwrt.org/wiki/platforms
можно купить, поставить openwrt и упражняться.
можно купить, поставить openwrt и упражняться.
Я имею ввиду не купить в виде комплекта для разработки с большим числом коннекторов.
Ага, вотпрямщаз. Я с февраля жду — последнее сообщение от них — «вот завтра отправим» и далее тишина, все участники проекта сообщения игнорируют. 54 евро не прям вот такие деньги за 2 комплекта, чтобы сильно горевать, но больше я ни один российский проект по железу не поддержу.
(: есть и неотечественные, например domino.io/product/domino-pi
О, вы наверное в курсе — чем закончилась драма с разделением компании? Вроде же были люди, которые встречались с одним из разработчиков, видели готовые платы.
Вот так из-за одних уродцев делается имидж всей индустрии.
А вы где заказывали? Просто за кикстартер и за заказы с сайта в итоге отвечают две разные компании.
Я заказывал на сайте, со мной связались месяц назад, уточнили адрес доставки и прислали.
Да, у них есть проблемы. Но это не значит что они всех кинули. Просто проблемы оказались достаточно большими чтобы не суметь их быстро решить.
Я заказывал на сайте, со мной связались месяц назад, уточнили адрес доставки и прислали.
Да, у них есть проблемы. Но это не значит что они всех кинули. Просто проблемы оказались достаточно большими чтобы не суметь их быстро решить.
С сайта заказывал. Проблема ещё усложняется тем, что попросил товарища оплатить, так как мою долларовую визу их процессинг не жрал, только рублёвая нужна была (там как раз шумиха с визой/мастеркардом для РФ была). В процессе переписки мне подтвердили, что да, есть такой получатель, всё клёва, буквально завтра отправим… и пинг пропал.
Меня, как пользователя, вообще не интересует, кто кого там внутри команды кинул и что не поделил. Для меня теперь вообще, всё, что связано с Black Swift — потенциальный кидос и попадос, до тех пор, пока меня не убедят в обратном.
Меня, как пользователя, вообще не интересует, кто кого там внутри команды кинул и что не поделил. Для меня теперь вообще, всё, что связано с Black Swift — потенциальный кидос и попадос, до тех пор, пока меня не убедят в обратном.
А я вам ничего про «кинули/не поделили» не говорил.
Есть проблемы. Их медленно, но разруливают. Платы медленно, но рассылают.
Я понимаю ваше недовольство. Сам в течении года возмущался, потому что думал что тупо кинули.
Но между «тупо кинули» и «возникли большие проблемы» — есть разница.
Если вы просто клиент, которому нужна плата — не понимаю зачем вы вообще в предзаказы в фирму без репутации полезли, если существует множество альтернативных плат сравниымх по функционалу и давно создавших себе репутацию.
Если же вы вписались в частности чтобы помочь отечественному продукты — не понимаю вашего возумщения, т.к. риски и возможные проблемы были изначально и вообще предзказ и краудфандинг таких вещей на том этапе который был год назад — это авантюра. Вы сами осознано влезли в авантюру, а сейчас воете о том что вас кинули.
Есть проблемы. Их медленно, но разруливают. Платы медленно, но рассылают.
Я понимаю ваше недовольство. Сам в течении года возмущался, потому что думал что тупо кинули.
Но между «тупо кинули» и «возникли большие проблемы» — есть разница.
Если вы просто клиент, которому нужна плата — не понимаю зачем вы вообще в предзаказы в фирму без репутации полезли, если существует множество альтернативных плат сравниымх по функционалу и давно создавших себе репутацию.
Если же вы вписались в частности чтобы помочь отечественному продукты — не понимаю вашего возумщения, т.к. риски и возможные проблемы были изначально и вообще предзказ и краудфандинг таких вещей на том этапе который был год назад — это авантюра. Вы сами осознано влезли в авантюру, а сейчас воете о том что вас кинули.
Возможно, не видели ещё — geektimes.ru/company/unwds/blog/266676
Упражняться не очень выйдет — на таком комплекте недоступны средства отладки и процесс изучения платформы происходит примерно как поклейка обоев в комнате через замочную скважину.
НЛО прилетело и опубликовало эту надпись здесь
Микротик, как пример не совсем чтобы, если верить автору поста, мейнстримной архитектуры :)
Живут, и, похоже, знают, что будут делать дальше.
Живут, и, похоже, знают, что будут делать дальше.
Как инженер команды, поддерживающей еще одну (еще менее известную в широких кругах архитектуру 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 можно купить в каждой булочной, а такую же платку на своей любимой платформе Х не купить ни за какие деньги, но это не умаляет важности других платформ и архитектур.
В наши дни не только продолжают существовать давно известные архитектуры, причем, некоторые обретают второе дыхание (см. en.wikipedia.org/wiki/OpenPOWER_Foundation занимающейся активным развитием и продвижением решений на основе IBM Power), но и появляются новые архитектуры (пусть и не очень часто, см. www.kalrayinc.com/kalray/products/#processors).
Дело просто в том, что конкурировать с x86 на рынке лэптопов и c ARM на рынке смартфонов действительно очень тяжело ввиду разных факторов, а потому все большую популрность преобретают процессоры и платформы, заточенный под какие-то конкретные рынки или области применения. И обыватель как правило не знает, с каким процессором он имеет дело, подходя к холодильнику, включая телевизор или садять в автомобиль. Более того, неншние SoC-и (т.е. системы на кристалле) как правило содержат не одно процессорное ядро, а целый зоопарк ядер. В современных смартфонах (уж не говоря про лэптопы и десктопы) как минимум: основной процессор, на котором выполняется ОС, с ним в связке может работать сопроцессор обработки звука и/или видео, мониторингом и регулировкой питающих напряжений занимается еще один процессор, в контроллере экрана и сенсорной панели тоже про процессору… но на слуху только ARM и x86 :)
Да, немного обидно, что RPi можно купить в каждой булочной, а такую же платку на своей любимой платформе Х не купить ни за какие деньги, но это не умаляет важности других платформ и архитектур.
Посыл статьи в том, что 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 за всё время их существования.
Тулзы и прочее пилится лишь компаниями производителями (IMG/IBM) и отдельными волонтёрами.
Какой смысл в SMT для задач, которые потянет I6400?
Проще 4хA53 поставить, которые ещё и на большей частоте могут работать.
>> отгрыз у ARM назад несколько процентов рынка
Какого именно?
В любом случае продажи ARM процессоров пока что расли экспоненциально (12 миллиардов продано в 2014г)
https://en.wikipedia.org/wiki/ARM_Holdings#Mali_licensees
12 миллиардов это больше чем количество x86 процессоров в PC за всё время их существования.
У меня на столе сейчас лежит 8 ARM устройств и только одно x86 под столом.
Причём в том x86, что у вас под столом наверняка ещё парочка ARM-процессоров где-нибудь сидит…
Скорее ощутимо больше, чем парочка. Если только в hdd их обычно 2-3, хотя и со специализированными кусками. www.arm.com/markets/embedded/hdd-ssd.php
ARM победил на мировом рынке вашего стола
Боюсь, что разработать ARM невозможно без x86, который под столом. Есть тулзы проектирования под ARM, кады?
ARM это исполнительные машинки, ширпотреб (телефон, планшет). x86 это рабочие лошадки для бизнеса, разработки. Под те же ARM.
ARM это исполнительные машинки, ширпотреб (телефон, планшет). x86 это рабочие лошадки для бизнеса, разработки. Под те же ARM.
Замените в вашем утверждении x86 на Alpha (да, кажется, Alpha, хотя могу путать, помню точно что там какой-то 64-битный процессор был), ARM на x86, сдвиньте по времени лет примерно так на 20 — и тоже получите абсолютно верное утверждение. Только… где сейчас та Alpha? Вот и x86 имеет неплохие шансы на движение в этом направлении — как бы сложно ни было это себе сейчас представить…
Вопрос в том, почему же x86 лучше Alpha? Ведь именно поэтому они вытеснили Alpha, не так ли?
Мне кажется стоит учитывать не только сам процессор, но и его применение. И здесь выходят на свет законодатели в сфере софта. Возможно, это даже заслуга Microsoft. Поскольку большинство ПК работали и работают под Windows. Большинство софта работает под Windows.
Мне кажется стоит учитывать не только сам процессор, но и его применение. И здесь выходят на свет законодатели в сфере софта. Возможно, это даже заслуга Microsoft. Поскольку большинство ПК работали и работают под Windows. Большинство софта работает под Windows.
Большинство софта работает под Windows.Сие есть или уже неправда или «почти неправда». «Большинство софта» сегодня работают под Android и чуть меньше под iOS — ну или это случится через пару лет.
Возможно вы хотели сказать «большая часть „настоящего“, „профессионального“, софта работает под Windows»… ну так 20 лет назад это же самое можно было сказать про «big UNIX»… разница, конечно, в том, что мир «big UNIX»а был раздроблен, а WIntel — это единая платформа, что должно дать ей чуть больше устойчивости… поживём — увидим. Я не готов давать «руку на отсечение» и утверждать что через 20 лет Wintel перейдёт в разряд legacy… но вероятность такая есть, да.
вот и меня удивило насчёт мипсов. Покажите мне упакованный в коробку ARM за $30 с 5-ю ethernet и я удивлюсь.
Все эти армы для тех, кто готов вкладывать деньги ещё и в упаковку. Я вот не готов, покупаю готовые роутеры для мелких задач, а там мипс.
Где почитать про это ваше чудо с мультитредингом?
Все эти армы для тех, кто готов вкладывать деньги ещё и в упаковку. Я вот не готов, покупаю готовые роутеры для мелких задач, а там мипс.
Где почитать про это ваше чудо с мультитредингом?
Если вы рассмотрите процессоры для стиральных машинок, то вы там и не такую экзотику увидите. MIPSы в роутерах укоренились очень крепко, но даже оттуда их, скорее всего, скоро выдавят. А это была последняя ниша где процессор кого-то волновал.
Тут речь идёт не о законченных программно-аппаратных платформах (там может быть какая угодна экзотика), а о чём-то подо что выпускаются независимо программы и железо.
Роутеры сюда отнести можно с большой натяжкой, в любом случае.
Тут речь идёт не о законченных программно-аппаратных платформах (там может быть какая угодна экзотика), а о чём-то подо что выпускаются независимо программы и железо.
Роутеры сюда отнести можно с большой натяжкой, в любом случае.
Очень глупо! почему доля Windows намного больше чем Мак, потому что сама операционка стоит дешевле! И не надо покупать Мак при этом! Почему андроид больше рынка чем у того айфон блакбери итд! потому что андроид дешевле! Кто на рынок зашел первым тот и снял все сливки!
Вы принципиально точки в конце предложений не ставите?
Операционка на Мак не стоит ничего ;)
«Бесплатный сыр бывает только в мышеловке». Пишу с Мака.
Вот только ставить её не на Мак лицензия не разрешает.
Зависит от законодательства страны.
Разве? Вот выдержка из 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.
Взято от сюда
Причем я говорю именно про легальность использования. То что все ставят хакинтошы и ни у кого с этим проблем нету — это отдельная тема.
Вроде бы в некоторых странах пункты договоров, противоречащих законодательству данной страны автоматически признаются ничтожными. И если в такой стране Apple в рамках данного соглашения передает право использования некому лицу, он может ставить данную ОС куда хочет полностью легально.
Могу ошибаться.
Могу ошибаться.
Кое-где в Евросоюзе можно использовать OEM-версии и подержанное ПО, так что полностью легальную лицензию винды можно купить на ебее в виде recovery-диска с лицензионной наклейкой или в виде просто наклейки, переустанавливать на неограниченное число компов (но строго по очереди — стёр на старом, поставил на новый), а потом — стереть со своего компа и перепродать лицензию дальше :)
Главное, чтобы в любой момент времени этот лицензионный ключик использовался только на одном компьютере, чтобы соблюсти условия лицензии.
Главное, чтобы в любой момент времени этот лицензионный ключик использовался только на одном компьютере, чтобы соблюсти условия лицензии.
Есть ссылочка на первоисточник?
Нет ссылочки, я сам как бы сам являюсь первоисточником, так как покупал так Windows, но могу погуглить за вас: lmgtfy.com/?q=oem+used+software+eu
У меня ссылки тоже нет, но по факту у нас в Голландии на местном аналоге Ибея так куча софта продаётся. Я себе винду 8.1 купил за что-то типа 15-25 евро, присматриваюсь к оффлайновому лайтруму за 18.
Раньше писали «non-Apple-labeled» — официальные наклейки с яблоком были в комплекте с каждым айподом, наклеил на хакинтош, вот тебе и Apple-labeled.
Юный неофит, успокойся и проходи дальше, пока ты не в состоянии понять о чём тут говориться.
НЛО прилетело и опубликовало эту надпись здесь
> OS X уже который год раздаётся бесплатно. А до этого стоил смешных денег на порядок ниже Windows. А линукс так вообще от рождения свободен.
Бесплатного ничего не бывает. Стоимость операционки не складывается из положения звезд на небе, а включает в себя работу программистов, маркетологов и т.п., что включается в стоимость конечного устройства. Роллинг-модель обновления теперь есть и у Виндоус.
Бесплатного ничего не бывает. Стоимость операционки не складывается из положения звезд на небе, а включает в себя работу программистов, маркетологов и т.п., что включается в стоимость конечного устройства. Роллинг-модель обновления теперь есть и у Виндоус.
И… в стоимость чего включается работа программистов, комьюнити, и т.п. GNU/Linux?
В сэкономленные бизнесом деньги, которые потом попадают в добавочные стоимости их проприетарных продуктов.
Хм… Я вас не понял. Вы хотели сказать «сэкономленные деньги вычитаются из стоимости проприетарных продуктов»? Нет, я могу предположить, что «добавляются» в том смысле, в каком можно складывать отрицательные числа, но интуиция мне подсказывает, что вы не об этом говорите.
В стоимость коммерческих продуктов тех компаний, в которых эти программисты работают.
это больше вопрос того чья инфраструктура развита! Статья больше о рыночной экономике нежели об архитектуре, хотя тут и есть своя взаимосвязь!
Еще один фактор, на мой взгляд, — фокус на конечном потребителе. Мы абсолютно правильно констатируем преимущества и недостатки платформ/шин/загрузчиков/ос. А голос остается за купюрой потребителя, который покупает то, что решает его проблему или удовлетворяет потребность за приемлемые деньги с необходимым качеством.
Раньше вопрос выбора правильной архитектуры напрямую влиял на возможности устройства. Сегодня же мы можем подключить телефон к телевизору по Wi Fi и стримать 1080p@60. И потребителю пофиг на кривой загрузчик и ошибки шины…
Раньше вопрос выбора правильной архитектуры напрямую влиял на возможности устройства. Сегодня же мы можем подключить телефон к телевизору по Wi Fi и стримать 1080p@60. И потребителю пофиг на кривой загрузчик и ошибки шины…
А потом оказывается что платформа из-за шины или кривого загрузчика принципиально не сможет поддерживать 4К видео, и для того чтобы перейти на 4К прийдётся серьёзно переделывать саму платформу, адаптировать под неё уже написанный софт и т.д. а там БАХ — уже и 8К надо а платформа 4К уже впритык поддерживает… вот это и есть тупик в развитии.
абсолютно верно. Инвестирует потребитель, будущее железа его вообще не интересует. Он лишь осознает, что в среднем через 2 года купит новый телефон. И вполне вероятно, что внутри него будет новый SoC, с абсолютно новой но не менее кривой шиной…
С другой стороны встает overenginering.
Он и сейчас стоит в полный рост… когда 8-ядерные процессоры используют для просмотра фильмов, сёрфинга в интернете и печати различных документов. Большая часть ресурсов и возможностей обычных ПК попросту простаивают и оказываются невостребованными.
Они по крайней мере появились с вполне конкретной целью, в результате эволюции. Да дома может что то и не надо, но в поф сфере оно пригодиться.
Я имел ввиду классический водоворот проектирования, когда на старте пытаются заложить все что можно и получается, что то настолько невообразимо крутейшее насколько и сложное. Но дорого и не нужно.
Я имел ввиду классический водоворот проектирования, когда на старте пытаются заложить все что можно и получается, что то настолько невообразимо крутейшее насколько и сложное. Но дорого и не нужно.
Невостребованными? Да современный софт сожрёт сколько ни дай, и ещё попросит. Потому как фреймворки с песочницами жиреют день ото дня.
Два уровня виртуализации и пять слоёв абстракций — и вот уже простая веб-страничка в две картинки и два абзаца отжирает 4Гб памяти и 4 ядра из 8…
А Unity так разжирел, что уже и в 2Гб памяти не лезет. А разработчики, получив очередной кол за то, что их поделка в полтора полигона вылетает на девайсе с 2Гб памяти каждый раз, когда на устройство приходит SMS, плачутся — мол, тут от нас ничего не зависит, просто возьмите устройство помощнее.
Два уровня виртуализации и пять слоёв абстракций — и вот уже простая веб-страничка в две картинки и два абзаца отжирает 4Гб памяти и 4 ядра из 8…
А Unity так разжирел, что уже и в 2Гб памяти не лезет. А разработчики, получив очередной кол за то, что их поделка в полтора полигона вылетает на девайсе с 2Гб памяти каждый раз, когда на устройство приходит SMS, плачутся — мол, тут от нас ничего не зависит, просто возьмите устройство помощнее.
Это называется транжирство и непрофессионализм. Конкретно для выполняемых функций многие части компьютера рядовыми пользователями не используются.
А между тем, такая фундаментальная вещь как PCI-шина берёт свои корни со времён больших машин и прошла сквозь множество поколений компьютеров вплоть до сегодняшних дней.
А между тем, такая фундаментальная вещь как PCI-шина берёт свои корни со времён больших машин и прошла сквозь множество поколений компьютеров вплоть до сегодняшних дней.
Вероятно, не «некоему Джиму», а очень даже Джиму Кирку, капитану Энтерпрайз.
He's dead, Jim
He's dead, Jim
Скорость увеличения производительности снизилась в разы, поэтому у конкурентов появился шанс догнать текущих фаворитов, причем именно архитектурой, потому что текущая упирается в физические пределы и по размерам и по энергоконтролю.
Следовательно, хорошая архитектурная идея, которая потенциально масштабируется больше, чем текущие лидеры, может выстрелить.
А виртуализация сильно упрощает старт и миграцию.
Мне кажется, что рано сдался, ну или просто попал не в тот проект, который может конкурировать на текущем рынке. Развиваются же ардуины/распберри потихоньку.
Следовательно, хорошая архитектурная идея, которая потенциально масштабируется больше, чем текущие лидеры, может выстрелить.
А виртуализация сильно упрощает старт и миграцию.
Мне кажется, что рано сдался, ну или просто попал не в тот проект, который может конкурировать на текущем рынке. Развиваются же ардуины/распберри потихоньку.
Если смотреть на Android toolchains в NDK, то архитектуры там только растут:
Дальше моя диванная аналитика: из-за большого количество приложений производители телефонов будут поддерживать arch-arm и где-то arch-x86, просто чтобы не подставлять своих клиентов не работающими игорями на C++. Если x86 еще может легко перейти на x86_64 (consumer x86 на андроидах все равно экзотика), то перевести арм на 64 бита будет сложновато, только если поддерживать два ABI одновременно.
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 одновременно.
производители телефонов будут поддерживать arch-arm и где-то arch-x86, просто чтобы не подставлять своих клиентов не работающими игорями на C++Вы же не думаете, что в одном устройстве одновременно и arm и x86?
Во первых это вроде бы возможно, некоторые x86 планшеты вроде могут запускать arm-овский код (какой-то режим эмуляции: stackoverflow.com/questions/13005303/how-does-native-android-code-written-for-arm-run-on-x86). Но пытался рассуждать про другое, а именно будут ли производители телефонов на базе Android переходить на 64-битные версии arm и x86.
Но пытался рассуждать про другое, а именно будут ли производители телефонов на базе Android переходить на 64-битные версии arm и x86.А куда деваться? Ещё лет несколько можно пожить без 64 битов можно, но рано или поздно переходить придётся. Это не так страшно как кажется если не уподобляться придуркам, которые устроили всем «кузькину мать» в Linux'овых дистрибутивах — но это чисто некомпетентность дистрибутиводелов, ничего особо страшного тут нет. Сравните ужасы переходов в Linux и в Windows — и вы всё поймёте…
Актуальность перехода на 64-бит на телефонах не слишком вроде высокая, адресация >2 Гб нужна меньше чем поддержка существующих приложений. Было бы конечно неплохо если бы производители ввели одновременную поддержку двух архитектур (32 и 64-битной) какое-то время.
Бòльшая адресация памяти — на мой взгляд наихудший аргумент в пользу 64 бит, и все его удивительно упорно повторяют. Для ОС есть PAE, а приложений, использующих 4Ггб я вообще ни разу не встречал (конечно я не говорю о серверах — мы же о чем-то более близком к пользователю, верно?).
64 бита, это возможность делать расчеты с более высокой точностью без падения производительности — за счет большего размера регистра; плюс улучшение производительности за счет α) большего числа регистров (хотя по АРМ я могу быть не прав, я не знаю их подноготную, так, по-крайней мере, на х86), и β) лучших соглашений о вызовах, которые намного реже используют стек.
64 бита, это возможность делать расчеты с более высокой точностью без падения производительности — за счет большего размера регистра; плюс улучшение производительности за счет α) большего числа регистров (хотя по АРМ я могу быть не прав, я не знаю их подноготную, так, по-крайней мере, на х86), и β) лучших соглашений о вызовах, которые намного реже используют стек.
Пользователи тоже разные бывают. Всякие CAD/CAM, 3D, разработка вполне могут требовать более 4GiB адресного пространства на приложение.
> 64 бита, это возможность делать расчеты с более высокой точностью без падения производительности — за счет большего размера регистра
Если брать x86/x64 то вроде бы производительность плавающей точки будет примерно одинакова на SSE инструкциях. Насчет целочисленной арифметики не уверен, наверное x64 будет лучше, но ведь чаще всего int — это 32-бита.
> лучших соглашений о вызовах, которые намного реже используют стек.
Да, по крайней мере на windows с ABI у x64 стало получше.
С другой стороны тот же Кнут жалуется на 64-битные указатели (http://www-cs-faculty.stanford.edu/~uno/news08.html), т.е. когда программе не нужно больше 2Гб памяти, она все равно вынуждена использовать 64-битные указатели, что в два раза дороже по размеру, а значит хуже влезает в разного рода кэши процессоров.
Если брать x86/x64 то вроде бы производительность плавающей точки будет примерно одинакова на SSE инструкциях. Насчет целочисленной арифметики не уверен, наверное x64 будет лучше, но ведь чаще всего int — это 32-бита.
> лучших соглашений о вызовах, которые намного реже используют стек.
Да, по крайней мере на windows с ABI у x64 стало получше.
С другой стороны тот же Кнут жалуется на 64-битные указатели (http://www-cs-faculty.stanford.edu/~uno/news08.html), т.е. когда программе не нужно больше 2Гб памяти, она все равно вынуждена использовать 64-битные указатели, что в два раза дороже по размеру, а значит хуже влезает в разного рода кэши процессоров.
Эмм… А можно поподробнее, что за проблемы с переходом 32 → 64 в GNU/Linux? Я вот с самой первой установки использую х86_64, и единственная проблема, которая у меня вообще когда-либо возникала — когда для курсовой по оптимизациям надо было скомпилировать 32-битный wine (погонять в профилировщике), и я не мог поставить 32-битные девелоперские зависимости. Решилось посредством компиляции под lxc-tools.
А можно поподробнее, что за проблемы с переходом 32 → 64 в GNU/Linux?Изначально, когда x86-64 только появился куча дистрибутивов решила, что все разработчки просто ждут-недождутся возможности попортировать свой код на x86-64 и слелали чисто x86-64 дистрибутивы. Когда пользователи такого «чисто 64-битного дистрибутива» спрашивали «а как же Flash?» им отвечали «это — не наши проблемы, когда Adobe сделает — тогда и будет». Adobe, разумеется, неизменно отвечал что их 32-битная версия отлично работает, а если работчики дистрибутивов поломали совместимость, то пусть они её и чинят. Через какое-то время появился костыль и жизнь стала полегче, а ещё через какое-то время появился и 64-битный Flash.
Со временем, конечно, всё утряслось, но сколько людей за это время попробовола Linux, «обожглись» и вернулись на Windows — одному богу ведомо.
Сравните с MacOS или Windows, где все версии поддеживают практически все программы, плагины и прочее. Да, проблемы есть и там, но подход в принципе другой: разработчики этих операционок понимают, что опреционка сама по себе, в общем-то, никому не нужна, нужны программы, которые под операционкой работают — а значит разработчиков нужно холить и лелеять… в разумных пределах, конечно: да, можно одной-двумя не шибко популярными программами и пожертвовать если кто-то из разработчиков пользуется уж какими-то сильно недокументированными возможностями, но в общем и целом совместимость между версиями — это головная боль разработчиков операционок, разработчики программ ничего и никому делать не обязаны.
Таким образом, сегодня мы строим одноразовые системы, не учитывающие того, что ждет нас в будущем
А много ли «неодноразовых» систем кроме System 360 и IBM PC?
Прошу прощения, просто я похоже единственный здесь, кто не понимает проблемы. Пожалуйста, объясните мне кто-нибудь, в чем сыр-бор? О какой поддержке речь — мы же не на ассемблере кодим, взял, скомпилировал с GCC, и вот приложение уже работает на другой архитектуре.
Нет, я могу предположить, что где-то могут быть закодены операции, предполагающие, скажем, 32-разрядность, но если они явно не используют, к примеру, int32_t, это чревато проблемами на 64 разрядных архитектурах тоже, и будет пофиксено независимо от поддержки, скажем 16-битной архитектуры (если таковая существует). Так же я мог бы предположить, что автор говорит про софт с закрытыми исходниками, но маловероятно, учитывая что он в число «поддерживаемых архитектур» внес АРМ и х86 — и существует очень мало приложений с закрытым кодом, поддерживающих обе.
Так в чем посыл то?
Нет, я могу предположить, что где-то могут быть закодены операции, предполагающие, скажем, 32-разрядность, но если они явно не используют, к примеру, int32_t, это чревато проблемами на 64 разрядных архитектурах тоже, и будет пофиксено независимо от поддержки, скажем 16-битной архитектуры (если таковая существует). Так же я мог бы предположить, что автор говорит про софт с закрытыми исходниками, но маловероятно, учитывая что он в число «поддерживаемых архитектур» внес АРМ и х86 — и существует очень мало приложений с закрытым кодом, поддерживающих обе.
Так в чем посыл то?
Так как автор — бывший разработчик OpenBSD, смею предположить, что речь идет все же больше о системном софте.
Ничего страшного в использовании int32_t как раз и нету, проблемы начинаются там где используется long. Например для 64-х битных платформ есть несколько моделей придставления типов данных: LLP64/IL32P64, LP64/I32LP64, ILP64 SILP64. На платформе win64, long длиной 32 бита, на большинстве unix-like систем — 64 бита. Но это все в принципе не проблема.
По своему скромному опыту, могу сказать, что на больших проектах даже переход с armv7 на aarch64, может быть очень болезненным. Проблемы начинаются тогда, когда:
В коде Хавока, есть место где вообще вручную правят vtable.
Ничего страшного в использовании int32_t как раз и нету, проблемы начинаются там где используется long. Например для 64-х битных платформ есть несколько моделей придставления типов данных: LLP64/IL32P64, LP64/I32LP64, ILP64 SILP64. На платформе win64, long длиной 32 бита, на большинстве unix-like систем — 64 бита. Но это все в принципе не проблема.
По своему скромному опыту, могу сказать, что на больших проектах даже переход с armv7 на aarch64, может быть очень болезненным. Проблемы начинаются тогда, когда:
- Есть оптимизации, которые зависят от выравниваний.
- Где-то есть всевозможные хитрых манипуляции с указателями, которых делают предположение, что они именно 32-х битных.
- Когда структуры в прямом виде пишуться/читаются из файла.
- Используюся различные ассмеблерные вставки, скажем для использования NEON.
- Используются сдвиговые операции.
Я писал «не используют int32_t» — оно понятно, чистые int и long имеют лишь четко заданную нижнюю границу. То, что вы сейчас перечислили, забота компилятора, за исключением 1) манипуляций с указателями, в предположении от 32-битности, 2) прямое чтение структур из файла (ну это — кроме как по недосмотру — вообще детская ошибка, очевидно что надо выравнивание отключать), 3) ассемблерные вставки, 4) сдвиговые операции. Все перечисленное будет приводить к пробемам даже при миграции х86_32 → х86_64, не говоря уже об армах, следовательно автор все-таки говорил о чем-то другом.
Да, автор писал о другом. Скорее всего о разработке системного софта, ведь, он бывший разработчик OpenBSD. Там то уж часто нужно весьма плотно работать с железом. Отсюда и проблемы с поддержкой платформ, особенно если, как писал автор, есть проблемы с: тулчейном, флагманскими проектами и документацией.
Я же в качестве примера написал, что проблемы возможны и с прикладным софтом, причем на ровном месте.
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает. Причем внутри струкур находятся указатели, которые хранят оффсеты на другие структуры в файле. При чтении файла, к значению указателя добавляется абсолютный адрес и получаем указатель на струкуру в памяти.
Я же в качестве примера написал, что проблемы возможны и с прикладным софтом, причем на ровном месте.
ну это — кроме как по недосмотру — вообще детская ошибка
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает. Причем внутри струкур находятся указатели, которые хранят оффсеты на другие структуры в файле. При чтении файла, к значению указателя добавляется абсолютный адрес и получаем указатель на струкуру в памяти.
Ах, спасибо, теперь понятно.
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает.Ну это не отменяет элементарности этой ошибки :) Скорее всего движок был написан очень давними программистами, а те, кто работают сегодня, знают что для починки багов потребуется решить много проблем, в частности возможно сломается совместимость с форматами — поэтому они или их руководство не решаются туда лезть. Я думаю, рано или поздно им придется заняться этой проблемой. В частности потому, что графический движок — как раз таки софт, особенно заинтересованный в работе с размерами более 32-битных (я молча полагаю, их движок 32-битный, поскольку 64-битные ОС начали набирать свою популярность относительно недавно).
О какой поддержке речь — мы же не на ассемблере кодим, взял, скомпилировал с GCC, и вот приложение уже работает на другой архитектуре.Ну да. Работает. Пока не упадёт, да. Вам вообще такие слова как «memory ordering» знакомы? А табличку в Wikipedia видели?
Сейчас вопрос стоит так: либо выиграет ARM — тогда ещё есть шанс, либо выиграет x86 — и вот тогда уже всё. Совсем всё. Пока ARM впереди, так что автор рано панику разводит :-)
Есть ещё endianess, например, который у x86 и ARM разный. Если при маршаллинге, разработчик о нём не задумывается, то данные при парсинге превращаются в мусор.
Вас кто-то в криостазисе несколько десятилетий продержал? Единственная «выжившая» big-endian архитектура — это IBM System z (в девичестве — IBM/360). Список исчерпывающий. Все остальные выжившие системы — либо little-endian (x86), либо переключаемые. Android, в частности, работает только с little-endian…
P.S. Как обычно я игнорирую встройку. Если у вас железо не предполагает отдельного от него выпуска программ, то у вас, с одной стороны, развязываются руки (и вы можете делать много вещей, которых «большие дяди» делать не могут), с другой — ну какая, нафиг, разница что у вас там с софтом если его никто кроме вас не делает и делать не будет?
P.S. Как обычно я игнорирую встройку. Если у вас железо не предполагает отдельного от него выпуска программ, то у вас, с одной стороны, развязываются руки (и вы можете делать много вещей, которых «большие дяди» делать не могут), с другой — ну какая, нафиг, разница что у вас там с софтом если его никто кроме вас не делает и делать не будет?
Единственная «выжившая»Ну дак статья и повествует про всякие маргинальные платформы, их состояние и про то, что они как бы не выживают.
Она рассказывает про то, что всякие MIPSы и POWERы — находятся между жизнью и смертью. И это так. Вроде как окончательно они ещё не умерли, но одной ногой они уже всяко в могиле.
А вот всякие 68k, SuperH и прочие всякие AVR32 и ColdFire уже сошли со сцены: теоретически они ещё выпускаются, но практически — только для всяких программно-аппаратных комплексов. Можно, конечно, вспомнить про всякие FireBee, но это настолько нишевой продукт, что это даже не смешно.
Big Endian умер. Аминь.
А вот всякие 68k, SuperH и прочие всякие AVR32 и ColdFire уже сошли со сцены: теоретически они ещё выпускаются, но практически — только для всяких программно-аппаратных комплексов. Можно, конечно, вспомнить про всякие FireBee, но это настолько нишевой продукт, что это даже не смешно.
Big Endian умер. Аминь.
В общем-то, Big Endian ARM скорее «одной ногой в могиле», чем «совсем ушёл со сцены».
Вот, например, неплохой обзор состояния дел.
Вот, например, неплохой обзор состояния дел.
Третий слайд: 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-сети «живы» на этом основании как бы странно…
В этом смысле Big Endian вообще никогда не умрёт: в конце-концов люди до сих пор разрабатывают M68K-совместимое железо! Сегодня, прямо сейчас! Но это всё legacy. Как электрическая сеть постоянного тока: да, в Сан-Франциско ещё лежат кабели, вкопанные больше 100 лет назад и по прежнему питают лифты, но говорить о том, что DC-сети «живы» на этом основании как бы странно…
Судя по комментариям, вы не единственный. Изначально у 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 — давно бы уже девайс прошивал, а так только получилось собрать компилятор.
это ОС, разработчики которой постоянно думают над безопасностью её ядра и компонентов,
это ОС, которая работает на самом разном железе.
И автор статьи страдает именно по поводу второго аспекта. И дело даже не в 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 — давно бы уже девайс прошивал, а так только получилось собрать компилятор.
Отдельная боль — это сборка 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, просто потому что когда-то под него уже делали патч при разработке архитектуры ядра процессора, а потом переносить под свежие версии не имеет смысла.Как это не имеет смысла? Вам софт под ваш процессор нужен или нет? Если нужен — нужно переносить, если не нужен — ну это дело ваше, зачем тогда вообще процессор делать если вы на нём ничего запускать не собираетесь?
Подход: «какой копилятор дадим, тот и будете пользовать» хорош для встройки, где весь софт пишется с нуля. Если вы хотите использовать уже готовые библиотеки — будьте добры озаботиться приличным компилятором.
То есть вот такую проблему 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 не особо хотят поддерживать непопулярные платформы, потому что смысла большого в этом нету.
А дальше ваши вопросы про одно и то же, на самом деле. Вот есть bluetooth чипсет, очень популярный и недорогой, я хочу сделать под него свою кастомную прошивку. Что мне предлагает производитель? А он предлагает мне взять gcc 3.3.3 и не выёживаться. Мультиклет, как пишут по ссылке выше, вообще предлагает компилятор с поддержкой только C89. И команда OpenBSD пытается заставить свою ОС работать вот на подобных странных архитектурах. Именно про это пост, что производители железа не хотят вкладываться в развитие инструментов для разработчиков, а команды разработки gcc/clang не особо хотят поддерживать непопулярные платформы, потому что смысла большого в этом нету.
Вот конкретно с 3.3.3 такая засада.Которая конкретно в 3.3.4 уже отсутствует.
Так что не надо про «можно собрать версию N+1 с помощью версии N и ВСЁ». Разработчики GCC довольно серьёзно относятся к совместимости. Я сам собирал GCC 4 с помощью GCC 2.95.
А вот в обратную сторону… ну что тут можно поделать? Нет, я понимаю — вы бы хотели бы чтобы любая версия GCC могла быть собрана любой другой версией GCC, но, извините, без машины времени тут никак не обойтись. Ошибки в старых версиях GCC можно поправить только выпуском новой версии — или у вас есть какое-то другое предложение?
Ну предложение то простое — чтобы производители железа портировали свои патчи в новые версии самостоятельно, благо популярных открытых компилятора всего два.
Ну для этого они должны решить что они разрабатывают.
Проблема в том, что многие разработчики «железа» считают, что они до сих пор живут в мире, где железо поменять сложно, а софт — легко. Соотвтественно разработка софта идёт «по остаточному принципу».
Но с середины 70х этот мир начал стремительно сокращаться и к настоящему времени его, в общем, больше нет.
Что произошло в 70х? Появились персоналки и софт стал «трудно меняемым».
Нет, исправить одну программу по прежнему легче, чем железку. А как насчёт тысячи программ? Всё ещё готовы сражаться? Ну тогда получите миллион и умрите.
В современном мире у вас нет возможности выпустить чип и надеяться на то, что его будут использовать три с половиной исследовательских лаборатории. Вам нужны миллионные тиражи — иначе разработка не окупится. Так уж устроена современна литография.
А если у вас миллионные тиражи и вы разрешите ваше устройство программировать, то рано или поздно у вас будут миллионы программ — со всеми вытекающими (ну или не будет и вы таки умрёте, но странно начинать разрабатывать платформу сразу затачивая её под крах, не так ли?).
Отсюда и получилось это разделение на встройку и несколько «живых» платформ. Но и при этом даже и встройка начинает сейчас стремительно сокращаться! Повторно используемый код и там начинает рулить!
Но почему-то производители железа по прежнему считают, что главное — сделать железо. Я знаю только одну команду, которая так не считает. Это, как ни удивительно, МЦСТ со своим Эльбрусом. Они говорят: вам должно быть неважно, какая у нас архитектура (а она у нас супер-пупер замечательная), так как мы предоставляем x86 эмулятор.
Ну хоть так. Остальные же разрабатывают железо, а потом пытаются придумать — где они возьмут софт под это железо. А сейчас, вообще говоря, нужно делать наоборот.
Даже крупнейшие фирмы на эти грабли наступают. Itanic ведь именно поэтому же сдох! Причём там они думали над этим вопросом — просто ответ оказался неубедительным. А если о нём и вообще не думать???
Проблема в том, что многие разработчики «железа» считают, что они до сих пор живут в мире, где железо поменять сложно, а софт — легко. Соотвтественно разработка софта идёт «по остаточному принципу».
Но с середины 70х этот мир начал стремительно сокращаться и к настоящему времени его, в общем, больше нет.
Что произошло в 70х? Появились персоналки и софт стал «трудно меняемым».
Нет, исправить одну программу по прежнему легче, чем железку. А как насчёт тысячи программ? Всё ещё готовы сражаться? Ну тогда получите миллион и умрите.
В современном мире у вас нет возможности выпустить чип и надеяться на то, что его будут использовать три с половиной исследовательских лаборатории. Вам нужны миллионные тиражи — иначе разработка не окупится. Так уж устроена современна литография.
А если у вас миллионные тиражи и вы разрешите ваше устройство программировать, то рано или поздно у вас будут миллионы программ — со всеми вытекающими (ну или не будет и вы таки умрёте, но странно начинать разрабатывать платформу сразу затачивая её под крах, не так ли?).
Отсюда и получилось это разделение на встройку и несколько «живых» платформ. Но и при этом даже и встройка начинает сейчас стремительно сокращаться! Повторно используемый код и там начинает рулить!
Но почему-то производители железа по прежнему считают, что главное — сделать железо. Я знаю только одну команду, которая так не считает. Это, как ни удивительно, МЦСТ со своим Эльбрусом. Они говорят: вам должно быть неважно, какая у нас архитектура (а она у нас супер-пупер замечательная), так как мы предоставляем x86 эмулятор.
Ну хоть так. Остальные же разрабатывают железо, а потом пытаются придумать — где они возьмут софт под это железо. А сейчас, вообще говоря, нужно делать наоборот.
Даже крупнейшие фирмы на эти грабли наступают. Itanic ведь именно поэтому же сдох! Причём там они думали над этим вопросом — просто ответ оказался неубедительным. А если о нём и вообще не думать???
Ну хоть так. Остальные же разрабатывают железо, а потом пытаются придумать — где они возьмут софт под это железо. А сейчас, вообще говоря, нужно делать наоборот.
Тем не менее, новые аппаратные платформы каким-то образом появляются на свет.
Вот взять хотя бы amd64 и aarch64 из заголовка статьи. Обе сравнительно недавние. К тому моменту, когда они появились, — очевидно, софта под них ещё не было. Но в обоих эти случаях через несколько лет после появления платформы под неё начал выходить софт.
Чем AMD64 и AArch64 отличаются от всяких Alpha и Itanium, умерших во младенчестве — мне не понятно, честное слово.
Я бы не назвал, х86_64 недавней платформой, 13 лет немало времени для развития экосистемы — другое дело, что популярность она начала набирать сравнительно недавно, это верно. Но вообще это сравнение некорректное — на х86_64 по-прежнему работают приложения под х86_32, т.е. на момент появления 64-разрядной версии уже была куча готового софта. Добавление «родной» поддержки х86_64 — как только появились компиляторы — производилось под GNU/Linux потому что это было нетрудно, и под Windows по остаточному принципу. Поправьте меня если ошибаюсь, но полагаю, что под aarch64 та же ситуация с софтом.
Я не знаю истории с Alpha, но полагаю, что именно Itanium умер просто потому, что Intel плохо вкладывались в рекламу и продажи. Во-первых, я ни разу не видел его в магазинах, хотя, признаться, мне было бы интересно его купить просто из любопытства, и думаю ни мне одному (разумеется при разумной цене) — с софтом, спасибо FOSS, проблем не будет. Во-вторых, пока здесь не упомянули его, я даже и не знал, что он до сих пор существует! Я был абсолютно уверен, что после неудачи в районе 2002 года они прекратили производство — везде о нем расписывается в тонах R.I.P. И только сейчас я обнаружил, что последний выпуск был всего несколько лет назад. А все потому, что Intel не занимается его рекламой, конференциями, бенчмарками на нем, не упоминает его как бы между прочим в беседе на другие темы — такое ощущение, будто они его просто сделали, и забыли!
Я не знаю истории с Alpha, но полагаю, что именно Itanium умер просто потому, что Intel плохо вкладывались в рекламу и продажи. Во-первых, я ни разу не видел его в магазинах, хотя, признаться, мне было бы интересно его купить просто из любопытства, и думаю ни мне одному (разумеется при разумной цене) — с софтом, спасибо FOSS, проблем не будет. Во-вторых, пока здесь не упомянули его, я даже и не знал, что он до сих пор существует! Я был абсолютно уверен, что после неудачи в районе 2002 года они прекратили производство — везде о нем расписывается в тонах R.I.P. И только сейчас я обнаружил, что последний выпуск был всего несколько лет назад. А все потому, что Intel не занимается его рекламой, конференциями, бенчмарками на нем, не упоминает его как бы между прочим в беседе на другие темы — такое ощущение, будто они его просто сделали, и забыли!
Я не знаю истории с Alpha, но полагаю, что именно Itanium умер просто потому, что Intel плохо вкладывались в рекламу и продажи.Нет, нет и нет. Itanium умер потому что это была попытка продвинуть новую архитектуру в нишу, которая уже была занята другими архитектурами. Тут никакая реклама не поможет: софта-то нет!
То, что Itanium'ов вообще хоть сколько-то удалось продать — это просто фантастический успех рекламного отдела: она навешали просто мегатонны лапши на уши всяким HP и SGI, после чего те сами, добровольно убили свои собственные платформы, чтобы их место занял Itanium. Но даже это благородное самоубийство его, разумеется, спасти не смогло.
Во-первых, я ни разу не видел его в магазинах, хотя, признаться, мне было бы интересно его купить просто из любопытства, и думаю ни мне одному (разумеется при разумной цене)Это вы процессор с кристаллом в 700mm2 хотите увидеть «по разумной цене»? Чисто для справки: AMD Radeon Fury X имеет кристал размером 600mm2, у GeForce GTX Titan — 560mm2…
Подержанный Itanium можно купить за весьма небольшие деньги, кстати, но новый? Intel — это всё-таки коммерческая компания, продавать что-то ниже себестоимости она если и будет — то недолго.
А все потому, что Intel не занимается его рекламой, конференциями, бенчмарками на нем, не упоминает его как бы между прочим в беседе на другие темы — такое ощущение, будто они его просто сделали, и забыли!Так и есть. Часть Itanium'ов продаётся по долгосрочным контрактам, которые предусматривают не один год поддержки. Oracle пыталась «выскочить» — не удалось, Intel же понимал, что это безнадёга, так что какое-то количество процессоров ещё будет выпущено (может даже ещё одна модель будет, я не знаю как там контракты составлены), но это уже в чистом виде «жизнь после смерти».
Itanium умер потому что это была попытка продвинуть новую архитектуру в нишу, которая уже была занята другими архитектурами. Тут никакая реклама не поможет: софта-то нет!Мне кажется, тут аргумент про софт звучит неубедительно, потому что на момент появления Itanium в нем имелась аппаратная эмуляция x86 архитектуры (да, я знаю, она была медленной, но она была), и очень быстро появились ОС под IA64, включая Windows.
да, я знаю, она была медленной, но она былаС практической точки зрения это значит, что её не было. «Проблему курицы и яйца» (которую отлично решала поддержка старых архитектур при появлении 80386 или AArch64) она не решала.
Одно дело — когда у вас есть отличный x86 процессор, который вы можете закупать миллионными тиражами игнорируя тот факт что в нём есть какая-то там «новая архитектура»: вы его будете покупать и использовать годами — пока, наконец у вас не появится парочка программ под «новую архитектуру» (сам личто участвовал в переходе на x86-64 в одной организации: до 2010 года примерно подавляющее большинство софта было 32-битным).
Совсем другое — когда у вас есть настолько дерьмовый x86 процессор, что использовать его как x86 процессор просто бессмысленно: при выполнении неоптимизированного под Itanium программного кода для x86 систем его производительность была в 8 раз меньше, чем у x86 процессоров на той же частоте (а частота у Itanium'а была, кстати, зачастую ниже, чем даже у бюджетных x86 процессоров того же года выпуска). При таком раскладе покупать этот процессор для x86 кода вы не станете, а значит — не станете его покупать и вообще, скорее всего: софта-то нет!
А раз этого процессора ни у кого нет, то с какого перепугу вдруг у кого-то может возникнуть желание писать под него софт?
Новая архитектура CPU может «выстрелить» только и исключительно когда открывается новый рынок. Лобовая атака бесполезна. Тот же ARM на рынке десктопов давно мёртв. Он может туда ещё вернуться — но это произойдёт потому, что он «зайдёт» с другого рынка (планшетов, данном случае). Itanium же пытались продвинуть на рынок северов «в лоб». Маркетологам памятник надо поставить за их усилия — но они были обречены с самого начала.
Вот взять хотя бы 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 не имели ничего, что можно было бы на них пускать.
Почему-то 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 потонул.
Это существенно отличается от 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 этого допустить, понятно, не мог.
Для использования SSE не нужна поддержка со стороны ОС.
«создать для себя пару сегментов, перейти в long mode и развести «маленький такой x86-64» посреди 32-битного процесса» — это не то чтобы новое изобретение: старинные штуки под названием «DOS extender» работали похожим образом. Но согласитесь, что такие выкрутасы намного сложнее, чем «просто добавить в старый код новые инструкции там, где они нужны, и больше ничего не трогать».
По всем остальным пунктам полностью согласен. Выходит, что успех/неуспех нового процессора в не меньшей степени, чем качествами самого процессора, определяется маркетинговой политикой и рыночной конъюнктурой.
«создать для себя пару сегментов, перейти в long mode и развести «маленький такой x86-64» посреди 32-битного процесса» — это не то чтобы новое изобретение: старинные штуки под названием «DOS extender» работали похожим образом. Но согласитесь, что такие выкрутасы намного сложнее, чем «просто добавить в старый код новые инструкции там, где они нужны, и больше ничего не трогать».
По всем остальным пунктам полностью согласен. Выходит, что успех/неуспех нового процессора в не меньшей степени, чем качествами самого процессора, определяется маркетинговой политикой и рыночной конъюнктурой.
Для использования SSE не нужна поддержка со стороны ОС.Да шо вы такое говорите. А кто регистры дополнительные будет сохранять? Пушкин?
Но согласитесь, что такие выкрутасы намного сложнее, чем «просто добавить в старый код новые инструкции там, где они нужны, и больше ничего не трогать».Разница в любом случае не качественная, а количественная. Для перехода в x86-64 нужно сделать
far jmp, а для переключение в режим работы с MMX — вызвать инструкцию EMMS… так ли уже велика разница? И если разница между far jmpом и EMMSом так принципиальна, то куда вы отнесёте Thumb и ARM26? Это уже новые архитектуры или ещё нет?Я боюсь что с вашими подходами один ARM превратится в дюжину разных архитектур… А в
x86 (с его всякими unreal mode) вы их сколько насчитаете?Выходит, что успех/неуспех нового процессора в не меньшей степени, чем качествами самого процессора, определяется маркетинговой политикой и рыночной конъюнктурой.Только всё наоброт. Если у вас есть новая ниша, которая, по тем или иным причинам, не может быть занята существующей архитектурой — у вас есть шанс. Если ниши нет — то уже неважно насколько хорош ваш процессор.
Интересным примером регулярно открывающейся «новой ниши» являются, к примеру, игровые приставки: так как люди редко покупают новую приставку, чтобы играть на ней в старые игры (для этого у них старая прис тавка есть), то здесь каждое новое поколение — это очередной шанс для очередной новой архитектуры. Но и то: предыдушее поколение было сплошь PowerPC, нынешнее — спрошной x86, так что, похоже, уже и тут груз существующих библиотек уже довлее настолько, что появление чего-то принципиально нового — весьма проблематично.
Скоро, возможно, откроется ниша для IoT (сегодня есть две крайности: либо всё делать в традициях «полноценной встройки» и не допускать никакой перепрограммируемости вообще, либо сувать в электрическую лампочку Android и 2GiB памяти… кажется что должно появиться что-то посредине), со временем, возможно, ещё какие-то ниши будут. Но везде и всюду рулит софт.
Просто к слову — на консолях использование отличных от х86 архитектур экономически выгодно, поскольку усложняет создание эмуляторов приставок, и повышает необходимые вычислительные ресурсы для их работы.
К примеру: если бы приставка была оснащена х86 процессором, то можно не использовать виртуальную машину — достаточно сделать для десктопов Wine-подобную оболочку, и игры будут работать почти без ущерба производительности.
К примеру: если бы приставка была оснащена х86 процессором, то можно не использовать виртуальную машину — достаточно сделать для десктопов Wine-подобную оболочку, и игры будут работать почти без ущерба производительности.
Это теория, которая расходится с практикой чуть менее, чем полностью. То есть с одной стороны вы правы — достаточно сделать для десктопов 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 у неё стандартные, только «ускоритель с боку» является некоей «инновацией»… не поддержанной софтом и потому никому не нужной: все разработчики его буквально прокляли и в большинстве игр его мощь попросту не используется.
Посмотрите на шестое поколение приставок: 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 у неё стандартные, только «ускоритель с боку» является некоей «инновацией»… не поддержанной софтом и потому никому не нужной: все разработчики его буквально прокляли и в большинстве игр его мощь попросту не используется.
Да шо вы такое говорите. А кто регистры дополнительные будет сохранять? Пушкин?
Ну значит, не-SSE-шная ОС позволяет запускать SSE-приложения по одному =)
А поддержка SSE в ядре ОС добавляет возможность запускать несколько SSE-приложений одновременно.
Если мне не изменяет память, первыми SSE-приложениями были 3D-игры; и вполне разумно было предположить, что пользователь не станет запускать одновременно несколько 3D-игр — а значит, поддержка SSE ядром ОС была необязательна.
Ну значит, не-SSE-шная ОС позволяет запускать SSE-приложения по одному =)Не позволяет. Операционка должна не только сохранять регистры, но и сообщить процессору, что она это делает установив в единичку бит OSFXSR в CR4. Иначе SSE-инструкции не распознаются.
И чтобы предупредить вашу следующую идею: для поддержки 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 — и это только из того, что «навскидку» вспомнилось) — что будет несколько… гхм… странно.
Так шта… нету между x86-64 и разными другими расширениями типа SSE или AVX512 никакой качественной разницы. Не-ту. Количественная — да, есть, это весьма серьёзное расширение, спору нет, но вся эта разница — количественная, «новой» существующую архитектуру это не делает. Ну или делает, но тогда у вас x86 распадётся на дюжину архитектур и ARM тоже (там вообще прикольно: архитектура, вроде как, одна, но разных видов ABI… вагон и маленькая тележка: OABI и EABI, hard float и soft float, уже упоминавшийся режим ARM26 — и это только из того, что «навскидку» вспомнилось) — что будет несколько… гхм… странно.
ARM тоже (там вообще прикольно: архитектура, вроде как, одна, но разных видов ABI… вагон и маленькая тележка: OABI и EABI, hard float и soft float, уже упоминавшийся режим ARM26 — и это только из того, что «навскидку» вспомнилось) — что будет несколько… гхм… странно.Не считая ещё особенностей использование инструкции ветвления
B/BX Rm при младшем бите Rm выставленном в 0 или 1 ,)
В-целом Вы правы («Без поддержи со стороны ядра вы ни 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)
Например, 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)
Ну это вы уже в частности полезли. Понятно что когда я говорил про ядро я имел в виду 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 процессор, по сути, а эмуляция — была тормозной всегда…
И дырочку вы никакую в этом смысла не найдёте: из 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 процессор, по сути, а эмуляция — была тормозной всегда…
НЛО прилетело и опубликовало эту надпись здесь
Да, помню как в бытность программистом Windows Mobile приходилось собирать 3 версии, под ARM, MIPS и SH3 :) Устройства были Jornada SH3 и Casio E125.
Выглядел девайс примерно так:
Давно было… :)
Выглядел девайс примерно так:
Давно было… :)
А кто-нибудь может мне объяснить причину этого наброса оригинального автора?
Я перечитал все комментарии здесь, оригинальное сообщение на pastebin («Дети, запомните, если вы хотите открыть дискуссию, никогда, никогда, это не открывайте на pastebin и gist!»), на редите, перечитал комменты на его оригинальный твит, и все равно не понимаю.
Имеем на входе такой контекст: Миод Валлат, давнишний разработчик OpenBSD (который не про новые архитектуры, и относительную популярность. про это FreeBSD, и который не про пыльные, старые, маленькие железки — про это NetBSD, а который про безопасность и правильную процедуру разработки). И он пишет что он разочаровался и уходит из OpenBSD, потому как никто уже не веселится с маргинальными железками (оставляем за скобками его опосредованный наброс на MIPS и Power, которые очень даже ок во FreeBSD). Если тебе хочется копаться со старьем — иди коммить в NetBSD. Никто слова плохого не скажет. Здесь же читается что-то другое, кроме некорректного наброса про современные архитектуры.
Мне так кажется (ни на чем не настаиваю, полностью мои спекуляции) что Миод просто устал и разочаровался в проекте OpenBSD. (Если даже денег на эксперименты с не x86/arm железками нет). Не удивлюсь увидев его в скорости в более сытном (но не намного) контексте FreeBSD…
С другой стороны, может мне кто-нибудь объяснить, а зачем вообще существует такое большое количество ответвлений BSD — FreeBSD, OpenBSD, NetBSD, Dragonfly? Почему они с такой легкостью плодят форки, и почему не умеют работать вместе? Чего они добились за это время живя по-отдельности? [Вопросы большей частью риторические]
Я перечитал все комментарии здесь, оригинальное сообщение на pastebin («Дети, запомните, если вы хотите открыть дискуссию, никогда, никогда, это не открывайте на pastebin и gist!»), на редите, перечитал комменты на его оригинальный твит, и все равно не понимаю.
Имеем на входе такой контекст: Миод Валлат, давнишний разработчик OpenBSD (который не про новые архитектуры, и относительную популярность. про это FreeBSD, и который не про пыльные, старые, маленькие железки — про это NetBSD, а который про безопасность и правильную процедуру разработки). И он пишет что он разочаровался и уходит из OpenBSD, потому как никто уже не веселится с маргинальными железками (оставляем за скобками его опосредованный наброс на MIPS и Power, которые очень даже ок во FreeBSD). Если тебе хочется копаться со старьем — иди коммить в NetBSD. Никто слова плохого не скажет. Здесь же читается что-то другое, кроме некорректного наброса про современные архитектуры.
Мне так кажется (ни на чем не настаиваю, полностью мои спекуляции) что Миод просто устал и разочаровался в проекте OpenBSD. (Если даже денег на эксперименты с не x86/arm железками нет). Не удивлюсь увидев его в скорости в более сытном (но не намного) контексте FreeBSD…
С другой стороны, может мне кто-нибудь объяснить, а зачем вообще существует такое большое количество ответвлений BSD — FreeBSD, OpenBSD, NetBSD, Dragonfly? Почему они с такой легкостью плодят форки, и почему не умеют работать вместе? Чего они добились за это время живя по-отдельности? [Вопросы большей частью риторические]
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сегодняшний мир — это amd64, armv7 и aarch64. Всё остальное мертво, Джим