URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 86346
[ Назад ]

Исходное сообщение
"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено opennews , 06-Сен-12 11:10

Дмитрий Андрич (Dimitry Andric) провёл (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/05...) тестирование производительности компиляторов Clang 3.1 и Clang 3.2 в сравнении с GCC 4.2.1 и GCC 4.7.1 при сборке C и С++ проектов во FreeBSD 10.0-CURRENT. Тесты сосредоточены исключительно на оценке времени компиляции, измерение производительности выполнения итоговых исполняемых файлов планируется провести в будущем. При сборке использовались (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/05...) предлагаемые по умолчанию опции оптимизации ("-O2 -pipe -fno-strict-aliasing" для Clang, "-O2 -pipe" для GCC).

В большинстве ситуаций Clang оказался быстрее GCC, при этом потребляя значительно меньше памяти. В некоторых тестах разрыв был значителен, например, при сборке большого C++ проекта gcc 4.2.1 выполнил сборку на 86% медленнее Clang 3.1 и потребовал на 217% больше памяти. GCC 4.7.1 сократил разрыв до 68% и потребовал на 220% больше памяти, чем Clang 3.1. Clang 3.2 оказался в среднем на 3% медленнее Clang 3.1, потребление памяти сохранилось на одном уровне.
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/05...
Новость: http://www.opennet.me/opennews/art.shtml?num=34762

Содержание

Оценка производительности Clang/LLVM и GCC при сборке во Fre...,dq0s4y71, 11:10 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Денис, 11:28 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,BratSinot, 11:58 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:34 , 07-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 12:31 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Пыщ я Бетмен, 12:45 , 06-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 13:02 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Алексей, 13:18 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 13:57 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 14:17 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Ytch, 22:03 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 22:13 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,Антон, 03:30 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,iZEN, 07:05 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 14:09 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 11:44 , 07-Сен-12
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 14:20 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 15:14 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 16:57 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 13:59 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 15:18 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 16:50 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 20:22 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 22:29 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 22:54 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 23:58 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 14:06 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 16:14 , 06-Сен-12
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Aesthetus Animus, 16:27 , 06-Сен-12
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Ytch, 22:05 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 16:30 , 06-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 17:03 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ваноним, 17:09 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 17:29 , 06-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 17:36 , 06-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Карбофос, 22:24 , 06-Сен-12
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:36 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Карбофос, 09:52 , 07-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Карбофос, 22:21 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Vkni, 13:01 , 07-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 13:35 , 07-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во...,AlexAT, 15:00 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 15:27 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,AlexAT, 23:46 , 08-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 06:44 , 09-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во...,Vkni, 17:10 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 20:26 , 07-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Zenitur, 15:38 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:36 , 07-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Кевин, 20:27 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Aceler, 20:35 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:36 , 07-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:38 , 07-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 00:53 , 07-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во...,Аноним, 05:39 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 11:46 , 07-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 00:49 , 07-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во...,Клыкастый2, 09:39 , 07-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 12:02 , 07-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во...,Vkni, 13:04 , 07-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ком.пилятор, 09:05 , 07-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Andrey Mitrofanov, 10:25 , 08-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,fidaj, 11:12 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:39 , 07-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 00:51 , 07-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Анонимоус2, 11:16 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,an., 15:51 , 06-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,x0r, 11:30 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,BratSinot, 11:57 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 16:12 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,BratSinot, 17:07 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:40 , 07-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Pickle, 12:22 , 06-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 12:37 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Михрютка, 14:29 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 15:08 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,sanDro, 15:00 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:42 , 07-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 12:52 , 06-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 13:21 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Алексей, 16:06 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:43 , 07-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 00:57 , 07-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во...,Аноним, 05:34 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 12:05 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 13:39 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 15:21 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 17:06 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 20:24 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 22:31 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 22:54 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,ананим, 00:01 , 08-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во...,Vkni, 13:13 , 07-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,iZEN, 01:29 , 07-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 05:35 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,iZEN, 07:08 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ананим, 13:56 , 07-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,ВовкаОсиист, 13:22 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,arsenicum, 13:30 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 16:11 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,an., 16:16 , 06-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 00:44 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,iZEN, 01:31 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Led, 03:49 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 05:47 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 05:22 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,iZEN, 07:09 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,AlexAT, 09:12 , 07-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,4ertus2, 02:06 , 07-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во...,arisu, 12:08 , 07-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,qux, 20:07 , 11-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,анон, 14:10 , 06-Сен-12
Оценка производительности Clang/LLVM и GCC при сборке во Fre...,Аноним, 14:35 , 06-Сен-12
- Оценка производительности Clang/LLVM и GCC при сборке во Fre...,pavlinux, 15:01 , 06-Сен-12
  - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,AlexAT, 21:38 , 06-Сен-12
    - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,pavlinux, 00:53 , 07-Сен-12
      - Оценка производительности Clang/LLVM и GCC при сборке во Fre...,YetAnotherOnanym, 20:13 , 07-Сен-12
        
        Оценка производительности Clang/LLVM и GCC при сборке во Fre...,pavlinux, 00:27 , 08-Сен-12

Сообщения в этом обсуждении

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено dq0s4y71 , 06-Сен-12 11:10

Не понимаю смысла подобных тестов. Время компиляции - ничтожная часть всего времени, затраченного на разработку проекта. А уж пользователям вообще пофигу, сколько времени вы его там компилировали, им важно чтобы программа быстро выполнялась (т.е. качество кода).

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Денис , 06-Сен-12 11:28

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

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено BratSinot , 06-Сен-12 11:58

Вот только GCC может так долго и толство компилировать из-за оптимизации.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:34

> Вот только GCC может так долго и толство компилировать из-за оптимизации.
Да, при LTO и глобальной оптимизации память он жрет прилично. Но зато выдает на гора более шустрый и компактный код. Учтя что компиляция редко, а работа кода зачастую постоянно - странно экономить на фазе компиляции чтобы постоянно профукивать все полимеры на фазе выполнения.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 12:31

>В процессе разработки как раз скорость компиляции важна
нафиг не важна.
ну не поверю я, что вы все исходники сразу правите, что требует перекомпиляции всех obj-файлов.
зыж
ну или у вас всё в одном, громадном файле.
ну или постоянно делаете make clean. или make mrproper.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Пыщ я Бетмен , 06-Сен-12 12:45

О, как часто тычешься после одной кривой компиляции в ошибки сборки "уже исправленного" проекта, хотя "вроде всё что исправлено должно быть перекомпилировано", что частенько make clean рулит.
Но это ж надо иногда что-то писать и реально собирать самому, чтобы знать про эти грабли

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 13:02

>О, как часто тычешься после одной кривой компиляции в ошибки сборки "уже исправленного" проекта, хотя "вроде всё что исправлено должно быть перекомпилировано", что частенько make clean рулит.
LOL
это функциональность make поддерживает даже БЕЗ написания правил.
ман суффиксные правила (suffixes)
и суффиксы по умолчанию
$ make -p|grep -i suffix
SUFFIXES := .out .a .ln .o .c .cc .C .cpp .p .f .F .m .r .y .l .ym .yl .s .S .mod .sym .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch .web .sh .elc .el
.SUFFIXES: .out .a .ln .o .c .cc .C .cpp .p .f .F .m .r .y .l .ym .yl .s .S .mod .sym .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch .web .sh .elc .el

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Алексей , 06-Сен-12 13:18

И конечно же при изменении .h файла make сможет корректно найти все места, где этот .h используется и их перекомпилировать.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 13:57

ну! не всё коту масленица! :D
тут придётся поработать. опять же http://en.wikipedia.org/wiki/Precompiled_header
ну если кому проще сделать make clean, чем добавить пару строчек в мэйкфайл, то при чём тут компилятор.
зыж
ну и мир не закончился на make/autotools.
есть ещё scons, qmake наконец.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 14:17

А! ещё кое-что по теме пспомнил (может кому будет интересно)
>$ man gccmakedep
>gccmakedep - create dependencies in makefiles using 'gcc -M'
>By default, gccmakedep places its output in the file named makefile if it exists, otherwise Makefile.
с примером использования в мэйкфале
>EXAMPLE
>   Normally, gccmakedep will be used in a makefile target so that typing 'make depend' will bring the dependencies up to date for the makefile.  For example,
>           SRCS = file1.c file2.c ...
>           CFLAGS = -O -DHACK -I../foobar -xyz
>           depend:
>                   gccmakedep -- $(CFLAGS) -- $(SRCS)
так что всё решаемо

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Ytch , 06-Сен-12 22:03

Ну, как бы, у gcc есть целая группа ключей (-M -MM -MD ...) связанная с построением файлов зависимостей, которые, в свою очередь, могут создаваться прямо при основной компиляции (без отдельного вызова компилятора/утилит) и includ'иться прямо в тот же Makefile (сразу всей кучей). В общем, имхо, проблема перекомпиляции только нужного при изменении какого-то header'a давно решена.
Если по каким-то причинам не подходит стандартный формат вывода зависимостей, то решается ключиком -M с последующим перенаправлением вывода на вход самописной/стандартной утилитки для преобразования/фильтрации.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 06-Сен-12 22:13

а ещё можно, например, выкинуть make. я вот несколько лет назад выкинул — и как хорошо жить-то стало! как будто жмущие деревянные ботинки снял.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Антон , 07-Сен-12 03:30

А что взамен?

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено iZEN , 07-Сен-12 07:05

Maven

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 14:09

на жабе (и скорее всего только ДЛЯ жабы)???
на xml??? где без IDE точно с ума сойдёшь?
да даже вр.. бздишнегам не пожелаю! :D

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 11:44

> А что взамен?
один из форков jam, сильно переработаный под мою специфику.
p.s. точнее, под специфику наших сборок, не только под мою.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 14:20

CMake очень не плох http://ru.wikipedia.org/wiki/Cmake
особенно если нужно для мэйк/вс/хыкод генерить
и синтаксис простой
зыж
но опять же - это замена аutotools/.., а не make.
а вот scons заменяет и аutotools, и make.
но на питоне, включая сценарии сборки ... что на любителя. но если любитель - профессионал в питоне, то может быть отличным выбором! :D

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 15:14

при наличии pkg-config автокрап вообще не нужен (а кто в pc-файлы не делает — тот ССЗБ). при необходимости конфигур-скрипт делается руками в несколько строчек. заодно там же можно проверить версию POSIX и систему. ну, и особого смысла в проектах, где уже нужен автокрап, штатно поддерживать что-то кроме gcc и clang нет.
а если программа для сборки требует гвидобейсик… нененене, дэвидблэйн.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 16:57

а без уничижительных, мещанских названий никак?
зыж
>ну, и особого смысла в проектах, где уже нужен автокрап, штатно поддерживать что-то кроме gcc и clang нет.
есть другое мнение - кроме поддержки gcc (ну, возможно(!!!), и то для бздишного менталитета, теперь и шланга) ничего и не нужно.
по крайней мере в POSIX'системах.
к тому же, нет ничего сложного и для icc (или любого другого) настроить. например http://stackoverflow.com/questions/1280418/how-do-i-get-auto...
AC_PROG_CC([gcc icc])
$ ./confgure CC=icc
усё.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 13:59

>а ещё можно, например, выкинуть make.
можно.
а можно и не выкидывать, а просто разобраться в нескольких деталях и эффективно использовать.
отличная, расширяемая система.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 15:18

> а можно и не выкидывать, а просто разобраться в нескольких деталях и
> эффективно использовать.
а можно — выкинуть. что, у make, например, уже появилась вменяемая обработка подкаталогов? нененене, рекурсивные вызовы make не предлагать.
впрочем, любители make потому и не любители раскидывать части проекта по подкаталогам — потому что PITA.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 16:50

> нененене, рекурсивные вызовы make не предлагать.
это ещё почему?
хотя и без них можно - отличный механизм по принципу всё своё ношу с собой - в любой проект вместе с мэйкфайлом вставить можно весь каталог не напрягаясь вообще.
> впрочем, любители make потому и не любители раскидывать части проекта по подкаталогам — потому что PITA
да что там сложного то?
all:
    cd ./subdir1; make all
    cd ./subdir2; make all
    ......................
    cd ./subdirN; make all

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 20:22

забавно то, что мэйкофилы даже не понимают.
хинт: дерево зависимостей.
суперхинт: общее.
суперсуперхинт: где?

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 22:29

гиперхинт: а зачем нужно общее дерево зависимостей?

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 22:54

> гиперхинт: а зачем нужно общее дерево зависимостей?
затем, что в отдельных каталогах далеко не всегда живут библиотеки. впрочем, мэйкофилы скажут «это нинада!»

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 23:58

а им и НЕ НАДО там жить!!!
зыж
ты откуда свалился то? у меня даже к Лунатикам таких вопросов нет.
не, ну зашибись, будем сырцы с библиотеками мешать!

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 07-Сен-12 14:06

>Ну, как бы, у gcc есть целая группа ключей (-M -MM -MD ...)
именно поэтому я привел gccmakedep, а не makedepend.
см. пример - используются именно возможности gcc.
а сам gccmakedep всего-лишь:
$ file /usr/bin/gccmakedep
/usr/bin/gccmakedep: POSIX shell script, ASCII text executable
зыж
но траблы всё-равно бывают иногда.
иногда встречается при многоплатформенной разработке с кучей специфичных ifdef с include.
но и тут, если не быдлокодить, то всё обходится.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 16:14

> И конечно же при изменении .h файла make сможет корректно найти все
> места, где этот .h используется и их перекомпилировать.
Сможет, ибо у нормальных людей dependency tracking используется в процессе разработки. Ну и пересобирается только то что зависело от этого .h файла. Как-то так, да.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Aesthetus Animus , 06-Сен-12 16:27

makedepend

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Ytch , 06-Сен-12 22:05

> И конечно же при изменении .h файла make сможет корректно найти все
> места, где этот .h используется и их перекомпилировать.
Вы не поверите!
(секрет фокуса - см. ключи gcc -M -MM -MD -MMD и т. п.)

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 16:30

> всех obj-файлов.
спалился ))) У нас они имеют расширение ".o" )))

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 17:03

obj-файлы - это не файлы с расширением .obj, чудик! :D
(кстати, винда .obj определит так - http://ru.wikipedia.org/wiki/Obj OBJ — это формат файлов описания геометрии)
а вот определять принадлежность к типу файлов по расширению - ВОТ ЭТО ПАЛЕВО! :D
>$ man gcc
>...
>By default, the object file name for a source file is made by replacing the suffix .c, .i, .s, etc., with .o
.o - всего-лишь расширение по-умолчанию obj-файла.
зыж
и ещё почитай мануалы на утилиту file
ну и узнай что такое /usr/share/misc/magic.mgc

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ваноним , 06-Сен-12 17:09

ccache[+distcc] спасают в случаях чистых сборок

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 17:29

Причем местами очень нехило спасают

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 17:36

а местами очень не хило лажают.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Карбофос , 06-Сен-12 22:24

примеры - в студию! или это просто было написано, дабы что-то написать?
p.s. это такой уж проект, что его используют очень многие и, в первую очередь, его тестируют на регрессию

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:36

> а местами очень не хило лажают.
Это как?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Карбофос , 07-Сен-12 09:52

да он и сам даже не объяснит, как.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Карбофос , 06-Сен-12 22:21

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

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Vkni , 07-Сен-12 13:01

> В процессе разработки как раз скорость компиляции важна -- если время сборки
> незначительно, можно прогонять автотесты каждые полчаса, а то и чаще. Очень
> помогает от тупых ошибок.
Ставьте -O0, это ускорит компилятор в разы.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 13:35

> Ставьте -O0, это ускорит компилятор в разы.
а заодно усыпит некоторые варнинги и изменит поведение программы. happy debugging, bitches!

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено AlexAT , 07-Сен-12 15:00

>> Ставьте -O0, это ускорит компилятор в разы.
> а заодно усыпит некоторые варнинги и изменит поведение программы. happy debugging, bitches!
Только в случае, если код ногами писан.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 15:27

> Только в случае, если код ногами писан.
угу-угу. ты же, вроде, не «приветмирщик», а глупости городишь. ничего, что задействуются разные куски компилятора, например, в которых тоже могут быть ошибки? нет, ситуация не гипотетическая, а из большого проекта. где при -O0 считает нормально, а при -O2 — неверно, причём иногда и слабовоспроизводимо. из-за размеров проекта глазами по асму выяснить почти невозможно, по логам можно, но тоже удовольствие то ещё. зато рааааадости от того, что девелоперы показывают: «УМВР», а билды для тестеров — ёк. у меня таких примеров было достаточно, чтобы перейти на -O2 сразу, дабы разработчики видели то же самое, что и продакшн увидит. а тестеры не тестили две, по сути, разных версии программы, одна из которых не нужна вообще никому.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено AlexAT , 08-Сен-12 23:46

Про -O3 еще могу поверить. Про -O2 заливайте кому-нибудь другому, либо ссыль на багрепорт.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 09-Сен-12 06:44

ну, не верь, чо. какая жалость: мне AlexAT не поверил! рыдаю весь просто.
мне похрен, веришь или нет — я на это в проектах наступал. но ты, конечно, не верь: таки у тебя вышло убедить меня, что ты «приветмирщик». жаль. минус один адекват.
p.s. вот зачем выпендриваться было? спросил бы нормально — и код бы дал, и ссылку на тикет.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Vkni , 07-Сен-12 17:10

> а заодно усыпит некоторые варнинги
точно? какие именно?
> и изменит поведение программы.
это да, бывает.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 20:26

>> а заодно усыпит некоторые варнинги
> точно? какие именно?
которые появляются после агрессивной оптимизации. например «использовано до того, как инициализировано». или про алиасинг.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Zenitur , 06-Сен-12 15:38

Ну так надо же оправдать переход FreeBSD на Clang.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:36

> Ну так надо же оправдать переход FreeBSD на Clang.
Странно. Сегодня Зенитар - Кэп. При том вполне годный.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Кевин , 06-Сен-12 20:27

для бсд? нуну.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Aceler , 06-Сен-12 20:35

А если у тебя ферма для сборки?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:36

Один из показателей эффективности компилятора.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:38

> Один из показателей эффективности компилятора.
Вот только почему-то про другие показатели бсдшники предпочитают не вспоминать. Зато на их несчастье это регулярно вспоминает фороникс, влобешник сравнивая 2 компилера в одинаковой конфигурации, где задом особо не поюлишь. И когда код нагенеренный шлангом сливает раза в три по скорости тому что нагенерил GCC - вот это лихо, да :)

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 00:53

> И когда код нагенеренный шлангом сливает раза в три по скорости тому что нагенерил GCC
> - вот это лихо, да :)
займусь немного взаимоисключающими параграфами: а это тоже в большинстве случаев неважно. числодробилки пишет не так много народу, а в большой прикладухе время сборки может оказаться поважнее того, что выходной код немного медленней.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Аноним , 07-Сен-12 05:39

> займусь немного взаимоисключающими параграфами: а это тоже в большинстве случаев неважно.
Да как сказать, зависит от того что считать большинством. Как для начала это большинство оценивалось? По всей планете прошел и статистику собрал кто и что компилит? :)

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 11:46

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

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 00:49

> Один из показателей эффективности компилятора.
причём достаточно маловажный. любители постоянно пересобирать мир могут уже нааскать у родителей на машины помощнее. ну, или у спонсоров.
остальным же намного более важно, какой код компилятор даёт на выходе. если он делает это за, в общем-то, разумное время и с нормальным потреблением ресурсов (случаи супероптимизации всей программы рассматривать не будем: понятно, что теоретически такой оптимизатор обставит всех; а практически пока он соберёт свой приветмир, у детей уже бороды до пола поотрастают).
пока что в этом плане кланг ничем особо похвастаться не может, увы. быть «не хуже» — это не достижение, это минимально необходимое условие. хотя и непростое, да. и за то время, пока кланг догоняет, gcc тоже на месте не стоит. и даже любители бсд постепенно осознают, что бывают версии gcc новее, чем 4.2 (вот этому факту я больше всего удивился).

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Клыкастый2 , 07-Сен-12 09:39

> причём достаточно маловажный.
для оценки самого компилятора? да, не особо интересен. для оценки потенциала, архитектуры - вполне годный. тут надо посмотреть через годик-другой. если так всё и останется - значит толку особого не будет.
> и даже любители бсд постепенно осознают, что бывают версии gcc новее, чем 4.2
ну как бы это нормально. собственно вопрос, что вкорячено в make.conf. и тут варианты только приветствуются. пусть пилят шланг, пусть пилит свой компилер интел, амд - это только плюсы.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 12:02

ну дык я же не против, чтобы пилили. шланг — проект вполне достойный, и уже даже пригодный к использованию. пусть ещё расширения gcc научится понимать — и вообще хорошо будет.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Vkni , 07-Сен-12 13:04

> пока что в этом плане кланг ничем особо похвастаться не может, увы.
> быть «не хуже» — это не достижение, это минимально необходимое условие.
В общем, да. Но в нынешнее время ещё один компилятор совершенно не повредит.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ком.пилятор , 07-Сен-12 09:05

есть соурс-бейзед, есть разработчики дистров. Нельзя сказать что скорость сборки вообще никому не важна

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Andrey Mitrofanov , 08-Сен-12 10:25

> Не понимаю смысла подобных тестов. Время компиляции - ничтожная часть всего времени,
Вона яЗен там внизу биёт себя пяткой в груди, что _каждый_ раз при запуске по 10-30% проигрыша есть афигенный чендж на 68% выигрыша один раз при сборке. Это Нужно, это Прогрессивно! Мы все охотно верим, что он приникся и погрузился в мир Будущего - мир континууса интергрейтуса, собирай на каждый чих, не запускай ни разу.
Да, мы не понимаем, но надо же быть благодарными за возможность прикоснуться в Будущему?!</футур>
Тесты это хорошо!! Выкинут наконец из "базы" gcc (обещали же!?), нам таааак полегчает.
+++Ждём FreeBSD 10 без gcc в базе Team, member #000001.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено fidaj , 06-Сен-12 11:12

Ну вот зачем из письма, залетевшего в рассылку, делать новость на опеннете?
Давайте тогда уж по всем письмам в рассылке (и не только про хорошее) будем писать мегановости... - тем более, что по проблемам проекта есть куда более интересные письма.
Как будто бы в проекте уже вообще ничего не осталось делать - как только меряться скоростью сборки компиляторов...

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:39

> Ну вот зачем из письма, залетевшего в рассылку, делать новость на опеннете?
Иначе форумные тролли отощают с голодухи :)

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 00:51

> Ну вот зачем из письма, залетевшего в рассылку, делать новость на опеннете?
потому что давно не было срачей clang vs gcc.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Анонимоус2 , 06-Сен-12 11:16

Без размеров выходных файлов и их профилирования, эти тесты только для троллей.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено an. , 06-Сен-12 15:51

По моим измерениям, размер выполняемых файлов процентов на 10% больше у clang (3.1), чем у gcc (4.6.2). С точки зрения производительности, на разных выполняемых файлах (содержащих boost юнит-тесты для проекта) то один, то другой лидировали с отрывом ~15%, хотя чаще все же gcc. Естественно, я компилировал значительно меньше кода, чем во FreeBSD, поэтому их статистика была бы гораздо интереснее.
Таким образом, clang, как компилятор вполне подходит для постоянного девелопмента (т.к. действительно быстрее компилирует исходники и выдает более читабельные ошибки), хотя продакшн-релизы пока еще лучше собирать на gcc. Более того, gdb лучше работает с отладочной инфой от gcc, чем от clang, а для clang другого приличного отладчика (пока) нет (я в курсе про lldb - на текущий момент, он малопригоден для отладки под linux, по сравнению с gdb).

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено x0r , 06-Сен-12 11:30

а tcc вообще всех порвет по скорости компиляции...

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено BratSinot , 06-Сен-12 11:57

Прочитайте новость. Речь идет о C++, С'шные проекты может GCC оторваться.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 16:12

> а tcc вообще всех порвет по скорости компиляции...
...зато проиграет по оптимизации и количеству поддерживаемых архитектур :P

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено BratSinot , 06-Сен-12 17:07

А че по оптимизации? Он между прочим только инструкции процессора использует.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:40

> А че по оптимизации? Он между прочим только инструкции процессора использует.
Кирпичи то у всех одинаковые. Но у одних из них получаются дворцы, а у других - сараи.
Вывод: кроме кирпичей есть еще некоторая разница в том кто и как их разложит :)

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Pickle , 06-Сен-12 12:22

Оке. А теперь приведите сравнение быстродействия проектов собранных с Clang и GCC. При этом на 2-3 различных (полностью) конфигурация. ИМХО, разница будет в другую сторону.
Рабочие сборки вообще (для крупных проектов) запускают без оптимизации (если конечно не её тестируют). "Оптимизацию" кода тоже нет смысла проверять используя "оптимизацию при сборке", т.к. принято оперировать не секундами/минутами/часами, а кол-вом требующихся операций для выполнения той или иной части кода (при этом не стоит забывать и про "скорость" той или иной операции).

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 12:37

а вот это как в конце сообщения понимать?
>Conclusion:
>-----------
>Both gcc 4.2.1 and 4.7.1 are the fastest compilers for building this specific large C++ library, but both versions of clang are not far behind. Both versions of gcc use quite a bit more memory than either version of clang.
кто врёт-то?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Михрютка , 06-Сен-12 14:29

а это некоторые анонимы в целях экономии моска ничего, кроме двух строчек в конце не читают.
данный конкретный канклюжн относится к сборке boost.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 06-Сен-12 15:08

ага, а некоторые только первые 2-е строчки.
зыж
щечки, щечки подправь.
а то лопнут.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено sanDro , 06-Сен-12 15:00

>> кто врёт-то?
Кто кто? Автор новости. Точнее не врёт, а говорит полуправду, что считается хуже чем просто лгать. И что показывает его любовь к clang. Взял из трёх тестов результат одного, который его больше устроил, а остальные в новости вообще не упомянул.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:42

> остальные в новости вообще не упомянул.
Ну бсдшники же. Как обычно, свое - не пахнет.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 12:52

тут уже видимо важна не новость кому-то а итоговый холивар... нафиг мне Clang если в зависимостях gcc если я не разработчик...

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 13:21

1. Clang компилит быстрее GCC - факт.
2. GCC оптимизирует программу лучше и на выходе программа работает быстрее чем собранная Clang - факт.
Пользователям положить на 1, для них главное чтобы программа работала шустрее, и как следствие авторам програмы это тоже становится важнее.
Когда Clang дорастет до GCC по второму параметру и при этом сохранит первый(или хотя бы паритет), тогда ОК.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Алексей , 06-Сен-12 16:06

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

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:43

> Вы не поверите, но компилятор нужен программистам. И скорость компиляции и понятность
> диагностики ошибок является достаточно важным параметром.
...но не настолько чтобы простить в 3 раза более тормознутый код, который еще и более пухлый к тому же зачастую.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 00:57

> …но не настолько чтобы простить в 3 раза более тормознутый код, который
> еще и более пухлый к тому же зачастую.
вполне настолько. например, некий большой рогалик на c++ (нет, даже не спрашивай; писал это не я) у меня клангом почти в два раза быстрей собирается, нежели gcc. тут речь идёт о разнице в минутах. оно, вроде бы, и не так важно, но в силу специфики написания этого рогалика после изменений может пересобраться чуть ли не половина кода. и пара часов в день — тю-тю, если активно фичи допиливать. а вот разницы в скорости работы собраного кода на глаз не заметно.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Аноним , 07-Сен-12 05:34

> оно, вроде бы, и не так важно, но в силу специфики
> написания этого рогалика после изменений может пересобраться чуть ли не половина
> кода. и пара часов в день — тю-тю, если активно фичи
> допиливать.
Да, так и быть, шланг - хорошая штука для компиляции вот этого твоего конкретного рогалика на си++. Правда это интересует полтора землекопа на всю планету. Я в их число не попадаю :P.
> а вот разницы в скорости работы собраного кода на глаз не заметно.
Да уж, такое и на JS тормозить не будет, а время компиляции вообще станет нулевое. Если продолжить ту же логику чуть дальше.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 12:05

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

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 13:39

а нефиг было с таким умным видом вот тут make выкидывать :D
http://www.opennet.me/openforum/vsluhforumID3/86346.html#48
>а ещё можно, например, выкинуть make.
зыж
брехня это всё.
за 20-30 минут ВСЕ кеды и вмести с Qt компилятся. (как гентушник говорю)
даже при условии, что этот сферический "рогалик" размером с Qt (а я не верю в такие рогалики), даже если компиляция идёт на атомах (очень серьёзная контора видимо!), даже если команда не из тех кому думать, а только прыгать (любое изменение в исходниках приводит к перекомпиляции и пересборке!!! самое время кричать - выкинуть make! :D), даже если этот супер-дупер РОГАЛЪ собирается не частями, а целиком и несколько раз в день (архитект видимо тоже из тех кто прыгает), то и то такие трагические выводы НЕ ПОЛУЧАЮТСЯ.
и это если над проектом "прыгает" куча людей одновременно. :D

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 15:21

> а нефиг было с таким умным видом вот тут make выкидывать :D
а нефиг балаболить, если ни проекта, ни системы сборки не видел.
хотя что это я… у тебя же libastral, ты лучше меня всё знаешь. и как проект был сделан изначально, и как развивался, и почему он так собирается…
впрочем, радуйся, что не увидишь: сбрендил бы ещё больше, стал бы напрямую с космическим разумом беседовать.
p.s. откуда у тебя там взялись «конторы» и «архитекты» — я тем более не знаю. видимо, таки космический разум нашептал.

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 17:06

>> а нефиг было с таким умным видом вот тут make выкидывать :D
>а нефиг балаболить, если ни проекта, ни системы сборки не видел.
я и вижу, что ты либо нифига не видел, либо дальше быдлокодерства не ушёл.
>хотя что это я… у тебя же libastral, ты лучше меня всё знаешь
libastral? не, этот быдлокодерский термин не знаю.
а вот лучше тебя знаю? да, практически уже уверен в этом.
зыж
>p.s. откуда у тебя там взялись «конторы» и «архитекты» — я тем более не знаю. видимо, таки космический разум нашептал.
котора? это синоним фирмы, коллектива, комьюнити или любой другой формы коллективной разработки.
хотя одинокому быдлокодеру не понять.
архитект? это архитектор проекта. при этом все будут собирать и складывать своё в совместный проект только по его указанию "когда" и "как".
опять же, одинокому быдлокодеру не понять.
зато понятно какого уровня рогалики ты в одиночку пишешь? :D

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 20:24

ясно. дегенерация прогрессирует, но Мнение Имеешь. ну, имей дальше, я в этом больше участия не принимаю. abtreten!

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 07-Сен-12 22:31

я и не удивлён :D

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 22:54

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

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено ананим , 08-Сен-12 00:01

ну тебе вообще верить нельзя! :D
обещал свалить и вот он, опять! :D
зыж
пишу вообще только по одной причине - поржать! :D

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено Vkni , 07-Сен-12 13:13

> Да уж, такое и на JS тормозить не будет, а время компиляции
> вообще станет нулевое. Если продолжить ту же логику чуть дальше.
Компиляция - это не только перевод на ассемблер, но и статическая проверка кода. Как там у JS с этим?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено iZEN , 07-Сен-12 01:29

> ...но не настолько чтобы простить в 3 раза более тормознутый код, который еще и более пухлый к тому же зачастую.
Бред.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 05:35

> Бред.
Форониксу с их бенчами расскажи. Почему-то код сгенеренный шлангом проигрывает в вообще всех тестах кроме 1-2 по жизни. В некоторых местах - очень люто, в несколько раз.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено iZEN , 07-Сен-12 07:08

>> Бред.
> Форониксу с их бенчами расскажи. Почему-то код сгенеренный шлангом проигрывает в вообще
> всех тестах кроме 1-2 по жизни. В некоторых местах - очень
> люто, в несколько раз.
Всего-то на 10-30%. Это не "несколько раз".

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ананим , 07-Сен-12 13:56

30% - это выкинуть больше чем одно ядро из моего 4-х-ядерника.
думаю хоть с памятью там не такие же проблемы?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено ВовкаОсиист , 06-Сен-12 13:22

Помоему у gcc на данный момент лучьше поддержка С++ чем у шланга, или нет? Как у шланга с С++11?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено arsenicum , 06-Сен-12 13:30

http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/projects/cxx0x.html
Судя по таблицам у Clang дела чуть лучше.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 16:11

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

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено an. , 06-Сен-12 16:16

Попробуйте последний стабильный релиз (3.1) - там они значительно улучшили дело, даже по сравнению с 3.0

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 00:44

> Попробуйте последний стабильный релиз
Не вижу смысла. Reason: clang не поддерживает половину архитектур с которыми я работаю на регулярной основе.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено iZEN , 07-Сен-12 01:31

>> Попробуйте последний стабильный релиз
> Не вижу смысла. Reason: clang не поддерживает половину архитектур с которыми я
> работаю на регулярной основе.
Да ладно! User294, не ври.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Led , 07-Сен-12 03:49

Clang уже умеет что-то кроме x86 и кое-как (т.е. условно) ARM?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 05:47

> Clang уже умеет что-то кроме x86 и кое-как (т.е. условно) ARM?
Ну LLVM теоретически умеет много чего... а практически чаще всего получается сферический конь в вакууме. Ну это как обычно у бсдшников.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 07-Сен-12 05:22

> Да ладно! User294, не ври.
Ну тогда скажи как мне шлангом бинарь для Atmel AVR получить? Да и для Cortex M3 там когда я смотрел - все было на удивление криво. То-есть, в теории его убедить можно. На практике - через ту еще ж. Не говоря о том что GCC оптимизит намного лучше.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено iZEN , 07-Сен-12 07:09

>> Да ладно! User294, не ври.
> Ну тогда скажи как мне шлангом бинарь для Atmel AVR получить?
Когда всякие там ПЛМ дорастут до уровня микропроцессора, тогда и спрашивай.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено AlexAT , 07-Сен-12 09:12

> Когда всякие там ПЛМ дорастут до уровня микропроцессора, тогда и спрашивай.
Незнание предмета детектед. ПЛМ (ПЛИС) - это всякие там альтерки и прочие. ARM - это RISC-микропроцессор.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено 4ertus2 , 07-Сен-12 02:06

Наткнулся недавно на несоответствие между clang и gcc.
Думал ошибка первого. Оказалось, наоборот: gcc не держит стандарт.
A a(B(c));
в коде должно разрешаться как объявление функции, принимающий параметр B, а не как (как могло бы показаться и проглатывает gcc) создание переменной a с приведением переменной c к типу B (п. 8.2 драфта).

"Оценка производительности Clang/LLVM и GCC при сборке во..."
Отправлено arisu , 07-Сен-12 12:08

напиши репорт, ребята из gcc такие фишки вполне чинят.
но c++ всё-таки атомная хрень.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено qux , 11-Сен-12 20:07

> A a(B(c));
> в коде должно разрешаться как объявление функции, принимающий параметр B, а не
> как (как могло бы показаться и проглатывает gcc) создание переменной a
> с приведением переменной c к типу B (п. 8.2 драфта).
Вы про такое, где если добавить "typedef int B;", то скомпилируется только с предупреждением?
$ echo '
a(B(c));int main () { return 0; }
' | gcc -x c -
<stdin>:2:3: error: unknown type name ‘B’
По (единственной) ошибке clang сложно понять, считает ли он B(c) объявлением функции:
$ echo '
a(B(c));int main () { return 0; }
' | clang -x c -
<stdin>:2:3: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
a(B(c));
  ^
<stdin>:2:5: error: a parameter list without types is only allowed in a function definition
a(B(c));
    ^
<stdin>:2:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
a(B(c));
^
2 warnings and 1 error generated.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено анон , 06-Сен-12 14:10

Когда не могут меряться производительностью кода, начинают выкатывать вот такие вот "результаты". И типа они на коне, хоть в чём-то.

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено Аноним , 06-Сен-12 14:35

На 86% медленнее это на 14% быстрее с другого конца?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено pavlinux , 06-Сен-12 15:01

Тебя надо в ЦентрИзбирКом :)
С другого конца будет 714%

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено AlexAT , 06-Сен-12 21:38

146% же

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено pavlinux , 07-Сен-12 00:53

> 146% же
100% = 100
100 - 86% = 14
С другой стороны:

14 = 100%
100 = ?

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено YetAnotherOnanym , 07-Сен-12 20:13

42

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."
Отправлено pavlinux , 08-Сен-12 00:27

> 42
100 - это 42% от 14 ??? :)