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

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

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

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

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

тьфу опечатался. наоборот х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.

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

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

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

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

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

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

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

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

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

«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% это не вошло.

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

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

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

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

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

«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 почти не вызывался для определенного бенчмарка по той причине, что было мало аллокаций на куче — это только один из кейсов.

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

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

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

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

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

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

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

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

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

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

Лжешь.

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

Цитаты выше.

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

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

Цитаты выше.

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

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.

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

тесты 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» - пожалуй, всё же утверждали.

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

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

Только вот бенчмарки, результат которых показал всего 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 может занять значительно время.

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

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

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

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

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

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

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

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

Ой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

okay.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

js противник go, rust, java, c, js. ;)

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

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

Ядро ЧЕГО??

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

как-то само

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

Да хрен на 15% процессорного времени. Это голое ядро со старта выжирает вдвое больше памяти, чем дебиан/линукс с рабочим столом xfce, cups и smbd.