LINUX.ORG.RU

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

 , ,


6

4

Ядро было написано аспирантом 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%.

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

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

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

спроси у балмера. он тебе объяснит, что производительность не главное. главное маркетинг and to deliver! если бы ты ему предложил Go, пока они висту 7 лет писали... они бы сделали «ассемблерные вставки», где нужно, а с остальным справились бы за 2 года. и никто бы не заметил разницы в скорости.

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

дрова ты с линукса не сдерёшь - там юзерспейс надо часто тащить

vmware это сделали и ничего им за это не было.

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

Тебе достаточно исходного компилятора Go, а дальше любой вариант из доступных OS/Arch:

это для высокоуровневого кода, а как ты учтешь изменения в user API того же Linux ?

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

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

на С с таким срезанием углов можно и быстрее наваять.

// our flags; bits 9-11 are ignored for all page map entries in long mode
const PTE_COW mem.Pa_t = 1 << 9
const PTE_WASCOW mem.Pa_t = 1 << 10

а это ему кто-то сказал что игноред или он сам придумал? в опенбсд был большой бугурт изза этих самых битов в коре2.

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

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

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

где то читал что ядро на C которое писали в 197какомто году жрало на 30% больше ресурсов чем то которое было написано в машинных кодах.

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

Объясни мне, добрый человек, как rust связан с llvm, если я могу его собрать с gcc без всяких libllvm. Я что-то не так понимаю?

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

это для высокоуровневого кода, а как ты учтешь изменения в user API того же Linux ?

А можно конкретнее? Я не совсем понял о чем речь.

Если под «user API того же Linux» имеется ввиду API ядра — то его не ломают. Но это очевидно, поэтому скорее всего ты имел ввиду что-то другое. Так что?

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

и даже это не «эквивалентный код» относительно линукса

Не, там не в этом суть. Они не пытались сделать ядро на Go таким же по функциональности, как и Linux. Они просто взяли и вырезали из Linux весь код, который был «не эквивалентным».

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

«The fraction of CPU time consumed by garbage collection and safety checks is less than 15%. The paper compares the performance of equivalent kernel code paths written in C and Go, finding that the C version is about 15% faster.».

Доо. Только время GC входит в эту сумму примерно так: Biscuit: монолитное POSIX-совместимое ядро на Go

А если почитать статью, там видно, что они прыгают через обручи, только бы избежать GC. И это тоже доставляет:

«In summary, while the benchmarks in §8.4 / Figure 7 incur modest collection costs, a kernel heap with millions of live objects but limited heap RAM might spenda significant fraction of its time collecting.»

Но, естественно, в 15% это не вошло.

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

Почему в той новости про быстрый раст нету сноски «в составе llvm, т.е. в составе крестового рантайме».

Потому что всем пофиг, на чем написан бэкенд компилятора. В случае с Go на это тоже всем пофиг.

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

Чего? Ладно, мне лень объяснять, но предположим. Ты можешь его собрать gcc - это ничего не изменит. Ведь суть не в том, что там llvm, а в том, что он состоятелен только потому, что там llvm. Измени llvm на гцц - ничего не поменяется.

В этом «языке» в дизайне заложен паразитизм на сишно/крестовом рантайме. Без него он несостоятелен, целиком и полностью. Всё это целиком и полностью следует из заявлений пациента относительно go. Go без гц нет - го несостоятелен и все измерения «без гц» несостоятельны(по логике пациента), а это значит, что руста без С/С++ компилятора нет - раст несостоятален и все измерения «с С/С++ компилятором» несостоятельны.

Это ключевое.

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

«The fraction of CPU time consumed by garbage collection and safety checks is less than 15%. The paper compares the performance of equivalent kernel code paths written in C and Go, finding that the C version is about 15% faster.».

Еще раз, «The fraction of CPU time consumed by garbage collection and safety checks is less than 15%».

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

Перечитай статью, там понятно же все рассказано.

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

Царь, ты опять пришел без справки из психдиспансера?

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

Ты столько долго думал и это всё?

Потому что всем пофиг, на чем написан бэкенд компилятора.

За это тебя уже надо выпилить нахрен отсюда за балабольство, т.к. на крестах там не бекенд. Вернее бекенд тоже, как и всё остальное. Именно раст - это огрызок фронтенда для llvm. А бекенд - это относительно llvm, а не твоего грызка.

В случае с Go на это тоже всем пофиг.

Потому что всем пофиг работает там GC или нет. Я жду как скоро ты выпилишь своё балабольство из мейнпоста. Действуй.

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

Если под «user API того же Linux» имеется ввиду API ядра — то его не ломают.

API ядра для юзерспейс - да. Его не ломают (на самом деле иногда ломают) но постоянно добавляют новые системнве вызовы и целые подсистемы, например drm/kms, bluez, v4l2, wireless nl80211. Кросскомпилятор собирается под конретное ядро чтобы учесть это.

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

на крестах там не бекенд. Вернее бекенд тоже, как и всё остальное.

Лжешь.

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

Ты с темы не съезжай. Отвечай за балабольство. Когда ты его выпилишь, ведь никого не интересует - работает там гц или нет. Я жду.

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

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

То, что GC почти не вызывался для определенного бенчмарка по той причине

Цитаты выше.

Перечитай статью, там понятно же все рассказано.

Это тебе ее надо перечитать.

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

Цитаты выше.

Да, например эта цитата:

8.5 GC delays

We measured the delays caused by garbage collection (in- cluding interleaved concurrent work) during the execution of NGINX, aggregated by allocator call, system call, and NGINX request. 0.7% of heap allocator calls are delayed by collection work. Of the delayed allocator calls, the average delay is 0.9 microseconds, and the worst case is 115 microseconds, due to marking a large portion of the TCP connection hashtable.

2% of system calls are delayed by collection work; of the delayed system calls, the average delay is 1.5 microseconds, and the worst case is 574 microseconds, incurred by a poll system call that involved 25 allocatorcalls that performed collection work.

22% of NGINX web requests are delayed by collection work. Of the delayed requests, the average total collec- tion delay is 1.8 microseconds (out of an average request processing time of 45 microseconds). Less than 0.3% of requests spend more than 100 microseconds garbage collecting. The worst case is 582 microseconds, which includes the worst-case system call described above.

Которая намекает, что тесты garbage collector были, и в статье отражены. Никаких фатальных «а вот gc заработал и все зафризилось» обнаружено не было.

Это тебе ее надо перечитать.

NO U.

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

тесты garbage collector были, и в статье отражены.

Только вот бенчмарки, результат которых показал всего 15% проигрыша, «allocate no heap memory in steady-state, so Biscuit’s garbage collector is not invoked».

Никаких фатальных «а вот gc заработал и все зафризилось» обнаружено не было.

Этого никто не утверждал. Хотя... «a kernel heap with millions of live objects but limited heap RAM might spenda significant fraction of its time collecting» - пожалуй, всё же утверждали.

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

Да писали уже и на Java и на C# - что-то даже работало. Кстати если нельзя руками играться с памятью, то все традиционные механизмы защиты памяти и страниц можно выбросить. Какая разница что ты в одном адресном пространстве с ядром если ты не можешь трогать никакие адреса руками.

Еще похлеще бы взять да и затребовать писать весь софт на языках, в которых нету unsafe. Или есть unsafe, но устанавливать в сорцах и уже на месте компилировать в натив с нужным уровнем верификации, что мол конкретных код не содержит unsafe. Потом все держать в одном адресном пространстве и не копировать туда сюда память из ядра и в ядро. Например в случае с Rust было бы вообще супер

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

Только вот бенчмарки, результат которых показал всего 15% проигрыша, «allocate no heap memory in steady-state, so Biscuit’s garbage collector is not invoked».

А кто-то это отрицал? Я выше даже описывал это сам.

Моя претензия к манипуляциям вроде «это относительно быстро только потому, что GC не вызывался».

Потому что тесты GC были, и я тебя тыкал в них носом уже несколько раз — еще раз копипастить смысла не вижу — ты все равно не воспринимаешь.

Никаких фатальных «а вот gc заработал и все зафризилось» обнаружено не было.

Этого никто не утверждал. Хотя... «a kernel heap with millions of live objects but limited heap RAM might spenda significant fraction of its time collecting» - пожалуй, всё же утверждали.

Сходи на курсы английского. Эта фраза не «утверждает, что GC все стопорит», она говорит про то, что при ограниченном количестве памяти GC может занять значительно время.

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

В идиоматическом Go освобождением памяти занимаются не отдельные владельцы ресурсов (как в каком-нибудь Rust) : освобождение там делегировано центральной инстанции. Что вовсе не значит, что эта инстанция не может управляться кодом приложения явно, в ручном или полуавтоматическом режиме. Теоретически, дорогой рекурсивный обход всех ссылок приложения garbage-коллектором может быть избежен если приложение будет более явно указывать рантайму какие объекты должны остаться живыми.

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

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

В языке с GC мы должны явно указывать, какие объекты должны остаться?

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

Моя претензия к манипуляциям вроде «это относительно быстро только потому, что GC не вызывался».

Не-а, она в чем-то другом. Потому что фразу «garbage collector в тестах производительности почти не вызывался» ты удалил.

Эта фраза не «утверждает, что GC все стопорит», она говорит про то, что при ограниченном количестве памяти GC может занять значительно время.

«Значительное время» - это определение «фриза».

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

«Значительное время» - это определение «фриза».

Ой.

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

Речь о том, что приведенная тобой фраза имеет свой смысл только если ты не забываешь про «при ограниченном количестве памяти», то есть при недостатке ресурсов.

Для самых маленьких — это значит, что с текущей реализацией GC могут быть проблемы в том случае, если у тебя не осталось памяти.

Разницу понимаешь между твоим «ГЦ ФСЁ ТАРМАЗИТ» и той фразой, которую используют авторы?

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

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

Речь о том, что приведенная тобой фраза имеет свой смысл только если ты не забываешь про «при ограниченном количестве памяти», то есть при недостатке ресурсов.

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

Я конечно понимаю, что у тебя горит от того, что

Не-а. Это у тебя проекция.

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

ОС разной степени игрушечности (и серьезности) писали на чем угодно, от Фортрана до CL и Java с Haskell.

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

Без понятия, что заставило тебя подумать, будто я об этом забываю.

Если ты сознательно игнорируешь — и того хуже.

Ты говорил, что никто не писал о «всё зафризилось» - я тебе указал, что авторы сами говорят о такой возможности.

Авторы нигде не писали, что «все зафризилось».

ОС разной степени игрушечности (и серьезности) писали на чем угодно, от Фортрана до CL и Java с Haskell.

Но горит у тебя почему-то только от ОС, написанной на Go.

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

Ты говорил, что никто не писал о «всё зафризилось» - я тебе указал, что авторы сами говорят о такой возможности.

я тебе указал, что авторы сами говорят о такой возможности.

Авторы нигде не писали, что «все зафризилось».

okay.jpg

Но горит у тебя почему-то только от ОС, написанной на Go.

У тебя опять рефлексия. Я недоволен тем, что опубликованная на главной новость вводит людей в заблуждение.

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

У тебя опять рефлексия. Я недоволен тем, что опубликованная на главной новость вводит людей в заблуждение.

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

[1]: Именно мнимый, потому что я, например, используют и то и то — в разных задачах.

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

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

Хм. Зачем бы мне это было надо? Я бы понял, если бы ты приписал мне желание заставить Go выглядеть максимально убого, но зачем мне, чтобы он выглядел «не слишом убого»?

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

Хм. Зачем бы мне это было надо?

Проявление rust-фанатизма.

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

Зачем бы мне это было надо? Я бы понял, если бы ты приписал мне желание заставить Go выглядеть максимально убого, но зачем мне, чтобы он выглядел «не слишом убого»?

Проявление rust-фанатизма.

Из Rust-фанатизма я хочу, чтобы Go не выглядел слишком убого? Это слишком хитрый план для меня.

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

разве go это противник rust? ты ещё скажи, что java противник сишечки

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

Debian GNU/Biscuit уже начали пилить?

Будь первопроходцем! Флаг тебе в руки, и барабан на шею!

Odalist ★★★★★ ()

Ядро ЧЕГО??

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

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

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

Odalist ★★★★★ ()

27 тысяч строк на Go

НЕНУЖНО. Конечно логично, что хипстеры пишут на хипстерском языке. Совсем уже офигели.

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

Из Rust-фанатизма я хочу, чтобы Go не выглядел слишком убого?

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

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

У Go не язык с GC. У Go реализация с GC. Сам язык GC не требует. Что доказывается тем фактом, что при запуске Go-программы с GOGC=off, она не перестаёт от этого быть Go-программой. Если вам этого мало, вот слова straight from the horse's mouth: https://youtu.be/RIvL2ONhFBI?t=3221
Сам язык как таковой подталкивает лишь к тому, чтобы за освобождение выделений отвечала центральная инстанция, не более того.

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

У Go не язык с GC. У Go реализация с GC. Сам язык GC не требует.

Как освободить память, если мне надо? Если есть ссылки из нескольких мест, что случается?

вот слова straight from the horse's mouth: https://youtu.be/RIvL2ONhFBI?t=3221

Это из серии «any color you like».

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

А как можно собирать мусор без механизма сбора мусора?

Фри вызывать на каждый маллок?

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

У Rust нормальная система типов и высокий порог вхождения. Для Go это было неприемлимо (да и до сих пор).

tailgunner ★★★★★ ()

В лялихе дофига в ядре написано на ассемблере под каждую платформу. Так что сравнение некорректное.

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

Ну в расте же как-то само и без GC, я не вникал.

Это феерично.

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

27 тысяч строк на Go

Интересно, сколько рвотных пакетиков на это ушло?

bread ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)