LINUX.ORG.RU

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

 , ,


10

3

Сегодня открылся ЛОР в NetSurf в Haiku RISC-V.

С начала этого года делаю порт свободной UNIX-like операционной системы Haiku на процессорную архитектуру RISC-V (64 бит) (подробнее: My Haiku RISC-V port progress, My progress on real RISC-V hardware). Сейчас система уже неплохо работает на реальном RISC-V железе HiFive Unmatched, есть графика, сеть WiFi, поддержка многоядерности (SMP), пакеты портов собираются на самом железе, работает воспроизведение видео.

RISC-V — полностью открытая и свободная от каких либо отчислений процессорная архитектура, конкурирующая с ARM. Архитектура довольно новая и свободная от легаси вроде четырёх несовместимых наборов команд в ARM, разных MMU, и т.п.. Также архитектура очень простая и выразительная: я написал дизассеблер за два дня и минимально работающий порт Haiku за несколько недель. Для Haiku это первый рабочий порт на не x86-совместимую архитектуру. Остальные порты находятся в зачаточном состоянии без рабочего userland более 10 лет.

Компания SiFive производит открытые ядра RISC-V и готовые платы с полностью открытым программным обеспечением включая драйверы и прошивки. Я использую плату HiFive Unmatched. На плате есть шина PCIe так что можно использовать многие существующие драйвера Haiku без изменений.

Железо выглядит как-то так: раз, два.

Используемое железо:

  • Мат. плата: HiFive Unmatched.
  • Диск: Silicon Power SSD 256GB 3D TLC NAND M.2 2280 PCIe3.0×4 NVMe1.3 P34A60
  • Сеть: Intel AC 9260 M.2 WiFi
  • Видеокарта: AMD Radeon R7 250

>>> Просмотр (1920x1080, 263 Kb)

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 1)

Ответ на: комментарий от steeels

Во, еще RV-новость подоспела. Уровень Neoverse — это уже серьезная заявочка. Ну и акселераторы чиплетами — тоже очень хорошо.

aist1 ★★★
()
Ответ на: комментарий от Oberstserj

Nokia 7610 - один из первых недосмартфонов с крутилятором на борту.

И где там был этот «крутилятор»? Держал в руках этот 7610, ничего подобного не заметил.

EXL ★★★★★
()
Ответ на: комментарий от aist1

Выделение памяти под теги раньше рассматривалось как расточительство, но сейчас памяти много

Дело не столько в расточительстве рамы, сколько в том, как сейчас устроены DRAM и контроллеры памяти для них: они бурстами читают большие пачки данных с последовательных адресов. Поэтому надо думать, как эти вещи докрутить, чтобы хранение/загрузка тегов были эффективными. Сильвербуллета пока нет.

Я скажу, что FPGA - это вообще full time job при любом раскладе

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

Либо акселерация аналитики над данными в БД, интегрированная с планировщиком запросов.

Коллега сейчас чем-то таким как раз занимается.

Много проектов сейчас в стелсе, и каждый год что-то неожиданное появляется

Вот бы научиться эти стелсовые проекты из своих московий находить, а то тоска здесь после 14 года. А из вентаны пока не ответили :(

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

Мимикрокодильный коллега навскидку поинтересовался: memoria vs https://github.com/arximboldi/immer

А потом они вышли в мир, пришли на работу и стали там работать с тем, с чем умеют.
Я заметил, что именно его сейчас начинают массово преподавать в универах.

Это валидный поинт, да.

он позволяет делать SW/HW co-design, чего ARM делать не позволяет.

Теперь АРМ дает кастомерам делать свои кастомные инструкции. За много денег, наверняка. Но экспериментировать на риск5, особенно университетам и небольшим стартапам, конечно, куда проще и дешевле.

И, раз корпорации вкладываются в RV

Ну, не то, чтобы они супер массово вкладывались пока. Вот если гугл какой-нибудь из своих следующих соков для телефонов/ноутов сделает на риск5, вот тогда станет интересно :)

steeels
()
Ответ на: комментарий от Zyy

Одно из главных сливных бачков энергоэффективности x86 – декодер инструкций.

4-way декодер у zen/skylake жрёт под 20% от общего потребления ядра если процессор не считает математику векторными расширениями, конечно. Шире декодер уже и смысла нет делать, ибо регистров мало и степень суперскалярности сложно повысить, да и жрать такой декодер будет совсем уж немеряно.

8-way декодер у жирных ядер в M1 жрёт где-то 3-4% от общего потребления ядра, опять же когда оно не считает математику векторными расширениями.

Причина в неоднородной длине и форме кодирования инструкций x86.

timdorohin ★★★★
()
Ответ на: комментарий от timdorohin

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

Непонятно почему ARM так и не смог обогнать несмотря на несколько десятков лет развития.

X512 ★★★★★
() автор топика
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

электричество дешёвое

интересно сколько ещё фукусим нужно чтобы люди перестали бесполезно тратить ресурсы планеты

spbob
()
Ответ на: комментарий от X512

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

Энергоэффективность как раз таки важна: например очень важна для серверов(сколько влезет в стойку). К тому же не надо забывать про проблему с dark silicon.

Непонятно почему ARM так и не смог обогнать несмотря на несколько десятков лет развития.

Потому что никто не пытался сделать АРМы на 100-200вт на 4/8 ядер. Зато теперь в том же павер энвелопе они делают процы по 100+ ядер на сокет и передают привет интелу.

x86 получается самый быстрый для однопоточных задач.

(возможно) современный х86 имеет самую высокое абсолютное быстродействие. Однако меряться этим показателем - то еще удовольствие, тк начальные условия(техпроцесс и тд) не равны.

steeels
()
Последнее исправление: steeels (всего исправлений: 1)
Ответ на: комментарий от steeels

Энергоэффективность как раз таки важна: например очень важна для серверов

Я не отрицаю что много где энергоэффектиность важна, но не везде. Есть задачи, которые чисто алгоритмически не масштабируются на несколько потоков. Пока не появятся процессоры с высокой однопоточной производительностью, о смерти x86 говорить не приходится, это довольно серьёзная ниша. Правда я не виду фундаментальных проблем почему нельзя сделать процессор набора команд ARM/RISC-V не уступающим x86 по абсолютной однопоточной производительности. Или набор команд x86 чем-то помогает в однопоточной производительности?

X512 ★★★★★
() автор топика
Ответ на: комментарий от X512

Правда я не виду фундаментальных проблем почему нельзя сделать процессор набора команд ARM/RISC-V не уступающим x86 по абсолютной однопоточной производительности. Или набор команд x86 чем-то помогает в однопоточной производительности?

Фундаментальных проблем и я не вижу. Видимо, экономически не выгодно, вот и не делают.
Хотя яббл уже делает какие-то заявки на успех с М1: хороший перф в хорошем павере. Надо ждать, смогут/захотят они это отскалировать до ~50-100-150вт десктопа или нет.

steeels
()
Последнее исправление: steeels (всего исправлений: 1)
Ответ на: комментарий от steeels

Видимо, экономически не выгодно, вот и не делают.

Просто не хотят залезать на чужую площадку, которая очень консервативна к тому же. Несмотря на все недостатки проциков Intel, проблем с поставками, и преимущества проциков AMD, серверная доля Intel не сильно-то и упала. Особенно в абсолютном плане. AMD набирает долю за счет физического роста датацентров.

aist1 ★★★
()
Ответ на: комментарий от steeels

Вот бы научиться эти стелсовые проекты из своих московий находить

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

Работать с американскими компаниями без релокации может оказаться проблематично, так как regulations. Export control, короче. Тут мало находиться на территории Штатов, тут еще и GC нужно иметь как минимум. Но значительная часть железа под экспортный контроль не попадает, так что всё может быть.

По моему опыту, «рассылать резюме» бесполезно. Нужно искать людей в Linkedin и выходить на них, заинтересовывать, чтобы они двигали. Даже сидючи здесь, в Штатах, это — основной способ попасть туда, куда тебе надо с гарантией.

Если хочется именно в России что-то поднять, с выходом на мировой рынок, то я бы заходил через storage, а не через те же CPU/MCU. Поясню ниже.

Мимикрокодильный коллега навскидку поинтересовался: memoria vs https://github.com/arximboldi/immer

Разница примерно такая же, как между Postgresql и STL. Immer — это классический С++-идеоматический фреймворк для иммутабельных (функциональных) STL-like контейнеров, работающих в RAM.

Memoria ориентирована на продвинутые структуры данных типа сжатых пространственных индексов, смешанных распределений вероятностей и т.п., для поддержки алгоритмов ИИ. Вот, например, есть модель RL-агента MC-AIXI-CTW. Для таких вещей Меморию можно использовать для представления распределения вероятностей, которое этот агент использует для ситуативного вывода. Вообще, вероятностное программирование — тема. Но там есть проблемка. Вероятностные алгоритмы есть, а вероятностных структур данных (кодирующих распределения вероятностей) — нет. Ну и железо специальное надо для сэмплинга. И будет next big thing (нет).

А всякая мелочь типа Map<K,V>, Vector<V>, Table<> и т.п. — это попутный продукт, получаемый специализацией простых контейнеров.

Ну и последнее отличие в том, что в Мемории создается полный стек от физического хранения данных на устройствах до execution. Причем с ориентацией на акселераторы, что поддерживается внутренними структурами данных. Вот я сейчас вылизываю SWMRStore (Single Writer Multiple Readers), которые внутри похож на LMDB (CoW over mmap), но только имеет consistency points, бранчики и историю. И систему типов Мемории сверху. Голый LMDB не получится использовать как файловую систему, так как будет дикая фрагментация, а SWMRStore — можно. Получится что-то типа «ZFS на стероидах», но только с атомарной/транзакционной семантикой уровня приложений. Скорости хватит.

Сейчас SWMRStore сделан над mmap (так пока что проще), но в Мемории есть кроссплатформенная подсистема асинхронного ввода-вывода над AIO/epoll/uring/IOCP/kqueue и Boost Fibers. Так что прямая работа с высокопроизводительными NVMe-устройствами (SPDK) не представляет технической проблемы.

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

Мне сейчас нужно отойди, потом поясню, что можно поднять в России в плане storage.

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

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

Китайцы это отдельный разговор, они в Москве в последние пару лет тоже активно пылесосили рынок.

Работать с американскими компаниями без релокации может оказаться проблематично, так как regulations. Export control, короче.

В докрымские времена в уютненьком стартапе на нащу сторону отгружали только софт(никакого хв) и как-то подмигивали, чтобы экспортную лицензию нам не выписывать. Релоцироваться, гипотетически, мне сейчас относительно проще из-за L1 и гринки, которую начнут делать сразу по прибытию, но я зачем-то купил тут квартиру и вляпался в ремонт :)

Мне сейчас нужно отойди, потом поясню, что можно поднять в России в плане storage.

Может, удобнее будет продолжить общение в почте или линкедине?

steeels
()

Я тут ещё в последнее время стал постить процесс разработки на свой Youtube канал.

X512 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.