LINUX.ORG.RU

Продемонстрирован запуск openSUSE с ядром Linux, собранным при помощи Clang

 , , ,


0

2

Разработчики openSUSE представили видеоролик, на котором продемонстрирован процесс загрузки и работы дистрибутива в графическом окружении, при использовании ядра Linux, собранного с использованием компилятора Clang вместо GCC. Сборка осуществлена с задействованием наработок проекта LLVMLinux, развиваемом при участии организации Linux Foundation с целью решения проблем со сборкой ядра в Clang и продвижения созданных патчей в upstream-проекты (ядро Linux и LLVM/Clang).

Использование компилятора Clang, распространяемого под лицензией BSD, позволяет задействовать дополнительные техники оптимизации и диагностики проблем, например, автоматизировать выявление фактов разыменования указателей и других ошибок, связанных с некорректной работой с памятью. Изначально проект LLVMLinux развивался в рамках инициативы Linaro и был ориентирован на сборку ядра для платформы ARM, но месяц назад была обеспечена поддержка архитектур x86_64 и i586.

Для упрощения формирования сборочного окружения и кросс-компиляции ядра с использованием Clang и LLVM подготовлен специальный сборочный инструментарий.

Сборка ядра для архитектур i586 и x86_64 полностью работоспособна и позволяет получать рабочие системы, что демонстрирует пример openSUSE, но официально подобные ядра пока не готовы для применения в конечных продуктах.

Дополнительно налажен ежедневный процесс сравнительного тестирования при помощи пакета Linux Test Project (LTP) свежих сборок ядра, собранных с использованием GCC и Clang.

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

★★★★

Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 1)

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

Отловить человеческие ошибки

Список отловленных ошибок можно где-нибудь посмотреть?

и куски индусского кода

А это что такое?

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

Дональд Кнут в треде, все в машину!

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

ядро это не то место где нужна оптимизация.

Это примерно как «Госдума - не место для дискуссий».

northerner ★★★
()

шлоанголлвм нужен был двум людям - Стиву Джобсу и Похорониковскому Микаэлю Ларабелю. Один все еще пивными фотками приарит разное, второй сами знаете.

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

Процесс разработки gcc таков, что новые подсистемы типа графена и LTO стоят в статусе экспериментальных годами. И всё равно с gcc 4.7.0 не собирается вебкит, и это не проблема в вебките. Код на языке C (->никакой проверки типов в визиторах) и архитектура 20-летней давности (рассчитанная на низкое потребление памяти 20 лет назад и в силу этого размазывающая генерацию кода и платформо-зависимые хаки по всему коду и в результате потребляющая куда больше памяти сейчас) не дают быстро интегрировать и отловить баги в серьёзных изменениях.

Далее - утилиты для программиста. Clang даёт полный набор

  • Интеграция в IDE. Это означает, что с clang IDE больше не будет подчёркивать красным код, который собирается компилятором, и не будет фейлиться с автодополнением на всяких
    for (auto &item: collection) {
       item.???
    }
    
  • Статический анализатор, который, в отличие от существующих опенсорсных и всяких пафосных PVS-studio, не лажает на сложных идиомах или новых конструкциях и практически не даёт ложных срабатываний; плюс та же интеграция в IDE - memory leaks в XCode ловятся анализатором очень красиво
  • Поддержка расширений инородных компиляторов - речь о visual C++, конечно. Можно сказать, что это не нужно, нам и так хорошо (с 2% на десктопе, ага), или что люди должны сами переписать код. Но что проще - переименовать 20000 файлов с *.CPP на *.cpp или написать питоновский скрипт, который сделает это сам? Переписывать весь код или доработать фронтенд, снизив переписывание на 90%, что для clang не является чем-то чрезмерно затратным?
  • Ну и сообщения об ошибках. GCC очень долго о них не заботился, иногда в его сообщениях просто была дырка из-за того, что он не мог сделать pretty print для определённого выражения. Теперь clang его пнул хорошенько, и начали исправляться. Но пока до кондиции не дошли. Вот тут описан текущий статус. Вот вам пример оттуда:
    #include <stdio.h>
    void f() {
    printf("%.*d");
    }
    
    Здесь одна проблема - забытый аргумент типа int. GCC 4.8 даёт два варнинга (дважды говорит про забытый аргумент типа int) и неверно указывает на позицию варнинга (что говорит о фундаментальных проблемах в количестве мета-инфомации, хранимой в синтаксическом дереве)
anonymous
()
Ответ на: комментарий от cvs-255

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

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

AVL2 ★★★★★
()

19 секунд загрузка только kernel на 8 ядерном?! Или это во время загрузки ядро компилируется?

Для сведения. Ядро, скомпилированное gcc, грузится около секунды на медленных процессорах с обычного hdd.

P.S.

Clang хорош для отлова ошибок, но пока не может побить по производительности gcc.

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

применить анализаторы кода из llvm к ядру

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

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

А как с производительность clang vs gcc?

Брось :) Тут правды никогда не отыщешь.

Buy ★★★★★
()

По сабжу, ну молодцы.

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

19 секунд загрузка только kernel на 8 ядерном?! Или это во время загрузки ядро компилируется?

А что, есть уже на чем скомпилировать ядро за 19 секунд? Я имею ввиду не минимальный обрезок.

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

Например копирование данных в цикле на memmove

А вот за такое по лбу надо. Потому что некоторые любят заполнять массив шаблоном именно с помощью копирования в цикле. А memmove так не умеет, т.к. при перекрывающихся участках копирует в ту сторону, при которой нужного эффекта не достигается.

cvs-255 ★★★★★
()
Ответ на: комментарий от red_eyed_peguin

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

ну возьми и посмотри.

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

Ядро 2.6 можно было скомпилировать и загрузить секунд за 15-20, насчет новых не знаю.

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

Я очень не люблю clang и llvm. Во-первых, потому что не GPL.

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

Во-вторых, потому что очень ограниченная поддержка архитектур.

Это как раз временно. К тому же добавление новых архитектур (как апаратных так и ОС) в clang как раз сделано проще и правильнее.

В-третьих, потому что все эти бредни вокруг этого отвлекают от Бриллианта — а именно, GCC.

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

Ядро (Linux the Kernel) вообще-то независимо от компиляторов и прочего (особенно всяких библиотек C).

Неправда. ГЦЦхмов там достаточно. Еще в начале 2000х Линус благословил сказав «компилятор- это инструмент»

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

может быть оно там какой-нибудь raid инициализировало?

Фиг его знает, не стал вникать в суть происходящего на видео, так как скорость инета не позволяет смотреть видео в нормальном качестве.

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

Я очень не люблю clang и llvm. Во-первых, потому что не GPL.

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

Вы правы - фанатики столмана нормальными инженерами быть не могут :) У них все по религии :) Столман не благословил - значит это от дьявола и должно быть уничтожено.

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

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

К разговору о ядре это не относится - там с алгоритмами всё в порядке.

да, верно. алгоритм 12309 идеален и никто ничего менять не собирается.

Ну да и это не в ядре - при каждом очень минорном обновлении фиксится по 50-150 багов.. местами и в алгортмах тоже :)

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

Инжинер

Видимо Вы не инжинер

Судя по написанию слова «инжинер» дважды(!) в одном предложении вы тоже не инженер.

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

Столман не благословил - значит это от дьявола и должно быть уничтожено.

К счастью, многие это переростают. Юношеский максимализм, вроде как, не порок даже.

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

При желании и возможности это лечится. Даем задачу. Расчитываем время по более фичастому инструменту. Выходные и ночевки за свой счет :)

yurkis
()
Ответ на: Инжинер от anonymous

Судя по написанию слова «инжинер» дважды(!) в одном предложении вы тоже не инженер.

А давайте возражать по существу.

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

Эх.. сколько нормальных ребят пришлось увольнять за такие вот приколы

И кто тебе поверит, балабол, что ты, студентота, кого-то увольнял? Мечтать не вредно, а сеть - она всё стерпит. Пиши «есчо», автор.

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

А давайте возражать по существу

Так это и было по существу. Ни один инжЕнер не может написать это слово дважды с ошибкой в одном предложении.

Более того, руководители таких рангов, которым позволено кому-то давать «задачки» и кого-то увольнять тут редкость, они не зарегистрированы и в спорах не участвуют.

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

Так это и было по существу. Ни один инжЕнер не может написать это слово дважды с ошибкой в одном предложении.

Ну как бы у всех бывают описки (да, и дважды в одном предложении тоже), особенно если прямо перед этим написать 5 раз: 1 Task N - 3 engineers.... 2 Task M - 5 engineers.... Возвращаясь к нашим баранам: Исходя из того что Вы обратили внимание только на правописание с моей мыслью Вы вобщем согласны? (ну кроме слова инжЕнер)

Более того, руководители таких рангов, которым позволено кому-то давать «задачки» и кого-то увольнять тут редкость, они не зарегистрированы и в спорах не участвуют.

Это просто тайная ложа руководителей команд/проектов. Их никто не видел. Они не регистрируются. Они не пишут. Они за нами просто наблюдают... Кстате, можно ли предположить что Вы тоже не из их числа т.к. снизошли до спора?

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

Как ни странно, clang в моей убунте скомпилировался без проблем, а компиляция gcc падает где-то в начале (в убунте, в Opensuse). Поэтому называть бриллиантом GCC слишком смело. Не GPL-вские альтернативы гыцаце нужны. GPL не святыня, чтобы на нее молиться.

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

компиляция gcc падает где-то в начале (в убунте, в Opensuse)

Сообщение об ошибке бутстрапа в студию.

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

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

Novell-ch ★★★★★
()
Ответ на: комментарий от quiet_readonly

Правильно будет make -j9 если у тебя восьмиядерный процессор.

Hackeridze
()
Ответ на: комментарий от Novell-ch

А нахрен они старье конпилят и хвастают? Когда нынешние версии собираться будут — тогда пусть праздник и устраивают.

Hackeridze
()

Хорошо. Сабж хорош. Легко расширяем. У него большое будущее. А конкуренция между двуся основными открытыми компиляторами подстегнёт развитие обоих.

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

Зюзя так долго стартует?

Черт побери, вы серьезно думаете что 19 секунд это нормально? Или вы все slim-trolls, а я так и не въехал? Сговор?

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

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

Novell-ch ★★★★★
()
Ответ на: комментарий от lucentcode

Люди, которые могли писать код gcc, ВНЕЗАПНО могут ливануть на шланг и писать его! Потеря же! А мне нужен D в gcc и ждать я долго не могу!

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

Почему бы FSF не использовать LLVM для построения будущих версий своего компилятора? GCC поддерживает куда больше платформ чем LLVM. Но LLVM имеет более либеральную лиценизию. И на его основе, добавив кодогенераторы под нужные платфрмы и развив GCC использующий вместо бэк-энда LLVM можно добиться более лёгкого развития GCC. Ну, и интероперабельности с Clang. И со всеми будущими открытыми компиляторами, какие только будут возникать. И проблема исчезнет сразу с перебеганием разработчиков на сабж.

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

Мериться, у кого ядро быстрее грузится... Поттеринг вами был бы доволен.

dmfd
()
Ответ на: комментарий от cvs-255

Никакой компилятор не сделает пузырьковую сортировку быстрой

4.2 :)

За пруфлинком гуглите «Superlinear speedup by program distillation/transformation» и ищите работы Нила Джонса и Джеффа Гамильтона.

buddhist ★★★★★
()

GNUКапец не за горами.

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

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

А вы, видимо, не ученый :)

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

GPL можно использовать для GCC. А кодогенератор и прочие низкоуровневые части могут отлично и под BSD-like лицензией жить.

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

Эксперимент

2 yurkis

Спорим, ты будешь мониторить эту ветку, чтобы последнее слово осталось за тобой? Доказательство этого: ты обязательно напишешь свой бессодержательный ответ, не приносящий тебе ничего, кроме траты времени. Выводы сделай сам, если сможешь.

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

GPL можно использовать для GCC. А кодогенератор и прочие низкоуровневые части могут отлично и под BSD-like лицензией жить.

GCC под GPLv3 ;)

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

Но её лицензия очень похожа на нормальную BSD. Которая совместима с GPL v3, разве нет?

lucentcode ★★★★★
()
Ответ на: комментарий от alex-w

В чём разница? Только в патентах? Так разработчики LLVM клянутся что не используют запатентованные технологии. Поэтому код LLVM полностью совместим с GPL. Да и для компилятора и базовых библиотек строгое лицензионное «лево» - не самый оптимальный выбор.

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