Haiku на RISC-V плате HiFive Unmatched и ЛОРом в NetSurf

У эпла дохлые процы для лаптопов

Эм, нет.

Во-вторых, на самом деле эпл отхапал себе передовой техпроцесс 5нм, и именно от техпроцесса энергопотребление зависит значительно. Когда у интела всё ещё старый 14нм техпроцесс.

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

Чё там даёт risc на самом деле не известно

Упрощение архитектуры.

Эм, нет.

Покажи аналог EPYC 7763 от эпла.

Арм не просто так используют в телефонах

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

Упрощение архитектуры.

Apple M1 сложнее Intel Skylake.

За лицензию на x86 платить не нужно, например

За х86 платить некому, даже если очень захочется. А за лицензию на арм архитектуру платить нужно

За лицензию на x86 платить не нужно, например.

За какие нибудь SSE, AVX может быть и нужно платить отчисления.

Уважуха таким увлечённым людям

Звучит похоже на тегирование памяти, которое есть в эльбрусах, а не как в АРМе.

Да, конечно. Как в Эльбрусе. Я в этом деле совсем нуб. Поэтому буду плавать в вопросах где что и как сделано. До вникания в RV я вообще не догадывался, что то, что мне нужно — это называется «тегированная память»))

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

А почему не прототипировать архитектурные штуки сначала в qemu?

Это правильно. Начинать, конечно же, надо с VM и эмулятора. И только потом садиться за реальное железо. Конкретно в моем случае я хочу еще по ходу получить какой-то hands on с железом, так как я его не нюхал 20+ лет с момента окончания своего универа.

Если будет интерес, то я бы рекомендовал захаживать на эту воркгруппу(и, наверняка, в другие тоже)...

Спасибо за приглашение, я обязательно присоединюсь ко всем релевантным WG, когда подразгребу свой бэклог (стабилизирую Меморию). Но будет это, скорее всего, уже в следующем году.

Про «обычность» фпга, куда влезает такой дизайн от Jan я бы поспорил: он как-то всегда тяготеет к самому хайенду :)
К тому же, насколько я помню, он не публиковал сорцы этого дизайна, к сожалению.

Сорцов нет, но это не так важно. На таких FPGA нету NoC, а используемый Яном Hoplite router уязвим к неограниченному росту задержек. Т.е. на Alveo U50/U280 можно с такими дизайнами поиграться, но, по хорошему, нужно ждать следующее поколение FPGA с уже разведенным NoC. Их уже местами можно купить.

Alveo U50, кстати, стоит что-то около $2500. Его вполне можно купить себе дамой для поигрушек (я купил). С поправкой на то, что это всё же серверное железо (нужно кулер приделывать). Альтернатива от Intel стоит более $12K. Это уже далеко за гранью.

Зато понимает Латтнер и остальные девелоперы, которые кинулись делать ускорители всего, что только можно

Гы. Все побежали, и я побежал. Так и получилось.))) Я внимательно слежу за Circt и у меня на него есть свои планы.

Я с ним согласен, но сейчас архитрудно найти инвестиции, если ты не разрабатываешь yet-another-ai акселератор, увы.

Не, не всё так драматично. Есть smart storage, есть NN, есть database acceleration и есть edge computing. И есть огромная ниша — это trading memory for speed. В частном случае — динамическое программирование. В более сложном случае — переход, например, от нейронных сетей к сжатым пространственным индексам типа quad/oct-tree. Последние имеют гораздо лучшую асимптотику для точечных операций (логарифмическую вместо линейной) и могут динамически обновляться.

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

И, кто знает, может быть лет через 5-7 X512 будет писать в Haiku уже совсем другие приложения)))

Всё хитрее. SSE2+ запатентован и является неотъемлемой частью X86_64. Мы даже эмулятор без разрешения Intel сделать не можем.

Забыл добавить. Trading memory for speed — это еще и стратегия энергосбережения для compute-intensive задач. Хранящиеся где-нибудь в кристаллах предрасчитанные задачи «жрать» не просят совсем. Хранить становится выгоднее, если транспортировка данных менее энергозатратна, чем перевычисление.

RISC-V — это такой изящный хак в самое сердце системы монополий, выросших вокруг железостроения. Чем и интересен :) Это не просто «еще одна ISA».

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

Хуже всего, что все упирается в DRAM: эльбрус(и не только) хранит теги в ецц битах, что не всем нравится/подходит. Гугл, кстати, внедрил тегированую память в железки, начиная с пикселя 4. Ограниченно, не для всей системы, а для некоторых приложений, но тем не менее. Костя Серебряный рассказывал, что это был долгий и болезненный процесс, но, надеюсь, в случае с тегами для риск5 дело пойдет проще.

Сорцов нет, но это не так важно.

Я бы сказал, что важно. Самому с нуля пилить проект такого класса, как сделал Ян(с почти 100% утилизацией железки), это супер весело и интересно, но за разумное время его по ночам не сделать, имхо.

Alveo U50, кстати, стоит что-то около $2500. Его вполне можно купить себе дамой для поигрушек (я купил)
Альтернатива от Intel стоит более $12K.

Тут я соглашусь. 10k+ это уже простенький тейпаут на 130/180нм :)

database acceleration

Это же сейчас активно пытаются ускорить на гпу, по крайней мере некоторый класс БД? Я еще видел работы про ускорение на фпга, но они были из того времени, когда питчили зеон+фпга в одном корпусе, а потом куда-то пропали.

Мы даже эмулятор без разрешения Intel сделать не можем.

Покупайте симикс, сотрудникам интела тоже хочется кушать :)

И, кто знает, может быть лет через 5-7 X512 будет писать в Haiku уже совсем другие приложения)))

Индустрия(и всякие внутренние презентации) говорит про +-10 лет до «вырастания» риск5. Хотя какие-то локальные прорывы с теми же акселераторами могут случиться гораздо раньше.

Хранить становится выгоднее, если транспортировка данных менее энергозатратна, чем перевычисление.

А ты видел ресерч от ETHZ про in memory computing?

RISC-V — это такой изящный хак в самое сердце системы монополий, выросших вокруг железостроения.

риск5 сильно снизил порог для входа в ресерч архитектуры и инноваций. Но вот насчет пошатнуть монополии в общем случае - не уверен: тот же арм ползет в сервера уже лет 7+, а то и больше(привет, АМД А1100), а риск5 еще даже не оброс достаточным количеством фич и расширений.

Покажи аналог EPYC 7763 от эпла.

А я говорил, что аналог есть? Или это тот процессор, который стоит на границе между дохлыми ноутбучными процессорами и десктопные?

За лицензию на x86 платить не нужно, например

Зато нужно за другую.

Современные х86, ЕМНИП, даже вмещают транслятор циск-инструкций в риск.

За лицензию на x86 платить не нужно

За лицензию х86 платить не нужно, тк ее никто не продаст. Выкрутасы китайцев с VIA/AMD не в счет.

Современные х86, ЕМНИП, даже вмещают транслятор циск-инструкций в риск.

Да, х86 ядра работают на uOP, которые имеют риск5 формат. Но сам транслятор уже достаточно оптимизированный и не так сильно влияет на дизайн. Про форматы микрокода можно почитать ресерчи Максима Горячего и ко, которые их реверсят.

А я говорил, что аналог есть?

Выходит эпловский arm таки не тянет на аналог x86?

на границе между дохлыми ноутбучными процессорами и десктопные

Это уже твои пост-фактум дополнительные характеристики. Ну сделаю скидочку, покажи аналог скромного 5950X.

Зато нужно за другую.

Арм за одно предоставляет готовый дизайн блоков для кастомных soc, а для x86 пойди такое поищи.

Современные х86, ЕМНИП, даже вмещают транслятор циск-инструкций в риск.

С технической точки зрения арм не имеет преимуществ тогда, хочешь сказать?

Выходит эпловский arm таки не тянет на аналог x86?

Это вы вообще чего решили? Конкретный процессор не тянет на замену другого конкретного процессора, всё. EPYC 7763 не тянет на замену Helio P60, это ничего не доказывает.

Это уже твои пост-фактум дополнительные характеристики.

Нет, просто вы взяли два частных случая, пытаясь что-то доказать.

Арм за одно продаёт готовый дизайн блоков для кастомных soc, а для x86 пойди такое поищи.

Одни плюсы.

С технической точки зрения арм не нужен тогда, хочешь сказать?

Прекратите выдумывать мои тезисы.

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

Я не думаю, что лишняя сущность добавляет эффективности.

Разумеется, не добавляет. Но это не такая уж и большая плата за 30-40 лет совместимости.

ничего не доказывает

Ну покажи наконец, что доказывает твой изначальный тезис «Обогрев комнаты — преимущество х86».

вы взяли два частных случая

Я взял хоть какую-то конкретику. У тебя пустые заявления.

Одни плюсы.

Жаль, к изначальному тезису не относящиеся.

Прекратите выдумывать

Но ты же сам себе противоречить начинаешь.

Ну покажи наконец, что доказывает твой изначальный тезис «Обогрев комнаты — преимущество х86».

Х86 менее эффективны, чего так, я уже рассказал.

Х86 менее эффективны

А что такое «эффективны»? Те какая метрика берется за основу: плотность кода, IPC, perf/watt?

Я что-то не припомню, где ты приносил пруф энергоэффективности arm vs x86 на одинаковом техпроцессе и частоте, которые имеют огромное влияние на энергоэффективность, и разница в них кардинально исказит сравнение.

А что такое «эффективны»?

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

Те какая метрика берется за основу: плотность кода, IPC, perf/watt?

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

всё ещё будет потреблять энергию

И сколько же он потребляет? Хоть не теряется на фоне потребления intel ME?

Иногда полное ощущение, что запятые для тебя — непреодолимая преграда.

После запятой было это:

не конкурент по вычислительной мощности серьёзным процам для hi-end десктопов и серверов

Эм, да.

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

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

Ок, значит, мы говорим про энергоэффективность.

Это из реального мира, речь про сферический процессор в вакууме, просто внутри современного х86 стоит процессор, выполняющий риск-инструкции.

Я бы тут заострил внимание на различии «архитектуры/ISA» и «микроархитектуры»: первая описывает как должна работать машина, а вторая - конкретную ее реализацию.
Как уже выше заметили, на энергоэффективность влияет куча факторов, в том числе и техпроцесс. Поэтому нельзя сравнивать абстрактный х86/циск с абстрактным арм/риск.
При всем этом М1 от яббла, действительно, эффективнее интела в IPC и потреблению энергии. Причины этого известны.

https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/

Прототип процессора архитектуры риск-в набирает 110 тысяч единиц в тесте CoreMarks на ватт. Но о нём не много известно.

пруф энергоэффективности arm vs x86

риск-в набирает 110 тысяч единиц в тесте CoreMarks на ватт

Ты точно не бот?

Эппл делает не только дохлые процессоры для ноутбуков, недавно выпустили новый аймак на М1.

Имея 30% от производительности нормального ноутбучного процессора. Нарастят производительность до 100% - эффективность упадёт до обычных значений. Они там же в статье пишут, что не сравнивали с энергоэффективными ядрами m1, а только с мощными, как бы намекает, почему.

Точно, просто в глаза долблюсь.

Эппл делает не только дохлые процессоры для ноутбуков

Но и дохлые процы для моноблоков?

M1 не конкурент нормальному десктопному процессору.

Имея 30% от производительности нормального ноутбучного процессора

И потребляя в 100 раз меньше.

Нарастив потребление в 100раз, производительность не вырастет в те же 100раз.

Кстати говоря:

ignore memory … effects and focus primarily on the pipeline operation. This is CoreMark’s domain.

Бенч полная нерепрезентативная синтетика.

Что по вашему «нормальный десктопный процессор»?

Давай ты не будешь ходить окольными путями, и сразу скажем, что m1 - для ультратонких ноутбуков и офисных моноблоков, без особых требований к производительности.

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

Очень хорошую производительность и телефоны последние лет пять показывают. Но это далеко не та производительность, которая требуется разработчику. А мы же всё таки с этой перспективы смотрим.

Гвоздь и микроскоп.

Амазон специально сделал свои процессоры на АРМ для серверов.

Само по себе это не говорит ровно ни о чём, нужно смотреть на конкретное применение.

Если ты пытаешься доказать, что RISC годится для вычислений, то ты делаешь это неправильно. У меня для тебя одно слово: POWER.

У меня для тебя одно слово: POWER.

Что POWER? Они до x86 не дотягивали так что Apple с них ушла. И сейчас тоже вроде не дотягивают по абсолютной однопоточной скорости.

не дотягивают по абсолютной однопоточной скорости

И?

Очень хорошо, пожалуй и себе закажу платку если будет рабочий порт.

Хуже всего, что все упирается в DRAM: эльбрус(и не только) хранит теги в ецц битах, что не всем нравится/подходит.

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

это супер весело и интересно, но за разумное время его по ночам не сделать, имхо.

Я скажу, что FPGA - это вообще full time job при любом раскладе. Это не для любителей. А профессионалам кушать надо и детишек кормить.

Это же сейчас активно пытаются ускорить на гпу, по крайней мере некоторый класс БД? Я еще видел работы про ускорение на фпга, но они были из того времени, когда питчили зеон+фпга в одном корпусе, а потом куда-то пропали.

Это потому, что GPU — единственный доступный акселератор. Вообще, можно брать Alveo, и берут, и делают. И там можно делать C++ HLS, как и в Cuda. Но есть одно «но». Компиляция прошивки длится от нескольких часов до нескольких дней. Т.е. это совсем не как в GUDA — запустил и посмотрел. Roundtrip очень длинный, отдладка проблематичная и все такое. Но даже несмотря на все эти трудности я бы всем рекомендовал приобщиться к FPGA-акселераторам, если по деньгам потянут. По сравнению с их возможностями CUDA выглядит жалким бейсиком. Оно того стоит.

Но вообще GPU не для БД из-за малых объемов памяти. На них обычно делают всякую in-DB аналитику. Графы там потраверсить, ML потренировать, вероятностный вывод сделать и т.п. Я бы сейчас брал для задач DB не GPU, а старшие Epyc. Куда более универсально и достаточно производительно.

Oracle делает какие-то «SQL-акселераторы» для своих спарков, но я плохо представляю, что это конкретно такое.

Но, в основном, да. Если мы говорим про акселерацию БД, то имеется в виду или акселерация типичных storage вещей, типа шифрования, хэширования и сжатия. Либо акселерация аналитики над данными в БД, интегрированная с планировщиком запросов.

Индустрия(и всякие внутренние презентации) говорит про +-10 лет до «вырастания» риск5. Хотя какие-то локальные прорывы с теми же акселераторами могут случиться гораздо раньше.

Это да. Но оно не сегодня началось. Много проектов сейчас в стелсе, и каждый год что-то неожиданное появляется. Так что, я думаю, что мой прогноз вполне реалистичен, если мы учтем стелс-разработки.

А ты видел ресерч от ETHZ про in memory computing?

Да. Смотрю за этой областью в пол глаза. Если коротко, то Меморию в долгосрочной перспективе можно рассматривать как фреймворк продвинутых структур данных для in-memory computing. Я считаю, что всё туда и идет постепенно.

Но вот насчет пошатнуть монополии в общем случае - не уверен:

Я сейчас объясню. Вот были большие юниксы и был маленький линукс. И большие юниксы были на столько «большими» и «сердитыми», что поставить их на настольную машину особо возможности и не было. Поэтому студентота ставила себе линукс. А потом они вышли в мир, пришли на работу и стали там работать с тем, с чем умеют. Так большие юниксы потеряли mindshare. А вслед за ним — и market share.

То же самое и с risc-v. Я заметил, что именно его сейчас начинают массово преподавать в универах. И пока что гегемонии ARM ничего не угрожает. Но они начнут быстро терять market share в перспективе 5 лет.

Ну и еще, почему корпорации заинтересованы в RV, он позволяет делать SW/HW co-design, чего ARM делать не позволяет. Их система команд закрыта для модификаций. Чтобы предотвратить фрагментацию платформы. Они, конечно, могут её (систему команд) открыть, но пока этого не произошло. И, раз корпорации вкладываются в RV, то и не ожидается, что произойдет.

Ну и еще, почему корпорации заинтересованы в RV, он позволяет делать SW/HW co-design, чего ARM делать не позволяет.

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

Всё верно. Пространство опкодов для расширений не такое уж и большое. То есть, это не идеальная технология. Но это всё равно лучше, чем то, что есть сейчас у того же ARM (ничего :)).

Разносить конфликтующие по опкодам сторонние расширения можно на уровне той же ОС.

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

Но нут изящного решения всё равно не будет, если не вводить CISC-like инструкции переменной длины. Пространства опкодов все равно на всех не хватит.

если не вводить CISC-like инструкции переменной длины

В RISC-V опкоды и так переменной длины. Спецификация допускает опкоды длиной до 24 байт.

Опа! Не знал, надо подтянуть матчасть.