Pull to refresh

Comments 254

Чисто любопытно, у десктопа на Power9 есть какие-то практические применения — кроме как девбокса?
Например, GPU добавить, и можно обсчитывать молекулярную динамику и визуализировать молекулы в VMD (Visual Molecular Dynamics) и другом подобном научном софте: есть возможность использовать шину NVLink 2.0. Для всяких AI на десктопе тоже должно хорошо подходить.
можно обсчитывать молекулярную динамику и визуализировать молекулы в VMD
Так это и на x86 давно и прекрасно работает. Рискну предположить, что x86 — это основная платформа для этих вещей даже, а Power — второстепенная.
Безусловно, x86 — это основная массовая платформа. Но свои плюсы в Power9 всё же есть. Тот же NVLink 2.0 работает на x86 только между GPU, а на Power9 работает и между GPU, и между GPU и CPU. Некоторый софт лицензируется по сокетам, и выгодно купить Power с меньшим количеством сокетов и множеством тредов (SMT4, SMT8), вместо x86 с большим количеством сокетов.
Но какие есть преимущества для того, что бы запускать VMD или MD на Power? Я вообще не уверен, что многие мейнстримные MD-движки поддерживают Power. Я слышал, что раньше какой-то банковский софт разрабатывался под Power, не знаю, так ли это всё ещё.
Извиняюсь что влезаю, про VMD, MD не в курсе, но куча всего ML поддерживает power, а в связи с тем что SUMMIT/sierra теперь на power9 поддержка power9 в ML стеке возрастет многократно(хотя она и сейчас нормальная). Более того в графовых задачах и ML использование NVLINK CPU-GPU, дает существенный прирост благодаря использования большего количества памяти. (на последнем ПАВТе было что-то такое). Что также работает и на ML задачах.
Но т.к. из-за summit/sierra сейчас будет имхо бум софта чисто под power, я думаю скоро появятся.

Процессинг вроде очень любит, плюс некоторые типы БД (oracle) очень хорошо на них работают хотя сейчас oracle активно рассказывает о том что будут их специализированные спарки.

В 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.

Имхо конечно, но впихивание NVLink без перевода стандарта в открытые — большая беда Power9, от которой выигрывает только NVidia
А рендер? Работа с музыкой, тяжелой графикой, большими проектами в фотошоп. Не у всех программистов из интересов только разработка, есть и интереснее. Разработка это только работа и лишь малая часть в ней хобби.
А рендер? Работа с музыкой, тяжелой графикой, большими проектами в фотошоп. Не у всех программистов из интересов только разработка, есть и интереснее. Разработка это только работа и лишь малая часть в ней хобби.

x86 вполне доступны.
Если уж имеешь экзотический Power9, то почему ты обязан его использовать и только его для всего.
Несколько компьютеров в доме — уже не редкость много лет как.
Тем более у того, для кого это профессия.

PCIe v4 из коробки.
Нет bottleneck с 2x100Gb, 200Gb, 400Gb сетевыми адаптерами.
Пардон за дилетантские вопросы, но разве нельзя собрать конфигурацию вокруг x86-процессора с PCIe v4 (и обойтись без головной боли из-за нестандартной архитектуры)?
И для каких практических нужд на десктопе можно использовать 400Gb Ethernet?
На десктопе конечно не надо, для AI/ML серверов бывает нужно 200Gb для доступа к сети или NVMe фабрике.
Текущие процессоры Intel Skylake, не поддерживают PCIe v4. Под 200Gb адаптер нужно занимать два PCIe v3 слота.
На десктопе конечно не надо, для AI/ML серверов бывает нужно 200Gb для доступа к сети или NVMe фабрике.
А, ну там да. Изначально просто я про десктопы спрашивал, так что подумал, что у кого-то уже на десктопах появились задачи, где такое нужно. :)

Текущие процессоры Intel Skylake, не поддерживают PCIe v4.
Неожиданно. Как-то я это упустил.
Но на сервере, разработчики запускают свой код. Даже если ты программируешь на каком нибудь питоне, не факт что под arm будут доступны необходимые тебе библиотеки.
Питон же интерпретатор, под отсутствием библиотек, Вы наверное понимаете, что не будет Python-C binding-ов, в которых есть ассемблерные вставки. В остальных случаях Си-шные байниндинги без ассемблерных вставок будут спокойно компилироваться под ARM
> Вы наверное понимаете, что не будет Python-C binding-ов

Binding — это лишь способ связать Python с библиотекой, написанной на ином языке. Вы вполне себе можете написать модуль Python, у которого реализация методов и функций будет на C, C++, assembler и т.д… При этом он не будет являться binding'ом к чему-либо.

> В остальных случаях Си-шные байниндинги без ассемблерных вставок будут спокойно компилироваться под ARM

Сильно зависит о того, насколько криворуким был автор кода, даже если он писал на чистом божественном C. Варианты могут быть разными:
  1. Не компилируется
  2. Компилируется, но не работает — например, автор заложился на порядок байт
  3. Компилируется, но работает не оптимально: например, код обращается к невыровненному адресу для загрузки из памяти 32-х битного значения. На ARM это сгенерирует исключение процессора, которое может перехватить ОС и проэмулировать успешное чтение памяти
  4. Просто работает
5. Просто работает, но периодически вылезают чудесные неотловимые баги.
Такое поведение не является атрибутом только именно native-кода )
Разумеется, но не очень приятно будет к сотне известных глюков получить ещё две сотни неизвестных.
2. Компилируется, но не работает — например, автор заложился на порядок байт
Порядок байт на ARM и x86 одинаковая и всегда была одинаковая (ранние модели опционально поддерживали Big Endian, но сейчас этот режим выпилили за ненадобностью).

3. Компилируется, но работает не оптимально: например, код обращается к невыровненному адресу для загрузки из памяти 32-х битного значения. На ARM это сгенерирует исключение процессора, которое может перехватить ОС и проэмулировать успешное чтение памяти
Чтобы такое увидеть вам потребуется откопать раритеное ядро 10-15-летней давности. На всех современных процессорах невыровненное чтение поддерживается аппаратно.

На самом деле в портировании под ARM есть свои чудеса, но их гораздо меньше, чем кажется. Но их, увы, таки больше, чем нужно для того, чтобы можно было вашу либо отдавать совсем не престировав.
Спасибо за уточнения. Но всё равно не стоит писать код, который закладывается на невыровненное чтение или на порядок байт. Не ARM, так другая архитектура, куда может потенциально угодить ваша либа, может очень плохо отнестись к таким фокусам )
Да о чем речь, есть случаи когда библиотек даже нет под другую ОСь или другой интерпретатор питона.
При всём уважении к Торвальдсу, мне кажется он слишком сгущает краски.
Во-первых, давно уже программисты не пишут только на C/C++, нынче в моде Node.js, С#, Java, Python и пр. Т.е. языки и платформы, которые в том или ином виде предлагают концепцию «Write once, Run everywhere». Современному программисту необязательно знать, как работает TCP/IP, чтобы написать веб-приложение.
Во-вторых, по поводу «Не надо замахиваться на 64-128 ядер, пока не получится сделать нормально хотя бы 8-ядерник». Много слабых ядер тоже могут найти свою нишу, я не думаю, что сразу замахиваться на нишу Xeon'ов хорошая идея.

Что там с памятью? Больше 8GB есть? Быстрый SSD можно подключить? Все драйвера в апстриме, или нужно привязываться к форку определённой версии?

Простите, не понял, вы о чем? Какие SSD? Какие драйвера?

Возьмём старую добрую малинку(raspberry pi).
Может ли разработчик на неё подключить быстрый ssd что бы компиляция кода шла быстро(в сравнении с microSD карточкой)?
Может ли разработчик запустить X11 с самой свежей убунтой/арчем? Что бы запустить классическую eclipse/Netbeans/jetbrains?
Будет ли компиляция и деплой достаточно быстрым?


Пожалуй на всё можно ответить нет.
И это мы говорим про плату, которая очень сильно толкнула развитие ARM для домашнего пользователя/разработчика.


Линус в данном вопросе прав.
В качестве примера можно глянуть мейнфреймы.
С ними происходит тоже самое что и коболом.
Они вымирают по естественным причинам.
Средний возраст разработчика за 50 лет(в конторе которая была клиентом).


Молодой домашний пользователь/разработчик не может получить что-то вроде мейнфрейма домой-> не может с ним поиграть -> не желания связываться с этой темой дальше.


Вот и с ARM ничего не будет.
Пока ARM не выпустит классическую материнку ATX формата с наборной оперативкой, PCIE, SATA и так далее.

Все сильно хуже. Будут ли на ARM работать всякие чисто серверные штуки — ну, там ceph (драйвер в ядре), gluster (тоже требуется поддержка со стороны ядра), iscsi (угу, iscsi-клиент тоже в ядре) и т.п… а без этого ARM становится весьма нишевым решением.
Вот как раз вот это вот всё есть в ядре. А поддержки большинства GPU — нету.
IronSoft Ceph Appliance работает на AMD ARM
Это же все платформо-независимый код. Что должно помешать работе?

Т.е. Вы гарантируете, что


  • нигде нет ассемблерных вставок;
  • нет привязки к low/big endian, размерности величин;
  • нет нюансов с сериализации/десериализацией данных;
  • нет завязок на компоненты, которые существуют только на x86_64 платформе?

Я бы не рискнул давать таковые...

Гарантировать? Таки Вы таки уже ставите в прод на основе моих комментариев? Так это зря…

Если вопрос реально интересен, это выясняется даже не качая исходников, благо они на гитхабе. Не знаю что нужно гластеру, а у ceph и iscsi зависимости только на сеть и общую криптографию, без уточнения платформы. Точнее, iscsi включает еще и конкретно интеловую крипту конкретно для x86.

Наличие ассемблерных вставок легко проверяется, средства для работы с любым порядком байтов в ядре в наличии (хотя, опять же, у x86 и ARM он одинаковый). Что может быть не так с размерностями величин и сериализацией я не понял.

Впрочем и смысла предыдущего вопроса я таки по прежнему не понимаю. Это чисто софтовые компоненты, давно включенные в ванильное ядро, значит написаны по стандартам ядра. Такие же претензии можно предъявить всему, включая планировщик процессов и драйвер ext2. Или уже были прецеденты?
Таки Вы таки уже ставите в прод на основе моих комментариев? Так это зря…

нет, конечно.
Если вопрос реально интересен, это выясняется даже не качая исходников, благо они на гитхабе. Не знаю что нужно гластеру, а у ceph и iscsi зависимости только на сеть и общую криптографию, без уточнения платформы. Точнее, iscsi включает еще и конкретно интеловую крипту конкретно для x86.

ну, это пока общие разговоры в пользу бедных.
Вот ниже коллеги пишут, что есть готовый appliance — IronSoft Ceph Appliance.
Другой вопрос, что работает ли он в режиме черного ящика и можно ли строить гетерогенные системы (например, часть ceph-нод на ARM, часть — на x86 — вот там перечисленные мной проблемы могут и стрельнуть). Например, k8s поднять на мастер-нодах на x86, а worker'ы на ARM — почему нет?
В любом случае, похоже, что только практика покажет жизненноспособность таких решений…
Такие же претензии можно предъявить всему, включая планировщик процессов и драйвер ext2. Или уже были прецеденты?

ну, вот, опять как пример — часто ли Вы монтируете файловую систему с устройства с посторонней архитектурой? Точно не каждый день. Разве что может SDшку с телефона, да и то для одной задачи — скопировать фотографии и видосики, а они в стандартных форматах. Совместимость-то платформ не ограничивается совместимостью каких-то коровых (от core) технологий (ФС, сеть и пр.), а еще и совместимостью приклада (немного не в тему, но могу напомнить, что даже офисные пакеты пока все еще не идеально открывают файлы друг друга).
ARM не выпускает железо вообще-то, они занимаются исключительно разработкой процессоров на «бумаге», которые потом лицензируют производителям.

Может ли разработчик запустить X11 с самой свежей убунтой/арчем? Что бы запустить классическую eclipse/Netbeans/jetbrains?

Мы точно всё еще говорим про игрушку за 30 баксов? Вы еще WebSphere + Oracle DB попытайтесь на ней поднять, а потом жалуйтесь, что говно этот ваш ARM.
Вот когда выйдет реальное железо на новой архитектуре, тогда и будет смысл предъявлять претензии, что у вас что-то не работает. А пока это напоминает анекдот про японскую пилу и сибирских мужиков.
на новой архитектуре
Вообще-то ARM с x86 (32bit) одного возраста.

А чем именно напоминает анекдот?
Разработчик хочет перенести свое приложение на ARM.
Для этого неплохо бы поднять систему разработки и сборки.
Может разработчик собрать комп на ARM с кросплатформенным линуксом?
Причем так, что бы ARM комп смог ему заменить рабочий комп на х86?
Нет.


Вот тут Lenovo пыталась выпустить нетбук на ARM но что-то пошло не так.

Ну вообще на арме есть продакшн решения. И это не малинка само-собой. Посмотрите например на nvidia jetson.
Мы точно всё еще говорим про игрушку за 30 баксов?
Нет. Можно и 300 отвалить. Но не 3000 — для большинства разработчиков это «многовато будет».

Об чём и речь — есть либо что-то очень очень дешёвое, либо разного вида дорогущие монстры. А «коробки для разработчика» — нету…
Почему-то все при слове ARM вспоминают только про малину.
Но это не значит, что если в малине чего-то нет, то этого нет вообще.
Совсем забыли про Odroid платки odroid-xu4 и odroid-hc2.
Они вполне годные для разработки прямо на них. Хотя ниже верно подметили, что совсем не обязательно что-то разрабатывать именно на самой ARM-коробочке. Кросс-компиляция отлично работает.
Они вполне годные для разработки прямо на них.

На старых 32-битных телефонных SoC с крошечными тормозными eMMC?
У меня есть две штуки. Очень они костыльные (не вина hardkernel — они большие молодцы) и медленные. Сколько будет собираться Chrome какой-нибудь. Хватит 2GB памяти?

Хотя ниже верно подметили, что совсем не обязательно что-то разрабатывать именно на самой ARM-коробочке. Кросс-компиляция отлично работает.

Речь в оригинальном посте и идёт о том, что кросс-компиляция — компромисс. Для маленьких или идеологически отгороженных платформ сойдёт, конечно.
Но разработчики которые не хотят сидеть на х86, нет имеют выбора.
Есть медленные и дешёвые и наоборот — 28-64 ядерные системы за огромные деньги, которые ещё и хрен купишь.
300 для разработчиков это не много. У нас как бы софт стоит соразмерно…
Дык нет же ничего за 300! Есть за 30 и есть за 3000! Первое — это дикие тормоза (к тем, кто создаёт эти машинки, впрочем, претензий нет: чего вы вообще хотите за такие деньги?), а второе — это уже чересчур дорого…

Об чём и речь…
Молодой домашний пользователь/разработчик не может получить что-то вроде мейнфрейма домой-> не может с ним поиграть -> не желания связываться с этой темой дальше.

Для мейнфрейма не было столь легкого доступа как нынче с виртуалками/эмуляторами/облаками.

То есть доступ к мейнфреймам «испокон веков» всякий удаленный/терминальный имелся. Но не так чтобы он был легко доступным/массовым и более-менее полноценным.

На современном x86 это уже последние годы как есть.
На ARM не вижу причин чтобы не сделали.
Возьмём старую добрую малинку(raspberry pi).

Пожалуй на всё можно ответить нет.
И это мы говорим про плату, которая очень сильно толкнула развитие ARM для домашнего пользователя/разработчика.

Скорее для DIY-щиков толкнула ARM. Поэтому вы и получили исключительно отрицательные ответы на ваши вопросы домашнего пользователя к железячке, которая продалась миллионными тиражами. Задавайте вопросы DIY-селфщика — получите положительные ответы :)
image

  • 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

Ничего так. Но вот SATA III и 2 x 10GbE SFP+ LAN ports я не понял

Не знаете, по какой цене это продавалось и насколько доступно?
Нашел рассказ о сборке ПК на базе 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."

Конкретно эта плата продавалась за $1000.
X-Gene1 должен был быть первым ARMv8 чипом, однако не стал таковым.
(не)Первый блин вышел комом — тормозной и нет совместимости со стандартами.

Не знал об этой плате.
Так же я хотел бы заметить что это одна плата.
Вроде бы других нет.
Да и ты сам указал что она тормозная.

Сейчас в наличии нигде не увидел. Про цену уже написали.

Опять же, в прошлом за $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
Эту плату лет 5 как сняли с продаж.
Значит фраза...
Вот и с ARM ничего не будет.
Пока ARM не выпустит классическую материнку ATX формата с наборной оперативкой, PCIE, SATA и так далее.
… опоздала, минимум, на тот же срок.
Нет, она не опоздала. Просто требование выпустить подобную плату — необходимое, но далекоооо не достаточное…
Для разработки под ARM не нужно компилировать конкретно на ARM машине. Просто используется компилятор под эту архитектуру. Это называется — кросс-компиляция. Собственно контроллер используется лишь для запуска ПО.
Я разрабатываю на ARM на обычной x86 машине под Debian в виртуалке. Не так давно, ради эксперимента, наши дотнетчики собрали .NetCore хелловорлд для ARM платки на своих виндовых машинах вообще почти ничего не зная про линукс и просто выбрав нужные пункты в студии.
А с коркой и не должно быть проблем, кроме принудительного использования интринсиков.
Для разработки под ARM не нужно компилировать конкретно на ARM машине. Просто используется компилятор под эту архитектуру. Это называется — кросс-компиляция.
Кросс-компиляция — известная вещь, вот только натив — удобнее.

Если у вас выбора особо нет (скажем почти все смартфоны — они под ARM), то да — вы будете заморачиваться. А если выбор есть — выберите натив.
Речь как раз о том, что очень большие преимущества должны быть у среды исполнения, чтобы заниматься разработкой в одной среде, а запускать (прежде всего в тестовых целях самим разработчиком) в другой.
Ну вот вам убунта с идеей на арм. Знакомый в такой даже на котлине что-то пописывает вечерами.

Ок. Такого ещё не видел.
Однако я более чем уверен что на таком конфиге всё работает очень медленно.

Современному программисту необязательно знать, как работает TCP/IP, чтобы написать веб-приложение.


Вот не могу согласиться с подобным утверждением. Программист должен иметь представление, как работают механизмы, которые он использует. Потому как понимание механизма работы (например) TCP/IP позволит принять во внимание фрагментацию пакетов, маршрутизацию, MTU и другие особенности.
там есть структура sk_buff которая хранит данные переданные в сокет и заголовки транспортного, сетевого и канального уровня. Фрагментация пакетов происходит на самом нижнем уровне (неприменно при передаче на сетевую карту). Вот статья по сетевому стеку в линукс.
Программист должен

Кому должен?

фрагментацию пакетов, маршрутизацию, MTU и другие особенности

Насколько это необходимо, чтобы парой «магических» команд в консоли поднять простенький сайт на той же джанге? Нет, поймите меня правильно, я согласен с вами, что знание своего инструмента — это полезный навык для любого специалиста, не важно, говорим мы о программисте или сварщике. Но сегодня это сакральное знание не является необходимым, чтобы делать сайты на каком-нибудь вордпрессе.
Проблема в том, что если делать серьезный проект, то не глубокое знание, но хотя бы готовность с этими MTU бороться — нужна. И, да, я сталкивался с кейсами, когда требовалось изучение проблемы и иногда тот же MTU стрелял и был причиной.
С другой стороны, если проект несерьезный, то Вы идете на хостинг типа tilda или wordpress, возможно, что даже с бесплатным тарифом, и запиливаете свой сайт там.
Итог — эти девбоксы на АРМе никому не нужны.
Если проект серьезный, то у вас будут отдельно обученные люди, которые либо сами разберутся, либо помогут программистам разобраться и понять проблему. Однако это не отменяет того, что желательно всем участникам процесса хотя бы минимально понимать смежные области.
Ну если проект серьезный, то у вас будет Software Architect, который в этом уже когда-то разобрался и исключит вот этот колхоз после релиза это
помогут программистам разобраться и понять проблему
на этапе планирования. И поможет отдельно обученным программистам не портить себе конечности из огнестрельного оружия. Возможно и качественные параметры улучшатся. Однако это не отменяет того, что желательно всем участникам процесса хотя бы минимально понимать смежные области. Но это только мое мнение. Или не только, не знаю.

Нормальный Software Architect ничего исключать не будет, а будет запускать прототипы и проводить тесты. И не забывайте про волшебную формулу


Прибыль = Доходы − Затраты

Уменьшаем затраты на сервера и системы охлаждения, увеличиваем прибыль.

Теперь я спокоен за фронтенд, статичный HTML и всякое такое

К сожалению, часто сталкиваюсь с программистами, которые не знают и не понимают, как работает компьютер, и почему его программа "не работает". В чем разница между 127.0.0.1 и 0.0.0.0, что такое DNS. Абстракции это хорошо, но знать базовые вещи НЕОБХОДИМО.

В целом полезно для определении «базовых» знаний отталкиваться от задачи, а не от собственного багажа знаний.

Например у человека который меньше связан с сетью, и больше с разработкой компиляторов «базовые» знания будут совсем другие. Следуя вашей вы вероятно будете считать друг друга «людьми которые не знают и не понимают, как работает компьютер» что не очень хорошо влияет на продуктивность :)

Я наверное не совсем правильно выразился, при своём примере. Речь шла о том, что программист при запуске своего Web-приложения, утверждал, что оно у него на его рабочей станции работает, а другие не могут подключится к его приложению. Как выяснилось через пару минут, приложение было запущено на 127.0.0.1, как только перевесили на 0.0.0.0, все заработало. При этом он был уверен, что это одно и тоже, "ведь у него работает".


Конечно, у каждого есть свои нюансы в программировании и работе, кто то компилятор пишет, кто то сайты на друпале или ещё что то, но базовые вещи надо знать.
А то по наберут по объявлению… (С) не помню :)

Так и я не могу согласиться, и много кто ещё, но программисты уже массово не имеют представления, как компьютер работает, потому что абстракции над абстракциями везде. Да и не видны эффекты от этой же фрагментации почти нигде за пределами топ-100 сайтов рунета.

Да он про хренового программиста говорил.
Векторные инструкции. Разработчикам баз данных, интерпретаторов и виртуальных машин, библиотек придется поддерживать еще одну платформу. А для этого нужны девкиты. О чем собственно Торвальдс и говорит. А то может получится, что у разработчика на его рабочем x86 все прекрасно работает, а на ARM тормозит.
Даже разрабатывая на яве можно столкнуться с багами в коде, которые воспроизводятся только на арм-архитектуре. Там есть отличия в плане memory barriers, которые бывают критичны в многопоточке (а ядер на армах обычно много)

Если на какой-то платформе нарушена jmm, то это бага связки jvm-платформа, и, если платформа не позволяет это красиво пофиксить, то втыкают костыли в jvm.

Дело в том, что некоторые платформы дают больше гарантий, чем обещает JMM. И как итог, разработчики тестят на своих x86 и всё норм. А потом деплой на ARM и фантомные баги.
Баг в пользовательском коде (нарушение JMM), вот только на x86 этого может быть не видно.
Старому зануде Пингвинусу лишь бы погундеть.

АРМ хорошо, потому что недорого, а значит — в перспективе, массово. А все эти забубеные хрени, о которых он говорит, на 99% решаются разными уровнями абстракции.
АРМ хорошо, потому что недорого

Рановато пока об этом говорить. Процессора пока нет и ценника мы не знаем

Ну, чудес на свете не бывает, ARM достаточно последователен, гнёт свою линию не первый год.

Гнет то гнет, но недавно хажавался целью поднять свой максимально дешевый впн. Целенаправленно искал сервера на арме, но везде х86 оказался дешевле или имел такие преимущества, за которые совсем не жалко переплатить.

Ну, просто пока что мало таких решений.

Но вот я, например, не видел ни одного смартфона на x86. Зато на ARM их пруд пруди. Мне кажется, это потому что смартфоны не отягощены «железным» наследием Intel, как компьютеры (и серверы, в частности).

Думаю, в конце концов ARM либо подвинет, либо вытеснит X86. Дело времени.
Было достаточно много смартфонов на intel atom когда интел пытался залезть в эту нишу. Потом поняли, что поезд ушел и бросили эту затею.
ASUS Zenfone — внутри Intel z-какой-то, обычный телефончик, ничего выдающегося. Но себе больше не куплю (хотя тут наверно больше заслуга самих ASUS). Планшеты на z-каких-то всё ещё выпускают.
У меня был. Тут скорее заслуга их обоих. Asus ругались на Intel по части сложности сотрудничества. И какие-то из российских разработчиков тоже, что даже инфу о доступности и ценах процессора получить было сложно.
Разве раньше нужно было знать как работает тсп? он аппаратно инкапсулирован, а нам предоставляется только интерфейс в виде сокета.
По моему даже если пишешь драйвер для сетевой карты, тебе все равно нечего с ним не сделать.
Ну разве обычный ПК домашний, или любой серверный что предоставляют, может как то работать с тпс кроме как через сокет? Например изменить схему рукопожатий или заголовки, насколько я знаю нет, кроме того что нам доступны какие то параметры вроде mtu мы вообще больше никак не на что не влияем.
Именно отсюда и выходит что нет возможности быстро пересесть с ipv4 на 6.
Кроме хобота у этого слона есть и другие части тела…
Навскидку — habr.com/ru/company/smart_soft/blog/184430

А с «пересадкой» вообще «мимо тазика» — это, преимущественно, инфраструктурная проблема
Redis, который сам по себе является низкоуровневым кодом, спокойно работает на ARM, все тесты проходят, и нет никаких проблем со стабильностью. А раз уж код, написанный на C

Простите великодушно, но с этого места я начал смеяться. Наверное, у меня уже необратимо тяжёлая профессиональная деформация.
P.S. Чтобы не быть неправильно понятым. Я немало кода написал на взаправду низкоуровневом asm-е, в том числе под ARM с активным использованием NEON-а (это его SIMD-ы). И этот код, мягко говоря, не тот же самый, что для AVX и иже с ним. И вот, читая первое предложение из приведённой выше цитаты, я даже затаил дыхание в ожидании откровений на тему непринуждённой поддержки двух разных наборов инструкций в низкоуровневом коде. Но дочитав второе предложение до того места, где обрывается цитата, не смог сдержаться.
Полностью согласен. Это тот самый редис, который долго не умел нормально работать в кластеризованном режиме, согласно Jepsen-тестам. Молодцы, а чо?
Он и сейчас нормально не кластеризуется. И вообще эта недософтина полностью игнорирует архитектуру многоядерных ЦПУ утилизируя только одно ядро и выедая с его помощью кеши так, что рядом ничего толком не может крутиться.
ну, это не плохо и не хорошо. Просто данность. Тот же node.js однопоточный. golang — он тоже в первую очередь на одном процессоре, предлагая кооперативную многозадачность. Это сейчас тренд такой.
И даже если взять многопоточный софт, например, nginx — все равно требуется настраивать кол-во потоков (workers X) под конкретную нагрузку.
nginx — worker_processes auto;
обычно этого вполне достаточно.
Да вроде не тренд, просто было бы странно если бы софт магическим образом работал на несколько ядер, ну а интерфейсы потоков представляют все топ яп, так что я хз зачем вообще везде пишут что нода однопоточна.
Вы попутали.
nodejs — eventloop для сокетов и нормальным образом создаёт thread per worker.
golang — см. runtime.GOMAXPROCS()

Redis все запросы лопатит в одном thread, т.е. вообще в одном, причём этот один thread является main процессом. Ещё три thread'а, служебные (сброс на диск, лог...). Этот же main и моет CPU-кеш так, что всем остальным процессам в системе просто приходится курить, ну или начать конкурировать роняя производительность этого «супер-пупер-дупер быстрого» Redis в пол вместе с ростом латентности в потолок. Т.е. настроить его под нагрузку толком нельзя, кроме как запустить по redis'у на сервер и воткнуть перед ними какой-нибудь twemproxy, при этом это всё адский оверхед по железу и выглядит всё как костыль на костыле.
Я-то как раз ничего не попутал.
Асинхронщина и eventloop не отменяет однопоточности. Собственно, какая разница для нас сколько потоков, если они все блокируются на i/o?
golang — см. runtime.GOMAXPROCS()

Спасибо, я в курсе. Но это не отменяет того факта, что goroutine — это кооперативная многозадачность, а треды — вытесняющая. В этом отношении голанг несомненно хорош, что предоставляет некую гибридную модель.
Т.е. настроить его под нагрузку толком нельзя, кроме как запустить по redis'у на сервер

ну, норм вариант — ставить на один сервер несколько редисов, не?
при этом это всё адский оверхед по железу и выглядит всё как костыль на костыле.

соглашусь. Выглядит как костыль. Поэтому в своих проектах используем aerospike — он реально как (на старом сайте был какой-то ракетный движ изображен) ракета.
Субъективно, Вы всё попутали )
Причём тут отмена однопоточности? Речь о производительности.
io — который сейчас очень быстрый или aio — когда у тебя ssd хранилище на 1млн iops, а redis упёрся в потолок производительности одного ядра процессора при загрузке по io <1%.
> ну, норм вариант — ставить на один сервер несколько редисов, не?

Если нагрузки нет, можно хоть по пять redis'ов на ядро процессора.
НО когда есть нагрузка, то хоть у процессора и 128 ядер, а кеш (LLC) один и его когерентность выходит боком, когда redis активно задрачивает кеш в один thread на максимуме
UFO just landed and posted this here
Лучшее, что можно сделать сегодня (если нет денег на упоминавшийся тут уже Thunder X2) — купить Chromebook.

Мерять скорость на мобильнике — это себя не любить, там троттлинг начинается через пару секунд 100% загрузки одного ядра. А вот ChromeBook — он достаточно большой, чтобы на одном ядре можно было уже гонять бенчмарки без троттлига. А многопоточка — она и на «больших» процессорах и серверах скорость одного ядра ограничивает, так что разницы нету…
UFO just landed and posted this here
А смысл во всём этом, извините? Бенчмарки на виртуалке запускать в любом случае странно, а если не мерить скорость — то любой сотовый имеет сегодня такой же NEON, как и все эти серверные процессоры на AWS…
У scaleway есть ещё дешёвые ARM машинки.
ARM-железа у меня нет (мобильники не в счёт)

Во всех случаях у меня целевая платформа была как раз мобильная (+ близкие к ней smart box-ы) поэтому в качестве тестового железа я использовал какую-то мелкую плату разработчика (за давностью лет не помню, какую конкретно) и различные смартфоны (всё это богатство было подключено к Дженкинсу и настроено умными людьми ещё до меня). Позже тестировал свой код на iPad-е, начиная с тех версий где завезли поддержку ARMv8 (+ mac-mini в качестве платформы для разработки).
Для проверки корректности работы кода в обоих случаях я использовал unit test-ы, в которых верхний уровень был написан не мной. Логику непосредственно проверки я писал сам (я знаю, что это не совсем правильно, но я очень старался не давать своему коду поблажек в плане разнообразия тестовых воздействий). Ну и конечно, были regression-тесты в боевом приложении.
Ускорение оценивалось разными способами. Во первых, банальным измерением времени работы многократно запускаемой оптимизированной функции (в unit test-е). Ключевым моментом является именно многократность — когда количество запусков такое, что тест бежит несколько минут, можно отследить эффект даже от замены единичной asm-инструкции на другую. Во вторых, профилирование в Xcode для случая с iPad-ом. Ну и, в третьих, итоговый эффект оценивался измерением fps-ов в боевом приложении.
P.S. Кстати, о тротлинге. А этом отношении комрад khim прав. На мобильных устройствах с нагревом тяжко. Мы колхозили дополнительное охлаждение и к платам разработчика и мобильным девайсам. Были даже мысли обзавестись холодильником для этих целей. :) А вот iPad на удивление такой проблемой практически не страдал. Возможно за счёт размера.
Нотификация больше не нужна, возможно теперь не будут заворачивать?
Не знаю, не интересовался. Нужно копать.
Тем не менее, создатель Linux Линус Торвальдс скептично прокомментировал анонс.

Прокомментировал? Да он же опять всех идиотами и дебилами обозвал. Эх, талантливый человек, но полностью бестактный.

Собственно не совсем понятно, откуда такие понты, ведь 99% вклада в Linux сделано сообществом, а не им лично — он просто вовремя появился со своим свободным вариантом UNIX-ядра, которое, впрочем, ничем особенным в техническом плане не отличалось.

суметь организовать миллион гиков — это очень и очень круто. гики (в хорошем смысле) восприимчивы к техническим аргументам. и вот Торвальдс до того хорош по части технической аргументации, что справляется с ними… ну или справлялся (я перестал следить).
Дано: Вы известная IT-компания. Линус послал вас далеко и надолго.
Решений собственно два:
1 (со звёздочкой) — выделить из его посылов рациональное зерно и учесть в работе, потому что такой человек зря воздух сотрясать не будет.
2 (не требует мыслительных усилий) — выделить из его посылов все факи и скинуть их ближайшему SJW-отряду быстрого реагирования, который уже разберётся с негодяем по-свойски.
На самом деле все упирается в стоимость.

Если, например, Amazon EC2 и гугл предложат сопоставимые по производительности ARM конфигурации с ценой в два раза меньше x86 — народ подтянется, никуда не денутся.

Другой вопрос, что пока все не столь радужно с ценой этих решений.
Если, например, Amazon EC2 и гугл предложат сопоставимые по производительности ARM конфигурации с ценой в два раза меньше x86 — народ подтянется, никуда не денутся.

Простите, а откуда появится цена в два раза меньше x86?
Глянул цену современных ARMов, которые потенциально можно использовать в серверах, так она не такая уж и радужная.
А остальное железо — память, диски, набор логики стоят столько же
Экономия на электроэнергии?
Так ведь и здесь не все так однозначно получается, если TDP сравнивать
Может. Для задач нечувствительных к операциям с плавающей точкой.
Ну те же веб приложения и базы данных.
Просто за счет того, что сильно больше ядер и больше эффективность на единицу площади и на ватт.
Но пока не сильно видно.
ТДП очень хитрая характеристика. У интел в последнее время — очень хитрая. Во всяком случае на нагруженных серверах потребление сильно выше их ТДП с учетом памяти, диска и всего остальное.
а почему оно должно стать в 2 раза меньше? я вообще пока не очень понимаю смысл всей это попеи с ARM. когда на телефон ставят ARM вместо x86 — это понятно, масштабирование вниз, производительность не нужна, нужно батарейку беречь и для idle можно добавить совсем уж медленно ядрышко. а в облаках такой проблемы нет, там загрузку по необходимости можно добавить, спасибо виртуализации. там как раз нужно масштабирование вверх.
если вдруг у ARM будет значительно ниже цена в пересчете на какую-то полезную операцию — тогда может быть. но откуда? другая физика? другие материалы? частоты там близкие сейчас…
если вдруг у ARM будет значительно ниже цена в пересчете на какую-то полезную операцию — тогда может быть. но откуда? другая физика? другие материалы? частоты там близкие сейчас…

оптимизация на уровне кода? оптимальность структуры команд с одинаковой длиной (или ARM, как и x86, имеет переменную длину команд?)
транслятор в uops — это мизерная часть, насколько я понимаю. много на нем не сэкономишь.
Зависит от остального. Если у вас большое, сложное и горячее ядро под максимальную скорость в однопоточке — то нет. А вот если у вас сотня простых и мелких ядер — то легко.

Но не всякую архитектуру на такую конструкцию портирует…
и почему все это сотня простых и мелких не может эксплуатировать несколько «крепких» ядер?
Потому что в тепловой пакет сотни простых и мелких ARM-ядер на 1GHz влезет одно скоростное ядро на 4GHz от Intel — которое по скорости их явно не догонит.

Вот только программисты не умеют писать софт под 100 мелких и простых ядер — а под одно скоростное — умеют. И вот пока эту проблему не решат — ARM на сервере будет «сливать»…
Вот только программисты не умеют писать софт под 100 мелких и простых ядер

Программисты-то умеют. Задачи не все раскладываются на 100+ ядер…
en.wikipedia.org/wiki/Amdahl%27s_law
Нет — программисты именно что не умеют. Амдал — он, конечно, велик и могуч, но он не объясняет как вообще система с процессором не то на 100Hz, не то на 1000Hz под кодовым называнием «Home Sapiens» может вообще решать большинство задач, с которыми она сталкивается.

Я думаю на 99% проблема с «принципиальной нераспараллеливаемостью» тех задач, которые решаются на современных компьютерах связана не с тем, что задачи, связанные с реальным миром (ну там «переслать видео из точки А в точку Б» или «подрисовать на фотографии усы») состоят из непараллелящихся подзадач (которые портят нам «всю малину»), а потому, что вся компьютерная индустрия последние полвека занималась тем, что алгоритмы, требующие десятков, сотен, а то и миллионов «ядер» — выкидывала в мусорную корзину и тщательно отбирала лишь такие, которые могут эффективно работать на одном однопоточном ядре.

Потому и потребуется для изменения не год, не два, а десятилетия. Но выхода, по большому счёту, нет: за последние 10 лет производительность одного ядра выросла, дай бог, вдвое (притом что производительность всяких GPU/TPU выросла в десятки и сотни раз), так что выбора у нас нет, нужно брать вышеупомянутую «корзину» и смотреть чего там найдётся… но для этого нужно, чтобы всякие Knight Mill'ы и тому подобные звери были не только на суперкомпьтерах, но и на столах у разработчиков…
Все таки не всегда получается. Я вот как раз в основном на GPU и пишу с 2005 года (реконструкция CT images, собственно первая на GPU, GE Medical, примерно половина сканеров в мире ), так что сталкиваюсь регулярно, что то раскидывается, а что то нет.
Пример из другой области, более понятный:
Работу не всегда можно раскидать по произвольно большой группе людей. Тот же закон Амдала и тут работает. Девять женщин ребенка за месяц не родят…
Не все распараллеливается (:

PS: Если Вы знаете как распределить произвольный алгоритм, напишите статью, сможете получить несколько нобелевских или что там еще. Впрочем, насколько мне известно формального доказательства принципиальной невозможности распараллеливания нет. Так что карты в руки. И извиняюсь за наезд, это не лично к Вам, просто начальство достало ровно с Вашими аргументами.
Все таки не всегда получается.
Я бы сказал так: не всегда получается на GPU. А у GPU — архитектура очень, как бы сказать, специфическая. Она под очень узкий класс алгоритмов заточена. Что и как можно делать, чтобы параллелить, условного говоря, GUI — мы не знаем.

Гораздо хуже, впрочем, то, что мы разработали сами для себя кучу ограничений, которые вполне могут обозначать, что часть задач, которые мы сами себе придумали — не параллелятся в принципе.

Или, условно говоря, задача «добавить блок редактирования на web-страничке» — вполне может параллелиться, а вот задача «отреагировать на изменение DOM-дерева в соответствии со спецификациями HTML и CSS» — уже нет.

И мы не знаем на какую глубину нам придётся разбирать здание IT, перед тем, как мы сможем его перестроить под новую парадигму… а главное — последние лет 10 мы загоняем себя всё глубже и глубже в тупик, выбираться из которого будет ой как непросто: почти все последние разработки по-прежнему рассчитаны на одно обченно-обченно быстрое ядро, а не на сотню параллельно работающих объектов…
В реконструкции работа как раз раскидана и на GPU и на все свободные ядра CPU (кроме псевдоядра собственно контролирующего GPU /GPUs ), и до появления GPU картинка тоже как то восстанавливалась у нас. Несмотря на то что разрабатываемые алгоритмы весьма хорошо параллелятся все равно где нибудь да упрешься или в шину или ещё куда нибудь. Амдал работает, гад. Поговорите с людьми пишущими на FPGA, они Вам объяснят стоимость распаралелливания хотя бы простых арифметических операций
Человек — это скорее FPGA. Мозг сильно заточен под распознавание лиц людей, например, поэтому именно с этим проблем нет. Нетривиальная логика — тоже есть. То есть те функции, на которые миллионы лет оптимизировала эволюция. А попробуйте перемножить два int32 числа, или удержать в памяти с сотню байт — у вас это получится намного хуже, чем даже у 100гц компьютеров.

Касательно «выкидывания в корзину» параллельных алгоритмов — это вы сейчас странное сказали. Любой параллельный алгоритм может быть выполнен последовательно. Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени. Другое дело, что задача создавать параллелизуемые алгоритмы сама по себе не ставилась. Но они и менее эффективны в целом, и требуют затрат на синхронизацию, и для понимания сложнее, так что до недавнего времени не были так востребованы.

Ну и не стоит останавливаться только на параллельности. Можно развивать FPGA и делать хорошие конвейеры. Возможно, в будущем у процессоров или отдельно по PCI будет несколько FPGA массивов, и высокопроизводительные приложения будут их использовать, как сейчас видеокарты.
А попробуйте перемножить два int32 числа, или удержать в памяти с сотню байт — у вас это получится намного хуже, чем даже у 100гц компьютеров.
Обычный человек на это неспособен (как вы верно заметили — «прошивка» не та), но соотвествующие номера в цирке демонстрировались — то есть в принципе мозг на это способен. А 100Гц компьютеров в природе не бывает: уже ЭНИАК — это 10кГц (но один процессор!)… С него всё и пошло.

Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени.
Может и почти всегда будет. Опять-таки, вернёмся к мозгу: «частота» — меньше килогерца, но общее количество операций, выполняемых в ту же секунду… суперкомпьютеры [пока] отдыхают. То есть плата за «широкую» параллелизацию — это увеличение общего количества операций на несколько порядков.

Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени.
С чего вы взяли? Наоборот, как правило хорошо параллелящиеся алгоритмы требуют больше (часто сильно больше) операций. Если исполнять их последовательно — получим проигрыш.

Можно развивать FPGA и делать хорошие конвейеры. Возможно, в будущем у процессоров или отдельно по PCI будет несколько FPGA массивов, и высокопроизводительные приложения будут их использовать, как сейчас видеокарты.
Это всё лирика. Главная проблема, которая заставляет нас использовать процессоры на много гигагерц — это фабрики фабрик фабрик, которые превращают любое простое действие в последовательное взаимодействие сотен объектов. И тут уже пресловутый «закон Амдала» встаёт в полный рост: если вам, чтобы принять решение, нужно передать данные через сто посредников — то вы можете делать это последовательно или параллельно, синхронно или асинхронно, на одном ядре или на сотне… но пока все сто обрабочиков последовательно не отработают — ответа вы не получите.

И что с этим делать — не знает никто. Известно только, что человек — так не работает. От момента, когда вы видите улыбающегося младенца до момента, когда вы улыбатесь ему в ответ не проходит достаточно времени для того, чтобы цепочка из хотя бы нескольких сотен нейронов успела сработать. Всё поведение основано на цепочках, которые гораздо короче, чем цепочка связанных объектов, отрабатывающих клики при наборе текста на вот этой вот страничке Хабра.

Не будете же вы утверждать, что страничка Хабра — это более сложная вещь, чем человек?

Где-то мы свернули «не туда» в дизайне компьютерных систем… но пока неясно как это исправить…
С чего вы взяли? Наоборот, как правило хорошо параллелящиеся алгоритмы требуют больше (часто сильно больше) операций.

Тут извиняюсь, ошибся. Хотел написать «хуже».
Всё поведение основано на цепочках, которые гораздо короче, чем цепочка связанных объектов, отрабатывающих клики при наборе текста на вот этой вот страничке Хабра.

С другой стороны, у поведения имеется огромное количество когнитивных погрешностей, которые возникли именно из-за этой оптимизации. Представьте, что вы сотню лет пишете и переписываете код этой странички. Естественно, за это время вы успеете перепробовать тонну подходов, выучите или создадите ассемблер и напишете на нём. И это будет дико эффективно.
Где-то мы свернули «не туда» в дизайне компьютерных систем

Если у нас были кубики «О», «П», «А» и «Ж» — мы не могли сложить «Вечность». Всем требуется выпускать продукты «быстрее, ещё быстрее». А написать быстро, без ошибок и производительное — выберите два, как говорится.
вот нашел такое от 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) работа по разработке/доводке таких решений стоит немалых денег и не масштабируется (в отличие от железок, которых можно наклепать сколько угодно)
Для того, чтобы не попадать пальцем в небо по поводу энегропотребления рекомендбую прочитать про big.LTTLE и задуматься над вопросом: «а нафига в современных смартфонах 8 ядер, если работать одновременно могут только 4».

Что касается распараллеливания — то, опять-таки, рекомендую вспомнить, что в голове у человека «процессор» на частоту ниже одного килогерца (хотя и с миллиардами активных компонент) — если бы реальных задач, которые плохо параллелялятся было бы много, то человечество давным-давно бы вымерло.

Другое дело, что все программистские тулы, средства разработки, отладки и прочего — рассчитаны на однопоточный или, в крайнем случае, на малопоточный код и справиться с сотнями и тысячами «голов» просто не могут. Но тут как раз проблема курицы и яйца: пока у нас на рабочих стоят компьютеры не с сотнями-тысячами ядер по 1GHz, а с 4-6-8 по 4GHz — мы над всем этим задумываться не будем, а пока у нас нет библиотек под такое железо нам на подобных серверах — нечего запускать.
это большая наивность — думать, что параллельное программирование не развивается из-за гигагерцев на десктопах. тысячи (сотни тысяч) ядер давно уже есть — загляните на top500.org. как давно есть много тулзей и программистов и что там еще нужно.
И как много программистов имеют доступ к компьютерам из Top500?
немало. они же на них не работают постоянно. отлаживаются на простых системах, потом тестируют на системах побольше и так далее. но это не главное. главное, что изначально задачи ставятся работать в масштабе сотен тысяч — миллионов ядер.
Немало — это какой процент от 20 миллионов разработчиков, которые существуют? Сомневаюсь я что больше 1-2% что-то…

Так что да: ниша, где люди гоняют сильно параллелящиеся задачи — да, она есть, она существует, но если сравнить её с количеством людей, порождающих что-то на принципиально однопоточном JS… она всё ещё очень и очень мала…
зато процент головастых там значительно выше. ТО взяли не кол-вом.
Это неважно. Пока массовые разработчики будут использовать JS и Node.JS — на серверах будет рулить однопоток.

То есть да, то, что технологии разрабатываются на суперкомпьютерах и потом «спускаются» в персоналки — это всегда так было (и с суперскалярностью и с SIMD'ами — это всё суперкомпьютеры лет на 10-20 раньше, чем персоналки получили), так что и с параллельными программами так же будет.

Но мы пока в начале процесса.
так вот, докладываю… никаких «чудес» или суперинструментов или технологий «там» нет. нечего ждать. по-крайней мере сейчас так.
Для начала, какой процент от 20 миллионов разработчиков занимается разработкой сверхтяжелого научного/инженерного софта? А ведь масштабы миллионов ядер — оно для моделирования чего-нибудь.

И при чем тут Node.JS? Это несколько другие задачи. Это веб, и здесь идет параллелизм уровня запросов, а не вычислительных задач внутри него. И всякий веб, ынтырпрайз, мобильные/десктопные приложение итп (где, наверное, сосредоточена бОльшая часть разработчиков) чаще сталкиваются не с cpu-bound задачами.
И всякий веб, ынтырпрайз, мобильные/десктопные приложение итп (где, наверное, сосредоточена бОльшая часть разработчиков) чаще сталкиваются не с cpu-bound задачами.
Если бы они не были cpu-bound, то их можно было бы, условно, запустить на кластере «малинок». Однако — так «оно» не работает…
По оценке ARM, работая на частоте 3 ГГц, процессор на базе Cortex-A76 по производительности будет сравним с процессором Intel Core i5-7300U, работающим на частоте до 3,5 ГГц.

Врут. Либо сравнивают 4 потока Интела с 4 ядрами ARM.
По оценке 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, т.к. СО будет спроектирована с запасом)
это понятно. я в целом пытался сказать, что производительность/ватт должна быть близкая. нет смысла сравнивать 1GHz ARM и 4 GHz x86. просто потому что x86 тоже можно ограничить 1GHz, если абсолютная производительность не нужна.
просто потому что x86 тоже можно ограничить 1GHz
Если вы ограничите x86 — то упрётесь в то, что одно декодирование потока инструкций займёт больше ресурсов, чем всё, что делает ядро ARM. Вспомните: ARM2 — 30 тысяч транзисторов, 80386 — 275 тысяч транзисторов. Это ещё до интеграции кешей, FPU и прочего.

Когда вы делаете «большое», «тяжёлое» ядро — эта разница вас не волнует, само ядро будет сильно больше декодера в любом случае. А вот если вы делаете сотни «малых» ядер — это отличие очень даже может выстрелить.
Но чудес не бывает, в общем случае (если нет явных ошибок в архитектуре и задача не узкоспециализирована)
ядро из большего количества транзисторов будет иметь больший ipc или обработает больше данных

если удельную производительность ARM поднимать до уровня x86 то энергопоребление и цена также возрастут
если нет явных ошибок в архитектуре и задача не узкоспециализирована
Задача декодирования потока инструкций по определению узкоспециализирована.

если удельную производительность ARM поднимать до уровня x86 то энергопоребление и цена также возрастут
Совершенно верно — именно поэтому ARM'у бессмысленно соревноваться в одноядерной производительности с x86. А вот Intel'у — бесполезно пытаться пролезть в IoT.

Но вот вопрос: может ли сильно большая «производительность на ватт», которую даёт ARM, помочь ему выиграть на серверах? Ответ — зависит от программистов, очевидно.
с теми же кортекс А7 х86 конкурировать в производительности на ватт никак не сможет. 90мВт на 1.3ГГц на ядро. кварки — и те больше кушали (при никакой производительности)…
ключевое — выделил. 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 ядрах.
под какой именно нагрузкой? одно дело — memcpy гонять, другое — linpack с avx512.
Cinebench R15, Prime95. В Linpack любой чип будет есть больше.
Прямо такие сотни? Я не уверен. Попытался поискать информацию, но везде SoC'и с GPU. Ну и да, идея не нова, Intel делал в свое время Intel Xeon Phi с кучей маленьких ядер. Ну и где он теперь?
Попытался поискать информацию, но везде 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² на ядро. С соответствующей себестоимостью и стоимостью…
Мой Core i5-2500K (SandyBridge, 32нм, 4 ядра х 4,3ГГц) при 100% BOINC вычислениями потребляет до 105 Ватт. Тут около 25 Ватт на ядро 2011 года.
Если загрузить чем-то вроде расчётов числа Пи для стресс теста, то потребление будет больше, но это совершенно нетипичная нагрузка.
Присоединюсь к 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, рабочие частоты), но неизбежно потеряет по пути свою энергоэффективность.
При этом даже на 1 ГГц х86 ядра в большинстве задач, кроме самых простых оказываются в 2-3 раза быстрее чем ARM @ 1 ГГц

Уточняйте, какое ARM ядро вы имеете в виду. Их довольно и они покрывают диапазон от микроконтроллеров до серверов.
Apple A12 имеет IPC местами выше чем у Skylake (и его клонов), при весьма скромном энергопотреблении.

Наклепать кучу низкочастотных x86 ядер… — вообще не вопрос.

Гладко было на бумаге, да забыли про овраги(с). 4.5W Core-m перегревается под нагрузкой моментально и тротлится до 1GHz. Лёгкая добыча.

если будет предлагаться в текущем виде, т.е. много дешевых медленных ядер

С чего вы взяли что они медленные? ThunderX2 используется в суперкомпьютерах, например.
А ещё дополню, что пока медленный будет работать дольше, чем быстрый, разница в суммарном потреблении на решение одной задачи будет уменьшаться.
И ещё можно добавить экономический эффект от того, что быстрый обслужит больше клиентов и будет приносить дивиденды, пока медленный ещё продолжает обработку.
Наклепать кучу низкочастотных x86 ядер, отрезав «лишнее»(большие кэши например) и попутно снизив им рабочие напряжения до минимума и за счет этого получить близкую к ARM энергоэффектиность (только без геморроя и вопросов совместимости/миграции между разными архитектурами) — вообще не вопрос.
Для мегагения Mad__Max — так конечно. А то у Intel что-то всю дорогу огредышащие монстры получаются. И даже когда они одно «простенькое» ядро делают — тоже: получается почему-то гораздо хуже, чем если использовать ядра ARM. Думаете в Intel процессоры разрабатывать не умеют?

Даже внутри одной полностью совместимой архитектуры, подход «много медленных, но зато дешевых ядер» проиграл.
Именно потому что внутри одной архитектуры вы не можете сделать взамен одного быстрого ядра сотню. Можно сделать 3-4, не больше. Во всяком случае Intel больше не смог. Вы, возможно, сможете…
В суперкомпьютерах пашет, где для него есть достойные задачи.
Thumb имел переменную длину команд (либо 16 либо 32 бит); в AArch64 все команды длиной 32 бит.

Но в общем, «оптимизация на уровне системы команд» для потребительской платформы — это pie in the sky: для новой архитектуры можно сделать систему команд, максимально соответствующую микроархитектуре, но под эту новую архитектуру не будет софта. (Так и было в самых первых ARM.) К тому моменту, когда софта станет много, архитектура уже не будет соответствовать новым микроархитектурам, и в новых процессорах придётся реализовывать хитроумную трансляцию в uops. (По этому пути пошли и x86, и ARM.)
Давно бы перешел на арм, но серверов нет (а те что есть — днище). Ноутов на арме тоже как-то не видать.
Ноуты на ARM часто обладают неплохой автономностью.
Например Lenovo Yoga C630 (на Snapdragon 850), по заявлениям производителя, на одном заряде держится до 25 часов.
Для сравнения, по тестам с сайта laptopmag.com, долгожителем среди x86 ноутов является Lenovo ThinkPad T480 (Core i5-8350U), который продержался 17 часов 19 минут.
(К сожалению не нашёл сравнения производительности.)
Если хотите серьезный сервер, то смотрите в сторону плат с ARM64, с поддержкой UEFI. Такие платы работают так же, как обычные x86-компьютеры: загружаются с флешки из обычного общего образа флешки или .iso, имеют UEFI-меню с настройками.

См. www.96boards.org/products, wiki.ubuntu.com/ARM/Server/Install
Из дешевых: libre.computer

Сервера есть, а вот приличный devbox стоит 1200$, и в России подобное не купить скорее всего. Получается, Линус пока прав.

а вот приличный 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к
96 boards — помойка. Купил плату на Helio X20 за $200. Как оказалось работал там только Андроид (да я дурак, не проверил). Сейчас сайт поддержки мёртв.
Сама плата то же не ахти. Накопитель — только флешка.
Прошелся по схеме Wifi модуля — кучи компонентов не хватает (конденсаторов). И так сойдёт!
Плохой инструмент всё равно что его отсутсвие, а очень часто даже хуже.
Пример — отвёртка. Можно купить дешёвую китайскую отвёрку за копейки, которая после нескольких операций потеряет жало и станет бесполезной. Это не отвёртка, это хлам.
Thundex X2 «жало» не потеряет. Он вполне сравним по скорости со своими «одноклассниками» на X86 за $5000-$10000… к сожалению и по цене — тоже.

То есть в диапазон, указанный Линусом ($500-1000) он снова не попадает — только теперь уже не потому что «хлам тормозной» (как Raspberri PI), а потому что цена у него серверная… а посредине, между ними… зияет пустота.

Лучшее, что существует — это Хромбуки, но они, как бы, всё равно сильно недотягивают до рабочей станции — и по цене (что неплохо), но и по объёму памяти, SSD и прочего (а вот это — уже проблема).
Ну малинка точно не является серверной машиной :)
Хотя признаюсь, сам я на ней пару простых серверов, как например, меди-сервер и бекап-сервер держу.
А так, солидарен с вами.

Хотя в данной области я не разбираюсь.

Однако я в ARM верю.
То как работает новый iPad Pro тому показатель.
Рендер сравним с полноценным топовым макбуком.
Чем плохи гигабайтовские ARM серверы? Они собраны на довольно быстром ARM, который используется в нескольких суперкомпьютерах.
по обещаниям должно дать 60% прирост по сравнению с текущей платформой

Наконец-то! Давно ждали! Впечатляющие цифры! Остаётся понять, о чём тут идёт речь...

скорее всего на них сбросят всякую глупую чепуху, вроде фронтенда

Вот сейчас обидно было

Правильно. По заветам суровых линуксоидов, «веб-макаки должны страдать». (И пофиг, что linux на самом деле и взлетел благодаря таким «веб-макакам»)
Подавляющее большинство установок Linux — это встроенные системы, где никаких «веб-макак» и в помине нету.

К тому же код, разработанные веб-макаками исполняется в Windows на клиенте, а не на Linux-сервере.
Ну так он эту мысль прямо с поверхности взял. Архитектура сильно другая. Под нее надо наработать кучу кода и практик, чтобы платформа реально выстрелила. Выиграть только количеством ядер не получится. При имеющемся софте мне устройства на arm кажутся менее отзывчивыми. Хотя это может быть и субъективным ощущением.
Так и есть, им далеко до десктопных процессоров.
Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.
Речь человека, который застрял во временах C/C++. Но ведь уже есть языки типа Rust, которые без бубна компилируются под разные архитектуры.
Но ведь уже есть языки типа Rust, которые без бубна компилируются под разные архитектуры.
Угу. Под целых 14. А под ещё десяток — не компилируется. В отличие от ядра Linux…

Речь человека, который застрял во временах C/C++.
Речь человека, программы которого работают на таком количестве архитектур, с которыми сравнивать Java или Rust просто смешно: разница не на одну-две архитектуры, а в разы (Linux — поддерживает 25-50 архитектур — смотря как считать, rust поддерживает порядка 10-15 архитектур — опять-таки смотря как считать, Java — ну где-то с полдюжины «живых» архитектур осталось).
rust поддерживает порядка 10-15 архитектур — опять-таки смотря как считать

Rust ничего не может поддерживать — поддерживает llvm.
О, уже побежали минусовать адепты раста. Но я, специально для них, поясню. Компилятор раста имеет всего один таргет — это llvm-ir, но даже его он не генерирует самостоятельно. Таким образом ни о каких 10-15, да даже о двух архитектурах речи идти не может.

Так же, даже если мы забудем об этом факте — хост-компилятор раста зависит от С/С++ кода и не может быть более портабельным, нежели С/С++-код, т.к. напрямую зависит от него.

Так же, даже в рантайме раст зависит от llvm-рантайма и libc — таким образом тут он не может быть портабельнее С/С++ т.к. напрямую зависит от них и в рантайме.
Я не думаю что тут минусовали «адепты раста». Скорее нелюбители занудства. И неправды. Да, настоящее время раст имеет ровно один компилятор — но это не значит, что так будет всегда. И можно себе представить и написаннаю на нём OS и его работу на «голом железе» — он достаточно низкоуровневен для этого.

Так что ваше высказывание — неверно просто по факту: да, таки раст может-таки поддерживать архитектуры, которые не умеет поддерживать LLVM — просто так получилось, что сейчас — это не так.

Всё равно что обсуждать Формулу-1 и зациклится на том, что шины у всех команд — от Pirelli. И что, дескать, они всё и определяют. Сегодня да, а завтра, может, Goodyear вернётся или Bdigestone…
Да, настоящее время раст имеет ровно один компилятор — но это не значит, что так будет всегда.

Какая глупость.

Да, настоящее время с++ имеет ровно проблемы — но это не значит, что так будет всегда.

Поздравляю, вы умножили на ноль основной довод к существованию раста, который каждый день ретранслируется на хабре.

Так что ваше высказывание — неверно просто по факту

Оно верно по-факту. И вы даже не сообщили в чём именно оно неверно.

да, таки раст может-таки поддерживать архитектуры, которые не умеет поддерживать LLVM — просто так получилось, что сейчас — это не так.

Какие основания у этого утверждения?

В конечном итоге я так и не увидел основания для «неверно». К тому же, как всегда был проигнорирован основной тезис, а именно «без бубна компилируются под разные архитектуры.» — тут говорится именно о лучшей портируемости раста. Попытки вида «потом что-то будет» не работают, даже если в них поверить. Ведь он не просто должен быть портируемым на пару платформ, но и портироваться проще и шире(как минимум не уже).

Ну и конечно же, я мог бы сослаться на

без бубна компилируются под разные архитектуры

компилируются

Это настоящие время, а не фентезийное. И этого уже было достаточно для опровержения ваших рассуждений.
Но ведь уже есть языки типа Rust, которые без бубна компилируются под разные архитектуры.
Слова человека, который никогда серьезно не задумывался о производительности. Не в языке дело, а в разных возможностях у разных архитектур.
Итак, выпускается железо, имеющее сравнимую с х86 производительность, но с гораздо меньшим энергопотреблением. Хоба — и различные регионы с плохим электричеством (Африка, Азия, какая-нибудь Сельва) — все в твоих руках!
UFO just landed and posted this here
Тяжело доступное, бывающее редко или вообще доступное только из генератора/солнечной панели.
Пчёлы против мёда, Линус против линукса ARMa. Во всяком случае для Linux'ов смена архитектуры ядра должна быть наименее болезненной. Они не первый год десятилетие на ARM-ах крутятся. GCC прекрасно эту архитектуру поддерживает (LLVM — тоже, хотя последний как раз конкурирующая организация поддерживает, но на серверах Apple вообще никому не конкурент). Со скриптовыми языками тоже всё неплохо. Python для «малинки» — мейнстрим, а если какой Perl для ARM специально не оптимизировали (на самом деле, как оно с перлом — не в курсе), тот уже дело соответствующего сообщества доказать, что их язык — живее всех живых (и докажут ведь). Сложно (почти невозможно) разработчику купить linux-ноут с ARM-ом внутри? Ну так с чего-то начинать надо, Linux вон до сих пор на десктопах — экзотика, а на серверах — вне конкуренции. А так, появится спрос (хочу процессор как на сервере, для которого разрабатываю), появится и какое-никакое предложение. И это будет лишний гвоздь в будущий гроб морально устаревшей, обмазанной многими слоями legacy (и вследствии этого греющей воздух) wintel-архитектуры.
А что такое архитектура wintel применительно к серверам, подавляющее количество которых на Linux? Если речь про x86, то что именно морально устарело в этой архитектуре (интересут мнение касаемо технологической составляющей). Потому как по число разных технологичных штук (HT, SIMDs и т.д.) эта архитектура (и ее реализация ) не смотрится так уж бледно.
Слои совместимости. Которые нужны как раз для нормальн6ой работы старого проприетарного кода и на серверах не сильно требуются.
Пчёлы против мёда, Линус линукса ARMa

Он не против ARM. Это критика ARM вендоров, которые замахнулись на межпланетные полёты, в то время как инженеры вытирают задницы придорожным лопухом.
Не, если воспринимать это как крик разработчика, «не забывайте нас, дайте нам возможность приобрести приличные, по адекватной цене, домашние компьютеры с такой архитектурой, чтобы мы могли спокойно разрабатывать для неё софт» — ок, всё нормально. Надеюсь кто-то, от кого это зависит, его услышит и поймёт правильно.

ps. И да, я бы на месте этих самых вендоров предложил бы такие машинки по себестоимости (а то и чуть меньше) университетам. MIT там, Berkeley и т.д. Оно как-то сильно поспособствует.
Там проблема не в себестоимости. Разработка очень дорого стоит вот этого вот всего. Когда вы выпускаете Raspberry PI миллионными тиражами — они амортизируется, когда серверное железо за десять тысяч долларов — там уже с сотни экземпляров прибыль, а тут надо вложить миллионы долларов, а продать потом сотню или, в лучшем случае, тысячу штук — планово-убыточное мероприятие…
Что мешает выпустить ограниченной партией те же (уже разработанные) платы не напаивая на них 50тиканальные SAS, Тбит/с Ethernet и т.п. чисто серверные компоненты?
Здравый смысл? Основаная цена серверой платы, как уже говорилось — это цена её разработки и тестирования.

Выпуская ограниченным тиражом урезанную версию — вы, тем самым, уменьшаете количество людей, которые купят её за полную цену… то есть усугубляете проблему ещё больше.

А попытка продать её, условно, за $950 вместо $1000 (а это и есть примерная цена всех этих напаянных «50тиканальные SAS, Тбит/с Ethernet и т.п. чисто серверных компонент») приведёт к тому, что вам ещё и антирекламу сделают.

Нафиг это кому надо?
Заблуждение. Это называется "(ценовая) сегментация рынка". «Разработка» урезанной версии, практически, бесплатна и разница в цене может быть довольно-таки значительной если правильно распределить затраты на R&D между сегментами. «Суровый энтерпрайз» в любом случае купит полную версию (да еще и со специально спроектированным шасси и расширенной гарантией), а вариант с камнем попроще и без части интерфейсов, но по более низкой цене, вполне удовлетворит запросы разработчиков/энтузиастов в качестве основы для рабочих станций/стендов для отладки/экспериментов. А это, в свою очередь, формирует/расширяет сообщество разработчиков/пользователей и стимулирует спрос на топовые решения.
«Суровый энтерпрайз» в любом случае купит полную версию (да еще и со специально спроектированным шасси и расширенной гарантией)
«Суровый» — может быть. А обычные всякие Гуглы и Фейсбуки вполне себе готовы купить урезанную версию при её наличии. Ибо деньги считать таки умеют.

Сегментация рынка — да, это здорово, но над тем, чтобы не убить при при этом продажи в дорогом сегменте — приходится долго работать. Или уже забыли времена SMP-серверов на Celeron'ах? Они не так давно (по историеским меркам), в общем-то случились. И Intel'у пришлось изрядно-таки поработать над тем, чтобы подобные системы не продавались…
А обычные всякие Гуглы и Фейсбуки вполне себе готовы купить урезанную версию при её наличии. Ибо деньги считать таки умеют.

Гугль, Фейсбук или Яндекс скорее свой велосипед построят, а потом его еще и заопенсурсят. Да просто потому что могут!!!
Свой велосипед они будут строить не «потому что могут», а «потому что дешевле».

Для своих датацентров — да, они закажут миллион материнок под свой собственный форм-фактор и вы с этого ничего не получите, а вот для разработки и предварительной оценки — вполне могут пару сотен материнок у вас прикупить. Но они как раз не будут закупать самую дорогую модель — потому что для разработки им она и не нужна.

Так что описанный вами феномен делает выпуск дешёвых, урезанных, версий ещё более рискованным мероприятием…
При наличии подтвержденного спроса со стороны «простых Гугла и ФБ» (а эти конторы свои приобретения планируют сильно заранее) затраты на R&D в расчете на единицу продукции уже на старте снижаются до пренебрежимых величин.

уже забыли времена SMP-серверов на Celeron'ах?
А маркетинговые фейлы много с кем случались — например, Sony пришлось полностью пересмотреть ценовую политику после того как ушлые студенты из дотировавшихся в тот момент PS3 начали строить HPC-кластеры.
При наличии подтвержденного спроса со стороны «простых Гугла и ФБ» (а эти конторы свои приобретения планируют сильно заранее) затраты на R&D в расчете на единицу продукции уже на старте снижаются до пренебрежимых величин.
Я боюсь вы путаете прод и разработку. Закупки серверов в прод — да, планируются сильно заранее, тут иначе нельзя — но как gecube уже объяснил тут вам вряд ли чего обломится.

А закупки под ресёрч — никто и нигде не планирует на 5 лет вперёд. Даже в такой консервативной конторе, как IBM отделение R&D отделено от всей остальной компании — именно чтобы не планировать закупки за пять или десять лет и, в случае необходимости, мочь закупить какие-нибудь Thunder X2 за пару-тройку месяцев.

Что, конечно, всё равно гораздо дольше, чем в каких-нибудь совсем мелких компаниях, но вот уже никак не до уровня «затраты на R&D в расчете на единицу продукции уже на старте снижаются до пренебрежимых величин».

А маркетинговые фейлы много с кем случались — например, Sony пришлось полностью пересмотреть ценовую политику после того как ушлые студенты из дотировавшихся в тот момент PS3 начали строить HPC-кластеры.
Тоже хороший пример. А не назовёте хоть одну компанию, которая бы выпустила дешёвые матери для разработчиков и за счёт них загребла кучу бабла? Я вот что-то не припомню ни одного случая, когда выпуск дешёвой версии чего-либо «для разработчиков» вёл к финансовому успеху. А вот обратных примеров — вагон.

Отсюда и подходы.
Почитал я комментарии к посту и не понял ажиотажа. Узкий специалист высказал свое мнение по специфическому вопросу.
Кто реально завязан на архитектуру процессора?
Ну да, разработчики компиляторов. Использование возможностей CPU по максимуму — это их хлеб.
Разработчики средств виртуализации и связанного с этим софта, наверное тоже да. (Я с этим вопросом знаком достаточно поверхностно).
Возможно, разработчики какого — то специфичного софта, который использует особенности архитектуры CPU для оптимизации.
Еще раз напомню, речь про сервера!
Остальные — то чего возбудились? Вы все равно используете то, что вам компилятор породил, и самый главный для вас вопрос: сколько будет стоить решение именно ваших задач, а не то, как они будут решены.
Ну вот, снова минуса. :)
Ок, был не прав, возможно. Но не дайте умереть в неведении, объясните неучу, чем так плох процессор от ARM относительно процессоров x86, кроме того, что под ARM весь, или почти весь, софт надо портировать? Да, это долго и дорого, и это большой аргумент в пользу того, что Линус прав.
Я все еще уверен, что тема статьи — это узкий и специфичный вопрос, потому что люди, даже разработчики, по большей части, являются потребителями готового софта и железа, и для них важнее вопрос цены и возможностей полностью готового устройства, со всем необходимым софтом на нем, чем то, как это устроено.
Серверный рынок — пока не самый большой для ARM.

Не соглашусь. Он — огромен. И это не противоречит ни заявлению Товальдса, ни данной статье. Просто использование идет параллельно. Перетащить все на ARM — редкость. Но применение в серверах это данность.
Как раз сейчас у меня очередной этап портирования кода: x86(SSE, AVX) -> ARM (NEON). Могу только констатировать, что в данном вопросе Линукс полностью прав: Без нормальной девборды этот процесс весьма длительный и утомительный (с кросскомпиляцией и без дебагера).

P.S. А так на текущем этапе ARM явно не хватает широкого SIMD. NEON с его 128-bit на текущем этапе достаточно скромно выглядит по сравнению с AVX и уж тем более AVX-512.
А так на текущем этапе ARM явно не хватает широкого SIMD.

Увы, пришествия SVE в массовые процессоры ждать ещё долго. Сейчас есть только Fujitsu A64FX.
У Apple A12 (начиная с A9?) 3 SIMD юнита, таким образом обрабатывается 3х128 = 384 бит.

Почему без дебаггера? Еще 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 — его нигде нет, так что если вы не сами себе покупаете железо под процессинг, а для людей делаете — придется писать два раза, с ним и без него.

Писать приходится 6 раз минимум: Scalar, SSE, AVX, AVX2|FMA, AVX-512 и NEON.
Я вам немножко завидую. Мне очень нравится ручная оптимизация, но по работе занимаюсь совершенно другими вещами. Пару раз в жизни удавалось пописать под NEON (в соседней с вами геймдев компании), счастью не было предела, когда запускал бенчмарки.
У ARM есть SVE, который куда разумнее бесконечных AVX/AVX2/AVX512… вот только, как вы правильно заметили, без девборды подо всё это разработывать тяжело…
При всем уважении к заслугам Линуса, не могу согласиться.
Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.

Я, для своего «пэт-проджекта» действительно готов переплатить. Вот только это скорее исключение, когда разработчик сам оплачивает хостинг.
Обычно хосинг и инфраструктуру оплачивает условный «бизнес», а у них есть другие метрики, например, «стоимость владения». Если АРМ действительно предложит серверное решение с более оптимальным соотношением производительность/цена – появится спрос на оптимизацию софта под эту платформу. За спросом подтянется предложение.
Удобство для разработчика – дело не последнее, но и явно не приоритетное. Иначе бы х86 был бы в каждом смартфоне.
Обычно хосинг и инфраструктуру оплачивает условный «бизнес», а у них есть другие метрики, например, «стоимость владения».
И для подавляющего большинства бизнесов — это аредна одной-двух VPS или чего-либо подобного.

Google и Yandex, конечно, на слуху — но это только вершина бизнеса. В большинстве случаев для малых (и во многих случаях) для средних бизнесов хостинг идёт как бесплатная довеска к разработке. Потому получается, фактически, «разработчик сам оплачивает хостинг»: это всё идёт по той же статье бюджета.

Удобство для разработчика – дело не последнее, но и явно не приоритетное. Иначе бы х86 был бы в каждом смартфоне.
Смартфоны — дело другое: тут за железо и разработку платят совсем разные люди. А вот там, где это идёт из одного кармана — там x86 задавил большинство конкурентов. Потому что вначале «фиг с ценой сервера, мы пока маленькие, заплатим чуть больше за сервер, зато будет экономия на разработке», а потом, лет через 10, «да, мы уже большие — но у нас уже всё-привсё заточено под x86, переделка встанет в такие деньги, что лучше даже не начинать».
Возможно, я не прав в прогнозах, но я бы очень хотел, чтобы АРМ «взлетел» на серверах (ибо на десктопах у него шансов нет совсем). Не потому, что мне эта архитектура нравится, а потому, что x68 нужна конкуренция. И наоборот, хочу прихода х86 на мобильнее устройства, по тем-же причинам.

И я думаю, что в контексте данной статьи шанс прийти на рынок серверов у АРМ есть.
И для подавляющего большинства бизнесов — это аредна одной-двух VPS

Я с вами согласен (с оговорками), если считать «бизнесом» каждое юр. лицо.
Но раз мы говорим о рынке серверов – то там мелкие потребители «одной-двух VPS» (на которых крутится написанный под них софт) особой роли не играют. Основные потребители физических серверов – это крупный бизнес, (IT корпорации, банки, операторы мобильной связи и т д ). И на их серверах, зачастую, крутится типичный софт (я где-то читал, что 30% всех серверов в мире – это сервера СУБД). И в этом сегменте у АРМ, имхо, есть шанс занять свою нишу. Ибо это большая часть рынка физических серверов и относительно немного крупных производителей софта такого уровня.
А вот на десктопах – я не верю в успех АРМ по той причине, что там бесконечный набор софта и сразу вылазит проблема «АРМ на десктопе не нужен пользователю, потому что под него нет нужного софта, а разрабатывать софт под АРМ не выгодно, т. к. нет пользователей»
Возможно, я не прав в прогнозах, но я бы очень хотел, чтобы АРМ «взлетел» на серверах (ибо на десктопах у него шансов нет совсем).
Почему нет? Тут где-то уже была фотка IntelliJ Idea на Note 9. Ещё пару лет и телефоны сравняются по мощности с офисными машинками.

И наоборот, хочу прихода х86 на мобильнее устройства, по тем-же причинам.
А вот тут уже всё. Снизу вверх двигаться гораздо проще.

Но раз мы говорим о рынке серверов – то там мелкие потребители «одной-двух VPS» (на которых крутится написанный под них софт) особой роли не играют.
Суммарно — как раз они и играют. Есть ещё «суровый ынтырпрайз», но на него надежды вообще никакой: там могут лет 5-10 только обдумывать возможность перехода куда-нибудь…

А вот на десктопах – я не верю в успех АРМ по той причине, что там бесконечный набор софта и сразу вылазит проблема «АРМ на десктопе не нужен пользователю, потому что под него нет нужного софта, а разрабатывать софт под АРМ не выгодно, т. к. нет пользователей»
А эта проблема как раз легко решается если начать со смартфонов. Да, конечно, вначале софт со смартфонов не будет вызывать ничего, кроме улыбки… ну так и с PC то же самое было: во времена, когда на рабочих станциях уже было и редактирование видео и 4G и прочие чудеса… PC только-только учился работать с директориями!

И долгое время софт писался на рабочих станциях (даже пресловутый Doom, если не забыли, писался на NextStep, а не на PC!). А потом… появилась Visual Studio — и круг замкнулся.

То же самое может произойти и здесь… а может и не произойти: всё-таки с точки зрения интерфейса рабочие станции ближе к PC, чем телефоны и планшеты.

Но если ARM не придёт на десктоп, то он и на сервер вряд ли придёт… в этом смысл обсуждаемой статьи…
Ещё пару лет и телефоны сравняются по мощности с офисными машинками.


Дело не в мощности. В случае десктопа — дело в наличии привычного для пользователя софта. Здесь пока даже с разными ОС на х86 все местами плохо, про АРМ – боюсь даже представить.
А не нужно ничего представлять. Нужно просто вспомнить что больше половины пользователей смартфонов никогда не работали с PC.

Соотвественно для них среда разработки, какая бы она ни была — будет приемлема. Потому что никакой другой у них нет и не будет.

А переход «мастадонтов» типа нас с вами — это лет через 10-20.
И еще такой момент, касательно цитаты Линуса:
Если ты разрабатываешь на x86, то и деплоить захочешь на x86, потому что сможешь запускать то, что протестил дома. А значит с радостью немного переплатишь за хостинг на x86, просто чтобы он совпадал с твоей рабочей средой, и полученные ошибки транслировались легче.

А теперь мысленно отмотайте время на 20 лет назад, и замените в цитате «x86» — на «Windows». Интересно звучит, правда? Но Linux «взлетел» (чему я очень рад), притом сначала взлетел именно на серверах
А теперь мысленно отмотайте время на 20 лет назад, и замените в цитате «x86» — на «Windows». Интересно звучит, правда?
Интересно и правдиво. Именно благодаря этому эффекту мы и имеем (до сих пор имеем!) существенную долю серверов под Windows.

Но Linux «взлетел» (чему я очень рад), притом сначала взлетел именно на серверах
Однако Linux ведь вытеснил не Windows. Он вытеснил «большие» UNIX'ы. А кого будет вытеснять ARM сегодня?

А чем принципиально разработка под Android/NDK и iOS отличается от серверной?


Почему куча разработчиков под вышеперечисленные платформы пользуются кросс компиляцией, а те кто пишут серверное ПО не смогут этого делать?

Если вы пишете Node.js/PostgreSQL, то вам придется купить сервер, что бы тестировать работоспособность и производительность.
А чем принципиально разработка под Android/NDK и iOS отличается от серверной?
Тем что вы никак не можете повлитять на то, какое железо стоит в телефоне, но очень даже можете повлиять на то, какое хелезо закупается/арендуется под сервер.

Грубо говоря в случае с телефоном вы пляшете от железа — и оно определяет, что вы можете сделать, а чего нет, а в случае с серверами — вы делаете программу и смотрите какое железо под неё купить, так что железо определяет лишь часть цены — и больше ничего.

И каким бы не было железо, но если разработка вам встанет дешевле — то вы будете покупать именно такой вариант.

Если было бы иначе — Windows на серверах уже давным-давно сгинула бы, потому что почти всегда она требует больше и более дорогих серверов… но нет же — свою долю она таки имеет.
Дебаг по шнурку ЮСБ и по эзернету точно не сильно отличаются? Проблема то не в компиляции, а отладке и еще переносить весь существующий зоопарк серверного софта, как открытого, так и закрытого и даже внутрикорпоративного с кучей легаси это просто таки колоссальный труд. Почему-то вопрос совместимости с существующими решениями Линуса слабо волнует.
Тем что, у 99% разработчиков есть телефон с Android и/или iOS. То есть не смотря на кросс компиляцию, я могу сразу потыкать пальцем в свое творение и т.п. Еще тем, что 90% разработчиков под мобильные платформы не интересует производительность на уровне экономии тактов — достаточно алгоритмической оптимизации. Ну и мотивации писать код для миллионов устройств сильно больше, чем под два с половиной сервера.
То есть, есть два варианта, либо АРМ производит нечто, что настолько лучше x86 для какой-то категории задач, что хостеры/облака массового и дешево предлагают ARM мощности, тогда программисты начнут придумывать как выкрутиться. Либо ARM предлагает доступные devkit'ы для разработчиков, тогда программистам будет просто любопытно их освоить и тогда, может быть, они сами найдут ниши для применения этой архитектуры где-либо за привычными рамками телефонов, чайников и телевизоров.
У разработчиков под вышеперечисленные платформы выбора особо нет, а под сервера — есть.

Ну и для серверной разработки с кросскомпиляцией нужно, минимум, два сервера, а без неё — один, потому что роль тестового выполняет машина разработчика. Понятно, что в реальности немного не так будет, но один хотя бы виртуальный сервер разработчику нужно предоставить, чтоб на QA он задачу отправлял хотя бы убедившись, что там не крашится всё сразу.
Более чем уверен, что достижение производительности на уровне х86, приведет к повышению энергопотребления до уровня того же х86. Что нивелирует главное преимущество.
Не понял зачем нужны серверы на ARM64 если есть мультитредовые MIPS64 от Broadcom?
lolwat?
Что вы имеете в виду? 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. Никакие серверные процессоры им не нужны.
А Вы в курсе на какой вычислительной платформе работают все наши и зарубежные сетевые операторы? И куда попали 8 миллиардов выпущенных чипов на основе MIPS?
Не путайте серверы и коммуникационное оборудование.
Свитчи могут быть на MIPS, но серверы х86.
Кстати, туда сейчас нацелен ARM с платформой Neoverse
www.anandtech.com/show/13475/arm-announces-neoverse-infrastructure-ip-branding-future-roadmap

Можете скачать готовый образ Centos и запустить хотя бы «LAMP»-stack?
На ARM можно, а на MIPS это просто никому не нужно.

И куда попали 8 миллиардов выпущенных чипов на основе MIPS?

В роутеры, на свалку и т.д.
ARM-ов сейчас выпускается >20 миллиардов штук в год.
Серверных платформ только в Wiki больше 10-и. Серверы на х86 сильны только своей дешевизной. А накладные расходы на их эксплуатацию (в т.ч. потребление электропитания) всегда были высокие.
Единственное на что можно надеяться для совершенно новой архитектуры, пытающейся конкурировать с x86, — это эксперименты и дополнительные возможности. Например это лучший момент сделать fpga модуль стандартным (arm чипы есть со встроенными блоками на сотню тысяч вентилей, к сожалению нет тонны готовых soc с ними). Вспомнить многопроцессорные системы с разделяемой памятью (на каждый проц свой блок оперативки). Экспериментировать с матричными архитектурами (когда не одна шина данных, а каждый блок проц+память соединене только с несколькими соседями) и т.п.

На x86 такие эксперименты практически под запретом, слишком много легаси.
Для совершенно новых архитектур нужно по новому писать софт, иначе от них не будет проку. А это очень большие деньги. Кто может потянуть такие эксперименты?
для GPGPU потянули за 10-13 лет (а это действительно было нечто новое), вангую что в случае FPGA в каждом чайнике народ разберется лет за 5, ведь технология то на самом деле старая, просто из-за специально культивируемой дороговизны не сильно распространена.

ARM+FPGA активно используется когда нужна обработка сигналов, т.к. мелкосерийно делать специальные чипы невыгодно. Или для работы с сетевым трафиком, даже интел поучаствовал, но это узко специфические задачи. Как вы планируете применять FPGA для серверов баз данных и приложений?

FPGA это GPU на стероидах, правда есть проблемы с количеством вентилей. Как минимум простейшее место применения — высокоэнергоэффективная (а на серверах это линейно от стоимости затрат) обработка видео, нейронные сети и т.п. Сейчас это на себя берет GPU.

Аналогия — Конечно, если у вас веб и дешевые программисты, которые обходятся заметно дешевле железа, вы будете использовать REST-подход и старый server side html template в программировании и горизонтально масштабироваться при повышении количества пользователей, вместо того чтобы использовать правильную архитектуру (тот же react) и SPA приложения и получить на порядок эффективнее приложение (буквально в несколько раз меньше затрат на железо).

Мы можем только гадать, какие вкусности родит сообщество, если это будет ДОСТУПНО! Сейчас о доступности даже не стоит и заикаться, так как любую хорошую технологию уничтожат маркетологи выставив неадекватный ценник.
И снова получаем узко специфические задачи. Сейчас ничто не мешает вставить модуль FPGA в сервер. Повторюсь, что это даст серверам приложений и базам данных?
Вы либо специально тролите либо не понимаете что я пишу, причина фактически та же о чем пишет линус?

Главная проблема — отсутствие распространения технологии а значит отсутствие специалистов и их слишком высокая стоимость. Отсутствие готовых наработок (а с опенсорсом или нет, это очень удобно выбрать готовый фреймоврк и за пару недель решить задачу, а не за пол года) и само собой дешевого девелоперского железа, чтобы это тестировать дома а не в облаке (поверьте, это дико неудобно).


Окей, забыли про видеообработку. Представьте что ваш компилятор общего назначения ваш код автоматически компилирует не только под выбранную архитектуру, но и параллельно собирает спецпроцессор под определенные части кода. В теории это может дать прирост на порядок для однопоточных задач (например заворачивает целые выражения, блоки кода или даже методы в метаинструкции, исполняющиеся за пару тройку тактов). Это будет плохо работать в виртуализированном окружении, когда один процессор, кеш и оперативную делят сразу несколько задач (на всех может вентилей не хватить, хотя это просто вопрос необходимости, понадобится сделают сопроцессор соседним чипом или несколькими)… но идеален для один пользователь — один процессор. Кажется как раз arm сейчас не на столько хороши чтобы делить их между несколькими пользователями.

Это возможно только после того как FPGA станет стандартным сопроцессором в большинстве используемого железа, и будет иметь такой же доступ к оперативной памяти что и сам процессор (как раз среди ARM чипов такие уже есть), и компании, которые ищут возможность оптимизировать свои затраты именно на вычислении, смогут вкладывать в эту технологию ресурсы.
Главная проблема — отсутствие распространения технологии а значит отсутствие

Проблема распространения нет. Я давал ссылка на FPGA от intel, который можно засунуть в сервер. Те кому нужны FPGA их уже используют.

Слышал, с 2013 года это слышу, и судя по тому что об этом только рекламные проспекты говорят — это нельзя назвать доступным. И кстати это не достижение интеля а стратис и алтера. И софт там что то типа opencl, крутая идея но… недоступно это простым смертным.

Вы стоимость лицензирования софта разработчика сможете озвучить, а то где не посмотрю — везде по запросу? И сколько будет стоить рабочее место разработчика. Я догадываюсь что многие тысячи баксов, а значит считай никто в этой области работать не будет как минимум в опенсорс (кстати может так получиться что и НЕ СМОЖЕТ из-за лицензионных ограничений)
Поэтому нужно много тысяч долларов, чтобы собрать нормальный девбокс на Power9.

Где-то от 2 до 5. Очень много.
Шаг 1.
http://web.archive.org/web/20130424020636/http://www.linuxfoundation.org/about
Оттуда:
...Linux Foundation спонсирует работу создателя Linux Линуса Торвальдса…

Шаг 2.
https://www.google.com/search?q=Linux+lobby+org+joins+with+RISC-V+bods+to+promote+open+chip+spec
Оттуда:
… две организации планируют объявить о сотрудничестве с целью повышения привлекательности RISC-V ISA, технологии, которую недавно пытался задушить проприетарный разработчик чипов Arm…

Шаг 3.
См. заголовок:
«Линус Торвальдс не верит, что серверы на ARM-архитектуре заменят x86. «Продавать 64-битную модель — идиотизм»»

image
все иное — просто погрешность… Поэтому нужно много тысяч долларов, чтобы собрать нормальный девбокс на

У RISC-V живых чипов, на которых можно запустить линукс (RV64G = RV64IMAFD с достаточным размером ОЗУ и вероятно MMU) — 1 тип с тиражом менее тысячи устройств (200 заявок в https://www.crowdsupply.com/sifive/hifive-unleashed за год). Цена материнской платы с GbE + 8GB RAM — 1 тысяча долларов. Для PCI-express нужна дополнительно плата с FPGA за 2 тысячи долларов (20 заявок в https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-board). См список Cores в https://riscv.org/risc-v-cores/ но Kendryte K210 линукс не запустит по причине отсутствия ОЗУ — https://blog.hackster.io/kendrytes-kd233-is-a-dual-core-risc-v-soc-designed-for-ai-applications-2ed75199b4c4
Под RISC-V уже готовят Debian и Fedora — их свежие презентации были на FOSDEM 2019


  • Fedora — "Current build farm: 3 SiFive HiFive, 64 QEMU, 30 QEMU instances can be added" "SiFive HiFive Unleashed: upstream kernel lacks support"
  • Debian — "Options for running RISC-V code include: Emulation via qemu, Linux-capable softcores… on FPGAs, SiFive Freedom U540, LowRISC… still probably 3-5 years away, SHAKTI — a project at the IIT Madras" "87% packages" "RISC-V definitely won’t become a release architecture for “Buster”… Hardware managed by DSA must fullfill certain requirements (rack-mountable,… easily available replacement hardware in case of failure)"

К вопросу о доступном железе: SolidRun обещает запустить miniITX ARM плату "ClearFog ITX" на 16 ядер A72 с акционной ценой в 550-500 долларов:
https://www.cnx-software.com/2019/03/29/clearfog-itx-workstation-ultimate-arm-developer-platform/


NXP LX2160A 16-core Arm Cortex A72 processor @ 2.2 GHz
System Memory – Up to 64GB DDR4 dual channel memory via SO-DIMM sockets on COM module
Storage
M.2 2240/2280/22110 SSD support
4 x SATA 3.0 ports
USB – 3x USB 3.0, 4x USB 2.0
Expansion – 1x PCIe x8 Gen 4.0 socket
Power Supply – ATX standard
Dimensions – 170 x 170mm (Mini ITX Form Factor)

Jon Nettleton, Chief Systems Architect, SolidRun:
https://www.cnx-software.com/2019/03/29/clearfog-itx-workstation-ultimate-arm-developer-platform/#comment-561815


I have been running initial benchmarking and real world performance is similar to a Xeon-D, or Xeon Silver 8 core 16 threads.… The main SOC runs at a TDP of 32W
We are doing linux kernel builds in 2-2.5 minutes on non-NVME storage.
И вот теперь Apple переходит на ARM и куча машин разработчиков будут на ARM. Теперь значит аргумент начинает работать против x86?
Помятуя как эппл относится к вендорлоку, открыто и доступно — это не про них, я легко поверю к примеру в вариант, когда ваш код, отлаживаемый на arm mac, вы сможете запускать только на баснословно дорогих, вполне реальных к появлению, серверных железках от эппл.

Так что нет…
Ну тут вопрос про сервера — вот я писал на Ruby, Python на x86 Mac, cледуая аргументам Линуса я должен был предпочитать x86 сервера (это правда, но скорее потому что хрен найдешь ARM), но теперь то уж точно ARM я должен предпочитать (на самом деле хрен по прежнему не так чтобы они везде есть)
в конечном счете все упирается в деньги

за счет высокого предложения x86 сервера и десктопные машины очень и очень доступны и дешевы

Какие то мифические или даже не совсем повышения скорости исполнения не заставят народ платить в несколько раз дороже, а энергопотребление волнует только датацентры и может быть тех бедолаг из евросоюза, кто платит больше евро за каждый киловат/ч.

p.s. линус писал не про интерпретируемые языки
Sign up to leave a comment.

Articles