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

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

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

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

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

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

Оно уже более быстрый год генерирует, чем gcc?

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

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

Говорят, что немного быстрее: http://laurovenancio.wordpress.com/2007/08/07/llvm-perf-tests/

у меня mesa, правда с 2.8svn собирается.

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

Лучше с Plan9.

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

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

>в модераторы каких-то лохов и хамов набирают уже

+много.

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

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

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

А связка GCC + dragonegg пишет обычные gcc'шные предупреждения? Или как clang?

А что с GCC 4.6?

Делала тесты?

GCCшные + свои

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

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

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 сыпет к примеру

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

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

Логотип:

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.

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

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

>xz-utils:
а clang'ом?

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

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

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

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

вот, сделала с утра с 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 , у гентушников как обычно есть больше свободы с помощью флагов изменять производительность в ту или иную сторону )

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

спасибо, очень доходчиво)

спасибо :)
есть ли где тесты по скорости и занимаемой памяти с lto и без?

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

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

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

кстати как там гляделка *sse* mmx* 3dnow* ? :)
64 уже умеет?

нет пока времени на это

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

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

megabaks@localhost ~ $ wgetpaste testgccgzip
Your paste can be seen here: http://paste.pocoo.org/show/206974/

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

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

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

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

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

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

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

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

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

дык мы ждём :)
айда?

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

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

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

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

>> Apple рулит.

давно ?

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

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

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

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

а веселее всех разрабам компилятора - и чтоб быстро работал и чтоб код быстрый генерил - сказка ^_^

Да. Именно такая задача обычно и ставится.

могу потестировать и скорость сборки ) с этим вообще все проще гораздо

Да, будьте любезны