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)

сравнение производительности эквивалентного кода на Си и на Go показало всего 15% разницы

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

Вчерашним студентом. На языке со сборщиком мусора. 15%. Звучит одновременно и безумно, и впечатляюще.

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

Когда повторят по функционалу написанное на C ядро, тогда и поговорим, а пока эти 15% go-шный пук в пространстве.

anonymous
()

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

It has enough POSIX compatibility to run some existing server programs (for example, NGINX and Redis)

Авторы понимают, что «POSIX-совместимость» у них так себе.

We disabled Linux’s kernel page-table isolation, retpoline, address space randomization, transparent hugepages, hardened usercopy, cgroup, fair group, and bandwidth scheduling, scheduling statistics, ftrace, kprobes, and paravirtualization to make its code paths similar to Biscuit. We also disabled Linux’s FS notifications, atime and mtime updates to pipes, and replaced Linux’s scheduler and page allocator with simple versions, like Biscuit’s. The benchmarks allocate no heap memory in steady-state, so Biscuit’s garbage collector is not invoked

Такой себе бенчмарк.

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

наколенная поделка, умеющая запускать дай бох с десяток программ, всего лишь на 15% медленнее полноценного ядра

вселенская сенсация, ломающие новости, линукс рип

anonymous
()

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

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

проектом, который был написан вчерашним студентом

и еще примерно тысячей и одним человеком

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

Это надо в текст новости, а то там жирным херня выделена.

PPP328 ★★★★★
()

Интересно, до практического применения доведут, или запилят прототип и забросят?

Radjah ★★★★★
()

Кто готов срезать 15% производительности своего процессора ради удобства программистов, не осиливших нормально спроектровать архитектуру ядра чтобы GC был не нужен?

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

We disabled Linux’s kernel page-table isolation, retpoline, address space randomization, transparent hugepages, hardened usercopy, cgroup, fair group, and bandwidth scheduling, scheduling statistics, ftrace, kprobes, and paravirtualization to make its code paths similar to Biscuit. We also disabled Linux’s FS notifications, atime and mtime updates to pipes, and replaced Linux’s scheduler and page allocator with simple versions, like Biscuit’s. The benchmarks allocate no heap memory in steady-state, so Biscuit’s garbage collector is not invoked

Они с отключенным GC на 15% медленнее. Как только начнут использовать кучу (пока у них все на статических массивах) - начнут терять 500%.

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

Go GC не особо подходит под нужды ОС. Если выделить памяти, а потом освободить - он её оставит себе, про запас.

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

Более того, большая часть статьи - это описание того, как они боролись за то, чтобы GC вызывался пореже.

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

Такой себе бенчмарк.

А что не так? В равных условиях.

Если бы эти фичи оставили включёнными, то на ядре на go работало бы быстрее, чем на linux.

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

А что не так?

С тем, что GC в работе не участвует? Всё так. Просто надо понимать, что меряет этот бенчмарк.

Если бы эти фичи оставили включёнными, то на ядре на go работало бы быстрее, чем на linux.

Или не работало бы.

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

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

anonymous
()

Название конечно полный отстой. Да и вообще, оно же никому не нужно.

time_LORd
()
Ответ на: комментарий от dekar

Кто готов срезать 15% производительности своего процессора ради удобства программистов

Примерно весь бизнес, а пользователей никто и не спрашивает. См. историю си.

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

Кто готов срезать 15% производительности своего процессора ради удобства программистов

Примерно весь бизнес [...] См. историю си.

Глупости. Си и UNIX взлетели из-за переносимости, а не «удобства программистов».

tailgunner ★★★★★
()

показало всего 15% разницы (однако garbage collector в тестах производительности почти не вызывался).

Отличный бенчмарк! (сарказм)

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

Что за «безумно», «впечатляюще»? Заказным спичрайтером работаете? Хоть тут то отдохните:)

Ничего это не значит, потому что в реальных условиях так будет не только nginx, а весь стек, и mysql, и pgsql, и nodejs, и php и контейнеры и бог знает что ещё. И как в этих условиях будет вести себя ядро даже не проверить, потому что оно это не может.

Единственный адекватный способ сравнить что-то - это сделать продукт на базе разработки. Вот пусть например на базе своего ядра сделает операционку для реального применения, пусть в роутере, пусть в raspberry pi, да где угодно и сравнит как оно будет справляться в сравнении с тем же gnu/linux.

Ну или другой вариант, пусть пишет на go не ядро, какой-нибудь софт или библиотеку и сравнивает с аналогами.

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

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

Верхняя граница непонятна совершенно, ровно как и не понятно засчет каких именно фичей языка оно набежало. Насколько помню свои ковыряния в ядре, там много где самые нетривиальные оптимизации есть в горячих местах. От процессоро-специфичных ассемблерных вставок, заканчивая likely()/unlikely() на условиях даже в обычных с виду драйверах. Думаю, за счет этого на чем-то более «горячем» набежит намного больше 15%.

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

Верхняя граница непонятна совершенно

О чем и речь.

ровно как и не понятно засчет каких именно фичей языка оно набежало.

За счет чего набежало 15% - более-менее понятно, в статье об этом говорится.

Думаю, за счет этого на чем-то более «горячем» набежит намного больше 15%.

Темна вода во облацех.

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

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

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

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

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

Разница по-прежнему неясна.

Удобство программиста без переносимости бизнес не интересует.

разработка заметно дешевле.

Начинаешь понимать.

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

Кто в теме, а что мешает делать сборку мусора без GC как в расте?

Потому что раст и гоу - языки разного уровня
Раст - системный язык, гоу - прикладной, и в чем смысл написания ядра на прикладном языке, непонятно

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

anonymous интересуется. А что, C - язык низкого уровня?

Нет, конечно.

Он же архитектуре современного железа соответствует от слова никак?

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

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

Начинаешь понимать

Тебя - перестаю. Удобство программиста - это и есть «дешевле», в том числе. Разработать на си кроссплатформенную ОС дешевле чем на ассемблере, разработать ее на Go - еще дешевле, пусть и с меньшим разрывом.

anonymous
()

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

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

Удобство программиста - это и есть «дешевле»

Это не тождественные понятия. И напомни, каким образом мы перешли от «Си и UNIX взлетели благодаря переносимости» к «удобство == дешевле»?

Разработать на си кроссплатформенную ОС дешевле чем на ассемблере, разработать ее на Go - еще дешевле

На ассемблере давно не пишут ОС. Go (если бы всё это было всерьез) пришлось бы конкурировать с готовыми ОС на Си, и хватит ли его гиптотетических преимуществ в «удобстве», никто не знает. Почитай статью.

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

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

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

прямо во многих

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

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

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

А что там такого?

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

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

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

~ 27 тысяч строк кода ? Я не программист, правда, но новость поразила своей силой и размахом. Хоть я и не первый раз встречаюсь с тем, что программы образования сейчас стали много-интереснее и много-лучше, но закодить в универе ядро ? ) Причём достаточно крепкое, ну хз

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

А что там такого?

Современная реализация tcp в линуксовом ядре - https://github.com/torvalds/linux/blob/master/net/ipv4/tcp.c

Размер кода - 100 килобайт

Размер реализации tcp стека в гоу - 90 килобайт

Понятно, что вещи несопоставимые, но все же

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

Что там ~4k LOC, что там. Насколько я понимаю, это просто (ха-ха) конечный автомат, он на любом языке будет похожим.

Хотя в старые времена ОС писали и на Паскале, и на Фортране... но вроде бы никто не считает эти языки системными.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.