LINUX.ORG.RU

LLVM 2.7

 , , , , ,


0

0

Low-Level Virtual Machine - инфраструктура компиляторов для различных языков программирования, кодогенераторов байт-кода и двоичного исполняемого кода для различных платформ.

  • Clang
    • Умеет собирать сам себя
    • Улучшена поддержка Objective-C ABI
    • Поддержка ARM для Linux и Darwin ABI
    • Множество улучшений в анализаторе кода
  • DragonEgg - плагин для gcc, заменяющий встроенные в gcc оптимизаторы и кодогенераторы аналогами от LLVM. Поддерживает C, C++, Fortran, Ada и слегка Obj-C.
  • llvm-gcc работает с gcc-4.5 и поддерживает ARM v7 NEON
  • Новый логотип
  • Ассемблер и дисассемблер машкода
  • И множество других улучшений в кодогенераторах, оптимизаторах, интерпретаторах и JIT, кодоанализаторах и поддержке ARM...

LLVM развивается силами корпорации Apple и сообщества. Исходники доступны под лицензией BSD.

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

★★★★★

Проверено: annoynimous ()
Последнее исправление: shahid (всего исправлений: 3)

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

>>> Умеет собирать сам себя

Мне страшно, скайнет уже близок?

Пока он не научится собирать себя и разбирать других бояться нечего.


Ассемблер и дисассемблер же!

Stinky
()

mplayer с dragonegg не собирается
p7zip не собирается
mesa с llvm 2.7 не собирается

хоть что-нибудь вообще им собирается ? )

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

mplayer с dragonegg не собирается p7zip не собирается mesa с llvm 2.7 не собирается хоть что-нибудь вообще им собирается ? )

Себя же умеет собирать. Бздуны говорят, что этого достаточно, чтобы избавиться от GCC.

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

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

Лучше с Plan9.

tensai_cirno ★★★★★
()

Когда ж плюсы вместе со всеми говноподелками сдохнут-то ?

anonymous
()

Уже версия 2.7. А все еще не понятно на сколько перспективно его использовать на линукс дестопе (и будет ли выигрыш относительно gcc).

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

можешь на меня нажаловаться в специальном разделе.

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

Да, практически все, кто пишет для iPhone/iPod/iPad... :-D

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

xz-utils:

GCC 4.5:
Piped 95.36 MB in 00h02m29.43s: 653.51 kB/second


GCC 4.5+dragonegg (llvm):
Piped 95.36 MB in 00h02m52.95s: 564.62 kB/second
заметно так медленнее вышло

GCC 4.4.3:
Piped 95.36 MB in 00h02m31.89s: 642.90 kB/second

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

GCCшные + свои

mplayer собрать оно не смогло из за того что не смогло включить инлайны для математики
/usr/include/bits/mathinline.h

Sylvia ★★★★★
()
Ответ на: А что с GCC 4.6? от iZEN

там нечего пока тестировать,
там пока просто -b убрали , ничего нового не добавлено в trunk по сравнению с branches/gcc-4_5-branch

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

spudec.c: In function 'sws_spu_image':
spudec.c:784:2: warning: passing argument 2 of 'sws_scale' from incompatible pointer type
libswscale/swscale.h:195:5: note: expected 'const uint8_t * const*' but argument is of type 'unsigned char **'
spudec.c:786:2: warning: passing argument 2 of 'sws_scale' from incompatible pointer type
libswscale/swscale.h:195:5: note: expected 'const uint8_t * const*' but argument is of type 'unsigned char **'
spudec.c: In function 'spudec_draw_scaled':
/usr/include/bits/mathinline.h:534:1: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type!



вот так на mplayer сыпет к примеру

Sylvia ★★★★★
()

Что вы всё мелочитесь со сборками. Забрасывать надо гнилые x86 и AMD64 платформы и создавать собственные отечественные процессоры RISC-архитектуры. Вообще проприетарщина уловила перспективы RISC - не зря производительные игровые консоли используют MIPS,POWER.

anonymous
()

Плохой, негодный логотип. Слишком агрессивный и отталкивающий.
В Линуксах на лого обычно всякие добродушные антилопы,
дебиловатые пингвины, рыбки, мышки, а тут глиста с крыльями такая.

Sphinx ★★☆☆
()

Логотип:

Usage Rights. This dragon image is owned by Apple Inc. and is available for your download and use royalty-free. By downloading this image, Apple grants you, and you accept, a non-exclusive license to use this image. All right, title and interest in the image, including the copyright therein, is retained by Apple.

Нафиг, нафиг...

northerner ★★★
()

Сабж закопать вместе с эппл.

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

если соберу еще раз , то проверю, отпишусь, вообще не хочется, т.к. есть dragonegg )

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

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

Итить. И правда... Смесь бульдога с носорогом. Зря они это. Objective C симпатичный язык. А тут к ниму плюсовую инфернальность прививают...

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

сравнительный тест производительности кода

вот, сделала с утра с gzip оценочный тест

платформа : x86 (ia-32)

код: gzip , asm отключен, почему gzip? маленький код с отсутствием asm (отключаем, хотя там есть 1-2 вставки), мало математики, в целом мне кажется неплох для моделирования производительности программ на Си

данные - 286 Mb ELF, и текста (инсталляция /usr/local/llvm )
флаги: GCC ставится в заведомо невыгодные условия тем, что используются те флаги, которые обычно используют майнтейнеры дистрибутивов, т.е. я поставила просто -O2 -march=pentium4 (-march - для определенности, в случае GCC 2.95 пришлось использовать -mpentium)

результат (сразу обсчитаный в %% производительности от GCC 4.4.3, он не только оказался генератором самого медленного кода, но и в настоящее время является основной «рабочей лошадью» для компиляции)

GCC 2.95:    103.8%
(-mpentium)

GCC 3.4.6:      113,5%

GCC 4.1.2:      103,1%

GCC 4.2.4:      103,6%

GCC 4.3.4:      103,2%

GCC 4.4.3 ==    100% ( 55.486 s)

GCC 4.5.0:      112%

Clang LLVM:   107,5%

llvm-gcc:      107,5%

dragonegg:   106,4%

intel c/c++ 11.1: 120,2%

pcc: fail @ syntax parse.

выводы - GCC 4.4.3 - тормоз, но в GCC 4.5.0 над оптимизацией поработали гораздо лучше, llvm показали практически одинаковый результат как в llvm-gcc так и clang, как и должно быть ) код dragonegg оказался чуть-чуть медленнее, былая надежда BSDшников pcc не осилил командную строку c параметрами и выбыл из гонки, в самом выгодном положении оказался Intel C/C++ 11.1 - он использовал векторизацию, которая не была разрешена для остальных.
Еще раз обращу внимание что используются только флаги -O2 -march=pentium4 , у гентушников как обычно есть больше свободы с помощью флагов изменять производительность в ту или иную сторону )

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

Пацаны, вы лучше за стабильность и тесты производительности напишите, чем в плюсах и объектах друг друга обмакивать :)

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

можно же самим сделать ) собрать что-нибудь и сравнить,
с++ можно сравнить, вопрос только что брать, а то получится как на форониксе, сравниваем asm вставку, с ней же, получаем 1-2% разницы за счет того что не asm )

-flto я пока не использую, с 4.5.0 не все пакеты собираются

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

в том-то и дело что не совсем ясно что конкретно пытать...
да 4.5.0 только начал собираться...

megabaks ★★★★
()

Не, это таки не корректно и как-то сильно по гентушному.)
Следовало бы еще сравнивать размер и быстродействие получаемого кода.
А быстродействие самого инструмента тут еще совсем не показатель.
Имхо, вполне может может быть, что только одного прогона gzip тут недостаточно будет.

elipse ★★★
()

попробовал погонять gzip

megabaks@localhost ~ $ wgetpaste testgccgzip
Your paste can be seen here: http://paste.pocoo.org/show/206974/
у меня получилось что с 4.5 быстрее чем с 4.4.3, но поскромнее ~107%
а вот с графитом на 4.5 быстрее чем без
первые 3 циферки 4.4.3 с графитом
вторые 3 - 4.5.0 с графитом
третьи 3 - 4.5.0 без графита
всё это дело в tmpfs (swap чистый)

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

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

сравнительный тест производительности кода

это и был тест полученного кода...

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

> это и был тест полученного кода...

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

2. косвенно еще сравниваются дефолтные плюшки проверки компиляторов разных версий (ну сравнение примитивного gcc 2.95 и gcc 4.4 - как земля и небо)

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

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

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

namezys ★★★★
()

Почитал про обсуждение obj-c и obj-c++

вы хоть понимаете, что obj-c по идее надстройка над языком. причем к С или С++ не привязанная?

Зачем нужен Obj-С++? Так некоторый ООП статический код на С++ оптимизируется и пишеться куда проще, чем на С - в результате быстрее и качественнее (особенно если без указателей все делать), да без вирт. функций

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

На работе этим заниматься не буду. А дома у меня только mac os

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

> А все еще не понятно на сколько перспективно его использовать на линукс дестопе (и будет ли выигрыш относительно gcc).

Выигрыш давно уже есть - более внятные сообщения об ошибках и static code analysis. Так что как минимум для разработки им пользоваться уже сейчас обязательно и необходимо. А собирать потом можно и gcc, и чем угодно еще.

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

это быстродействие gzip , те результирующего кода, а не скорости сборки,
gzip конечно не совсем идеал для сравнения, но с ним делать тесты просто, просто собрать с разными опциями, просто померить быстродействие.
вот например попадания в кеш процессора с --param l1-cache-size --param l2-cache-size я даже и не знаю на чем потестировать, нужен какой-нибудь c++ с stl желательно и возможностью замера производительности собранного,кроме firefox @ peacekeeper test что-то ничего не приходит другого, но ФФ сложно собирать чем-то отличным от GCC

Sylvia ★★★★★
()

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

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