Алиса Розенцвейг (Alyssa Rosenzweig) из компании Collabora, развивающая OpenGL-драйверы Panfrost для GPU Mali и Asahi для GPU Apple AGX, представила новый Vulkan-драйвер Honeykrisp для графического процессора, поставляемого в чипах Apple M1. Несмотря на то, что драйвер разрабатывается всего месяц, он уже признан консорциумом Khronos, как полностью реализующий спецификацию Vulkan 1.3 на оборудовании Apple c чипом M1. Honeykrisp стал первым драйвером для чипов Apple, имеющим сертифицированную поддержку графического API Vulkan...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61318
В таких новостях я бы хотел видеть присказку что такое Вулкан и чем он знаменит. Как в новостях про раст и безопасную память.А то не ясно чем вулкан от опенгл отличается и зачем он нужен.
Короче, OpenGL - это высокоуровневый API для написания графических приложений людьми напрямую. Vulkan - это очень низкоуровневый GPU API, который создан именно для того, чтобы служить бекендом/таргетом для разных движков и так далее. Он не создан для обычного хобби использования напрямую (если хочется, то можно, но больно и нет смысла). Vulkan вообще не только про графику, он именно про GPU, так что его можно использовать и для реализации всяких нейронных сетей и так далее, как CUDA.
Ты забыл упомянуть, что OpenGL уже несколько лет как умер.> Vulkan вообще не только про графику, он именно про GPU
Неверно, этим он вообще от OpenGL не отличается. Вычислительные шейдеры были и в OpenGL. Ты должно быть спутал c OpenCL.
>> OpenGL уже несколько лет как умерДа что ты такое несешь черт побери? Эта штука бессмертна к ней только и будут всякие вулканы прикручивать
Opengl доживает последние дни в виде легаси, vulkan является прямым развитием и продолжением технологий. И ты в целом ошибаешься, это opengl можно прикрутить к vulkan. Только зачем?
понятно, как x11 и как xmpp бггг)
opengl это ещё и офигенное api. Чем пользоваться разрабам ПО, если не им? vulkan'ом низкоуровневым страдать?
А не всё ли равно тебе как пользователю? Хотя у вулкана поменьше багов наберётся наверно. Opengl и так почти не используется в индустрии. Что ты предпочитаешь, чтобы все перешли на directx12, или чтобы все перешли на vulkan? Вообще, прямо сейчас у opengl нет паритета ни с чем, некоторый паритет поддерживается между dx12 и vk.
> А не всё ли равно тебе как пользователю?Как пользователю всё равно. А как разрабу нет.
> Хотя у вулкана поменьше
> багов наберётся наверно. Opengl и так почти не используется в индустрии.Здрасте. Все игры под linux-based ОС - opengl.
Да, все десятка два штук.
Разработчик никогда не выберет опенгл (если только не намеревается обеспечивать совместимость со старыми телефонами). В итоге, к примеру, игры, портированные на линукс, в основном понерфленные, без части шейдеров/теней/эффектов, с отличающейся производительностью, либо включают различные графические трансляторы и работают с переменным успехом. Все приличные игры под линукс на вулкане. Всё ПО тоже переползает на вулкан, настолько быстро, насколько это возможно.
> Да что ты такое несешь черт побери? Эта штука бессмертна к ней только
> и будут всякие вулканы прикручиватьЭто вы чего-то не понимаете. Из OpenGL невозможно сделать вулкан. Точнее, это - абсолютно бессмысленное занятие.
GL - высокоуровневый интерфейс с кучей внутреннего состояния, делающий дохрена внутри сам. Из этого невозможно собрать низкоуровневый "тонкий" слой абстракций над GPU, by design. Оно совсем не это. То-есть если это попытаться, из-за вон того перфоманс будет полным УГ, потому что GL не про просто и не про быстро - и никакого смысла в этом комбо просто нет. Прелесть вулкана в том что это быстрый и прямой интерфейс к GPU без кривого и устаревшего слоя абстракций которые только мешаются нормальным движкам.
А вот наоборот - сделать из vulkan'а GL - фигня вопрос. Вроде даже уже есть такой драйвер.
TL;DR сделать из низкоуровневой штуки высокоуровневую не вопрос, а вот наоборот - упс.
Весь линукс десктоп рендерится на OpenGL и его вариациях, как и все браузеры под линуксом. Да. Умер. Много лет.
Последний релиз 6 лет назад и больше не будет.
Моя точка зрения такова.Разгребая треды 2000 года на сайте ixbt, я узнал, что выбор между Direct3D 7 и OpenGL 1.4, это выбор между предсказуемостью и фичами. Фичи в Direct3D добавляет Microsoft, и никто больше. Тогда как в OpenGL фичи может добавить вендор.
Вот и встаёт перед разработчиком выбор. Сделать более красивую игру, но тестировать её на всех возможных видеокартах (экспериментальные фичи могут быть на одних картах и не быть на других). Или сделать менее красивую игру, зато одинаково работающую на картах всех производителей.
Потом был DirectX 8 и OpenGL стал проигрывать по фичам. Фичи - главный козырь OpenGL, и проигрыш по фичам привёл к падению популярности самого OpenGL.
К 2004 году OpenGL - всё:
* Half Life 2 вышел без OpenGL.
* В Far Cry вырезали OpenGL в последний момент (можно включить в конфиге, но рендер недоделан, то текстуры пропадают, то модели).
* UT2003/UT2004 поддержку OpenGL сохранил.
* Doom 3 вышел провальной игрой.Каждый новый релиз Direct3D соотносится с новым поколением видеокарт:
* GeForce FX и Radeon 9700 это Direct3D 9
* GeForce 6/7 это Direct3D 9.0b/c
* GF 8 это D3D 10
* Fermi это D3D 11.А потом случилась беда. Microsoft анонсировал DX12 во время презентации Windows 8. Даже UT4 показывал от Epic Games. Но... DX12 не вышел.
Это был первый случай, когда вендоры выкатили новое поколение видеокарт, а нового директ3д под него нет! А я напомню, вендоры не могут взять и добавить фичи самостоятельно. Только в OpenGL.
Вот тогда-то и решили откопать стюардессу. На сайте developer.nvidia.com начали публиковать экспериментальные драйверы для разработчиков. Там был OpenGL 2015 и OpenGL 2016.
https://www.phoronix.com/news/NVIDIA-OpenGL-2015-Linux
https://www.phoronix.com/news/OpenGL-2016-NVIDIA-DriverТам были все фичи, которые появились в новой видеокарте Kepler. На Direct3D 11 они были недоступны.
AMD пошла своим путём, сделав Mantle. Mantle позволял задействовать ВСЕ ядра CPU, а не так, что два работают, а два простаивают (или 4 работают, 4 простаивают). Но сложность написания кода игр выросла (некоторый код, который раньше писали разработчики драйвера, теперь пишет автор игры/движка).
Ну и на базе Mantle был создан DX12. А потом спецификации Mantle передали консорциуму Khronos Group, разработчику OpenGL. И они сделали на основе Mantle - Vulkan, который пришёл на смену OpenGL.
Если Linux это ядро, то OpenGL "умер" с включением в состав Mesa драйвера Zink https://docs.mesa3d.org/drivers/zink.htmlС того времени производителям железа нет необходимости поддерживать OGL в драйвере, достаточно Vulkan. Из имеющихся драйверов код в ближайшее время может быть и не выкинут, но тенденция ясна.
> Если Linux это ядро, то OpenGL "умер" с включением в состав Mesa
> драйвера Zink https://docs.mesa3d.org/drivers/zink.html
> С того времени производителям железа нет необходимости поддерживать OGL в драйвере, достаточно
> Vulkan. Из имеющихся драйверов код в ближайшее время может быть и
> не выкинут, но тенденция ясна.Угу. Вон Intel не реализовал поддержку DirectX9 в своих видеокартах Ark, сказал пусть будет DXVK прямо в драйверах. И что? Лютый багадром, глюкодром и треш в DX9 играх.
Это в какой ОС? У них вроде бы не только с DX9 были проблемы по началу.А вообще, это ничего не изменит в плане отказа от устаревающих API. Интел даже своё железо 5-ти летней давности не поддерживает, и это один из крупнейших производителей железа.
> Это в какой ОС? У них вроде бы не только с DX9
> были проблемы по началу.
> А вообще, это ничего не изменит в плане отказа от устаревающих API.
> Интел даже своё железо 5-ти летней давности не поддерживает, и это
> один из крупнейших производителей железа.Windows конечно же.
https://www.tomshardware.com/news/intel-xe-arc-swap-to-dx9-e...
Хотя нет ошибся, не DXVK, а D3D9On12. Хотя большинству dx9 игр можно подсунуть dxvk dll файлы прямо в каталог с игрой и оно работает везде по-разному.
>> Это в какой ОС? У них вроде бы не только с DX9
>> были проблемы по началу.
>> А вообще, это ничего не изменит в плане отказа от устаревающих API.
>> Интел даже своё железо 5-ти летней давности не поддерживает, и это
>> один из крупнейших производителей железа.
> Windows конечно же.
> https://www.tomshardware.com/news/intel-xe-arc-swap-to-dx9-e...
> Хотя нет ошибся, не DXVK, а D3D9On12. Хотя большинству dx9 игр можно
> подсунуть dxvk dll файлы прямо в каталог с игрой и оно
> работает везде по-разному.Я не вполне понимаю, что такое "Native DX9 hardware support". В Windows DX реализован на уровне драйвера - MS требует, что бы он предоставлял определённое API, а dll пространства пользователя выполняют роль обёрток. Если ОС поддерживает DX12, значит железо и драйвер реализует в первую очередь его (отсюда и возникла вся эта история, почему DX12 очень похож на Vulkan - производители железа объяснили MS, что им проще делать универсальный драйвер под все ОС). Там так или иначе происходила эмуляция предыдущих версий DX (двумерный DDraw7 в какой-то момент начали эмулировать через 3D), просто теперь её окончательно вынесли в пространство пользователя, что бы упростить драйвер. OGL там всю жизнь был обёрткой над DX, кстати.
Вот и я не понимаю почему Intel Ark самые глючные видеодрайвера (а возможно и видеочипы) на ютубе полно видео сравнения. И при том что кушает оно электричества на уровне Nvidia.
Наверное, потому что Intel это в первую очередь понты и политика, приводящая к уходу толковых людей во всякие Zilog-и. Сколько у них было громких пустышек? Penium 60, Pentium Pro, Itanic, P4 NetBurst, Intel 740, Curie... Отдадут Ark на доработку второсортному по мнению менеджмента подразделению, те и выкатят 2-ю версию, работающую.
Ну он и живой примерно как линукс десктоп.
Раньше все видяхи были концептуально разными, прям совсем. Я помню те времена, когда игры выходили под конкретную(!) видяху, а на других не работали. Так появилась нужда в каком-то абстрактном эталоне видяхи. Его то и описывает OpenGL, а разные вендоры реализуют его уже на базе своего железа. Считай виртуальная видеокарта. Удобно для разрабов игр, но жрёт проц даже с учётом всех оптимизаций.Со временем неэффективные архитектуры подохли благодаря конкуренции, а эффективные были активно "воспроизведены" всеми "участниками соревнований" благодаря промышленному шпионажу и инженерам перебезчикам. В итоге концептуально все видюхи сейчас очень похожи, необходимость в толстенной прослойке отпала. OpenGL стал неоправданно большим, сложным и избыточным.
Vulkan - простой и тонкий API для отрисовки графики. Он делает то же самое, что и OpenGL (нет конечно, но на уровне профана - да). Работает везде, не грузит проц как OpenGL, упрощает управление железом. С быстрым процом разницы видно не будет, а вот со слабеньким Vulkan может выдать больше фпс, меньше статтеров, ниже среднюю задержку.
Статтеры пропали потому что в Vulkan (как и в DX12) появилась асинхронная компиляция шейдеров. В DX9/10/11 для отрисовки шейдера он должен был сперва скомпилироваться в рантайме под комбинацию 3D модель + шейдер + текстура + видеочип + версия драйвера. И если что-то из этой солянки обновляется то кешированный шейдер становится не валидным. Именно так постоянно лагала игра Path of Exile.
Тем не менее DX11 из моего опыта 7 летней давности был самым лучшим, потому что управление видеопамятью делал сам. Но как только пошли видеокарты по 4/6/8/10/11/12+GB vram всем на это стало покласть кирпичи.
Почему нет отдельного абзаца
«Драйвер написан на Си. Выбор языка позволил сделать разработку в кратчайший срок»?
Плюсую про быстроту. На Си можно быстро набросать идею, проверить, набросать новую, проверить, улучшить. На расте придётся сразу писать правильно. Идея не подошла – переписываем, снова тратим время на борьбу с "правильным строгим компилятором".
С таким подходом далеко не уйдёшь. "Кое-как набросал и в продакшон" приводит к тому, что кодобаза становится неподдерживаемой настолько, что даже рефакторинги не помогут. Алсо на Си то с отсутствием вменяемых генериков и ООП очень быстро пишется код, да.
> Кое-как набросал и в продакшонНе перевирай, я такого не писал.
К этому и приводит всё. Я не защищаю раст тащемто, вопрос в том, что Си тут не пример для подражания. И да, борров чекер не будет пытать ошибками если к нему привыкнуть.
Раз ты раст не защищаешь, расскажи трезвым взглядом, почему дровишки для видоса для Asahi сначала написали на питоне, а потом переписали на раст?
> Алсо на Си то с отсутствием вменяемых генериков и ООП очень быстро пишется код, да.Не удержался аноним
Проговориться не краснея!
Он весь стандарт на память изучил,
И вот - сияющая панацея!Долой emacs и прочее старьё!
Мы в веке ООП и раста!
Научит щедро нас писать на нём,
И под винду собрать удастся.Вы suckless патчите ночами
Чтоб Wayland покорился вам.
А аноним позванивая TLS ключами
Шатать хотел и гном и этот хлам.На KDE скорее прыгай, детка!
Там кнопки, окна и Qt.
Зачем ты, сишный код лелея,
Пытаешься фэн-шуй найти?Под торжество deep learning-а в нейронах,
Двадцать второй стандарт откроем, брат!
Вам асинхронно обещаю море
Чистейших кодовых шедевров, это факт.Без ООП вы словно в джунглях,
А препроцессор не шаблон, не ври!
Структуру в функцию кидать - не мудро.
Скорее class мне в заголовке напиши.На c++е браузеры писали,
Дрова для Apple, весь Android.
А ты мне с гномом этим аномальным
А саклес краток словно Hello WorldНи классов, ни обвязки, где все соки?
GObject даже неприлично поминать!
Скорее растом я обмажусь при народе
Чем сишника в контору нанимать
Вы не понимаете того как живёт индустрия, а живёт она так же как в реальном биологическом мире - естественным отбором.
Нет проблемы в том чтобы там была неподдерживаемая кодовая база, потому что если идея годная и востребованная то перепишут с нуля.
Нужно просто силы свои оценивать. Личные проекты вообще лучше на питоне писать - быстро делается, так что не устанешь. Си не подходит ни чтоб писать долговечный, качественный код ни чтоб быстро прототипировать. В обоих нишах есть ЯП лучше. Проблема сишки в том, что пока одни прикручивали ООП и нормальную стандартную библиотеку в комитете ничего не делали. Пока другие придумывали как автоматизировать доказательство безопасности в комитете тоже ничего не делали. Жить за счёт прежних достижений можно, а вот в будущем что? Не надо только про стабильность говорить, стабильность это когда легаси код поддерживается, а новый пишется не опираясь на старые функции. Тут же на лицо стагнация.
Си подходит чтоб рубить бабло не слишком просиживая жопы за кампом, потому что пока аноним рассуждает о том, как ему кажется должно было бы быть, существует парадокс. Куча сишного кода, который работает и никуда не собирается. Вот следующая новость про ффмпег, ты думаешь там кто-то питона нюхал, или на крестах?
> Си подходит чтоб рубить бабло... на исправлении своего овнокода годами
> Куча сишного кода, который работает и никуда не собирается.
Еще как собирается. Из того же андроида дропают в основном дыряшечные кода и заменяют на нормальные языки - с++ и rust.
> ффмпег
это древняя куча легаси.
Понятное дело что переписать ЭТО на что угодно - это огромная проблема и никто не хочет в это макаться.
А современные вещи пишут и на си, и на расте.
Напр. rav1d/rav1e вместо dav1d.
> Напр. rav1d/rav1e вместо dav1d.ИЧСХ хотя rav1e теоретически где-то есть, реальная борьба идет между сишным libaom и сишно-плюсатым SVT1 :). А rav1e - ну, я живых юзеров оного не встречал. Хотя он формально и есть.
> ... на исправлении своего овнокода годамиНе обязательно своего, иногда чужого. И что??
Плюсовый код вообще с нуля переписывали не так давно.
А про Раст скорее прикольно поддакивать, типа даа, надо на раст, ах вот если бы на раст, но все понимают что это же шутка и трэшак, никто ничего делать не будет.Просто вдумайся, открыл gdb, пофиксил багу, потом открыл ютубчик, все довольны :)
Надо что-то новое написать - запилил на сишке и опять все довольны. Чтобы добраться до краша - это надо чтобы сначала проект стрельнул, попал в популярный браузер, всех 10 раз похакали, потом ты за 5 минут одной строчкой это починил, согласился что а вот если бы на раст, и пошёл чайку попить
> Понятное дело что переписать ЭТО на что угодно - это огромная проблема и никто не хочет в это макаться.Ещё как хочет, гугли libav-rs или что-то такое, там даже бывшие разрабы самого ффмпега клюнувшие на идею. Вот как раз если хочешь поставь себе на дистр вместо ффмпега, так оно безопаснее.
> Личные проекты вообще лучше на питоне писать - быстро делается, так что не устанешь. Си не подходит ни чтоб писать долговечный, качественный код ни чтоб быстро прототипировать. В обоих нишах есть ЯП лучше.Конечно, есть лучше. Называется Visual Basic. То, что медленный - так не медленней Python. Если Python устраивает по скорости, то и Basic сойдет.
Ну написал ты код, он заработал - дальше что с ним таким делать?
Переписывать под петон 4, потом под петон 5 и так далее?
И попутно разгребать 100500 лефтпад зависимостей разных версий.Код на С как был лет 30-40 назад так и остался, и собирается и работает.
Можешь вон скачать RFC с MD5 и от туда копипастой собрать референс.
> стабильность это когда легаси код поддерживается, а новый пишется не опираясь на старые функцииТак это вы щас за велосипедостроение топите получается.
Типа не надо старую функцию для md5 использовать, надо ещё раз новую md5 написать :)
> Нет проблемы в том чтобы там была неподдерживаемая кодовая база, потому что если идея годная и востребованная то перепишут с нуля.Судя по комментариям к любой новости про Wayland или Xorg, у последнего просто умопомрачительная востребованность. Однако переписывание с нуля почему-то не происходит. Видимо, не всё так просто с естественным отбором.
> Wayland
> C 97.1%Ой, а где Rust?
> Ой, а где Rust?Напр. тут github.com/Smithay/wayland-rs Rust 99.9%
тут github.com/YaLTeR/niri Rust 97.6%Ну и кроме композиторов есть бары, ланчеры и тд
Вот тебе ссылочка - просвещайся github.com/rcalixte/awesome-wayland
В проде используется Wayland на C от freedesktop, а не поделка от умельца с левого гитхаба.
Там штук 20 файлов всего.
Если говорить про имплементацию на си, то лучше уже вестон в пример приводи.Но все равно видно, что wayland на дыряшке написан:
fix undefined behavior in wl_array_for_each
Mitigate UAF crashes due to wl_client_destroy reentrancy
Mitigate UAF crashes due to iteration over freed wl_resources
avoid calling memcpy on NULL
fix segfault when accessing destroyed pool resource
fail on global name overflow
...
и это только первая страницаВ общем типиКал си)))
Вышеперечисленное говорит о профнепригодности кодописателей, а не недостатках Си. На Ассемблере ещё больше ошибок может быть, что не говорит о том, что язык плох, а говорит о непрофессионализме или невнимательности программеров.
Не всё так однозначно.util: fix undefined behavior in wl_array_for_each
If a wl_array has size zero, wl_array_for_each computes NULL + 0 to get
to the end pointer. This should be fine, and indeed it would be fine in
C++. But the C specification has a mistake here and it is actually
undefined behavior. See
https://davidben.net/2024/01/15/empty-slices.htmlClang's -fsanitize=undefined flags this. I ran into this in Chromium's
build with wayland-scanner on one of our XML files.../../third_party/wayland/src/src/scanner.c:1853:2: runtime error: applying zero offset to null pointer
#0 0x55c979b8e02c in emit_code third_party/wayland/src/src/scanner.c:1853:2
#1 0x55c979b89323 in main third_party/wayland/src/src/scanner.c
#2 0x7f8dfdb8c6c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#3 0x7f8dfdb8c784 in __libc_start_main csu/../csu/libc-start.c:360:3
#40x55c979b70f39 in _start (...)
https://gitlab.freedesktop.org/wayland/wayland/-/commit/8a7e...
Сам код:/**
* Iterates over an array.
*
* This macro expresses a for-each iterator for wl_array. It assigns each
* element in the array to \p pos, which can then be referenced in a trailing
* code block. \p pos must be a pointer to the array element type, and all
* array elements must be of the same type and size.
*
* \param pos Cursor that each array element will be assigned to
* \param array Array to iterate over
*
* \relates wl_array
* \sa wl_list_for_each()
*/
#define wl_array_for_each(pos, array) \
for (pos = (array)->data; \
+ (array)->size != 0 && \ // <-- исправление
(const char *) pos < ((const char *) (array)->data + (array)->size); \
(pos)++)https://gitlab.freedesktop.org/wayland/wayland/-/blob/8a7ecd...
Во-первых, UB здесь формальный, о чём указано в commit message и по ссылке (Fortunately, there is hope. Nikita Popov and Aaron Ballman have written a proposal to fix this in C. https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UC...).
Во-вторых, мне не понятно, откуда в (array)->data возьмётся NULL?
Mitigate UAF crashes due to wl_client_destroy reentrancyhttps://gitlab.freedesktop.org/wayland/wayland/-/merge_reque...
> We can probably avoid our crash by being less eager with performing updates that might end up being no-ops - but this doesn't feel like the right fix. We'd like to treat these update methods as idempotent and avoid us potentially introducing another similar crash in the future.
и так далее...
Там тоже не всё так однозначно. Однозначно другое: самому вбрасывающему "типикал си" читать это не обязательно, главное, наставить побольше смайликов для солидности.
>[оверквотинг удален]
> Но все равно видно, что wayland на дыряшке написан:
> fix undefined behavior in wl_array_for_each
> Mitigate UAF crashes due to wl_client_destroy reentrancy
> Mitigate UAF crashes due to iteration over freed wl_resources
> avoid calling memcpy on NULL
> fix segfault when accessing destroyed pool resource
> fail on global name overflow
> ...
> и это только первая страница
> В общем типиКал си)))В общем, понятно, кто набросы делает.
Там, где ему и место
Но про шаблончики и клинкод почитай, занимательная литература
> живёт она так же как в реальном биологическом мире - естественным отбором.А как это соотносится с взятками, чемоданами кому нужно, санкциями или протекцией внутр рынка...
Не, ну я понимаю, что человек это тоже "биологический мир", но к естественному отбору относится мало.Я уже молчу про всякие взбрыки великодушных диктаторов, из-а которых мы в ядро получили раст, а не С++.
> если идея годная и востребованная то перепишут с нуля
или будут твердить "работает не трогай", "всего 30 лет коду", "диды на улицу бегали, таз зачем вам канализация"
> Я уже молчу про всякие взбрыки великодушных диктаторов, из-а которых мы в
> ядро получили раст, а не С++.Ключевое слово "получили". Которое следует читать как "не смогли". Но виноват, как всегда, злой дядя.
А кто виноват в тупом заявлении типа "С++ это овно, его в ядре не будет"?
Марсиане? Рептилоиды?
Не, таки злой дядя, который сказал чушь, а потом не хотел признавать, что был не прав.
Не надо клеветать на Линуса Торвальдса. Он сформулировал иначе. Заявил, что много "бестолковых" программистов. Не заставлял каждого принимать это на свой счёт.
> C++ is a horrible language
> C++ leads to really really bad design choices
> You invariably start using the "nice" library features of the language like STL and Boost
> the whole C++ exception handling thing is fundamentally broken
> hide things like memory allocations behind your back.
> Note that no one in their sane mind would expect to use all the features
> of C++. Just like we have "kernel C" ... we would have "kernel C++"А вот это из рассылки текущего года, где Линус не появился. И слова про "their sane mind", а точнее, его отсутствие, как бы переносятся на Линуса: тот побеждал соломенное чучело, чтобы обосновать своё идеологическое (а не техническое) решение.
>> C++ is a horrible languageУмело выдернул цитату из контекста:
It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it.Если это сложно понять, то вот детская загадка:
Идёшь. Видишь впереди дверь. На двери написано "дуракам вход воспрещён". Что будешь делать?
>> Note that no one in their sane mind would expect to use all the features
>> of C++. Just like we have "kernel C" ... we would have "kernel C++"
> А вот это из рассылки текущего года, где Линус не появился. И
> слова про "their sane mind", а точнее, его отсутствие, как бы
> переносятся на Линуса: тот побеждал соломенное чучело, чтобы обосновать своё идеологическое
> (а не техническое) решение.А зачем ему появляться? Что бы что? У меня conforming implementation стандартной библиотеки для ядра, то есть поддерживаются исключения и typeinfo. Линус прав, я это не использую, и никто не использует. Оно сделано ради "conforming" и для юзерленда. Два человека взяли и сделали, а тут целое сообщество ноет, какой плохой Линус, какие плохие корпорации внедряют Rust и т.п. И это при том, что на всё это код открыт в gcc!
не так. Если взяться реализовавывать какой-то сложный проект, то на Си ты напишешь говнокод, в котором придется еще долго ловить баги, UB и прочие уязвимости, но который в целом будет как-то работать.А на расте ты потратишь несколько лет и в итоге плюнешь, потому что все это время правильный строгий компилятор будет тебя вымораживать долгим временем компиляции (даже инкрементальной), сигнатурами из дженериков с 20 трейтами (которые придется менять по всей кодовой базе на каждый чих, что приводит к предыдущему пункту), массивными паттерн матчингами с кучей вложенных скоупов при обработке ошибок, и т.д. и т.п.
Ну или гибридный подход, которым чаще всего и пользуются растоманы: написать ключевые части, делающие настоящую работу, на Си или C++, спрятать их глубоко в кишках проекта (желательно в другом репозитории, чтобы Github показывал "Rust 99%"), написать на расте тонкую "безопасную" обвязку над ними, и гордо объявить что проект "written in rust".
Раст отличный язык, C старая дырявая шляпа, на которую дрочат маргиналы опеннета
Может и отличный. От других. Но лицензия не позволит для ядра. Так что потаращились, и хорош.
Раст негоден для применения от слова совсем.
Используйте С++ и не парьте себе и людям мозги!
> Плюсую про быстроту. На Си можно быстро набросать идею, проверить, набросать новую,
> проверить, улучшить. На расте придётся сразу писать правильно. Идея не подошла
> – переписываем, снова тратим время на борьбу с "правильным строгим компилятором".Ну, предыдущий драйвер писался вначале на питоне, а потом переписывался на нормальный ЯП (не на СИшку).
Возможно тут или драчер проще, либо есть уже понимание как оно работает с учетом предыдущего опыта.
Потому что это правда для прототипов на Python. Сишка, мягко говоря, для быстрого прототипирования не подходит, из-за медленной компиляции (спасибо хедерам) и неопределённого поведения. Питон обладает просто гигантским количеством библиотек, имеет удобную стандартную библиотеку "из-коробки", и компиляции не требуется - код запускается мгновенно. Вот когда базовую идею отработал, драйвер может рисовать, вот тогда нужно и на Си переписать.
Что, прототип видеодрайвера на питоне? Да вы фантазёр.
Библиотеки помогут
Ознакомься плиз https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ раздел "GPU drivers in Python?!"
"большая часть драйвера на самом деле представляла собой просто набор жестко запрограммированных структур"
то есть, фреймворк m1n1 + инициалицация в стиле портянок
"в конце концов мне удалось их исправить и отрисовать треугольник""невозможно сделать на Python, верно?!
Оказывается, у Mesa есть нечто под названием drm-shim"
"Когда жуткий ужасный стек драйверов Mesa+Python заработал..."На этом с "драйвером на Питоне" всё. И далее изучение Rust и переписывание с Си на Rust, и дальнейшее развитие.
Это у С то медленная компеляция!?
Самые огромные проекты на С собираются минут за 10 на 5950х, а там по 6к .с файлов.
Неопределённое поведение вообще мало кому мешает, и в основном тем кто пишет как попало.Питон так себе язык, из за огромной кучи зависимостей все эти прототипы написанные на петоне не годны к продакшену в принципе.
По крайней мере к продакшену здорового человека, потому что поддерживать этот зоопарк практически не возможно.
На фоне этого все страшилки про С просто фигня, потому что они легко исправляются, патч отправляется автору и проблема решена, а тут сам стиль экосистемы питона это не стабильность.
>Самые огромные проекты на С собираются минут за 10 на 5950х, а там по 6к .с файлов.Вопрос в том почему что-то вообще может собираться 10 минут на 5950х. Скорость компиляции гцц падает с каждым релизом, а скорость кода растёт на какие-то доли процента. 6к же файлов это ничто для современного процессора, он может их все прочитать и распарсить так быстро, что вы и не заметите, скорее всего главным ботлнеком тут вообще будет диск. Вообще, люди пишущие компиляторы часто достигают отметок вроде пары миллионов строк в секунду (Хоть и показатель сомнительный, явно быстрее чем гцц)
>>Самые огромные проекты на С собираются минут за 10 на 5950х, а там по 6к .с файлов.
> Вопрос в том почему что-то вообще может собираться 10 минут на 5950х.
> Скорость компиляции гцц падает с каждым релизом, а скорость кода растёт
> на какие-то доли процента. 6к же файлов это ничто для современного
> процессора, он может их все прочитать и распарсить так быстро, что
> вы и не заметите, скорее всего главным ботлнеком тут вообще будет
> диск.Пока боттлнеком является экспертиза. После семантического анализа ("распарсить") транслятор с синтаксическим деревом делает всякие разные штуки, в просторечии называемые "оптимизация". Скорость gcc падает, потому что с каждым релизом этих разных штук всё больше, что бы генерируемый код работал быстрее. Ну а проверить, как влияет "диск", можно самостоятельно, если удастся настроить ccache.
Про диск я говорил в контексте быстрой реализации, а не гцц. AST строить кстати даже и не обязательно, некоторые компиляторы сразу генерируют байткод/бинарь. Тем не менее необходимость таких медленных оптимизаций сомнительна. tcc вот генерирует код в ~10 раз быстрее чем гцц, но быстрее ли бинарь в 10 раз?
> tcc вот генерирует код в ~10 раз быстрее чем гцц,
> но быстрее ли бинарь в 10 раз?Опять боттлнек в экспертизе? Я должен проверить за кого-то, что бы что-то доказать сам себе?
> Про диск я говорил в контексте быстрой реализации, а не гцц.
"Скорость компиляции гцц" (ц)
В контекст "неизвестной эксперту реализации" gcc подходит вполне - очевидно, что Ivan_83 писал о своём опыте с Clang, поскольку у него FreeBSD.
> AST строить кстати даже и не обязательно, некоторые компиляторы сразу генерируют байткод/бинарь.
Да даже понимать, что такое AST, не обязательно. Оно же абстрактное, а не просто синтаксическое.
+1 к тому что у вас экспертиза хромает :)
Я в tmpfs собираю уже очень давно.
> Это у С то медленная компеляция!?Очевидно, эксперт перепутал с Си++, то есть не видит меж ними разницы.
> Самые огромные проекты на С собираются минут за 10Вряд "огромные" проекты собираются разом за один присест. Даже наши скромные проекты (чуть более 100 000 строк) собираем по частям. Так что речь в любом случае идет максимум о десятке секунд.
Конечно по частям.
Но для замера скорости - полная пересборка.
Например вот время сборки ядра Линукс:
https://openbenchmarking.org/test/pts/build-linux-kernel&eva...
Так исходно не скорость измеряли, а обосновывали необходимость модулей в С++ "Сишка ... для быстрого прототипирования не подходит, из-за медленной компиляции (спасибо хедерам)". Немного перепутав, с кем не бывает.
> "Сишка .. для быстрого прототипирования не подходит, из-за медленной компиляции (спасибо хедерам)".Так в прототипе на Питоне всего пара сотен строк.
Даже игнорируя скорость работы, оно стартует дольше чем Си скомпилирует.Впрочем автор упомянул, что ему так ошибки при инициализации смотреть удобнее. Выкрутился.
Так в том и дело, что речь о драйвере, где строк мало, а далее вбрасывают про медленную компиляцию вообще всего из левой методички про Си++, подменив язык. Если именно драйвер, да ещё и прототип, и на Си++ быстро соберётся.
Вы бы скачали quemu да пособирали сами чтобы составить представление.
> огромные проекты
> по 6к .с файлов.Ахаха)) Любители хелоувордов начинают мерятся своими петпроджктами))
6к файлов это просто ни> мало кому мешает, и в основном тем кто пишет как попало.
Т.е. 99% погромистов на си, включая ядрописак.
> все эти прототипы написанные на петоне не годны к продакшену в принципе.
За использование прототипов в продакшене нужно бить, возможно даже ногами.
И не важно на каком языке прототип был написан.
qemu, samba - не мои проекты, я просто иногда их собираю.
Ты ебaнyтый? У Си - медленная компиляция, ты когда-нибудь ядро пытался скомпилировать?
>Драйвер написан на Си. Выбор языка позволил сделать разработку в кратчайший срокДрайвер написан методом чуть подправленного копипаста. Выбор копипаста независимо от языка позволил сделать разработку в кратчайший срок.
Тогда уж на Python надо писать. Он - чемпион по скорости прототипирования.
За чей счёт банкет?
Это же не раст программисты с КоКами и фондами.
Удивишься, но Asahi — это они самые. Трансгендерные кошкодевочки с КоКами. И основная разработка ведётся на ржавчине.Просто данный драйвер представляет из себя наскоро перепиленный nvk, поэтому не было смысла переписывать. И феноменальная степень совместимости оттуда же¹, а вовсе не чудеса скоростной разработки.
[1] — https://web.archive.org/web/20240417193247/https://www.phoronix.com/news/Mesa-NVK-Vulkan-Conformant
> Asahi — это FedoraФиксанул. То что эти кошкобaбы пишут это капля в море и то на основе опенсорсных наработок от Apple.
Корпорации угощают, как всегда
Вулкан, мммм, в игры из 2007 уже играть можно?
Никто не запрещал
d9vk разрешает
Да
>>Поддержка DXVK и vkd3d-proton позволит использовать драйвер Honeykrisp в Asahi Linux на оборудовании с ARM-чипами Apple для запуска Windows-игр при помощи Wine и эмулятора архитектуры x86.Подскажите, с целью повышения уровня образованности. Где можно про эмуляцию x86 в линуксах на Арме почитать?
https://box86.org/
Скорее FEX-Emu.
И зачем нам твой говяный FEX, когда есть богоподобный box64 с кодом на 10/10?
Еще Розетта, кстати. Она ведь под линуксы тоже есть
> Еще Розетта, кстати. Она ведь под линуксы тоже естьО... А дайте плз ссылок.
а на 4 малину так нормальный vulkan драйвер, выпустиь не могут, который год. инвалиды.
малинщики безумцы которые выбрали broadcom вместо процессора, apple в данном случае лучше