LLVM 2.7

сборка GMP v5 с --enable-cxx -O2 -g (как и используется разработчиками для сборки пакетов, можно конечно -O0 -g, но с -O2 случай более общий)

clang++ тест провалил, поэтому буду использовать llvm-g++ в качестве C++ теста вместе с Clang

user время компиляции (в %% не стала считать):

Clang (+ llvm-c++ ): 1m14.815s
llvm-gcc:            1m5.399s
dragonegg:           1m22.991s
GCC 4.5.0:           1m13.813s
GCC 4.4.3:           1m7.937s
GCC 4.3.4:           1m1.264s
GCC 4.2.4:           1m5.990s
GCC 4.1.2:           1m3.583s
GCC 3.4.6:           1m3.457s
Intel C/C++ 11.1:    1m15.785s

насчет clang++ , исправила несколько ошибок с тем чтобы он находил все что ему нужно для c++, поэтому ретест:

Clang/Clang++: 1m16.034s

Значит gcc 4.3.4 по скорости оказался быстрее даже своего брата версии 3.4.6. Ну что ж, спасибо. Я удивлен, но не удовлетворен.

%% к скорости по сравнению с GCC 4.4.3 (100%)

llvm-gcc:  103.9 %
clang:     89.3%
dragonegg: 81.8%
GCC 4.5.0: 92.0%

GCC 4.3.4: 110.8%
GCC 4.2.4: 102.9%
GCC 4.1.2: 106.8%
GCC 3.4.6: 107.0%
Intel: 89.6%

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

4.1 - 4.4 собраны с Profile Guided, следовательно работают быстрее тех, которые собраны без

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

llvm компиляторы собраны без профилирования, по ICC у меня нет информации, он бинарный.

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

кстати, Сильви, вопрос глупый, но... ты llvm+clang в релиз собирала или в дебаг?

если на С, то рекомендую гимп)

release

ядро пробовала собирать с 4.5?
а то вот сижу и думаю - раньше последняя цыфра перед OpenRC была 1.1ххх
сейчас же - 0.68ххх
конфиг/ядро аналогичные - в последнем случае добавился только ramzswap, но он сам по себе не работает, да и своп пустой
выходит таки гцц постарался?

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

пост от 7 августа 2007 года, сравнивался gcc 4.1.2 и llvm-gcc на базе gcc 4.2 и llvm 2.6 или даже 2.5.
Интересно сравнить более свежие версии, например, gcc 4.5 и dragonEgg, gcc 4.5 и llvm-gcc для 4.5. Хотя, если сравнение показывает тенденцию в целом, gcc стал медленее, а llvm — быстрее, общее направление обнадёживает.

Хаскелю тоже подфартило, LLVM бекенд по сравнению с GHC:
http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-...

> выводы - GCC 4.4.3 - тормоз, но в GCC 4.5.0 над оптимизацией поработали гораздо лучше,

но так и не догнали gcc 3.4.6, и если смотреть на абс. значения, gcc 4.1..4.4 — примерно на уровне gcc 2.95. Это просто на gzip так повезло или в среднем по больнице ситуация похожая?

былая надежда BSDшников pcc не осилил командную строку c параметрами и выбыл из гонки,

ну да, другую запускалку нужно, которая была бы совместима по ключикам командной строки. Вроде llvm-gcc и gcc. Можно попробовать взять ncc, у него вроде к gcc-змам ближе.

Для комплекта ещё можно взять какой-нибудь TenDRA и tcc, но 1)не факт, что соберётся из-за разных ключиков и gcc-змов 2) оптимизатор у этих компиляторов почти наверняка хуже 3) скорость компиляции должна быть повыше, но это ни о чём не говорит.

Респект за тесты.

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

к Си — привязанная. Во-первых, также, как для плюсов Cfront был компилятором плюсов в Си, для объектного Си был кросскомпилятор POM, тоже в Си. Во-вторых, production компиляторов objc было несколько, stepstone, gcc, apple, но apple — это вариант gcc со своими расширениями, форк. Нормальным, «нативным» можно считать только stepstone, gcc требует своего рантайма для objc (-lobjc). Это аналог CRT для objc. Он занимается тем, что реализует message-passing ООП посылкой сообщений, как в смоллтоке: есть селекторы сообщения, есть self объекта, есть тип id = *(void*). Макрами в си достаём self, селектор, выполняем вызов сообщения. Этот рантайм, реализация смоллтоковой объектной модели не сильно отличается по сути от реализации объектной модели GObject в glib/GTK, к примеру. Вся разница, что GObject реализован на макросах Си, а -lobjc — в компиляторе objc. Но это не принципиально: например, в Vala тот же код реализации объектной модели вполне может быть в «рантайме» компилятора Vala (не важно, кросскомпилируется язык Vala через Си или реализован как «нативный» компилятор).

Зачем нужен Obj-С++?

чтобы решить вопросы с компиляторозависимым C++ ABI, очевидно же. Кросскомпиляцией в Си или родным компилятором+ рантаймом — не важно.

Так некоторый ООП статический код на С++ оптимизируется и пишеться куда проще, чем на С

код с шаблонами? и без ООП? возможно. На си есть реализации любой объектной модели, не только objc/vtable/gobject.

На тему оптимизации Obj-C++ : ну, вот в смоллтоке есть PIC-кеш оптимизация вызовов методов. Есть мнение, что кросскомпиляцией objc в с, просто в рантайме её сложнее реализовать, чем в компиляторе. То есть, «отдельный компилятор для языка» + рантайм позволяет делать более глубокие оптимизации, чем кросскомпиляцией в Си. К примеру, тот же смоллток-компилятор в составе Etoile.

Я вообще не про это писал. Я имел в виду, что если написать ООП код на С++, которые достаточно хорошо оптимизируется (хотя бы из того, что компилятор знает, какие методы вызываются, а не посылается сообщение) - то можно получить хороший прирост производительности.

Когда я говорил, что obj-c не сильно связан с С или С++, я имел в виду, что это все можно было бы реализовать предпроцессором (как раньше было), но это не эффективно - поэтому и поддержка есть в компиляторе

>пост от 7 августа 2007 года, сравнивался gcc 4.1.2 и llvm-gcc на базе gcc 4.2 и llvm 2.6 или даже 2.5.

Судя по номеру ревизии SVN - это LLVM 2.1 из SVN (т.е. не релиз). И llvm-gcc в то время был gcc 4.0.1-based.

>ядро пробовала собирать с 4.5?

ядро с 4.5 должно собираться и нормально работать,
выйдет следующее - соберу на десктоп,
ноутбук у меня по какой-то странности не переваривает ядра собранные не gcc-4.3 oops'ит и паникует.

хотя с gcc-4.5 есть такой момент что, при конфигурировании можно указать -mfpmath= , у меня он сразу выставлен на SSE, что возможно и повлияло на тест в сторону увеличения производительности его кода, ядро же в загрузочных участках кода SSE очень не любит и указывает GCC -mno-sse для своей сборки, вот как оно уживется с встроенным значением -mfpmath я пока не знаю

Логотип неважный. На обложке DragonBook'а лучше нарисован.

А проект интересный. Посмотрим, во что он вырастет через пару годиков.