The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

OpenMandriva переходит на Clang и новый инсталлятор

10.02.2015 19:52

Разработчики дистрибутива OpenMandriva объявили о переходе по умолчанию на компилятор Clang, который будет использоваться вместо GCC для сборки пакетов в следующем выпуске дистрибутива (OpenMandriva Lx 3). В настоящее время clang позволяет успешно собрать около 90% пакетов из репозитория main. Из достоинств перехода на Clang отмечается ускорение процесса компиляции, сокращение потребления памяти, доступность расширенных средств диагностики ошибок, более качественная генерация и оптимизация объектного кода.

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

  1. Главная ссылка к новости (https://blog.openmandriva.org/...)
  2. OpenNews: Представлен Calamares 1.0, независимый от дистрибутивов фреймворк для построения инсталляторов
  3. OpenNews: Вышел дистрибутив OpenMandriva Lx 2014.0
  4. OpenNews: Выпуск дистрибутива OpenMandriva Lx 2014.1
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41650-calamares
Ключевые слова: calamares, mandriva
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Саул (?), 19:56, 10/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Закон не запрещает.
     
     
  • 2.12, Аноним (-), 21:02, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Закон не запрещает, но никаких преимуществ пользователям все это не дает. А вот недостатки будут - 10% пакетов в трэш, неспособность использовать OpenMP, который уже джва года обещают, ну и так далее.

    Так что как у юзеров этой мандалы упадет производительность в каком-нибудь imagemagic раза в 4 - известно кому надо за это сказать спасибо.

     
     
  • 3.25, Анонимур (?), 01:15, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Зачем OpenMP, когда есть няшный GDC?
     
  • 3.33, __yurkis__ (?), 09:47, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Из минусов:

    OpenMP (есть далеко не везде), чуть меньше производительность (на самомо деле в целом не сильно меньше)

    Из плюсов:

    Меньше нагрузка на сборочную инфраструктуру (бістрее компилирует), гораздо лучше средства диагностики.

    Из обьективного:

    Шланг достаточно активно догоняет GCC в скорости получаемого кода. Приблизительный паритет (пусть с минимальным перевесом GCC можно ждать в обозрииомом будущем).

     
     
  • 4.47, Xaionaro (ok), 19:07, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из искреннего интереса спрашиваю:

    > (на самомо деле в целом не сильно меньше)
    > Шланг достаточно активно догоняет GCC в скорости получаемого кода.

    А можно ссылочку? Например тут всё как-то не так [1]

    [1] http://www.phoronix.com/scan.php?page=article&item=gcc49_compiler_llvm35&num=

    И про это тоже ссылку, пожалуйста:

    > гораздо лучше средства диагностики.

     
     
  • 5.57, Клыкастый (ok), 08:35, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > [1] http://www.phoronix.com/scan.php?page=article&item=gcc49_com...

    CLang: 2,3,4,5
    GCC: 6,8,9,11
    паритет в 12,7,10

    Тест #1 хуже без OpenMP. Что тут "не так"? По-моему именно то, что тебе и сказали.

     
     
  • 6.58, Xaionaro (ok), 09:23, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> [1] http://www.phoronix.com/scan.php?page=article&item=gcc49_com...
    > CLang: 2,3,4,5
    > GCC: 6,8,9,11
    > паритет в 12,7,10
    > Тест #1 хуже без OpenMP. Что тут "не так"? По-моему именно то,
    > что тебе и сказали.

    Ну, например, рассмотрим вот это:

    >> (на самомо деле в целом не сильно меньше)

    Все тесты на производительность приложений из статьи (без исключений):

    - [ 1] Производительность GraphicsMagick: clang в 2 раза медленнее.
    - [ 2] Производительность Himeno Poisson Pressure Solver: gcc на 6.5% медленнее.
    - [ 6] Производительность C-Ray: clang в 1.5 раза медленнее.
    - [ 7] Производительность ebizzy: одинаковая.
    - [ 8] Производительность FLAC audio encoding: clang на 14% медленнее.
    - [ 9] Производительность With MP3 encoding via LAME: сlang на 24% медленнее.
    - [10] Производительность ffmpeg: одинаковая, ибо упичкан ассемблерным кодом (и поэтому не столь сильно зависит от особенностей компилятора).
    - [11] Hierarchical Integration test: clang в 1.5 раза медленнее.
    - [12] Производительность Apache web-server: одинаковая

    Это вовсе не «не сильно меньше».

    > CLang: 2,3,4,5

    В тесте №2 выигрыш крайне мал в сравнении с проигрышами в других тестах (см. выше). А тесты №3, №4 и №5 были не на производительность скомпилированной программы, а на скорость компиляции.

    То есть я бы скорее написал:

    GCC:   1,6,8,9,11
    CLang: 2(?)
    Draw:  2(?),7,10(?),12

     
  • 3.60, kevin (??), 23:03, 13/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    а разве в кланг ещё не впилили опенмп? я чёт на полгода из темы выпал вроде там уже всё почти готово было..
     

  • 1.5, Константавр (ok), 20:39, 10/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    >более качественная генерация и оптимизация объектного кода.

    А где цыфарки посмотреть? А то я в сказки не верю.

     
     
  • 2.7, Аноним (-), 20:54, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    в поисковике: "Clang 3.4 Performance Very Strong Against GCC 4.9"

    Только на поверку она не стронг местами.

     
     
  • 3.9, Аноним (-), 20:55, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > в поисковике: "Clang 3.4 Performance Very Strong Against GCC 4.9"
    > Только на поверку она не стронг местами.

    Лучшие традиции желтой прессы, да.

     
     
  • 4.11, Аноним (-), 21:00, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Лучшие традиции желтой прессы, да.

    Не знаю о чём вы, но в этих ваших интернетах более менее только он делает тесты.

     
     
  • 5.14, Аноним (-), 21:04, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Не знаю о чём вы, но в этих ваших интернетах более менее
    > только он делает тесты.

    Не знаю какие там тесты шланг делает более-менее но во всех программах использующих OpenMP он продувает GCC по числу ядер проца. А просто потому что шланг не умеет OpenMP.

     
     
  • 6.15, Аноним (-), 21:12, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что, собственно говоря, он и подтвердил в тесте сравнивая GCC 4.8 и  Clang 3.3
     
     
  • 7.23, Аноним (-), 23:25, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  Clang 3.3

    Это же подтвердилось в 3.4 и 3.5. Там уже джва года завтраками кормят про OpenMP. Но воз и ныне там.

     
  • 6.20, iZEN (ok), 23:04, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Не знаю о чём вы, но в этих ваших интернетах более менее
    >> только он делает тесты.
    > Не знаю какие там тесты шланг делает более-менее но во всех программах
    > использующих OpenMP

    Так назовите эти программы. Может их с гулькин нос наберётся и не интересны они большинству.

    > он продувает GCC по числу ядер проца. А просто потому что шланг не умеет OpenMP.

    Откуда вы это берёте?

    ///---http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html
    Clang 3.5 now has parsing and semantic-analysis support for all OpenMP 3.1 pragmas (except atomics and ordered). LLVM’s OpenMP runtime library, originally developed by Intel, has been modified to work on ARM, PowerPC, as well as X86. Code generation support is minimal at this point and will continue to be developed for 3.6, along with the rest of OpenMP 3.1. Support for OpenMP 4.0 features, such as SIMD and target accelerator directives, is also in progress. Contributors to this work include AMD, Argonne National Lab., IBM, Intel, Texas Instruments, University of Houston and many others.
    ---///

     
     
  • 7.22, Аноним (-), 23:23, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Так назовите эти программы. Может их с гулькин нос наберётся и не
    > интересны они большинству.

    Ну вон imagemagic, например. Во всех бенчах рвет шланга в хламину. И да, знаешь, втыкать на 8-ядернике в почти 8 раз дольше на процессинг картинки - совсем не здорово, имхо.

    Потреб-дям он конечно не интересен, им вообще интересно киношку смотреть да птичек метать, попутно запостив каой-нибудь крап в фэйсбук. Так что им вообще планшетика с андроидом - выше крыши.

    > Откуда вы это берёте?

    Да вон на форониксе бенчи например

    > Instruments, University of Houston and many others.

    Маркетинговый булшит это круто. А теперь айда сделать gcc в бенчмарках. Хренли мне толку с университета Хьюстона если это нечто сдриснет gcc в несклько раз на обработке картинки?

     
     
  • 8.42, iZEN (ok), 14:20, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нет такого приложения Есть ImageMagick Из этого я делаю вывод, что ты сам не и... большой текст свёрнут, показать
     
     
  • 9.44, iZEN (ok), 16:19, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    При активированной опции OPENMP в зависимостях оказывается GCC 4 8 4 порт lan... текст свёрнут, показать
     
  • 8.56, Аноним (-), 03:06, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там где обработка картинок ImageMagick-ом будет существенно нагружть проц ну нап... текст свёрнут, показать
     
  • 3.13, Аноним (-), 21:03, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Только на поверку она не стронг местами.

    А если программа использует OpenMP - то совсем-совсем-не-стронг.

     
     
  • 4.30, Аноним (-), 09:35, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да он и без OpenMP нифига не стронг.
     
  • 2.8, Аноним (-), 20:54, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > А где цыфарки посмотреть? А то я в сказки не верю.

    Какие циферки? Сказано же - _качественная_.

     

  • 1.6, Аноним (-), 20:43, 10/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Был же новость об этом? Полгода или год назад.
     
     
  • 2.10, Аноним (-), 20:57, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь не было. https://www.linux.org.ru/news/linux-general/11016773
     

  • 1.16, Анономс (?), 21:31, 10/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > ускорение процесса компиляции

    На что на что, а на это юзерам бинарного дистра пох. А вот то, что некоторые прогарммы теперь станут медленней работать нет.

     
     
  • 2.19, res2500 (ok), 22:29, 10/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а на это юзерам бинарного дистра пох.

    нет, это OpenMandriva пох на юзеров

     

  • 1.17, Crazy Alex (ok), 22:28, 10/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Из "преимуществ" понятно только ускорение компиляции. Остальное - либо чушь (вроде более качественного кода) либо (диагностика) касается разработчиков, а не маинтайнеров. Чай, не дебиан, чтобы вагон своих патчей накладывать.
     
     
  • 2.26, tensor (?), 05:01, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > чушь (вроде более качественного кода)

    Оптимальный код можно написать только мозгами на ассемблере, компилятор лишь стремится к этому через набор правил трансляции. Ничто не мешает усовершенствовать компилятор, избавившись, например, от поддержки "бородатых" архитектур. Вполне возможно, что Крэнг заменит gcc для "попсовых" x86, x64 или arm64; а gcc останется как "комбайн" для кросс-компиляции на кофемолки.

     
     
  • 3.27, Филипп Филиппович (ok), 06:14, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вы будете смеяться, но уже очень мало кто пишет на ассемблере код, который быстрее выдаваемого кодогенераторами современных компиляторов. Это раньше было просто, а сейчас человеку трудно учесть ту массу факторов, которую компилятор учитывает постоянно, процессоры стали очень уж сложно устроены.

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

     
     
  • 4.28, Аноним (-), 08:48, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Кодогенераты нам подарены инопланетянами? Или все-таки написаны людьми, к-е смогли угнаться за кодогенераторами и написать кодогенераторы?
     
     
  • 5.32, Аноним (-), 09:43, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Есть разница между описанием правил и постоянном следовании им. Так вот, разработчики компиляторов описали правила генерации кода (наряду с массой алгоритмов высокоуровневой оптимизации, о которых большинство даже не слышало).
     
  • 5.38, Филипп Филиппович (ok), 11:25, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Шахматные программы тоже создаются людьми, как и компьютеры. Но лучшие шахматные программы, запущенные на современных компьютерах, давно сильнее людей, даже чемпионов.

    А ещё подъёмные краны, созданные людьми, поднимают вес куда больший, чем человек. :)

     
  • 4.34, Алексей Морозов (ok), 09:51, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, лично у меня перестало хватать мозгов на качественную оптимизацию ещё где-то начиная с Пентиума, может, с MMX. Но, в принципе, я знаком с острозаточенными людьми, которые и в 2010-ом уделывали компиляторы в разы, правда, не на generic x86 & Co, а на гораздо более специфичных архитектурах.
     
     
  • 5.36, BSA (?), 10:54, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это в первую очередь из-за того, что компиляторы под "непопсовые" архитектуры мало кто сильно оптимизирует.
     
  • 5.39, Филипп Филиппович (ok), 11:36, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > правда, не на generic x86 & Co, а на гораздо более
    > специфичных архитектурах.

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

    Увы (или к счастью, скорее даже к счастью), чем дальше, тем будет тяжелее. Эра, когда люди писали на ассемблере, уходит. В 99% случаев ассемблер теперь нужен программисту только при отладке. Во всяком случае, на x86 и подобных.


     
     
  • 6.53, Аноним (-), 00:48, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В 99% случаев ассемблер теперь нужен программисту только при отладке.

    А из-за того что по-настоящему хорошо ассемблер уже мало кто знает, этот 1% случаев приносит мне 99% денег.

     
     
  • 7.54, Филипп Филиппович (ok), 01:34, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Что ж, быть экзотическим специалистом неплохо. До тех пор, пока эта экзотика востребована. Думаю, в редких случаях ещё будет довольно долго, так что от души желаю хорошего куска хлеба с маслом. :) Я сам до сих пор неравнодушен к ассемблерам, хотя очень давно не пишу на них: первая любовь не забывается. :)
     
  • 4.49, Ноно (?), 20:51, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То-то я смотрю, что в колибриОС программы запускаются раньше, чем я кнопку мыши отпускаю :)
    Почему  с каждой новой версией компиляторов на выходе программы становятся все тяжелее и тяжелее, ведь кодогенераторы лучше людей, пишущих на ассемблере?:)
     
     
  • 5.52, Аноним (-), 00:46, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это никак не относится к кодогенерации. В KolibriOS можно писать на си, и программы точно так же будут быстро запускаться.
     
  • 5.55, Led (ok), 01:57, 12/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То-то я смотрю, что в колибриОС программы запускаются

    Все три?

     

  • 1.24, Аноним (-), 23:34, 10/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00457.html
     
     
  • 2.31, Andrey Mitrofanov (?), 09:42, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >/emacs-devel/2015-02/msg00457.html

    we r the esr^Wllvm^Wapple surrender all yor shields

     

  • 1.29, Аноним (-), 09:33, 11/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > более качественная генерация и оптимизация объектного кода.

    ORLY?

     
     
  • 2.35, Andrey Mitrofanov (?), 09:56, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> более качественная генерация и оптимизация объектного кода.
    > ORLY?

    Сектанты же. А RMS просто спросил[I]!1![/I]

    ""[...]the LLVM people are fanatical, absolutely fanatical, about refactoring and keeping their architecture clean. The whole thing is kept extremely modular, very easily modified, very well documented. LLVM *is* clean. It is, in fact, architecturally beautiful. I wish it wasn't written in C++, and[...] -- https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00589.html

     
     
  • 3.37, Аноним (-), 11:21, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    забавно наблюдать как Штольману объясняют, что писать lldb гораздо проще чем GDB, потому что у LLVM модульная архитектура :)
     
     
  • 4.40, Аноним (-), 13:08, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    а толку метать бисер? это тело знает только что он бог и gcc единственный компилятор. Если бы у него хватило понимания - то давно сделал бы export AST для сторонних приложений.
     
     
  • 5.41, Andrey Mitrofanov (?), 13:39, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а толку метать бисер? это тело знает только что он бог и
    > gcc единственный компилятор. Если бы у него хватило понимания - то

    Если бы понимания хватило у тебя, у "нас" _давно были бы egcs II и XEmacs II.

     
     
  • 6.48, Аноним (-), 20:33, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> а толку метать бисер? это тело знает только что он бог и
    >> gcc единственный компилятор. Если бы у него хватило понимания - то
    > Если бы понимания хватило у тебя, у "нас" _давно были бы egcs
    > II и XEmacs II.

    А лично ты что нам подарил, прости?

     
     
  • 7.51, Andrey Mitrofanov (?), 21:50, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>> это тело знает
    >>>Если бы у него хватило понимания - то
    >> Если бы понимания хватило у тебя, у "нас"
    > А лично ты что нам подарил, прости?

    Взгляд в зеркало на собственное хамство, конечно. Пользуйтесь!

     

  • 1.43, Аноним (-), 14:21, 11/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ренегаты! :)
     
  • 1.45, manster (ok), 17:21, 11/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ядро тоже можно clang-ом?
     
     
  • 2.50, Эргил (?), 21:15, 11/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    http://llvm.linuxfoundation.org/index.php/Main_Page

    Но у меня месяца три назад не вышло, хотел ради интереса попробовать собрать, не собралось.

     

  • 1.59, Аноним (-), 13:42, 12/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не нужно собирают не нужным.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру