forum.opennet.ru - "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." (118)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
Сообщение от opennews (??) on 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... Новость: https://www.opennet.ru/opennews/art.shtml?num=34762
Ответить \| Правка \| Cообщить модератору

Оглавление

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во..., iZEN, 07:05 , 07-Сен-12, (78)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 14:09 , 07-Сен-12, (98)
Оценка производительности Clang/LLVM и GCC при сборке во..., arisu, 11:44 , 07-Сен-12, (85)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 14:20 , 07-Сен-12, (99)
Оценка производительности Clang/LLVM и GCC при сборке во..., arisu, 15:14 , 07-Сен-12, (101)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 16:57 , 07-Сен-12, (106)

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

Оценка производительности Clang/LLVM и GCC при сборке во..., arisu, 15:18 , 07-Сен-12, (102)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 16:50 , 07-Сен-12, (105)
Оценка производительности Clang/LLVM и GCC при сборке во..., arisu, 20:22 , 07-Сен-12, (111)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 22:29 , 07-Сен-12, (114)
Оценка производительности Clang/LLVM и GCC при сборке во..., arisu, 22:54 , 07-Сен-12, (118)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 23:58 , 07-Сен-12, (120)

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Аноним, 16:14 , 06-Сен-12, (32)
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Aesthetus Animus, 16:27 , 06-Сен-12, (34)
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Ytch, 22:05 , 06-Сен-12, (47)

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Карбофос, 22:24 , 06-Сен-12, (50) –1
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Аноним, 00:36 , 07-Сен-12, (53)

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Карбофос, 22:21 , 06-Сен-12, (49) –1
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Vkni, 13:01 , 07-Сен-12, (90)

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

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

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

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

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Кевин, 20:27 , 06-Сен-12, (42)
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Aceler, 20:35 , 06-Сен-12, (44)
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Аноним, 00:36 , 07-Сен-12, (54)

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

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

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

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., ком.пилятор, 09:05 , 07-Сен-12, (81)
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Andrey Mitrofanov, 10:25 , 08-Сен-12, (126)

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

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

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

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Pickle, 12:22 , 06-Сен-12, (8) +1
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., ананим, 12:37 , 06-Сен-12, (10)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во..., arisu, 22:54 , 07-Сен-12, (119)
Оценка производительности Clang/LLVM и GCC при сборке во..., ананим, 00:01 , 08-Сен-12, (121)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка производительности Clang/LLVM и GCC при сборке во Fre..., анон, 14:10 , 06-Сен-12, (19) +2
Оценка производительности Clang/LLVM и GCC при сборке во Fre..., Аноним, 14:35 , 06-Сен-12, (22) –1

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

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

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

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

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

Сообщения по теме [Сортировка по времени | RSS]

1. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +15 +/–

Сообщение от dq0s4y71 (??) on 06-Сен-12, 11:10

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +4 +/–

Сообщение от Денис (??) on 06-Сен-12, 11:28

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от BratSinot on 06-Сен-12, 11:58

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

52. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:34

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

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –1 +/–

Сообщение от ананим on 06-Сен-12, 12:31

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +3 +/–

Сообщение от Пыщ я Бетмен on 06-Сен-12, 12:45

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –2 +/–

Сообщение от ананим on 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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –1 +/–

Сообщение от Алексей (??) on 06-Сен-12, 13:18

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от ананим on 06-Сен-12, 13:57

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

20. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от ананим on 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)
так что всё решаемо

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

46. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Ytch on 06-Сен-12, 22:03

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

48. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 06-Сен-12, 22:13

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

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

70. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Антон (??) on 07-Сен-12, 03:30

А что взамен?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

78. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от iZEN (ok) on 07-Сен-12, 07:05

Maven

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

98. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 14:09

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

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

85. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 11:44

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

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

99. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 14:20

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

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

101. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 15:14

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

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

106. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 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
усё.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

96. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 13:59

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

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

102. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 15:18

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

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

105. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 16:50

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

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

111. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 20:22

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

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

114. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 22:29

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

Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

118. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 22:54

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

Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

120. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 23:58

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

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

97. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от ананим on 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.
но и тут, если не быдлокодить, то всё обходится.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

32. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 06-Сен-12, 16:14

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

34. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Aesthetus Animus (ok) on 06-Сен-12, 16:27

makedepend

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

47. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Ytch on 06-Сен-12, 22:05

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

35. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от Аноним (??) on 06-Сен-12, 16:30

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

36. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +3 +/–

Сообщение от ананим on 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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

38. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от ваноним on 06-Сен-12, 17:09

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

39. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 06-Сен-12, 17:29

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

40. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –2 +/–

Сообщение от Аноним (??) on 06-Сен-12, 17:36

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

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

50. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –1 +/–

Сообщение от Карбофос (ok) on 06-Сен-12, 22:24

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

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

53. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:36

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

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

84. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Карбофос (ok) on 07-Сен-12, 09:52

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

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

49. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –1 +/–

Сообщение от Карбофос (ok) on 06-Сен-12, 22:21

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

90. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Vkni (ok) on 07-Сен-12, 13:01

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

93. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 13:35

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

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

100. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от AlexAT (ok) on 07-Сен-12, 15:00

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

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

104. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 15:27

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

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

127. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от AlexAT (ok) on 08-Сен-12, 23:46

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

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

128. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 09-Сен-12, 06:44

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

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

108. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Vkni (ok) on 07-Сен-12, 17:10

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

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

113. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 20:26

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

Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

26. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от Zenitur (ok) on 06-Сен-12, 15:38

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

55. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +1 +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:36

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

42. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Кевин on 06-Сен-12, 20:27

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

44. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Aceler (ok) on 06-Сен-12, 20:35

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

54. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:36

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

56. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:38

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

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

65. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 00:53

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

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

76. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 05:39

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

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

86. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 11:46

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

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

62. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 00:49

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

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

83. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Клыкастый2 on 07-Сен-12, 09:39

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

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

87. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 12:02

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

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

91. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Vkni (ok) on 07-Сен-12, 13:04

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

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

81. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от ком.пилятор on 07-Сен-12, 09:05

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

126. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Andrey Mitrofanov on 08-Сен-12, 10:25

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +3 +/–

Сообщение от fidaj (ok) on 06-Сен-12, 11:12

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:39

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

63. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 00:51

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от Анонимоус2 on 06-Сен-12, 11:16

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +1 +/–

Сообщение от an. on 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).

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от x0r (??) on 06-Сен-12, 11:30

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от BratSinot on 06-Сен-12, 11:57

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

31. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 06-Сен-12, 16:12

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

37. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от BratSinot on 06-Сен-12, 17:07

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

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

58. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:40

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

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

8. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +1 +/–

Сообщение от Pickle on 06-Сен-12, 12:22

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от ананим on 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.
кто врёт-то?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –2 +/–

Сообщение от Михрютка (ok) on 06-Сен-12, 14:29

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

25. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +1 +/–

Сообщение от ананим on 06-Сен-12, 15:08

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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от sanDro (ok) on 06-Сен-12, 15:00

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

59. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:42

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

12. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 06-Сен-12, 12:52

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +5 +/–

Сообщение от Аноним (??) on 06-Сен-12, 13:21

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –1 +/–

Сообщение от Алексей (??) on 06-Сен-12, 16:06

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

60. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:43

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

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

66. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 00:57

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

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

74. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 05:34

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

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

88. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 12:05

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

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

94. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 13:39

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

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

103. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 15:21

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

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

107. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 17:06

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

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

112. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 20:24

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

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

116. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 07-Сен-12, 22:31

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

Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

119. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 22:54

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

Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

121. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от ананим on 08-Сен-12, 00:01

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

Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

92. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от Vkni (ok) on 07-Сен-12, 13:13

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

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

67. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –3 +/–

Сообщение от iZEN (ok) on 07-Сен-12, 01:29

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

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

75. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 05:35

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

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

79. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –2 +/–

Сообщение от iZEN (ok) on 07-Сен-12, 07:08

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

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

95. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от ананим on 07-Сен-12, 13:56

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

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

16. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –3 +/–

Сообщение от ВовкаОсиист (ok) on 06-Сен-12, 13:22

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от arsenicum (??) on 06-Сен-12, 13:30

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

30. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 06-Сен-12, 16:11

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

33. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от an. on 06-Сен-12, 16:16

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

61. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 00:44

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

68. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –3 +/–

Сообщение от iZEN (ok) on 07-Сен-12, 01:31

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

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

71. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Led (ok) on 07-Сен-12, 03:49

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

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

77. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 05:47

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

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

73. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от Аноним (??) on 07-Сен-12, 05:22

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

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

80. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –2 +/–

Сообщение от iZEN (ok) on 07-Сен-12, 07:09

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

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

82. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от AlexAT (ok) on 07-Сен-12, 09:12

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

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

69. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от 4ertus2 on 07-Сен-12, 02:06

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

89. "Оценка производительности Clang/LLVM и GCC при сборке во..." +/–

Сообщение от arisu (ok) on 07-Сен-12, 12:08

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

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

129. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от qux (ok) on 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.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

19. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +2 +/–

Сообщение от анон on 06-Сен-12, 14:10

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." –1 +/–

Сообщение от Аноним (??) on 06-Сен-12, 14:35

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от pavlinux (ok) on 06-Сен-12, 15:01

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

45. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от AlexAT (ok) on 06-Сен-12, 21:38

146% же

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

64. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от pavlinux (ok) on 07-Сен-12, 00:53

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

14 = 100%
100 = ?

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

109. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от YetAnotherOnanym on 07-Сен-12, 20:13

42

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

123. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..." +/–

Сообщение от pavlinux (ok) on 08-Сен-12, 00:27

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

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+15 +/–
Сообщение от dq0s4y71 (??) on 06-Сен-12, 11:10
Не понимаю смысла подобных тестов. Время компиляции - ничтожная часть всего времени, затраченного на разработку проекта. А уж пользователям вообще пофигу, сколько времени вы его там компилировали, им важно чтобы программа быстро выполнялась (т.е. качество кода).
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+4 +/–
	Сообщение от Денис (??) on 06-Сен-12, 11:28
	В процессе разработки как раз скорость компиляции важна -- если время сборки незначительно, можно прогонять автотесты каждые полчаса, а то и чаще. Очень помогает от тупых ошибок.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	7. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+2 +/–
	Сообщение от BratSinot on 06-Сен-12, 11:58
	Вот только GCC может так долго и толство компилировать из-за оптимизации.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	52. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+2 +/–
	Сообщение от Аноним (??) on 07-Сен-12, 00:34
	> Вот только GCC может так долго и толство компилировать из-за оптимизации. Да, при LTO и глобальной оптимизации память он жрет прилично. Но зато выдает на гора более шустрый и компактный код. Учтя что компиляция редко, а работа кода зачастую постоянно - странно экономить на фазе компиляции чтобы постоянно профукивать все полимеры на фазе выполнения.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	–1 +/–
	Сообщение от ананим on 06-Сен-12, 12:31
	>В процессе разработки как раз скорость компиляции важна нафиг не важна. ну не поверю я, что вы все исходники сразу правите, что требует перекомпиляции всех obj-файлов. зыж ну или у вас всё в одном, громадном файле. ну или постоянно делаете make clean. или make mrproper.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	11. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+3 +/–
	Сообщение от Пыщ я Бетмен on 06-Сен-12, 12:45
	О, как часто тычешься после одной кривой компиляции в ошибки сборки "уже исправленного" проекта, хотя "вроде всё что исправлено должно быть перекомпилировано", что частенько make clean рулит. Но это ж надо иногда что-то писать и реально собирать самому, чтобы знать про эти грабли
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	13. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	–2 +/–
	Сообщение от ананим on 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
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	14. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	–1 +/–
	Сообщение от Алексей (??) on 06-Сен-12, 13:18
	И конечно же при изменении .h файла make сможет корректно найти все места, где этот .h используется и их перекомпилировать.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	18. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от ананим on 06-Сен-12, 13:57
	ну! не всё коту масленица! :D тут придётся поработать. опять же http://en.wikipedia.org/wiki/Precompiled_header ну если кому проще сделать make clean, чем добавить пару строчек в мэйкфайл, то при чём тут компилятор. зыж ну и мир не закончился на make/autotools. есть ещё scons, qmake наконец.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	20. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от ананим on 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) так что всё решаемо
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	46. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от Ytch on 06-Сен-12, 22:03
	Ну, как бы, у gcc есть целая группа ключей (-M -MM -MD ...) связанная с построением файлов зависимостей, которые, в свою очередь, могут создаваться прямо при основной компиляции (без отдельного вызова компилятора/утилит) и includ'иться прямо в тот же Makefile (сразу всей кучей). В общем, имхо, проблема перекомпиляции только нужного при изменении какого-то header'a давно решена. Если по каким-то причинам не подходит стандартный формат вывода зависимостей, то решается ключиком -M с последующим перенаправлением вывода на вход самописной/стандартной утилитки для преобразования/фильтрации.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	48. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от arisu (ok) on 06-Сен-12, 22:13
	а ещё можно, например, выкинуть make. я вот несколько лет назад выкинул — и как хорошо жить-то стало! как будто жмущие деревянные ботинки снял.
	Ответить \| Правка \| ^ к родителю #46 \| Наверх \| Cообщить модератору


	70. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от Антон (??) on 07-Сен-12, 03:30
	А что взамен?
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору


	78. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от iZEN (ok) on 07-Сен-12, 07:05
	Maven
	Ответить \| Правка \| ^ к родителю #70 \| Наверх \| Cообщить модератору


	98. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 07-Сен-12, 14:09
	на жабе (и скорее всего только ДЛЯ жабы)??? на xml??? где без IDE точно с ума сойдёшь? да даже вр.. бздишнегам не пожелаю! :D
	Ответить \| Правка \| ^ к родителю #78 \| Наверх \| Cообщить модератору


	85. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от arisu (ok) on 07-Сен-12, 11:44
	> А что взамен? один из форков jam, сильно переработаный под мою специфику. p.s. точнее, под специфику наших сборок, не только под мою.
	Ответить \| Правка \| ^ к родителю #70 \| Наверх \| Cообщить модератору


	99. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 07-Сен-12, 14:20
	CMake очень не плох http://ru.wikipedia.org/wiki/Cmake особенно если нужно для мэйк/вс/хыкод генерить и синтаксис простой зыж но опять же - это замена аutotools/.., а не make. а вот scons заменяет и аutotools, и make. но на питоне, включая сценарии сборки ... что на любителя. но если любитель - профессионал в питоне, то может быть отличным выбором! :D
	Ответить \| Правка \| ^ к родителю #70 \| Наверх \| Cообщить модератору


	101. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от arisu (ok) on 07-Сен-12, 15:14
	при наличии pkg-config автокрап вообще не нужен (а кто в pc-файлы не делает — тот ССЗБ). при необходимости конфигур-скрипт делается руками в несколько строчек. заодно там же можно проверить версию POSIX и систему. ну, и особого смысла в проектах, где уже нужен автокрап, штатно поддерживать что-то кроме gcc и clang нет. а если программа для сборки требует гвидобейсик… нененене, дэвидблэйн.
	Ответить \| Правка \| ^ к родителю #99 \| Наверх \| Cообщить модератору


	106. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 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 усё.
	Ответить \| Правка \| ^ к родителю #101 \| Наверх \| Cообщить модератору


	96. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 07-Сен-12, 13:59
	>а ещё можно, например, выкинуть make. можно. а можно и не выкидывать, а просто разобраться в нескольких деталях и эффективно использовать. отличная, расширяемая система.
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору


	102. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от arisu (ok) on 07-Сен-12, 15:18
	> а можно и не выкидывать, а просто разобраться в нескольких деталях и > эффективно использовать. а можно — выкинуть. что, у make, например, уже появилась вменяемая обработка подкаталогов? нененене, рекурсивные вызовы make не предлагать. впрочем, любители make потому и не любители раскидывать части проекта по подкаталогам — потому что PITA.
	Ответить \| Правка \| ^ к родителю #96 \| Наверх \| Cообщить модератору


	105. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 07-Сен-12, 16:50
	> нененене, рекурсивные вызовы make не предлагать. это ещё почему? хотя и без них можно - отличный механизм по принципу всё своё ношу с собой - в любой проект вместе с мэйкфайлом вставить можно весь каталог не напрягаясь вообще. > впрочем, любители make потому и не любители раскидывать части проекта по подкаталогам — потому что PITA да что там сложного то? all: cd ./subdir1; make all cd ./subdir2; make all ...................... cd ./subdirN; make all
	Ответить \| Правка \| ^ к родителю #102 \| Наверх \| Cообщить модератору


	111. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от arisu (ok) on 07-Сен-12, 20:22
	забавно то, что мэйкофилы даже не понимают. хинт: дерево зависимостей. суперхинт: общее. суперсуперхинт: где?
	Ответить \| Правка \| ^ к родителю #105 \| Наверх \| Cообщить модератору


	114. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 07-Сен-12, 22:29
	гиперхинт: а зачем нужно общее дерево зависимостей?
	Ответить \| Правка \| ^ к родителю #111 \| Наверх \| Cообщить модератору


	118. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от arisu (ok) on 07-Сен-12, 22:54
	> гиперхинт: а зачем нужно общее дерево зависимостей? затем, что в отдельных каталогах далеко не всегда живут библиотеки. впрочем, мэйкофилы скажут «это нинада!»
	Ответить \| Правка \| ^ к родителю #114 \| Наверх \| Cообщить модератору


	120. "Оценка производительности Clang/LLVM и GCC при сборке во..."	+/–
	Сообщение от ананим on 07-Сен-12, 23:58
	а им и НЕ НАДО там жить!!! зыж ты откуда свалился то? у меня даже к Лунатикам таких вопросов нет. не, ну зашибись, будем сырцы с библиотеками мешать!
	Ответить \| Правка \| ^ к родителю #118 \| Наверх \| Cообщить модератору


	97. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от ананим on 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. но и тут, если не быдлокодить, то всё обходится.
	Ответить \| Правка \| ^ к родителю #46 \| Наверх \| Cообщить модератору


	32. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от Аноним (??) on 06-Сен-12, 16:14
	> И конечно же при изменении .h файла make сможет корректно найти все > места, где этот .h используется и их перекомпилировать. Сможет, ибо у нормальных людей dependency tracking используется в процессе разработки. Ну и пересобирается только то что зависело от этого .h файла. Как-то так, да.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	34. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от Aesthetus Animus (ok) on 06-Сен-12, 16:27
	makedepend
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	47. "Оценка производительности Clang/LLVM и GCC при сборке во Fre..."	+/–
	Сообщение от Ytch on 06-Сен-12, 22:05
	> И конечно же при изменении .h файла make сможет корректно найти все > места, где этот .h используется и их перекомпилировать. Вы не поверите! (секрет фокуса - см. ключи gcc -M -MM -MD -MMD и т. п.)
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору