На прошлой неделе компания ARM Holdings объявила, что разрабатывает новую микро-архитектуру для серверных процессоров. Вычислительное ядро, которое будет в ней использоваться, носит кодовое имя Ares, и по обещаниям должно дать 60% прирост по сравнению с текущей платформой. С каждым следующим поколением производительность должна расти еще на 30%.
Серверный рынок — пока не самый большой для ARM. Сейчас процессоры на ее архитектуре используются в мобильных и встраиваемых устройствах. Скачок производительности, который компания обещает производителям серверов, будет выше чем Intel и IBM проделали за последние несколько лет.
Тем не менее, создатель Linux Линус Торвальдс скептично прокомментировал анонс. Он считает, что будущее новой архитектуры не так радужно.
Я могу гарантировать, что пока все занимаются кроссплатформенной разработкой, платформа не будет стабильна и успешна. Некоторые думают, набор инструкций не важен для «облака» — разрабатываешь дома, деплоишь и все (под «дома» я имею в виду не в прямом смысле у себя дома, а в своем рабочем пространстве).
Это полная чушь. Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.
Поэтому провайдеры получат больше денег от серверов на x86 и будут держать их в приоритете. Любые варианты от ARM будут вторичны, и скорее всего на них сбросят всякую глупую чепуху, вроде фронтенда, статичного HTML и всякого такого.
Одно из заявленных преимущество ARM-архитектуры, которое позволило ей выиграть на мобильном рынке — энергопотребление. Компания считает, что благодаря этому снизится стоимость, а производительность будет не хуже. Такое сочетание поможет ей конкурировать и среди серверов. Но Торвальдс думает, что успех на рынке определяется другими причинами.
По его мнению определяющий фактор — именно «домашняя разработка». Маленькие компании тестируют рабочие нагрузки на обычных дешевых PC, а когда нагрузки вырастают — эти компьютеры берут на себя роль реальных серверов. И только при огромном росте нагрузок, компании переносят все в облако, не желая менять архитектуру во избежание проблем.
Именно это и убило вендоров RISC-процессоров и сделало x86 царем горы среди серверов. До той степени, что все иное — просто погрешность. А пару десятков лет назад такое бы звучало бы как фантастическая выдумка.Линус считает, что выходить на рынок серверов, не создав предварительно среду для разработки и не «заполонив рынок дешевыми девбоксами — полный идиотизм». К тому же он сомневается, что преимущества, которые называет ARM, действительно считаются преимуществами. По его словам, все текущие серверы на этой архитектуре — в реальности медленнее, дороже и вряд ли экономят так уж много энергии.
С Торвальдсом не согласился создатель Redis Сальваторе Санфилиппо. Он считает, большинство разработчиков не мыслит постоянным погружением в вычислительные ядра и вообще не придает значения воспроизводимости среды на уровне архитектуры. По его словам, перевод Redis на ARM-архитектуру не вызвал тех проблем, которыми пугает создатель Linux:
Redis, который сам по себе является низкоуровневым кодом, спокойно работает на ARM, все тесты проходят, и нет никаких проблем со стабильностью. А раз уж код, написанный на C много лет назад, когда об ARM еще никто не думал, работает практически из коробки, с приложениями на Ruby или Node тем более ничего не случится, когда их зальют на ARM-серверы.Компания-разработчик архитектуры тоже ответила Торвальдсу. Они согласны с его мнением, что разработка в рамках одной среды работает гораздо лучше, поэтому анонсируют собственную платформу для разработки, вероятно, на этой неделе.
Производители железа также идут в сторону изменений, которые по словам Торвальдса, необходимы для будущего новой архитектуры. Например Apple, по слухам, готовит к выпуску Маки с ARM-процессорами, Qualcomm ведет разработку ARM-процессоров для лэптопов, а Microsoft поддерживает ARM-разработку для Windows 10.
Сам Торвальдс в своем следующем посте тоже снизил градус скепсиса:
Посмотрим, что будет на самом деле, но сейчас ARM точно нравится мне больше, чем раньше.В обсуждении вопроса на Reddit отметили, что большинство известных архитектур не выдержали конкуренции с x86.
Пока я не увижу широкого распространения железа, которое люди могут использовать для разработки и развертывания, я придержу свои суждения. Просто я слышал слишком много обещаний о железе, которое после релиза никому и нигде не было нужно.
Надеюсь, ARM не будут слишком ударяться в перемасштабирование. Может им и удастся, но, если честно, я сомневаюсь. Это требует много времени и усилий. Не надо замахиваться на 64-128 ядер, пока не получится сделать нормально хотя бы 8-ядерник. Что они пока не продемонстрировали.
Но мало ли, может они меня удивят.
m88k? Мертва, или переехала на что-то вроде PowerPC. i860? Мертва. i960? Мертва. PA-RISC? мертва. AMD 29000? Мертва. IA64? Мертва. Alpha? Мертва.
Тем не менее, в обсуждении сошлись, что текущий рынок серверных архитектур разделяют три системы. ARM — как самая слабая и дешевая. Power9 — самая мощная, но невероятно дорогая. x86 среди них золотая середина в соотношении цена-качество:
Разрабатывать и деплоить на ARM нормально, если ты используешь Rasp. Pi. Но нужно что-то помощнее. С Power9 ситуация обратная: самая дешевая система — это Talos II. Поэтому нужно много тысяч долларов, чтобы собрать нормальный девбокс на Power9. Конечно, он хорош, но это слишком дорого для обычных нужд в разработке.Но во втором квартале этого года Raptor Computer Systems планирует выпустить десктоп с 4-ядерным CPU на архитектуре Power9 за 1200 долларов. Поэтому если такая тенденция сохранится — ARM будет повышать производительность, а Power9 снижать цену — в массовом сегменте может снова возникнуть конкуренция.
Поэтому x86 попадает как раз в нишу массового потребления — лэптопы и десктопы стоят до тысячи долларов.
Комментарии (226)
KonstantinSpb
25.02.2019 16:53-1archlinuxarm.org Linux под ARM компилируемый на ARM, никакой кросс-компиляции
kAIST
25.02.2019 17:11Но на сервере, разработчики запускают свой код. Даже если ты программируешь на каком нибудь питоне, не факт что под arm будут доступны необходимые тебе библиотеки.
KonstantinSpb
25.02.2019 22:08+1Питон же интерпретатор, под отсутствием библиотек, Вы наверное понимаете, что не будет Python-C binding-ов, в которых есть ассемблерные вставки. В остальных случаях Си-шные байниндинги без ассемблерных вставок будут спокойно компилироваться под ARM
dmitrmax
26.02.2019 07:44+1> Вы наверное понимаете, что не будет Python-C binding-ов
Binding — это лишь способ связать Python с библиотекой, написанной на ином языке. Вы вполне себе можете написать модуль Python, у которого реализация методов и функций будет на C, C++, assembler и т.д… При этом он не будет являться binding'ом к чему-либо.
> В остальных случаях Си-шные байниндинги без ассемблерных вставок будут спокойно компилироваться под ARM
Сильно зависит о того, насколько криворуким был автор кода, даже если он писал на чистом божественном C. Варианты могут быть разными:
- Не компилируется
- Компилируется, но не работает — например, автор заложился на порядок байт
- Компилируется, но работает не оптимально: например, код обращается к невыровненному адресу для загрузки из памяти 32-х битного значения. На ARM это сгенерирует исключение процессора, которое может перехватить ОС и проэмулировать успешное чтение памяти
- Просто работает
mistergrim
26.02.2019 17:205. Просто работает, но периодически вылезают чудесные неотловимые баги.
dmitrmax
26.02.2019 18:09Такое поведение не является атрибутом только именно native-кода )
mistergrim
26.02.2019 19:21Разумеется, но не очень приятно будет к сотне известных глюков получить ещё две сотни неизвестных.
khim
26.02.2019 18:36+12. Компилируется, но не работает — например, автор заложился на порядок байт
Порядок байт на ARM и x86 одинаковая и всегда была одинаковая (ранние модели опционально поддерживали Big Endian, но сейчас этот режим выпилили за ненадобностью).
3. Компилируется, но работает не оптимально: например, код обращается к невыровненному адресу для загрузки из памяти 32-х битного значения. На ARM это сгенерирует исключение процессора, которое может перехватить ОС и проэмулировать успешное чтение памяти
Чтобы такое увидеть вам потребуется откопать раритеное ядро 10-15-летней давности. На всех современных процессорах невыровненное чтение поддерживается аппаратно.
На самом деле в портировании под ARM есть свои чудеса, но их гораздо меньше, чем кажется. Но их, увы, таки больше, чем нужно для того, чтобы можно было вашу либо отдавать совсем не престировав.dmitrmax
26.02.2019 20:53Спасибо за уточнения. Но всё равно не стоит писать код, который закладывается на невыровненное чтение или на порядок байт. Не ARM, так другая архитектура, куда может потенциально угодить ваша либа, может очень плохо отнестись к таким фокусам )
Psionic
26.02.2019 17:28Да о чем речь, есть случаи когда библиотек даже нет под другую ОСь или другой интерпретатор питона.
DSolodukhin
25.02.2019 17:01При всём уважении к Торвальдсу, мне кажется он слишком сгущает краски.
Во-первых, давно уже программисты не пишут только на C/C++, нынче в моде Node.js, С#, Java, Python и пр. Т.е. языки и платформы, которые в том или ином виде предлагают концепцию «Write once, Run everywhere». Современному программисту необязательно знать, как работает TCP/IP, чтобы написать веб-приложение.
Во-вторых, по поводу «Не надо замахиваться на 64-128 ядер, пока не получится сделать нормально хотя бы 8-ядерник». Много слабых ядер тоже могут найти свою нишу, я не думаю, что сразу замахиваться на нишу Xeon'ов хорошая идея.
snizovtsev
25.02.2019 17:28Что там с памятью? Больше 8GB есть? Быстрый SSD можно подключить? Все драйвера в апстриме, или нужно привязываться к форку определённой версии?
DSolodukhin
25.02.2019 17:47Простите, не понял, вы о чем? Какие SSD? Какие драйвера?
UNIm95
25.02.2019 18:42+6Возьмём старую добрую малинку(
raspberry pi).
Может ли разработчик на неё подключить быстрыйssdчто бы компиляция кода шла быстро(в сравнении сmicroSDкарточкой)?
Может ли разработчик запуститьX11с самой свежей убунтой/арчем? Что бы запустить классическую eclipse/Netbeans/jetbrains?
Будет ли компиляция и деплой достаточно быстрым?
Пожалуй на всё можно ответить нет.
И это мы говорим про плату, которая очень сильно толкнула развитие ARM для домашнего пользователя/разработчика.
Линус в данном вопросе прав.
В качестве примера можно глянуть мейнфреймы.
С ними происходит тоже самое что и коболом.
Они вымирают по естественным причинам.
Средний возраст разработчика за 50 лет(в конторе которая была клиентом).
Молодой домашний пользователь/разработчик не может получить что-то вроде мейнфрейма домой-> не может с ним поиграть -> не желания связываться с этой темой дальше.
Вот и с ARM ничего не будет.
Пока ARM не выпустит классическую материнку ATX формата с наборной оперативкой, PCIE, SATA и так далее.
gecube
25.02.2019 18:51+1Все сильно хуже. Будут ли на ARM работать всякие чисто серверные штуки — ну, там ceph (драйвер в ядре), gluster (тоже требуется поддержка со стороны ядра), iscsi (угу, iscsi-клиент тоже в ядре) и т.п… а без этого ARM становится весьма нишевым решением.
Stinkynnov
27.02.2019 18:11+1Это же все платформо-независимый код. Что должно помешать работе?
gecube
27.02.2019 19:19Т.е. Вы гарантируете, что
- нигде нет ассемблерных вставок;
- нет привязки к low/big endian, размерности величин;
- нет нюансов с сериализации/десериализацией данных;
- нет завязок на компоненты, которые существуют только на x86_64 платформе?
Я бы не рискнул давать таковые...
Stinkynnov
27.02.2019 21:38+1Гарантировать? Таки Вы таки уже ставите в прод на основе моих комментариев? Так это зря…
Если вопрос реально интересен, это выясняется даже не качая исходников, благо они на гитхабе. Не знаю что нужно гластеру, а у ceph и iscsi зависимости только на сеть и общую криптографию, без уточнения платформы. Точнее, iscsi включает еще и конкретно интеловую крипту конкретно для x86.
Наличие ассемблерных вставок легко проверяется, средства для работы с любым порядком байтов в ядре в наличии (хотя, опять же, у x86 и ARM он одинаковый). Что может быть не так с размерностями величин и сериализацией я не понял.
Впрочем и смысла предыдущего вопроса я таки по прежнему не понимаю. Это чисто софтовые компоненты, давно включенные в ванильное ядро, значит написаны по стандартам ядра. Такие же претензии можно предъявить всему, включая планировщик процессов и драйвер ext2. Или уже были прецеденты?gecube
28.02.2019 08:10Таки Вы таки уже ставите в прод на основе моих комментариев? Так это зря…
нет, конечно.
Если вопрос реально интересен, это выясняется даже не качая исходников, благо они на гитхабе. Не знаю что нужно гластеру, а у ceph и iscsi зависимости только на сеть и общую криптографию, без уточнения платформы. Точнее, iscsi включает еще и конкретно интеловую крипту конкретно для x86.
ну, это пока общие разговоры в пользу бедных.
Вот ниже коллеги пишут, что есть готовый appliance — IronSoft Ceph Appliance.
Другой вопрос, что работает ли он в режиме черного ящика и можно ли строить гетерогенные системы (например, часть ceph-нод на ARM, часть — на x86 — вот там перечисленные мной проблемы могут и стрельнуть). Например, k8s поднять на мастер-нодах на x86, а worker'ы на ARM — почему нет?
В любом случае, похоже, что только практика покажет жизненноспособность таких решений…
Такие же претензии можно предъявить всему, включая планировщик процессов и драйвер ext2. Или уже были прецеденты?
ну, вот, опять как пример — часто ли Вы монтируете файловую систему с устройства с посторонней архитектурой? Точно не каждый день. Разве что может SDшку с телефона, да и то для одной задачи — скопировать фотографии и видосики, а они в стандартных форматах. Совместимость-то платформ не ограничивается совместимостью каких-то коровых (от core) технологий (ФС, сеть и пр.), а еще и совместимостью приклада (немного не в тему, но могу напомнить, что даже офисные пакеты пока все еще не идеально открывают файлы друг друга).
DSolodukhin
25.02.2019 18:57+2ARM не выпускает железо вообще-то, они занимаются исключительно разработкой процессоров на «бумаге», которые потом лицензируют производителям.
Может ли разработчик запустить X11 с самой свежей убунтой/арчем? Что бы запустить классическую eclipse/Netbeans/jetbrains?
Мы точно всё еще говорим про игрушку за 30 баксов? Вы еще WebSphere + Oracle DB попытайтесь на ней поднять, а потом жалуйтесь, что говно этот ваш ARM.
Вот когда выйдет реальное железо на новой архитектуре, тогда и будет смысл предъявлять претензии, что у вас что-то не работает. А пока это напоминает анекдот про японскую пилу и сибирских мужиков.UNIm95
25.02.2019 19:05+3А чем именно напоминает анекдот?
Разработчик хочет перенести свое приложение на ARM.
Для этого неплохо бы поднять систему разработки и сборки.
Может разработчик собрать комп на ARM с кросплатформенным линуксом?
Причем так, что бы ARM комп смог ему заменить рабочий комп на х86?
Нет.
Вот тут Lenovo пыталась выпустить нетбук на ARM но что-то пошло не так.
Flaksirus
26.02.2019 16:07Ну вообще на арме есть продакшн решения. И это не малинка само-собой. Посмотрите например на nvidia jetson.
khim
25.02.2019 19:15Мы точно всё еще говорим про игрушку за 30 баксов?
Нет. Можно и 300 отвалить. Но не 3000 — для большинства разработчиков это «многовато будет».
Об чём и речь — есть либо что-то очень очень дешёвое, либо разного вида дорогущие монстры. А «коробки для разработчика» — нету…undisclosed
26.02.2019 14:42Почему-то все при слове ARM вспоминают только про малину.
Но это не значит, что если в малине чего-то нет, то этого нет вообще.
Совсем забыли про Odroid платки odroid-xu4 и odroid-hc2.
Они вполне годные для разработки прямо на них. Хотя ниже верно подметили, что совсем не обязательно что-то разрабатывать именно на самой ARM-коробочке. Кросс-компиляция отлично работает.
beeruser
26.02.2019 16:39Они вполне годные для разработки прямо на них.
На старых 32-битных телефонных SoC с крошечными тормозными eMMC?
У меня есть две штуки. Очень они костыльные (не вина hardkernel — они большие молодцы) и медленные. Сколько будет собираться Chrome какой-нибудь. Хватит 2GB памяти?
Хотя ниже верно подметили, что совсем не обязательно что-то разрабатывать именно на самой ARM-коробочке. Кросс-компиляция отлично работает.
Речь в оригинальном посте и идёт о том, что кросс-компиляция — компромисс. Для маленьких или идеологически отгороженных платформ сойдёт, конечно.
Но разработчики которые не хотят сидеть на х86, нет имеют выбора.
Есть медленные и дешёвые и наоборот — 28-64 ядерные системы за огромные деньги, которые ещё и хрен купишь.
Flaksirus
26.02.2019 16:08300 для разработчиков это не много. У нас как бы софт стоит соразмерно…
khim
26.02.2019 18:38Дык нет же ничего за 300! Есть за 30 и есть за 3000! Первое — это дикие тормоза (к тем, кто создаёт эти машинки, впрочем, претензий нет: чего вы вообще хотите за такие деньги?), а второе — это уже чересчур дорого…
Об чём и речь…
yayashitoya
25.02.2019 22:04Молодой домашний пользователь/разработчик не может получить что-то вроде мейнфрейма домой-> не может с ним поиграть -> не желания связываться с этой темой дальше.
Для мейнфрейма не было столь легкого доступа как нынче с виртуалками/эмуляторами/облаками.
То есть доступ к мейнфреймам «испокон веков» всякий удаленный/терминальный имелся. Но не так чтобы он был легко доступным/массовым и более-менее полноценным.
На современном x86 это уже последние годы как есть.
На ARM не вижу причин чтобы не сделали.
agarus
25.02.2019 23:08Возьмём старую добрую малинку(raspberry pi).
…
Пожалуй на всё можно ответить нет.
И это мы говорим про плату, которая очень сильно толкнула развитие ARM для домашнего пользователя/разработчика.
Скорее для DIY-щиков толкнула ARM. Поэтому вы и получили исключительно отрицательные ответы на ваши вопросы домашнего пользователя к железячке, которая продалась миллионными тиражами. Задавайте вопросы DIY-селфщика — получите положительные ответы :)
VerdOrr
26.02.2019 01:55+2
- AppliedMicro® X-Gene1® processor (ARMv8, 8 cores, 2.4 GHz)
- 8 x ECC UDIMM DDR3 DIMM slots
- 2 x 10GbE SFP+ LAN ports
- 2 x GbE LAN ports (Marvell® 88E1512)
- 4 x SATA III 6Gb/s
a5b
26.02.2019 09:29Не знаете, по какой цене это продавалось и насколько доступно?
Нашел рассказ о сборке ПК на базе Gigabyte MP30-AR1
http://chezphil.org/rwanda/
"In fact this is the worst-documented processor I've ever had to use.… This board's greatest strength is that it actually exists. There are plenty of "vapourware" alternatives — for example, at least three based on AMD's non-existent ARM64 server chip — but I just gave up waiting for them."
Тесты — https://openbenchmarking.org/s/GIGABYTE%20MP30-AR0%20v01234567
https://news.ycombinator.com/item?id=12158463 "it's using the relatively ancient X-gene 1 chip, it doesn't come with SBSA/SBBR out of the box (although it is installable), it's expensive."beeruser
26.02.2019 13:01Конкретно эта плата продавалась за $1000.
X-Gene1 должен был быть первым ARMv8 чипом, однако не стал таковым.
(не)Первый блин вышел комом — тормозной и нет совместимости со стандартами.UNIm95
26.02.2019 15:12Не знал об этой плате.
Так же я хотел бы заметить что это одна плата.
Вроде бы других нет.
Да и ты сам указал что она тормозная.
VerdOrr
26.02.2019 17:12Сейчас в наличии нигде не увидел. Про цену уже написали.
Опять же, в прошлом за $600 продавалась еще вот такая железяка —
- AMD® Opteron™ A1100 SoC (4 x ARM Cortex-A57 cores)
- 2 x RDIMMs with 8 GB of DDR4 DRAM (expandable to 64GB)
- 2 x USB 3.0 Host Ports
- 1 x USB 3.0 Device Port
- 2 x SATA 3.0 Ports
- 1 x 1GBase-T Ethernet
- Standard UEFI boot environment
beeruser
26.02.2019 13:02Эту плату лет 5 как сняли с продаж.
VerdOrr
26.02.2019 17:01Значит фраза...
Вот и с ARM ничего не будет.
… опоздала, минимум, на тот же срок.
Пока ARM не выпустит классическую материнку ATX формата с наборной оперативкой, PCIE, SATA и так далее.khim
26.02.2019 18:40+1Нет, она не опоздала. Просто требование выпустить подобную плату — необходимое, но далекоооо не достаточное…
gendzo
26.02.2019 08:50Для разработки под ARM не нужно компилировать конкретно на ARM машине. Просто используется компилятор под эту архитектуру. Это называется — кросс-компиляция. Собственно контроллер используется лишь для запуска ПО.
Я разрабатываю на ARM на обычной x86 машине под Debian в виртуалке. Не так давно, ради эксперимента, наши дотнетчики собрали .NetCore хелловорлд для ARM платки на своих виндовых машинах вообще почти ничего не зная про линукс и просто выбрав нужные пункты в студии.alexr64
26.02.2019 12:42А с коркой и не должно быть проблем, кроме принудительного использования интринсиков.
khim
26.02.2019 13:27Для разработки под ARM не нужно компилировать конкретно на ARM машине. Просто используется компилятор под эту архитектуру. Это называется — кросс-компиляция.
Кросс-компиляция — известная вещь, вот только натив — удобнее.
Если у вас выбора особо нет (скажем почти все смартфоны — они под ARM), то да — вы будете заморачиваться. А если выбор есть — выберите натив.
VolCh
27.02.2019 13:54Речь как раз о том, что очень большие преимущества должны быть у среды исполнения, чтобы заниматься разработкой в одной среде, а запускать (прежде всего в тестовых целях самим разработчиком) в другой.
shell4692
25.02.2019 17:33+2Современному программисту необязательно знать, как работает TCP/IP, чтобы написать веб-приложение.
Вот не могу согласиться с подобным утверждением. Программист должен иметь представление, как работают механизмы, которые он использует. Потому как понимание механизма работы (например) TCP/IP позволит принять во внимание фрагментацию пакетов, маршрутизацию, MTU и другие особенности.javamain
25.02.2019 17:51там есть структура sk_buff которая хранит данные переданные в сокет и заголовки транспортного, сетевого и канального уровня. Фрагментация пакетов происходит на самом нижнем уровне (неприменно при передаче на сетевую карту). Вот статья по сетевому стеку в линукс.
DSolodukhin
25.02.2019 17:53Программист должен
Кому должен?
фрагментацию пакетов, маршрутизацию, MTU и другие особенности
Насколько это необходимо, чтобы парой «магических» команд в консоли поднять простенький сайт на той же джанге? Нет, поймите меня правильно, я согласен с вами, что знание своего инструмента — это полезный навык для любого специалиста, не важно, говорим мы о программисте или сварщике. Но сегодня это сакральное знание не является необходимым, чтобы делать сайты на каком-нибудь вордпрессе.gecube
25.02.2019 18:29-2Проблема в том, что если делать серьезный проект, то не глубокое знание, но хотя бы готовность с этими MTU бороться — нужна. И, да, я сталкивался с кейсами, когда требовалось изучение проблемы и иногда тот же MTU стрелял и был причиной.
С другой стороны, если проект несерьезный, то Вы идете на хостинг типа tilda или wordpress, возможно, что даже с бесплатным тарифом, и запиливаете свой сайт там.
Итог — эти девбоксы на АРМе никому не нужны.
Irker
25.02.2019 20:00+3Если проект серьезный, то у вас будут отдельно обученные люди, которые либо сами разберутся, либо помогут программистам разобраться и понять проблему. Однако это не отменяет того, что желательно всем участникам процесса хотя бы минимально понимать смежные области.
mishutka_ua
26.02.2019 08:47Ну если проект серьезный, то у вас будет Software Architect, который в этом уже когда-то разобрался и исключит вот
этот колхоз после релизаэтопомогут программистам разобраться и понять проблему
на этапе планирования. И поможет отдельно обученным программистам не портить себе конечности из огнестрельного оружия. Возможно и качественные параметры улучшатся. Однако это не отменяет того, что желательно всем участникам процесса хотя бы минимально понимать смежные области. Но это только мое мнение. Или не только, не знаю.
RPG18
26.02.2019 11:32Нормальный Software Architect ничего исключать не будет, а будет запускать прототипы и проводить тесты. И не забывайте про волшебную формулу
Прибыль = Доходы ? Затраты
Уменьшаем затраты на сервера и системы охлаждения, увеличиваем прибыль.
Oldster
26.02.2019 10:51+1К сожалению, часто сталкиваюсь с программистами, которые не знают и не понимают, как работает компьютер, и почему его программа "не работает". В чем разница между 127.0.0.1 и 0.0.0.0, что такое DNS. Абстракции это хорошо, но знать базовые вещи НЕОБХОДИМО.
Beyondtheclouds
26.02.2019 17:53+1В целом полезно для определении «базовых» знаний отталкиваться от задачи, а не от собственного багажа знаний.
Например у человека который меньше связан с сетью, и больше с разработкой компиляторов «базовые» знания будут совсем другие. Следуя вашей вы вероятно будете считать друг друга «людьми которые не знают и не понимают, как работает компьютер» что не очень хорошо влияет на продуктивность :)Oldster
26.02.2019 22:36Я наверное не совсем правильно выразился, при своём примере. Речь шла о том, что программист при запуске своего Web-приложения, утверждал, что оно у него на его рабочей станции работает, а другие не могут подключится к его приложению. Как выяснилось через пару минут, приложение было запущено на 127.0.0.1, как только перевесили на 0.0.0.0, все заработало. При этом он был уверен, что это одно и тоже, "ведь у него работает".
Конечно, у каждого есть свои нюансы в программировании и работе, кто то компилятор пишет, кто то сайты на друпале или ещё что то, но базовые вещи надо знать.
А то по наберут по объявлению… (С) не помню :)
rzerda
25.02.2019 17:56Так и я не могу согласиться, и много кто ещё, но программисты уже массово не имеют представления, как компьютер работает, потому что абстракции над абстракциями везде. Да и не видны эффекты от этой же фрагментации почти нигде за пределами топ-100 сайтов рунета.
RPG18
25.02.2019 17:43Векторные инструкции. Разработчикам баз данных, интерпретаторов и виртуальных машин, библиотек придется поддерживать еще одну платформу. А для этого нужны девкиты. О чем собственно Торвальдс и говорит. А то может получится, что у разработчика на его рабочем x86 все прекрасно работает, а на ARM тормозит.
trix
25.02.2019 18:12+3Даже разрабатывая на яве можно столкнуться с багами в коде, которые воспроизводятся только на арм-архитектуре. Там есть отличия в плане memory barriers, которые бывают критичны в многопоточке (а ядер на армах обычно много)
tbl
25.02.2019 18:50+2Если на какой-то платформе нарушена jmm, то это бага связки jvm-платформа, и, если платформа не позволяет это красиво пофиксить, то втыкают костыли в jvm.
fRoStBiT
25.02.2019 20:04+2Дело в том, что некоторые платформы дают больше гарантий, чем обещает JMM. И как итог, разработчики тестят на своих x86 и всё норм. А потом деплой на ARM и фантомные баги.
Баг в пользовательском коде (нарушение JMM), вот только на x86 этого может быть не видно.
farewell
26.02.2019 11:09+1Старому зануде Пингвинусу лишь бы погундеть.
АРМ хорошо, потому что недорого, а значит — в перспективе, массово. А все эти забубеные хрени, о которых он говорит, на 99% решаются разными уровнями абстракции.RPG18
26.02.2019 11:36АРМ хорошо, потому что недорого
Рановато пока об этом говорить. Процессора пока нет и ценника мы не знаем
farewell
26.02.2019 11:38Ну, чудес на свете не бывает, ARM достаточно последователен, гнёт свою линию не первый год.
x67
26.02.2019 14:23Гнет то гнет, но недавно хажавался целью поднять свой максимально дешевый впн. Целенаправленно искал сервера на арме, но везде х86 оказался дешевле или имел такие преимущества, за которые совсем не жалко переплатить.
farewell
26.02.2019 15:13Ну, просто пока что мало таких решений.
Но вот я, например, не видел ни одного смартфона на x86. Зато на ARM их пруд пруди. Мне кажется, это потому что смартфоны не отягощены «железным» наследием Intel, как компьютеры (и серверы, в частности).
Думаю, в конце концов ARM либо подвинет, либо вытеснит X86. Дело времени.vaslobas
26.02.2019 15:44Было достаточно много смартфонов на intel atom когда интел пытался залезть в эту нишу. Потом поняли, что поезд ушел и бросили эту затею.
vlivyur
26.02.2019 17:13ASUS Zenfone — внутри Intel z-какой-то, обычный телефончик, ничего выдающегося. Но себе больше не куплю (хотя тут наверно больше заслуга самих ASUS). Планшеты на z-каких-то всё ещё выпускают.
Grox
27.02.2019 13:24У меня был. Тут скорее заслуга их обоих. Asus ругались на Intel по части сложности сотрудничества. И какие-то из российских разработчиков тоже, что даже инфу о доступности и ценах процессора получить было сложно.
xPomaHx
26.02.2019 19:41Разве раньше нужно было знать как работает тсп? он аппаратно инкапсулирован, а нам предоставляется только интерфейс в виде сокета.
По моему даже если пишешь драйвер для сетевой карты, тебе все равно нечего с ним не сделать.
old_bear
25.02.2019 17:37Redis, который сам по себе является низкоуровневым кодом, спокойно работает на ARM, все тесты проходят, и нет никаких проблем со стабильностью. А раз уж код, написанный на C
Простите великодушно, но с этого места я начал смеяться. Наверное, у меня уже необратимо тяжёлая профессиональная деформация.
P.S. Чтобы не быть неправильно понятым. Я немало кода написал на взаправду низкоуровневом asm-е, в том числе под ARM с активным использованием NEON-а (это его SIMD-ы). И этот код, мягко говоря, не тот же самый, что для AVX и иже с ним. И вот, читая первое предложение из приведённой выше цитаты, я даже затаил дыхание в ожидании откровений на тему непринуждённой поддержки двух разных наборов инструкций в низкоуровневом коде. Но дочитав второе предложение до того места, где обрывается цитата, не смог сдержаться.gecube
25.02.2019 18:30+5Полностью согласен. Это тот самый редис, который долго не умел нормально работать в кластеризованном режиме, согласно Jepsen-тестам. Молодцы, а чо?
RNZ
26.02.2019 12:03Он и сейчас нормально не кластеризуется. И вообще эта недософтина полностью игнорирует архитектуру многоядерных ЦПУ утилизируя только одно ядро и выедая с его помощью кеши так, что рядом ничего толком не может крутиться.
gecube
26.02.2019 17:28ну, это не плохо и не хорошо. Просто данность. Тот же node.js однопоточный. golang — он тоже в первую очередь на одном процессоре, предлагая кооперативную многозадачность. Это сейчас тренд такой.
И даже если взять многопоточный софт, например, nginx — все равно требуется настраивать кол-во потоков (workers X) под конкретную нагрузку.playnet
26.02.2019 19:16nginx — worker_processes auto;
обычно этого вполне достаточно.gecube
26.02.2019 19:31это криво работает с cgroups, например.
github.com/nginxinc/docker-nginx/issues/31
второй комментарий
trac.nginx.org/nginx/ticket/1151
Патчи реджектнули… Хады!
xPomaHx
26.02.2019 19:46Да вроде не тренд, просто было бы странно если бы софт магическим образом работал на несколько ядер, ну а интерфейсы потоков представляют все топ яп, так что я хз зачем вообще везде пишут что нода однопоточна.
RNZ
26.02.2019 23:20+1Вы попутали.
nodejs — eventloop для сокетов и нормальным образом создаёт thread per worker.
golang — см. runtime.GOMAXPROCS()
Redis все запросы лопатит в одном thread, т.е. вообще в одном, причём этот один thread является main процессом. Ещё три thread'а, служебные (сброс на диск, лог...). Этот же main и моет CPU-кеш так, что всем остальным процессам в системе просто приходится курить, ну или начать конкурировать роняя производительность этого «супер-пупер-дупер быстрого» Redis в пол вместе с ростом латентности в потолок. Т.е. настроить его под нагрузку толком нельзя, кроме как запустить по redis'у на сервер и воткнуть перед ними какой-нибудь twemproxy, при этом это всё адский оверхед по железу и выглядит всё как костыль на костыле.gecube
26.02.2019 23:27Я-то как раз ничего не попутал.
Асинхронщина и eventloop не отменяет однопоточности. Собственно, какая разница для нас сколько потоков, если они все блокируются на i/o?
golang — см. runtime.GOMAXPROCS()
Спасибо, я в курсе. Но это не отменяет того факта, что goroutine — это кооперативная многозадачность, а треды — вытесняющая. В этом отношении голанг несомненно хорош, что предоставляет некую гибридную модель.
Т.е. настроить его под нагрузку толком нельзя, кроме как запустить по redis'у на сервер
ну, норм вариант — ставить на один сервер несколько редисов, не?
при этом это всё адский оверхед по железу и выглядит всё как костыль на костыле.
соглашусь. Выглядит как костыль. Поэтому в своих проектах используем aerospike — он реально как (на старом сайте был какой-то ракетный движ изображен) ракета.RNZ
26.02.2019 23:47Субъективно, Вы всё попутали )
Причём тут отмена однопоточности? Речь о производительности.
io — который сейчас очень быстрый или aio — когда у тебя ssd хранилище на 1млн iops, а redis упёрся в потолок производительности одного ядра процессора при загрузке по io <1%.
> ну, норм вариант — ставить на один сервер несколько редисов, не?
Если нагрузки нет, можно хоть по пять redis'ов на ядро процессора.
НО когда есть нагрузка, то хоть у процессора и 128 ядер, а кеш (LLC) один и его когерентность выходит боком, когда redis активно задрачивает кеш в один thread на максимуме
0xd34df00d
25.02.2019 20:34Я немало кода написал на взаправду низкоуровневом asm-е, в том числе под ARM с активным использованием NEON-а (это его SIMD-ы).
О, супер, вам немножко оффтопик-вопрос тогда. Предположим, у меня есть некоторый код на плюсах, в котором есть SSSE3/AVX2-варианты некоторых функций. Охота добавить и Neon-варианты (в первую очередь чтобы поиграться, конечно). ARM-железа у меня нет (мобильники не в счёт). Как продвинутые люди в этом случае
- проверяют корректность работы кода (скажем, хотя бы просто прогоняя тесты),
- оценивают ускорение от использования SIMD?
Для первого, наверное, и qemu сойдёт. А что делать для второго?
khim
25.02.2019 21:08Лучшее, что можно сделать сегодня (если нет денег на упоминавшийся тут уже Thunder X2) — купить Chromebook.
Мерять скорость на мобильнике — это себя не любить, там троттлинг начинается через пару секунд 100% загрузки одного ядра. А вот ChromeBook — он достаточно большой, чтобы на одном ядре можно было уже гонять бенчмарки без троттлига. А многопоточка — она и на «больших» процессорах и серверах скорость одного ядра ограничивает, так что разницы нету…0xd34df00d
27.02.2019 01:32+1Просто немножко жаба душит покупать ещё что-то для своего хобби-опенсорса всякого. А была бы возможность арендовать какой-то сервер где-то в облаке с ssh туда пусть даже за бакс в час, скажем, было бы супер.
Но это, опять же, к словам о возможности разработчикам поиграться с архитектурой.
PS. О, ниже ссылку на AWS дали, ништяк, ровно то, что нужно!khim
27.02.2019 02:21А смысл во всём этом, извините? Бенчмарки на виртуалке запускать в любом случае странно, а если не мерить скорость — то любой сотовый имеет сегодня такой же NEON, как и все эти серверные процессоры на AWS…
old_bear
26.02.2019 02:39ARM-железа у меня нет (мобильники не в счёт)
Во всех случаях у меня целевая платформа была как раз мобильная (+ близкие к ней smart box-ы) поэтому в качестве тестового железа я использовал какую-то мелкую плату разработчика (за давностью лет не помню, какую конкретно) и различные смартфоны (всё это богатство было подключено к Дженкинсу и настроено умными людьми ещё до меня). Позже тестировал свой код на iPad-е, начиная с тех версий где завезли поддержку ARMv8 (+ mac-mini в качестве платформы для разработки).
Для проверки корректности работы кода в обоих случаях я использовал unit test-ы, в которых верхний уровень был написан не мной. Логику непосредственно проверки я писал сам (я знаю, что это не совсем правильно, но я очень старался не давать своему коду поблажек в плане разнообразия тестовых воздействий). Ну и конечно, были regression-тесты в боевом приложении.
Ускорение оценивалось разными способами. Во первых, банальным измерением времени работы многократно запускаемой оптимизированной функции (в unit test-е). Ключевым моментом является именно многократность — когда количество запусков такое, что тест бежит несколько минут, можно отследить эффект даже от замены единичной asm-инструкции на другую. Во вторых, профилирование в Xcode для случая с iPad-ом. Ну и, в третьих, итоговый эффект оценивался измерением fps-ов в боевом приложении.
P.S. Кстати, о тротлинге. А этом отношении комрад khim прав. На мобильных устройствах с нагревом тяжко. Мы колхозили дополнительное охлаждение и к платам разработчика и мобильным девайсам. Были даже мысли обзавестись холодильником для этих целей. :) А вот iPad на удивление такой проблемой практически не страдал. Возможно за счёт размера.
vba
25.02.2019 18:18-10Тем не менее, создатель Linux Линус Торвальдс скептично прокомментировал анонс.
Прокомментировал? Да он же опять всех идиотами и дебилами обозвал. Эх, талантливый человек, но полностью бестактный.
xfaetas
25.02.2019 18:27-15Собственно не совсем понятно, откуда такие понты, ведь 99% вклада в Linux сделано сообществом, а не им лично — он просто вовремя появился со своим свободным вариантом UNIX-ядра, которое, впрочем, ничем особенным в техническом плане не отличалось.
bzzz00
25.02.2019 18:54+14суметь организовать миллион гиков — это очень и очень круто. гики (в хорошем смысле) восприимчивы к техническим аргументам. и вот Торвальдс до того хорош по части технической аргументации, что справляется с ними… ну или справлялся (я перестал следить).
Alexey2005
25.02.2019 21:13+4Дано: Вы известная IT-компания. Линус послал вас далеко и надолго.
Решений собственно два:
1 (со звёздочкой) — выделить из его посылов рациональное зерно и учесть в работе, потому что такой человек зря воздух сотрясать не будет.
2 (не требует мыслительных усилий) — выделить из его посылов все факи и скинуть их ближайшему SJW-отряду быстрого реагирования, который уже разберётся с негодяем по-свойски.
arheops
25.02.2019 18:33+3На самом деле все упирается в стоимость.
Если, например, Amazon EC2 и гугл предложат сопоставимые по производительности ARM конфигурации с ценой в два раза меньше x86 — народ подтянется, никуда не денутся.
Другой вопрос, что пока все не столь радужно с ценой этих решений.xaoc80
25.02.2019 18:56+1Если, например, Amazon EC2 и гугл предложат сопоставимые по производительности ARM конфигурации с ценой в два раза меньше x86 — народ подтянется, никуда не денутся.
Простите, а откуда появится цена в два раза меньше x86?
Глянул цену современных ARMов, которые потенциально можно использовать в серверах, так она не такая уж и радужная.
А остальное железо — память, диски, набор логики стоят столько же
Экономия на электроэнергии?
Так ведь и здесь не все так однозначно получается, если TDP сравниватьarheops
25.02.2019 19:03Может. Для задач нечувствительных к операциям с плавающей точкой.
Ну те же веб приложения и базы данных.
Просто за счет того, что сильно больше ядер и больше эффективность на единицу площади и на ватт.
Но пока не сильно видно.
ТДП очень хитрая характеристика. У интел в последнее время — очень хитрая. Во всяком случае на нагруженных серверах потребление сильно выше их ТДП с учетом памяти, диска и всего остальное.
bzzz00
25.02.2019 18:58+1а почему оно должно стать в 2 раза меньше? я вообще пока не очень понимаю смысл всей это попеи с ARM. когда на телефон ставят ARM вместо x86 — это понятно, масштабирование вниз, производительность не нужна, нужно батарейку беречь и для idle можно добавить совсем уж медленно ядрышко. а в облаках такой проблемы нет, там загрузку по необходимости можно добавить, спасибо виртуализации. там как раз нужно масштабирование вверх.
если вдруг у ARM будет значительно ниже цена в пересчете на какую-то полезную операцию — тогда может быть. но откуда? другая физика? другие материалы? частоты там близкие сейчас…gecube
25.02.2019 19:00+1если вдруг у ARM будет значительно ниже цена в пересчете на какую-то полезную операцию — тогда может быть. но откуда? другая физика? другие материалы? частоты там близкие сейчас…
оптимизация на уровне кода? оптимальность структуры команд с одинаковой длиной (или ARM, как и x86, имеет переменную длину команд?)bzzz00
25.02.2019 19:07+1транслятор в uops — это мизерная часть, насколько я понимаю. много на нем не сэкономишь.
khim
25.02.2019 19:22Зависит от остального. Если у вас большое, сложное и горячее ядро под максимальную скорость в однопоточке — то нет. А вот если у вас сотня простых и мелких ядер — то легко.
Но не всякую архитектуру на такую конструкцию портирует…bzzz00
25.02.2019 19:24и почему все это сотня простых и мелких не может эксплуатировать несколько «крепких» ядер?
khim
25.02.2019 19:29-3Потому что в тепловой пакет сотни простых и мелких ARM-ядер на 1GHz влезет одно скоростное ядро на 4GHz от Intel — которое по скорости их явно не догонит.
Вот только программисты не умеют писать софт под 100 мелких и простых ядер — а под одно скоростное — умеют. И вот пока эту проблему не решат — ARM на сервере будет «сливать»…
Sdima1357
25.02.2019 19:52+3Вот только программисты не умеют писать софт под 100 мелких и простых ядер
Программисты-то умеют. Задачи не все раскладываются на 100+ ядер…
en.wikipedia.org/wiki/Amdahl%27s_lawkhim
25.02.2019 21:01-2Нет — программисты именно что не умеют. Амдал — он, конечно, велик и могуч, но он не объясняет как вообще система с процессором не то на 100Hz, не то на 1000Hz под кодовым называнием «Home Sapiens» может вообще решать большинство задач, с которыми она сталкивается.
Я думаю на 99% проблема с «принципиальной нераспараллеливаемостью» тех задач, которые решаются на современных компьютерах связана не с тем, что задачи, связанные с реальным миром (ну там «переслать видео из точки А в точку Б» или «подрисовать на фотографии усы») состоят из непараллелящихся подзадач (которые портят нам «всю малину»), а потому, что вся компьютерная индустрия последние полвека занималась тем, что алгоритмы, требующие десятков, сотен, а то и миллионов «ядер» — выкидывала в мусорную корзину и тщательно отбирала лишь такие, которые могут эффективно работать на одном однопоточном ядре.
Потому и потребуется для изменения не год, не два, а десятилетия. Но выхода, по большому счёту, нет: за последние 10 лет производительность одного ядра выросла, дай бог, вдвое (притом что производительность всяких GPU/TPU выросла в десятки и сотни раз), так что выбора у нас нет, нужно брать вышеупомянутую «корзину» и смотреть чего там найдётся… но для этого нужно, чтобы всякие Knight Mill'ы и тому подобные звери были не только на суперкомпьтерах, но и на столах у разработчиков…Sdima1357
25.02.2019 22:02+1Все таки не всегда получается. Я вот как раз в основном на GPU и пишу с 2005 года (реконструкция CT images, собственно первая на GPU, GE Medical, примерно половина сканеров в мире ), так что сталкиваюсь регулярно, что то раскидывается, а что то нет.
Пример из другой области, более понятный:
Работу не всегда можно раскидать по произвольно большой группе людей. Тот же закон Амдала и тут работает. Девять женщин ребенка за месяц не родят…
Не все распараллеливается (:
PS: Если Вы знаете как распределить произвольный алгоритм, напишите статью, сможете получить несколько нобелевских или что там еще. Впрочем, насколько мне известно формального доказательства принципиальной невозможности распараллеливания нет. Так что карты в руки. И извиняюсь за наезд, это не лично к Вам, просто начальство достало ровно с Вашими аргументами.khim
25.02.2019 23:19-2Все таки не всегда получается.
Я бы сказал так: не всегда получается на GPU. А у GPU — архитектура очень, как бы сказать, специфическая. Она под очень узкий класс алгоритмов заточена. Что и как можно делать, чтобы параллелить, условного говоря, GUI — мы не знаем.
Гораздо хуже, впрочем, то, что мы разработали сами для себя кучу ограничений, которые вполне могут обозначать, что часть задач, которые мы сами себе придумали — не параллелятся в принципе.
Или, условно говоря, задача «добавить блок редактирования на web-страничке» — вполне может параллелиться, а вот задача «отреагировать на изменение DOM-дерева в соответствии со спецификациями HTML и CSS» — уже нет.
И мы не знаем на какую глубину нам придётся разбирать здание IT, перед тем, как мы сможем его перестроить под новую парадигму… а главное — последние лет 10 мы загоняем себя всё глубже и глубже в тупик, выбираться из которого будет ой как непросто: почти все последние разработки по-прежнему рассчитаны на одно обченно-обченно быстрое ядро, а не на сотню параллельно работающих объектов…Sdima1357
25.02.2019 23:49+1В реконструкции работа как раз раскидана и на GPU и на все свободные ядра CPU (кроме псевдоядра собственно контролирующего GPU /GPUs ), и до появления GPU картинка тоже как то восстанавливалась у нас. Несмотря на то что разрабатываемые алгоритмы весьма хорошо параллелятся все равно где нибудь да упрешься или в шину или ещё куда нибудь. Амдал работает, гад. Поговорите с людьми пишущими на FPGA, они Вам объяснят стоимость распаралелливания хотя бы простых арифметических операций
mk2
25.02.2019 22:18Человек — это скорее FPGA. Мозг сильно заточен под распознавание лиц людей, например, поэтому именно с этим проблем нет. Нетривиальная логика — тоже есть. То есть те функции, на которые миллионы лет оптимизировала эволюция. А попробуйте перемножить два int32 числа, или удержать в памяти с сотню байт — у вас это получится намного хуже, чем даже у 100гц компьютеров.
Касательно «выкидывания в корзину» параллельных алгоритмов — это вы сейчас странное сказали. Любой параллельный алгоритм может быть выполнен последовательно. Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени. Другое дело, что задача создавать параллелизуемые алгоритмы сама по себе не ставилась. Но они и менее эффективны в целом, и требуют затрат на синхронизацию, и для понимания сложнее, так что до недавнего времени не были так востребованы.
Ну и не стоит останавливаться только на параллельности. Можно развивать FPGA и делать хорошие конвейеры. Возможно, в будущем у процессоров или отдельно по PCI будет несколько FPGA массивов, и высокопроизводительные приложения будут их использовать, как сейчас видеокарты.khim
25.02.2019 23:01-1А попробуйте перемножить два int32 числа, или удержать в памяти с сотню байт — у вас это получится намного хуже, чем даже у 100гц компьютеров.
Обычный человек на это неспособен (как вы верно заметили — «прошивка» не та), но соотвествующие номера в цирке демонстрировались — то есть в принципе мозг на это способен. А 100Гц компьютеров в природе не бывает: уже ЭНИАК — это 10кГц (но один процессор!)… С него всё и пошло.
Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени.
Может и почти всегда будет. Опять-таки, вернёмся к мозгу: «частота» — меньше килогерца, но общее количество операций, выполняемых в ту же секунду… суперкомпьютеры [пока] отдыхают. То есть плата за «широкую» параллелизацию — это увеличение общего количества операций на несколько порядков.
Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени.
С чего вы взяли? Наоборот, как правило хорошо параллелящиеся алгоритмы требуют больше (часто сильно больше) операций. Если исполнять их последовательно — получим проигрыш.
Можно развивать FPGA и делать хорошие конвейеры. Возможно, в будущем у процессоров или отдельно по PCI будет несколько FPGA массивов, и высокопроизводительные приложения будут их использовать, как сейчас видеокарты.
Это всё лирика. Главная проблема, которая заставляет нас использовать процессоры на много гигагерц — это фабрики фабрик фабрик, которые превращают любое простое действие в последовательное взаимодействие сотен объектов. И тут уже пресловутый «закон Амдала» встаёт в полный рост: если вам, чтобы принять решение, нужно передать данные через сто посредников — то вы можете делать это последовательно или параллельно, синхронно или асинхронно, на одном ядре или на сотне… но пока все сто обрабочиков последовательно не отработают — ответа вы не получите.
И что с этим делать — не знает никто. Известно только, что человек — так не работает. От момента, когда вы видите улыбающегося младенца до момента, когда вы улыбатесь ему в ответ не проходит достаточно времени для того, чтобы цепочка из хотя бы нескольких сотен нейронов успела сработать. Всё поведение основано на цепочках, которые гораздо короче, чем цепочка связанных объектов, отрабатывающих клики при наборе текста на вот этой вот страничке Хабра.
Не будете же вы утверждать, что страничка Хабра — это более сложная вещь, чем человек?
Где-то мы свернули «не туда» в дизайне компьютерных систем… но пока неясно как это исправить…mk2
25.02.2019 23:47С чего вы взяли? Наоборот, как правило хорошо параллелящиеся алгоритмы требуют больше (часто сильно больше) операций.
Тут извиняюсь, ошибся. Хотел написать «хуже».
Всё поведение основано на цепочках, которые гораздо короче, чем цепочка связанных объектов, отрабатывающих клики при наборе текста на вот этой вот страничке Хабра.
С другой стороны, у поведения имеется огромное количество когнитивных погрешностей, которые возникли именно из-за этой оптимизации. Представьте, что вы сотню лет пишете и переписываете код этой странички. Естественно, за это время вы успеете перепробовать тонну подходов, выучите или создадите ассемблер и напишете на нём. И это будет дико эффективно.
Где-то мы свернули «не туда» в дизайне компьютерных систем
Если у нас были кубики «О», «П», «А» и «Ж» — мы не могли сложить «Вечность». Всем требуется выпускать продукты «быстрее, ещё быстрее». А написать быстро, без ошибок и производительное — выберите два, как говорится.
bzzz00
25.02.2019 20:12-2вот нашел такое от ARM:
По оценке ARM, работая на частоте 3 ГГц, процессор на базе Cortex-A76 по производительности будет сравним с процессором Intel Core i5-7300U, работающим на частоте до 3,5 ГГц. При этом TDP процессора Intel составляет 15 Вт, а TDP процессора ARM — 5 Вт.
если 3.5 уменьшить до 3 и перейти от категории «сравним» к производительности/ватт, то думаю никаких 100x 1GHz = 4 GHz и близко не будут. а буду вполне «сравнимые» значения. но это спекуляция, конечно.
а вот про возможность любую задачу распараллелить на множество независимых — это огромное преувеличение. я по работе постоянно с подобными сталкиваюсь. и вполне обоснованно могу утрвеждать, что:
1) при увеличении кол-ва «голов» расходы на синхронизацию растут нелинейно (очень часто)
2) работа по разработке/доводке таких решений стоит немалых денег и не масштабируется (в отличие от железок, которых можно наклепать сколько угодно)khim
25.02.2019 20:50-2Для того, чтобы не попадать пальцем в небо по поводу энегропотребления рекомендбую прочитать про big.LTTLE и задуматься над вопросом: «а нафига в современных смартфонах 8 ядер, если работать одновременно могут только 4».
Что касается распараллеливания — то, опять-таки, рекомендую вспомнить, что в голове у человека «процессор» на частоту ниже одного килогерца (хотя и с миллиардами активных компонент) — если бы реальных задач, которые плохо параллелялятся было бы много, то человечество давным-давно бы вымерло.
Другое дело, что все программистские тулы, средства разработки, отладки и прочего — рассчитаны на однопоточный или, в крайнем случае, на малопоточный код и справиться с сотнями и тысячами «голов» просто не могут. Но тут как раз проблема курицы и яйца: пока у нас на рабочих стоят компьютеры не с сотнями-тысячами ядер по 1GHz, а с 4-6-8 по 4GHz — мы над всем этим задумываться не будем, а пока у нас нет библиотек под такое железо нам на подобных серверах — нечего запускать.bzzz00
25.02.2019 20:52это большая наивность — думать, что параллельное программирование не развивается из-за гигагерцев на десктопах. тысячи (сотни тысяч) ядер давно уже есть — загляните на top500.org. как давно есть много тулзей и программистов и что там еще нужно.
khim
25.02.2019 21:02И как много программистов имеют доступ к компьютерам из Top500?
bzzz00
25.02.2019 21:03немало. они же на них не работают постоянно. отлаживаются на простых системах, потом тестируют на системах побольше и так далее. но это не главное. главное, что изначально задачи ставятся работать в масштабе сотен тысяч — миллионов ядер.
khim
25.02.2019 21:16Немало — это какой процент от 20 миллионов разработчиков, которые существуют? Сомневаюсь я что больше 1-2% что-то…
Так что да: ниша, где люди гоняют сильно параллелящиеся задачи — да, она есть, она существует, но если сравнить её с количеством людей, порождающих что-то на принципиально однопоточном JS… она всё ещё очень и очень мала…bzzz00
25.02.2019 21:33зато процент головастых там значительно выше. ТО взяли не кол-вом.
khim
25.02.2019 21:41Это неважно. Пока массовые разработчики будут использовать JS и Node.JS — на серверах будет рулить однопоток.
То есть да, то, что технологии разрабатываются на суперкомпьютерах и потом «спускаются» в персоналки — это всегда так было (и с суперскалярностью и с SIMD'ами — это всё суперкомпьютеры лет на 10-20 раньше, чем персоналки получили), так что и с параллельными программами так же будет.
Но мы пока в начале процесса.bzzz00
25.02.2019 22:10так вот, докладываю… никаких «чудес» или суперинструментов или технологий «там» нет. нечего ждать. по-крайней мере сейчас так.
easyman
25.02.2019 22:33Смотрите, .Net core уже быстрее С!
(много ядер, современный Xeon)
www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second
Alex_ME
25.02.2019 23:17+1Для начала, какой процент от 20 миллионов разработчиков занимается разработкой сверхтяжелого научного/инженерного софта? А ведь масштабы миллионов ядер — оно для моделирования чего-нибудь.
И при чем тут Node.JS? Это несколько другие задачи. Это веб, и здесь идет параллелизм уровня запросов, а не вычислительных задач внутри него. И всякий веб, ынтырпрайз, мобильные/десктопные приложение итп (где, наверное, сосредоточена бОльшая часть разработчиков) чаще сталкиваются не с cpu-bound задачами.khim
25.02.2019 23:21И всякий веб, ынтырпрайз, мобильные/десктопные приложение итп (где, наверное, сосредоточена бОльшая часть разработчиков) чаще сталкиваются не с cpu-bound задачами.
Если бы они не были cpu-bound, то их можно было бы, условно, запустить на кластере «малинок». Однако — так «оно» не работает…
beeruser
25.02.2019 21:43+2По оценке ARM, работая на частоте 3 ГГц, процессор на базе Cortex-A76 по производительности будет сравним с процессором Intel Core i5-7300U, работающим на частоте до 3,5 ГГц.
Врут. Либо сравнивают 4 потока Интела с 4 ядрами ARM.
NiTr0_ua
25.02.2019 22:43По оценке ARM, работая на частоте 3 ГГц, процессор на базе Cortex-A76 по производительности будет сравним с процессором Intel Core i5-7300U, работающим на частоте до 3,5 ГГц. При этом TDP процессора Intel составляет 15 Вт, а TDP процессора ARM — 5 Вт.
ключевое — выделил. 3.5ггц — «трупобуст», при активации которого камушек жрет намного более заявленных 15Вт. но — недолго, до перегрева, потом — скидывает частоты до базовой 2.6ГГц, потому как
The processor base frequency is the operating point where TDP is defined
да и вообще, TDP — требование к системе охлаждения, и потребление характеризует весьма косвенно (очень легко цифрами манипулировать — указав заниженную критическую температуру по факту можно занизить TDP, т.к. СО будет спроектирована с запасом)bzzz00
25.02.2019 22:46это понятно. я в целом пытался сказать, что производительность/ватт должна быть близкая. нет смысла сравнивать 1GHz ARM и 4 GHz x86. просто потому что x86 тоже можно ограничить 1GHz, если абсолютная производительность не нужна.
khim
25.02.2019 23:09-1просто потому что x86 тоже можно ограничить 1GHz
Если вы ограничите x86 — то упрётесь в то, что одно декодирование потока инструкций займёт больше ресурсов, чем всё, что делает ядро ARM. Вспомните: ARM2 — 30 тысяч транзисторов, 80386 — 275 тысяч транзисторов. Это ещё до интеграции кешей, FPU и прочего.
Когда вы делаете «большое», «тяжёлое» ядро — эта разница вас не волнует, само ядро будет сильно больше декодера в любом случае. А вот если вы делаете сотни «малых» ядер — это отличие очень даже может выстрелить.bvbr
27.02.2019 18:11Но чудес не бывает, в общем случае (если нет явных ошибок в архитектуре и задача не узкоспециализирована)
ядро из большего количества транзисторов будет иметь больший ipc или обработает больше данных
если удельную производительность ARM поднимать до уровня x86 то энергопоребление и цена также возрастутkhim
27.02.2019 19:48если нет явных ошибок в архитектуре и задача не узкоспециализирована
Задача декодирования потока инструкций по определению узкоспециализирована.
если удельную производительность ARM поднимать до уровня x86 то энергопоребление и цена также возрастут
Совершенно верно — именно поэтому ARM'у бессмысленно соревноваться в одноядерной производительности с x86. А вот Intel'у — бесполезно пытаться пролезть в IoT.
Но вот вопрос: может ли сильно большая «производительность на ватт», которую даёт ARM, помочь ему выиграть на серверах? Ответ — зависит от программистов, очевидно.
NiTr0_ua
26.02.2019 01:09с теми же кортекс А7 х86 конкурировать в производительности на ватт никак не сможет. 90мВт на 1.3ГГц на ядро. кварки — и те больше кушали (при никакой производительности)…
arquolo
27.02.2019 18:11ключевое — выделил. 3.5ггц — «трупобуст», при активации которого камушек жрет намного более заявленных 15Вт. но — недолго, до перегрева, потом — скидывает частоты до базовой 2.6ГГц, потому как
i5-7300U на 3.5 ГГц «жрет» именно 15-20 Вт, если Ваш экземпляр ест больше, то Вам следует сделать underclocking (в среднем можно выгадать -70 мВ, или 5-7 Вт).
Мой i7-8750H (втрое больше ядер, тот же техпроцесс), на базовой частоте (2.2 ГГц) ест 15-17 Вт, а 45 Вт достигает лишь при 3.7 ГГц на все ядра.
Вот ещё пример. Заметьте 3.6 ГГц при 50 Вт на всех 6 ядрах.
Alex_ME
25.02.2019 23:24Прямо такие сотни? Я не уверен. Попытался поискать информацию, но везде SoC'и с GPU. Ну и да, идея не нова, Intel делал в свое время Intel Xeon Phi с кучей маленьких ядер. Ну и где он теперь?
khim
26.02.2019 00:33Попытался поискать информацию, но везде SoC'и с GPU.
Достаточно, чтобы сделать грубую оценку. Raspberry Pi Model B v1.2 — это 4 ядра на 900MHz. Максимальное потребление под полной нагрузкой — 4 ватта. И это — целый компьютер, с USB-хабом, подключенной клавиатурой, мышью и GPU. Плюс далеко не самый новый техпроцесс. Так что вписать ядро ARM 1GHz (причём достатоно современное — там и NEON и всё такое) в полватта — выглядит вполне реально. Может даже меньше получиться. А ядро x86 на 4GHz потребляет ватт 50 легко (даже у двухядерных моделей TDP под 100 ватт).
Intel делал в свое время Intel Xeon Phi с кучей маленьких ядер. Ну и где он теперь?
Всё ещё где-то барахтается. Но у них ядра были гигантскими: 76 ядер — 682.6 mm?… по 9 mm? на ядро. С соответствующей себестоимостью и стоимостью…Grox
26.02.2019 03:54Мой Core i5-2500K (SandyBridge, 32нм, 4 ядра х 4,3ГГц) при 100% BOINC вычислениями потребляет до 105 Ватт. Тут около 25 Ватт на ядро 2011 года.
Если загрузить чем-то вроде расчётов числа Пи для стресс теста, то потребление будет больше, но это совершенно нетипичная нагрузка.
Mad__Max
27.02.2019 04:26Присоединюсь к Grox
У меня уже кучу лет работает x86 Phenom X6. 6 штук х86 ядер @ 3.6 ГГц с потреблением 110 Вт под 100% нагрузкой всех 6 ядер (TDP 125 Вт, но реально столько не потребляет, даже с умеренным разгоном — в те времена AMD выставляла TDP c приличным запасом и крупными градациями — после 95 Вт шло сразу 125 Вт без промежуточных вариантов)
Т.е. ~18 Вт / ядро
И это по технологиям производства уже больше чем 10 летней давности (45 нм).
При этом зависимость потребления от частоты нелинейная. На той же древней архитектуре AMD еще около 10 лет назад делала и по 12-16 ядер в том же термопакете, просто скинув немного частоты и напряжения питания. Например
Opteron 6272 — 16 x86 ядер @ 2.1-3 ГГц с TDP 115 Вт (~7 Вт / ядро)
А если еще дальше частоты и напряжение скинуть, то можно было делать так
Opteron 6262 HE — 16 x86 ядер @ 1.6 — 2.9 ГГц с TDP 85 Вт (5.3 Вт / ядро)
Или например из современного серверного:
AMD EPYC 7501 = 32 x86 ядра @ 2-3 ГГц с TDP 170 Вт (5.3 Вт/ядро).
При этом даже на 1 ГГц х86 ядра в большинстве задач, кроме самых простых оказываются в 2-3 раза быстрее чем ARM @ 1 ГГц
Вся хваленая энергоэффективность ARM это примитивная формула простое (медленное/низкоэффективное, т.е. с низкой удельной скоростью/ IPC) ядро, работающее на низкой частоте при низком рабочем напряжении.
Ака «Low-Low-Low» (Low IPC+Low frequency+Low voltage)
Только в этом нет ничего уникального изобретенного ARM или продвинутого. Это общие зависимости работы современных полупроводниковых чипов. Наклепать кучу низкочастотных x86 ядер, отрезав «лишнее»(большие кэши например) и попутно снизив им рабочие напряжения до минимума и за счет этого получить близкую к ARM энергоэффектиность (только без геморроя и вопросов совместимости/миграции между разными архитектурами) — вообще не вопрос.
Были бы только подходящие задачи и платежеспособный спрос под подобную архитектуру, т.е. под формулу множество слабых, медленных, но зато энергоэффективных (в плане вычислений/Вт) ядер. А вот с этим как раз проблема — большинство конечных клиентов хотят и выбирают менее эффективные, но зато более быстрые ядра. В частности те же Оптероны из примеров выше спросом толком не пользовались — покупатели предпочитали платить больше за меньшее количество, но зато более быстрых ядер от Intel. Даже внутри одной полностью совместимой архитектуры, подход «много медленных, но зато дешевых ядер» проиграл.
А значит либо ARM не найдет существенного спроса на сервером рынке, если будет предлагаться в текущем виде, т.е. много дешевых медленных ядер. Только под специфические, нишевые решения. Либо (скорее не либо, а после п.1) ринется наращивать скорость своих ядер (IPC, рабочие частоты), но неизбежно потеряет по пути свою энергоэффективность.beeruser
27.02.2019 05:48При этом даже на 1 ГГц х86 ядра в большинстве задач, кроме самых простых оказываются в 2-3 раза быстрее чем ARM @ 1 ГГц
Уточняйте, какое ARM ядро вы имеете в виду. Их довольно и они покрывают диапазон от микроконтроллеров до серверов.
Apple A12 имеет IPC местами выше чем у Skylake (и его клонов), при весьма скромном энергопотреблении.
Наклепать кучу низкочастотных x86 ядер… — вообще не вопрос.
Гладко было на бумаге, да забыли про овраги(с). 4.5W Core-m перегревается под нагрузкой моментально и тротлится до 1GHz. Лёгкая добыча.
если будет предлагаться в текущем виде, т.е. много дешевых медленных ядер
С чего вы взяли что они медленные? ThunderX2 используется в суперкомпьютерах, например.
Grox
27.02.2019 12:50А ещё дополню, что пока медленный будет работать дольше, чем быстрый, разница в суммарном потреблении на решение одной задачи будет уменьшаться.
И ещё можно добавить экономический эффект от того, что быстрый обслужит больше клиентов и будет приносить дивиденды, пока медленный ещё продолжает обработку.
khim
27.02.2019 16:43Наклепать кучу низкочастотных x86 ядер, отрезав «лишнее»(большие кэши например) и попутно снизив им рабочие напряжения до минимума и за счет этого получить близкую к ARM энергоэффектиность (только без геморроя и вопросов совместимости/миграции между разными архитектурами) — вообще не вопрос.
Для мегагения Mad__Max — так конечно. А то у Intel что-то всю дорогу огредышащие монстры получаются. И даже когда они одно «простенькое» ядро делают — тоже: получается почему-то гораздо хуже, чем если использовать ядра ARM. Думаете в Intel процессоры разрабатывать не умеют?
Даже внутри одной полностью совместимой архитектуры, подход «много медленных, но зато дешевых ядер» проиграл.
Именно потому что внутри одной архитектуры вы не можете сделать взамен одного быстрого ядра сотню. Можно сделать 3-4, не больше. Во всяком случае Intel больше не смог. Вы, возможно, сможете…
tyomitch
25.02.2019 19:58+1Thumb имел переменную длину команд (либо 16 либо 32 бит); в AArch64 все команды длиной 32 бит.
Но в общем, «оптимизация на уровне системы команд» для потребительской платформы — это pie in the sky: для новой архитектуры можно сделать систему команд, максимально соответствующую микроархитектуре, но под эту новую архитектуру не будет софта. (Так и было в самых первых ARM.) К тому моменту, когда софта станет много, архитектура уже не будет соответствовать новым микроархитектурам, и в новых процессорах придётся реализовывать хитроумную трансляцию в uops. (По этому пути пошли и x86, и ARM.)
tgz
25.02.2019 18:54+1Давно бы перешел на арм, но серверов нет (а те что есть — днище). Ноутов на арме тоже как-то не видать.
bzzz00
25.02.2019 18:58+1зачем?
VaKU
27.02.2019 18:11Ноуты на ARM часто обладают неплохой автономностью.
Например Lenovo Yoga C630 (на Snapdragon 850), по заявлениям производителя, на одном заряде держится до 25 часов.
Для сравнения, по тестам с сайта laptopmag.com, долгожителем среди x86 ноутов является Lenovo ThinkPad T480 (Core i5-8350U), который продержался 17 часов 19 минут.
(К сожалению не нашёл сравнения производительности.)
ValdikSS
25.02.2019 20:22Если хотите серьезный сервер, то смотрите в сторону плат с ARM64, с поддержкой UEFI. Такие платы работают так же, как обычные x86-компьютеры: загружаются с флешки из обычного общего образа флешки или .iso, имеют UEFI-меню с настройками.
См. www.96boards.org/products, wiki.ubuntu.com/ARM/Server/Install
Из дешевых: libre.computersnizovtsev
25.02.2019 21:13Сервера есть, а вот приличный devbox стоит 1200$, и в России подобное не купить скорее всего. Получается, Линус пока прав.
beeruser
25.02.2019 21:33+1а вот приличный devbox стоит 1200$
Это санки запряженные саранчой.
Приличный девбокс выглядит так (от ?2255)
store.avantek.co.uk/ampere-emag-64bit-arm-workstation.html
(от ?9035)
store.avantek.co.uk/avantek-thunderx2-arm-workstation-thunderx2station.html
И это проблема (хотя Ampere несоизмеримо ближе к народу).
Недавно цена на TX2 начиналась от ?11к
beeruser
25.02.2019 21:1996 boards — помойка. Купил плату на Helio X20 за $200. Как оказалось работал там только Андроид (да я дурак, не проверил). Сейчас сайт поддержки мёртв.
Сама плата то же не ахти. Накопитель — только флешка.
Прошелся по схеме Wifi модуля — кучи компонентов не хватает (конденсаторов). И так сойдёт!
beeruser
25.02.2019 21:01>> но серверов нет (а те что есть — днище)
Вы уж определитесь «нет» или «днище».
www.gigabyte.com/ARM-Server/Cavium-ThunderX2
www.avantek.co.uk
Ноутов целых 3 есть, но их не купить, т.к. out-of-stock везде.
kikiwora
25.02.2019 21:15Плохой инструмент всё равно что его отсутсвие, а очень часто даже хуже.
Пример — отвёртка. Можно купить дешёвую китайскую отвёрку за копейки, которая после нескольких операций потеряет жало и станет бесполезной. Это не отвёртка, это хлам.khim
25.02.2019 21:20Thundex X2 «жало» не потеряет. Он вполне сравним по скорости со своими «одноклассниками» на X86 за $5000-$10000… к сожалению и по цене — тоже.
То есть в диапазон, указанный Линусом ($500-1000) он снова не попадает — только теперь уже не потому что «хлам тормозной» (как Raspberri PI), а потому что цена у него серверная… а посредине, между ними… зияет пустота.
Лучшее, что существует — это Хромбуки, но они, как бы, всё равно сильно недотягивают до рабочей станции — и по цене (что неплохо), но и по объёму памяти, SSD и прочего (а вот это — уже проблема).kikiwora
25.02.2019 21:22Ну малинка точно не является серверной машиной :)
Хотя признаюсь, сам я на ней пару простых серверов, как например, меди-сервер и бекап-сервер держу.
А так, солидарен с вами.
Хотя в данной области я не разбираюсь.
Однако я в ARM верю.
То как работает новый iPad Pro тому показатель.
Рендер сравним с полноценным топовым макбуком.
beeruser
25.02.2019 21:21Чем плохи гигабайтовские ARM серверы? Они собраны на довольно быстром ARM, который используется в нескольких суперкомпьютерах.
Shtucer
25.02.2019 19:47-1по обещаниям должно дать 60% прирост по сравнению с текущей платформой
Наконец-то! Давно ждали! Впечатляющие цифры! Остаётся понять, о чём тут идёт речь...
CyberAP
25.02.2019 21:56скорее всего на них сбросят всякую глупую чепуху, вроде фронтенда
Вот сейчас обидно было
balsoft
27.02.2019 12:22Правильно. По заветам суровых линуксоидов, «веб-макаки должны страдать». (И пофиг, что linux на самом деле и взлетел благодаря таким «веб-макакам»)
khim
27.02.2019 16:45Подавляющее большинство установок Linux — это встроенные системы, где никаких «веб-макак» и в помине нету.
К тому же код, разработанные веб-макаками исполняется в Windows на клиенте, а не на Linux-сервере.
elve
25.02.2019 22:30Ну так он эту мысль прямо с поверхности взял. Архитектура сильно другая. Под нее надо наработать кучу кода и практик, чтобы платформа реально выстрелила. Выиграть только количеством ядер не получится. При имеющемся софте мне устройства на arm кажутся менее отзывчивыми. Хотя это может быть и субъективным ощущением.
Revertis
26.02.2019 00:18Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.
Речь человека, который застрял во временах C/C++. Но ведь уже есть языки типа Rust, которые без бубна компилируются под разные архитектуры.khim
26.02.2019 00:43Но ведь уже есть языки типа Rust, которые без бубна компилируются под разные архитектуры.
Угу. Под целых 14. А под ещё десяток — не компилируется. В отличие от ядра Linux…
Речь человека, который застрял во временах C/C++.
Речь человека, программы которого работают на таком количестве архитектур, с которыми сравнивать Java или Rust просто смешно: разница не на одну-две архитектуры, а в разы (Linux — поддерживает 25-50 архитектур — смотря как считать, rust поддерживает порядка 10-15 архитектур — опять-таки смотря как считать, Java — ну где-то с полдюжины «живых» архитектур осталось).0xtcnonr
27.02.2019 18:12rust поддерживает порядка 10-15 архитектур — опять-таки смотря как считать
Rust ничего не может поддерживать — поддерживает llvm.0xtcnonr
27.02.2019 20:51+1О, уже побежали минусовать адепты раста. Но я, специально для них, поясню. Компилятор раста имеет всего один таргет — это llvm-ir, но даже его он не генерирует самостоятельно. Таким образом ни о каких 10-15, да даже о двух архитектурах речи идти не может.
Так же, даже если мы забудем об этом факте — хост-компилятор раста зависит от С/С++ кода и не может быть более портабельным, нежели С/С++-код, т.к. напрямую зависит от него.
Так же, даже в рантайме раст зависит от llvm-рантайма и libc — таким образом тут он не может быть портабельнее С/С++ т.к. напрямую зависит от них и в рантайме.khim
27.02.2019 21:04-1Я не думаю что тут минусовали «адепты раста». Скорее нелюбители занудства. И неправды. Да, настоящее время раст имеет ровно один компилятор — но это не значит, что так будет всегда. И можно себе представить и написаннаю на нём OS и его работу на «голом железе» — он достаточно низкоуровневен для этого.
Так что ваше высказывание — неверно просто по факту: да, таки раст может-таки поддерживать архитектуры, которые не умеет поддерживать LLVM — просто так получилось, что сейчас — это не так.
Всё равно что обсуждать Формулу-1 и зациклится на том, что шины у всех команд — от Pirelli. И что, дескать, они всё и определяют. Сегодня да, а завтра, может, Goodyear вернётся или Bdigestone…0xtcnonr
27.02.2019 21:22+1Да, настоящее время раст имеет ровно один компилятор — но это не значит, что так будет всегда.
Какая глупость.
Да, настоящее время с++ имеет ровно проблемы — но это не значит, что так будет всегда.
Поздравляю, вы умножили на ноль основной довод к существованию раста, который каждый день ретранслируется на хабре.
Так что ваше высказывание — неверно просто по факту
Оно верно по-факту. И вы даже не сообщили в чём именно оно неверно.
да, таки раст может-таки поддерживать архитектуры, которые не умеет поддерживать LLVM — просто так получилось, что сейчас — это не так.
Какие основания у этого утверждения?
В конечном итоге я так и не увидел основания для «неверно». К тому же, как всегда был проигнорирован основной тезис, а именно «без бубна компилируются под разные архитектуры.» — тут говорится именно о лучшей портируемости раста. Попытки вида «потом что-то будет» не работают, даже если в них поверить. Ведь он не просто должен быть портируемым на пару платформ, но и портироваться проще и шире(как минимум не уже).
Ну и конечно же, я мог бы сослаться на
без бубна компилируются под разные архитектуры
компилируются
Это настоящие время, а не фентезийное. И этого уже было достаточно для опровержения ваших рассуждений.
picul
26.02.2019 00:56+1Но ведь уже есть языки типа Rust, которые без бубна компилируются под разные архитектуры.
Слова человека, который никогда серьезно не задумывался о производительности. Не в языке дело, а в разных возможностях у разных архитектур.
Praksitel
26.02.2019 01:34-2Итак, выпускается железо, имеющее сравнимую с х86 производительность, но с гораздо меньшим энергопотреблением. Хоба — и различные регионы с плохим электричеством (Африка, Азия, какая-нибудь Сельва) — все в твоих руках!
bentall
26.02.2019 02:07Пчёлы против мёда, Линус против
линуксаARMa. Во всяком случае для Linux'ов смена архитектуры ядра должна быть наименее болезненной. Они не первыйгоддесятилетие на ARM-ах крутятся. GCC прекрасно эту архитектуру поддерживает (LLVM — тоже, хотя последний как раз конкурирующая организация поддерживает, но на серверах Apple вообще никому не конкурент). Со скриптовыми языками тоже всё неплохо. Python для «малинки» — мейнстрим, а если какой Perl для ARM специально не оптимизировали (на самом деле, как оно с перлом — не в курсе), тот уже дело соответствующего сообщества доказать, что их язык — живее всех живых (и докажут ведь). Сложно (почти невозможно) разработчику купить linux-ноут с ARM-ом внутри? Ну так с чего-то начинать надо, Linux вон до сих пор на десктопах — экзотика, а на серверах — вне конкуренции. А так, появится спрос (хочу процессор как на сервере, для которого разрабатываю), появится и какое-никакое предложение. И это будет лишний гвоздь в будущий гроб морально устаревшей, обмазанной многими слоями legacy (и вследствии этого греющей воздух) wintel-архитектуры.xaoc80
26.02.2019 10:05А что такое архитектура wintel применительно к серверам, подавляющее количество которых на Linux? Если речь про x86, то что именно морально устарело в этой архитектуре (интересут мнение касаемо технологической составляющей). Потому как по число разных технологичных штук (HT, SIMDs и т.д.) эта архитектура (и ее реализация ) не смотрится так уж бледно.
bentall
26.02.2019 11:00Слои совместимости. Которые нужны как раз для нормальн6ой работы старого проприетарного кода и на серверах не сильно требуются.
beeruser
26.02.2019 13:08Пчёлы против мёда, Линус линукса ARMa
Он не против ARM. Это критика ARM вендоров, которые замахнулись на межпланетные полёты, в то время как инженеры вытирают задницы придорожным лопухом.bentall
27.02.2019 01:11Не, если воспринимать это как крик разработчика, «не забывайте нас, дайте нам возможность приобрести приличные, по адекватной цене, домашние компьютеры с такой архитектурой, чтобы мы могли спокойно разрабатывать для неё софт» — ок, всё нормально. Надеюсь кто-то, от кого это зависит, его услышит и поймёт правильно.
ps. И да, я бы на месте этих самых вендоров предложил бы такие машинки по себестоимости (а то и чуть меньше) университетам. MIT там, Berkeley и т.д. Оно как-то сильно поспособствует.khim
27.02.2019 02:16Там проблема не в себестоимости. Разработка очень дорого стоит вот этого вот всего. Когда вы выпускаете Raspberry PI миллионными тиражами — они амортизируется, когда серверное железо за десять тысяч долларов — там уже с сотни экземпляров прибыль, а тут надо вложить миллионы долларов, а продать потом сотню или, в лучшем случае, тысячу штук — планово-убыточное мероприятие…
Zanak
26.02.2019 08:48Почитал я комментарии к посту и не понял ажиотажа. Узкий специалист высказал свое мнение по специфическому вопросу.
Кто реально завязан на архитектуру процессора?
Ну да, разработчики компиляторов. Использование возможностей CPU по максимуму — это их хлеб.
Разработчики средств виртуализации и связанного с этим софта, наверное тоже да. (Я с этим вопросом знаком достаточно поверхностно).
Возможно, разработчики какого — то специфичного софта, который использует особенности архитектуры CPU для оптимизации.
Еще раз напомню, речь про сервера!
Остальные — то чего возбудились? Вы все равно используете то, что вам компилятор породил, и самый главный для вас вопрос: сколько будет стоить решение именно ваших задач, а не то, как они будут решены.Zanak
27.02.2019 11:45Ну вот, снова минуса. :)
Ок, был не прав, возможно. Но не дайте умереть в неведении, объясните неучу, чем так плох процессор от ARM относительно процессоров x86, кроме того, что под ARM весь, или почти весь, софт надо портировать? Да, это долго и дорого, и это большой аргумент в пользу того, что Линус прав.
Я все еще уверен, что тема статьи — это узкий и специфичный вопрос, потому что люди, даже разработчики, по большей части, являются потребителями готового софта и железа, и для них важнее вопрос цены и возможностей полностью готового устройства, со всем необходимым софтом на нем, чем то, как это устроено.
no404error
26.02.2019 08:56Серверный рынок — пока не самый большой для ARM.
Не соглашусь. Он — огромен. И это не противоречит ни заявлению Товальдса, ни данной статье. Просто использование идет параллельно. Перетащить все на ARM — редкость. Но применение в серверах это данность.
ErmIg
26.02.2019 10:56Как раз сейчас у меня очередной этап портирования кода: x86(SSE, AVX) -> ARM (NEON). Могу только констатировать, что в данном вопросе Линукс полностью прав: Без нормальной девборды этот процесс весьма длительный и утомительный (с кросскомпиляцией и без дебагера).
P.S. А так на текущем этапе ARM явно не хватает широкого SIMD. NEON с его 128-bit на текущем этапе достаточно скромно выглядит по сравнению с AVX и уж тем более AVX-512.beeruser
26.02.2019 16:54А так на текущем этапе ARM явно не хватает широкого SIMD.
Увы, пришествия SVE в массовые процессоры ждать ещё долго. Сейчас есть только Fujitsu A64FX.
У Apple A12 (начиная с A9?) 3 SIMD юнита, таким образом обрабатывается 3х128 = 384 бит.
GrigoryPerepechko
26.02.2019 17:09Почему без дебаггера? Еще 10 лет назад дебажили совершенно мусорные архитектуры на мобилках.
Ну а что касается железа — AWS предоставляет машины на ARM. 32 GB RAM, 16 ядер. Деплойте, дебажьте.
aws.amazon.com/blogs/aws/new-ec2-instances-a1-powered-by-arm-based-aws-graviton-processors
Хотите локально — вот 24 ядра
www.socionext.com/en/products/assp/SynQuacer/Edge
А что до AVX-512 — его нигде нет, так что если вы не сами себе покупаете железо под процессинг, а для людей делаете — придется писать два раза, с ним и без него.
ErmIg
26.02.2019 17:21Писать приходится 6 раз минимум: Scalar, SSE, AVX, AVX2|FMA, AVX-512 и NEON.
GrigoryPerepechko
26.02.2019 17:46Я вам немножко завидую. Мне очень нравится ручная оптимизация, но по работе занимаюсь совершенно другими вещами. Пару раз в жизни удавалось пописать под NEON (в соседней с вами геймдев компании), счастью не было предела, когда запускал бенчмарки.
i8008
26.02.2019 12:57При всем уважении к заслугам Линуса, не могу согласиться.
Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.
Я, для своего «пэт-проджекта» действительно готов переплатить. Вот только это скорее исключение, когда разработчик сам оплачивает хостинг.
Обычно хосинг и инфраструктуру оплачивает условный «бизнес», а у них есть другие метрики, например, «стоимость владения». Если АРМ действительно предложит серверное решение с более оптимальным соотношением производительность/цена – появится спрос на оптимизацию софта под эту платформу. За спросом подтянется предложение.
Удобство для разработчика – дело не последнее, но и явно не приоритетное. Иначе бы х86 был бы в каждом смартфоне.khim
26.02.2019 18:25Обычно хосинг и инфраструктуру оплачивает условный «бизнес», а у них есть другие метрики, например, «стоимость владения».
И для подавляющего большинства бизнесов — это аредна одной-двух VPS или чего-либо подобного.
Google и Yandex, конечно, на слуху — но это только вершина бизнеса. В большинстве случаев для малых (и во многих случаях) для средних бизнесов хостинг идёт как бесплатная довеска к разработке. Потому получается, фактически, «разработчик сам оплачивает хостинг»: это всё идёт по той же статье бюджета.
Удобство для разработчика – дело не последнее, но и явно не приоритетное. Иначе бы х86 был бы в каждом смартфоне.
Смартфоны — дело другое: тут за железо и разработку платят совсем разные люди. А вот там, где это идёт из одного кармана — там x86 задавил большинство конкурентов. Потому что вначале «фиг с ценой сервера, мы пока маленькие, заплатим чуть больше за сервер, зато будет экономия на разработке», а потом, лет через 10, «да, мы уже большие — но у нас уже всё-привсё заточено под x86, переделка встанет в такие деньги, что лучше даже не начинать».i8008
26.02.2019 23:44Возможно, я не прав в прогнозах, но я бы очень хотел, чтобы АРМ «взлетел» на серверах (ибо на десктопах у него шансов нет совсем). Не потому, что мне эта архитектура нравится, а потому, что x68 нужна конкуренция. И наоборот, хочу прихода х86 на мобильнее устройства, по тем-же причинам.
И я думаю, что в контексте данной статьи шанс прийти на рынок серверов у АРМ есть.
И для подавляющего большинства бизнесов — это аредна одной-двух VPS
Я с вами согласен (с оговорками), если считать «бизнесом» каждое юр. лицо.
Но раз мы говорим о рынке серверов – то там мелкие потребители «одной-двух VPS» (на которых крутится написанный под них софт) особой роли не играют. Основные потребители физических серверов – это крупный бизнес, (IT корпорации, банки, операторы мобильной связи и т д ). И на их серверах, зачастую, крутится типичный софт (я где-то читал, что 30% всех серверов в мире – это сервера СУБД). И в этом сегменте у АРМ, имхо, есть шанс занять свою нишу. Ибо это большая часть рынка физических серверов и относительно немного крупных производителей софта такого уровня.
А вот на десктопах – я не верю в успех АРМ по той причине, что там бесконечный набор софта и сразу вылазит проблема «АРМ на десктопе не нужен пользователю, потому что под него нет нужного софта, а разрабатывать софт под АРМ не выгодно, т. к. нет пользователей»khim
27.02.2019 00:03Возможно, я не прав в прогнозах, но я бы очень хотел, чтобы АРМ «взлетел» на серверах (ибо на десктопах у него шансов нет совсем).
Почему нет? Тут где-то уже была фотка IntelliJ Idea на Note 9. Ещё пару лет и телефоны сравняются по мощности с офисными машинками.
И наоборот, хочу прихода х86 на мобильнее устройства, по тем-же причинам.
А вот тут уже всё. Снизу вверх двигаться гораздо проще.
Но раз мы говорим о рынке серверов – то там мелкие потребители «одной-двух VPS» (на которых крутится написанный под них софт) особой роли не играют.
Суммарно — как раз они и играют. Есть ещё «суровый ынтырпрайз», но на него надежды вообще никакой: там могут лет 5-10 только обдумывать возможность перехода куда-нибудь…
А вот на десктопах – я не верю в успех АРМ по той причине, что там бесконечный набор софта и сразу вылазит проблема «АРМ на десктопе не нужен пользователю, потому что под него нет нужного софта, а разрабатывать софт под АРМ не выгодно, т. к. нет пользователей»
А эта проблема как раз легко решается если начать со смартфонов. Да, конечно, вначале софт со смартфонов не будет вызывать ничего, кроме улыбки… ну так и с PC то же самое было: во времена, когда на рабочих станциях уже было и редактирование видео и 4G и прочие чудеса… PC только-только учился работать с директориями!
И долгое время софт писался на рабочих станциях (даже пресловутый Doom, если не забыли, писался на NextStep, а не на PC!). А потом… появилась Visual Studio — и круг замкнулся.
То же самое может произойти и здесь… а может и не произойти: всё-таки с точки зрения интерфейса рабочие станции ближе к PC, чем телефоны и планшеты.
Но если ARM не придёт на десктоп, то он и на сервер вряд ли придёт… в этом смысл обсуждаемой статьи…i8008
27.02.2019 00:19Ещё пару лет и телефоны сравняются по мощности с офисными машинками.
Дело не в мощности. В случае десктопа — дело в наличии привычного для пользователя софта. Здесь пока даже с разными ОС на х86 все местами плохо, про АРМ – боюсь даже представить.khim
27.02.2019 00:24А не нужно ничего представлять. Нужно просто вспомнить что больше половины пользователей смартфонов никогда не работали с PC.
Соотвественно для них среда разработки, какая бы она ни была — будет приемлема. Потому что никакой другой у них нет и не будет.
А переход «мастадонтов» типа нас с вами — это лет через 10-20.
i8008
27.02.2019 00:12+1И еще такой момент, касательно цитаты Линуса:
Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.
А теперь мысленно отмотайте время на 20 лет назад, и замените в цитате «x86» — на «Windows». Интересно звучит, правда? Но Linux «взлетел» (чему я очень рад), притом сначала взлетел именно на серверахkhim
27.02.2019 00:29+2А теперь мысленно отмотайте время на 20 лет назад, и замените в цитате «x86» — на «Windows». Интересно звучит, правда?
Интересно и правдиво. Именно благодаря этому эффекту мы и имеем (до сих пор имеем!) существенную долю серверов под Windows.
Но Linux «взлетел» (чему я очень рад), притом сначала взлетел именно на серверах
Однако Linux ведь вытеснил не Windows. Он вытеснил «большие» UNIX'ы. А кого будет вытеснять ARM сегодня?
apro
26.02.2019 14:05А чем принципиально разработка под Android/NDK и iOS отличается от серверной?
Почему куча разработчиков под вышеперечисленные платформы пользуются кросс компиляцией, а те кто пишут серверное ПО не смогут этого делать?
RPG18
26.02.2019 14:21Если вы пишете Node.js/PostgreSQL, то вам придется купить сервер, что бы тестировать работоспособность и производительность.
khim
26.02.2019 18:30А чем принципиально разработка под Android/NDK и iOS отличается от серверной?
Тем что вы никак не можете повлитять на то, какое железо стоит в телефоне, но очень даже можете повлиять на то, какое хелезо закупается/арендуется под сервер.
Грубо говоря в случае с телефоном вы пляшете от железа — и оно определяет, что вы можете сделать, а чего нет, а в случае с серверами — вы делаете программу и смотрите какое железо под неё купить, так что железо определяет лишь часть цены — и больше ничего.
И каким бы не было железо, но если разработка вам встанет дешевле — то вы будете покупать именно такой вариант.
Если было бы иначе — Windows на серверах уже давным-давно сгинула бы, потому что почти всегда она требует больше и более дорогих серверов… но нет же — свою долю она таки имеет.
Psionic
26.02.2019 19:00Дебаг по шнурку ЮСБ и по эзернету точно не сильно отличаются? Проблема то не в компиляции, а отладке и еще переносить весь существующий зоопарк серверного софта, как открытого, так и закрытого и даже внутрикорпоративного с кучей легаси это просто таки колоссальный труд. Почему-то вопрос совместимости с существующими решениями Линуса слабо волнует.
v2kxyz
27.02.2019 18:12+1Тем что, у 99% разработчиков есть телефон с Android и/или iOS. То есть не смотря на кросс компиляцию, я могу сразу потыкать пальцем в свое творение и т.п. Еще тем, что 90% разработчиков под мобильные платформы не интересует производительность на уровне экономии тактов — достаточно алгоритмической оптимизации. Ну и мотивации писать код для миллионов устройств сильно больше, чем под два с половиной сервера.
То есть, есть два варианта, либо АРМ производит нечто, что настолько лучше x86 для какой-то категории задач, что хостеры/облака массового и дешево предлагают ARM мощности, тогда программисты начнут придумывать как выкрутиться. Либо ARM предлагает доступные devkit'ы для разработчиков, тогда программистам будет просто любопытно их освоить и тогда, может быть, они сами найдут ниши для применения этой архитектуры где-либо за привычными рамками телефонов, чайников и телевизоров.
VolCh
27.02.2019 18:23У разработчиков под вышеперечисленные платформы выбора особо нет, а под сервера — есть.
Ну и для серверной разработки с кросскомпиляцией нужно, минимум, два сервера, а без неё — один, потому что роль тестового выполняет машина разработчика. Понятно, что в реальности немного не так будет, но один хотя бы виртуальный сервер разработчику нужно предоставить, чтоб на QA он задачу отправлял хотя бы убедившись, что там не крашится всё сразу.
Viacheslav01
26.02.2019 16:10Более чем уверен, что достижение производительности на уровне х86, приведет к повышению энергопотребления до уровня того же х86. Что нивелирует главное преимущество.
belov2018
26.02.2019 20:33Не понял зачем нужны серверы на ARM64 если есть мультитредовые MIPS64 от Broadcom?
beeruser
26.02.2019 21:08+1lolwat?
Что вы имеете в виду? XLS/XLP?
Высокопроизводительных микроархитектур MIPS64 нет. Софта под MIPS тем более нет.
Вот история о том, как Broadcom XLP-II (MIPS) вырос в Cavium ThunderX2(ARM):
fuse.wikichip.org/news/1316/a-look-at-caviums-new-high-performance-arm-microprocessors-and-the-isambard-supercomputer/2
PS: Да и Broadcom-а то уже нет. Это Avago переименованная в Broadcom. Никакие серверные процессоры им не нужны.
rPman
26.02.2019 20:55+1Единственное на что можно надеяться для совершенно новой архитектуры, пытающейся конкурировать с x86, — это эксперименты и дополнительные возможности. Например это лучший момент сделать fpga модуль стандартным (arm чипы есть со встроенными блоками на сотню тысяч вентилей, к сожалению нет тонны готовых soc с ними). Вспомнить многопроцессорные системы с разделяемой памятью (на каждый проц свой блок оперативки). Экспериментировать с матричными архитектурами (когда не одна шина данных, а каждый блок проц+память соединене только с несколькими соседями) и т.п.
На x86 такие эксперименты практически под запретом, слишком много легаси.RPG18
27.02.2019 11:54Для совершенно новых архитектур нужно по новому писать софт, иначе от них не будет проку. А это очень большие деньги. Кто может потянуть такие эксперименты?
rPman
27.02.2019 20:55для GPGPU потянули за 10-13 лет (а это действительно было нечто новое), вангую что в случае FPGA в каждом чайнике народ разберется лет за 5, ведь технология то на самом деле старая, просто из-за специально культивируемой дороговизны не сильно распространена.
RPG18
28.02.2019 11:08ARM+FPGA активно используется когда нужна обработка сигналов, т.к. мелкосерийно делать специальные чипы невыгодно. Или для работы с сетевым трафиком, даже интел поучаствовал, но это узко специфические задачи. Как вы планируете применять FPGA для серверов баз данных и приложений?
shaukote
Чисто любопытно, у десктопа на Power9 есть какие-то практические применения — кроме как девбокса?
MMik
Например, GPU добавить, и можно обсчитывать молекулярную динамику и визуализировать молекулы в VMD (Visual Molecular Dynamics) и другом подобном научном софте: есть возможность использовать шину NVLink 2.0. Для всяких AI на десктопе тоже должно хорошо подходить.
DaylightIsBurning
MMik
Безусловно, x86 — это основная массовая платформа. Но свои плюсы в Power9 всё же есть. Тот же NVLink 2.0 работает на x86 только между GPU, а на Power9 работает и между GPU, и между GPU и CPU. Некоторый софт лицензируется по сокетам, и выгодно купить Power с меньшим количеством сокетов и множеством тредов (SMT4, SMT8), вместо x86 с большим количеством сокетов.
DaylightIsBurning
Но какие есть преимущества для того, что бы запускать VMD или MD на Power? Я вообще не уверен, что многие мейнстримные MD-движки поддерживают Power. Я слышал, что раньше какой-то банковский софт разрабатывался под Power, не знаю, так ли это всё ещё.
Kobalt_x
Извиняюсь что влезаю, про VMD, MD не в курсе, но куча всего ML поддерживает power, а в связи с тем что SUMMIT/sierra теперь на power9 поддержка power9 в ML стеке возрастет многократно(хотя она и сейчас нормальная). Более того в графовых задачах и ML использование NVLINK CPU-GPU, дает существенный прирост благодаря использования большего количества памяти. (на последнем ПАВТе было что-то такое). Что также работает и на ML задачах.
Но т.к. из-за summit/sierra сейчас будет имхо бум софта чисто под power, я думаю скоро появятся.
a5b
В power-десктопе "Blackbird" за 1.2 тыс долларов и в Talos 2 (>2.3 тыс долларов) у процессора нет NVlink: https://www.raptorcs.com/content/BK1B01/intro.html https://wiki.raptorcs.com/wiki/Blackbird, только "1 PCIe 4.0 x16 slot + 1 PCIe 4.0 x8 slot"
1 POWER9-compatible Sforza CPU socket = https://wiki.raptorcs.com/wiki/Sforza = "NVLink interfaces 0"
Между CPU и GPU nvlink был, по данным https://en.wikichip.org/wiki/nvidia/nvlink, с процессорами IBM POWER8+ (https://wiki.raptorcs.com/wiki/POWER8E) и доступен в старших платформах Power9 — Monza и LaGrange. Т.е. линк есть в суперкомпьютерных AC922.
Berkof
Имхо конечно, но впихивание NVLink без перевода стандарта в открытые — большая беда Power9, от которой выигрывает только NVidia
WeltRogg
А рендер? Работа с музыкой, тяжелой графикой, большими проектами в фотошоп. Не у всех программистов из интересов только разработка, есть и интереснее. Разработка это только работа и лишь малая часть в ней хобби.
yayashitoya
x86 вполне доступны.
Если уж имеешь экзотический Power9, то почему ты обязан его использовать и только его для всего.
Несколько компьютеров в доме — уже не редкость много лет как.
Тем более у того, для кого это профессия.
ustas33
PCIe v4 из коробки.
Нет bottleneck с 2x100Gb, 200Gb, 400Gb сетевыми адаптерами.
shaukote
Пардон за дилетантские вопросы, но разве нельзя собрать конфигурацию вокруг x86-процессора с PCIe v4 (и обойтись без головной боли из-за нестандартной архитектуры)?
И для каких практических нужд на десктопе можно использовать 400Gb Ethernet?
ustas33
На десктопе конечно не надо, для AI/ML серверов бывает нужно 200Gb для доступа к сети или NVMe фабрике.
Текущие процессоры Intel Skylake, не поддерживают PCIe v4. Под 200Gb адаптер нужно занимать два PCIe v3 слота.
shaukote
Неожиданно. Как-то я это упустил.