LINUX.ORG.RU

Biscuit: монолитное POSIX-совместимое ядро на Go

 , ,


7

7

Ядро было написано аспирантом MIT Cody Cutler в рамках исследования «The benefits and costs of writing a POSIX kernel in a high-level language» и доступно на GitHub странице MIT PDOS (Parallel and Distributed Operating Systems group at MIT CSAIL) под лицензией MIT.

Biscuit неплохо документирован и содержит 27 тысяч строк на Go, из которых всего 90 функций содержат небезопасные вызовы («unsafe»), необходимые для задач вроде доступа к регистрам процессора. Есть также небольшой загрузчик, написанный на ассемблере.

Особенности:

Скомпилировать и опробовать ядро довольно просто:

git clone https://github.com/mit-pdos/biscuit.git
cd biscuit/src
./make.bash && make -C ../biscuit qemu CPUS=2
При этом сборка с нуля занимает всего 38 секунд, из которых 33 секунды приходится на немного модифицированный рантайм Go, и всего 5 секунд непосредственно на сборку ядра.

Интересны результаты исследования. После проведения тестов производительности на таких приложениях, как NGINX, Redis, и CMailbench — обнаружилось, что сравнение производительности эквивалентных путей кода на Си и на Go показало всего 15% разницы. Доля процессорного времени, потребляемого сборкой мусора и проверками безопасности, по результатам авторов статьи — составляет менее 15%.

>>> Подробности

Deleted

Проверено: shell-script ()
Последнее исправление: Deleted (всего исправлений: 24)

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

Что как бы ставит вопрос «нафига тогда?».

Чтобы зачет поставили? Хотя... столько кода. Кто-то вероятно злоупотребил тяжелыми смузями.

bread
()
Ответ на: комментарий от anonymous

свои ядра и прочие велосипеды пишут во многих вузах, от студентов до профессоров, просто эти поделки так масштабно и пафосно не освещаются, а тут прям «ваааау, это ж МТИ!»

Я что-то не заметила пафоса. Вроде эта ОС не преподносится как убийца линукса, или готовый к продакшену продукт. Просто учебный проект, который может быть интересен в изучении, особенно для интересующихся языком go. Почему бы и нет?

totik
()
Ответ на: комментарий от anonymous

но чтобы все глобально - это вряд ли

Ну, есть thrashing, есть, в конце концов, 12309. Но ось на Go ко всему этому добавляет еще и stop-the-world.

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

Единственное полезное, что этот проект оценил - это оверхед «безопасного кода» в стиле Go (15%).

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

линуксукапец

отменяется
расходимся

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

Расскажи, какой из «вариантов на Rust» она порвет «по простоте применения».

Любой. By design.

anonymous
()
Ответ на: комментарий от tailgunner

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

anonymous
()
Ответ на: комментарий от totik

Учиться нужно хорошему. И если на Си распространяется понятие высокоуровневый ассемблер, то есть когда код написан на нормальном понятном человеку языке, а не состоит из сплошных ассемблерных команд, тогда можно получить прирост в скорости работы программ. Эта высокоуровневость дает прирост в скорости написания программ, а не в быстродействии. А вот когда начинают всякие Go и С++ проталкивать - там все зависит от реализации функций заложенных разработчиками. То есть если мозги кривые - тогда не удастся написать сложную функцию на Си, потому что надо быть адекватным. То есть имея Go или C++ легко можно ворочать большими объемами данных, а самое главное «Как» будет зависеть от создателей языка. И по этому параметру лучше Си только ассемблер может быть. Именно поэтому в ядре Linux используют Си на полную катушку. Да могут быть неожиданности если код писал человек с кривыми мозгами наискосок прочитав руководства по программированию и не слишком ясно представляющий как надо писать программу. Но сейчас этот проект доказывает что Go не дорос до уровня мастеров своего дела и не может заменить проргаммиста на Си.

anonymous
()
Ответ на: комментарий от annulen

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

И «сборка мусора» AKA «Garbage Collection» != Garbage Collector.

Почти во всех процессорах есть аж хардверная реализация сборки мусора в виде стека, которая отнимает в лучшем случае несколько тактов, например. А то, что делает Garbage Collector во всяких жабах с го - это примерно как рендерить и рисовать 3D при помощи CPU и функции SetPixel при наличии GPU.

Stanson ★★★★★
()

Лишний раз убедился что Линукс ненужная примитивная поделка, раз уж даже какой то аспирантишка за пару уикэндов его переписал.

А Виндоус никто не переписал потому что Энтерпрайз и надёжно а не это ваше красноглазие...

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

Почти во всех процессорах есть аж хардверная реализация сборки мусора в виде стека

Такое только в квотезы можно отправить. При таком уровне некомпетенстости обсуждать GC бессмысленно

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

Да компетенция около 0. Для справки. GC зачастую работает быстрее альтернативных систем управления памятью кучи. Основные проблемы - это непредсказуемость и фрагментация. В go кстати упаковка вообще отсутствует. Что впрочем и фича и бага одновременно. Да и фрагментация свойственна не только GC. Резюмируя GC - отличная штука для многих задач, но точно не для OS.

anonymous
()
Ответ на: комментарий от tailgunner

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

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

Я вот не пойму, что тебя так удивляет в том, что они стараются обойти GC? Аллокация памяти вообще штука небыстрая, особенно если её надо ещё собирать. Всё правильно делают.

Или ты про то что «15 процентов - ничестна»?

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

Я вот не пойму, что тебя так удивляет в том, что они стараются обойти GC?

А похоже, что меня это удивляет?

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

Выделение памяти - штука быстрая. Особенно если у вас есть приличный сборщик мусора.

Или ты про то что «15 процентов - ничестна»?

Я про «в 15% не входят расходы на GC».

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

с гц будет не 15, конечно, но и не 100500.

Никто не знает, сколько, и какие будут пики. Впрочем, неважно - никто не станет этим пользоваться.

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

Такое только в квотезы можно отправить.

Не только можно, но и нужно.

При таком уровне некомпетенстости обсуждать GC бессмысленно

Да я вообще-то и не собирался вообще как-либо обсуждать GC в понимании любителей всяких язычков для макак. Это всё равно что обсуждать какую-нибудь уринотерапию. Собирайтесь там своей кодлой и обсуждайте любую интересную вам гадость сколько влезет.

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

предел прочности ядра разделить на его плотность

anonymous
()
Ответ на: комментарий от Stanson

То есть существует какое-то другое, альтернативное понимание GC, стека, устройства процессоров? Удачи вам в вашей параллельной вселенной

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

Выделение памяти - штука быстрая. Особенно если у вас есть приличный сборщик мусора.

Фигасе, как связана скорость выделения памяти со сборщиком мусора? Вот от тебя не ожидал такого

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

Фигасе, как связана скорость выделения памяти со сборщиком мусора?

С копирующим коллектором выделение памяти - это буквально увеличение указателя.

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

Я посмотрел реализацию в вебките - там копирующий GC, но для аллокации объектов используется аллокатор общего назначения (но выделяет, разумеется, в пределах JS-ной кучи)

А какая разница - стек или просто большой массив с указателем?

Разница такая, что если надо в куче, которой управляет GC, выделять память для объектов разного размера, то чтобы не было адовой фрагментации нужно применять все те же общие алгоритмы, что и в сишной куче, т.е. эффективность выделения не должна быть сильно выше. Вот освобождение можно вынести в поток и от это выиграть сильно

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

А какая разница - стек или просто большой массив с указателем?

Разница такая, что если надо в куче, которой управляет GC, выделять память для объектов разного размера, то чтобы не было адовой фрагментации нужно применять все те же общие алгоритмы, что и в сишной куче

Разницы не увидел. В любом случае, живые объекты копируются в другую область памяти, а исходная освобождается полностью (в Chromium этого нет, AFAIK).

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

Переводить новости надо правиььно

We disabled Linux’s kernel page-table isolation, ....

Т.е. как минимум отключили изоляцию процессов. И еще пунктов 30.

The benchmarks allocate no heap memory in steady-state, so Biscuit’s garbage collector is not invoked

Т.е. кучу НЕ использует, таким образом сборщик мусора НЕ вовлечен.

Автору надо переводить текст, а не домысливать. Выводы не верные....

biohumanoid
()
Ответ на: комментарий от tailgunner

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

Я множатся твои потуги очень просто - ты идёшь сюда https://llvm.org/ProjectsWithLLVM/ и рассказываешь, почему твоя поделка существует в рамках llvm-инфраструктуры, т.е. в рамках компилятора llvm. Это будет слишком сложно для тебя - давай попроще.

https://llvm.org/docs/WritingAnLLVMBackend.html - вот тебе описание того, что такое бекенд. В частности:

compiler backends that convert the LLVM Intermediate Representation (IR) to code for a specified machine or other languages.

Теперь ты должен пойти и показать, где и как твоя поделка занимается этим. Т.е. в какой таргет она преобразует IR и где. Действуй.

nebanbmenyapls
()
Ответ на: комментарий от Odalist

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

VladimirP ★★★★
()
Ответ на: Переводить новости надо правиььно от biohumanoid

We disabled Linux’s kernel page-table isolation, ....

Т.е. как минимум отключили изоляцию процессов.

Они отключили патч против Meltdown. Процессы всё равно изолированы.

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

Теперь ты должен пойти и показать, где и как твоя поделка занимается этим. Т.е. в какой таргет она преобразует IR и где.

Специально для тупых: IR в таргет преобразует бэкенд LLVM, LLVM написан на Си++. Транслятор Rust преобразует исходный код в IR, транслятор Rust написан на Rust. Поймешь эти простые вещи - приходи (хотя лучше не приходи). В рамках этого топика ты больше не выступаешь.

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

А что, C - язык низкого уровня? Он же архитектуре современного железа соответствует от слова никак?

Разверни тезис подробнее, интересно же.

Ты про отсутствие встроенных в язык средств многопоточности, или ещё про что?

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

Однакож факт остается фактом. Сколько сил и времени ушло на реактос? И где они все еще? А тут пара месяцев и ядро...

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

Сколько сил и времени ушло на реактос?

Ты перепутал Linux и ReactOS.

А тут пара месяцев и ядро...

Зачем ты лжешь так глупо?

tailgunner ★★★★★
()

ядро на я.п. со сборщиком мусора. Срамота. Чтож, все актуальнее становится та юморная картинка, про драйвера на джаваскрипте

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

Эээ, я, конечно из деревни и все такое...

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

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

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

В связи с чем вопрос, как, по-твоему в растений, без gc, если gc - название механизма неявного освобождения памяти.э?

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

Мне тоже так казалось, но ганнер выше сказал, что Go не очень можно, мб он прав.

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

Но такое можно для любого языка реализовать. Даже для си

После этого Си уже будет чем-то другим.

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

в redox так-то даже gui есть, хоть и страшный вырвиглаз, а это поделие только пяток программ пускать умеет, это победа

Для громких слов этого достаточно

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