forum.opennet.ru - "Увидел свет набор компиляторов LLVM 3.7" (62)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Увидел свет набор компиляторов LLVM 3.7"

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

"Увидел свет набор компиляторов LLVM 3.7"	+/–
Сообщение от opennews on 02-Сен-15, 10:40
Представлен (http://lists.llvm.org/pipermail/llvm-announce/2015-September...) релиз проекта LLVM 3.7 (http://llvm.org) (Low Level Virtual Machine) - GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод (http://llvm.org/docs/BitCodeFormat.html) RISC подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы. Улучшения (http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes...) в Clang 3.7: - Обеспечена полная поддержка стандарта OpenMP 3.1 (http://ru.wikipedia.org/wiki/OpenMP) (Open Multi-Processing), предоставляющего средства для применения методов параллельного программирования в программах на языках Си и Си++. Доступны средства обеспечения параллелизма на уровне задач (распараллеливание функций и циклов) и параллелизма на уровне данных (векторизация, распараллеливание типовых операций над массивами данных). В том числе реализованы комбинированные директивы, такие как "#pragma omp parallel for" и "#pragma omp parallel sections", атомарные операции ("#pragma omp atomic") и средства векторизации последовательных и параллелизированных циклов на процессорах с поддержкой инструкций SIMD ("#pragma omp simd"). Реализация OpenMP в Clang базируется на открытой компанией Intel runtime-библиотеке OpenMP (http://openmp.llvm.org/), которая связывается с итоговыми OpenMP-приложениями и выполняет диспетчеризацию потоков в процессе выполнения OpenMP-программы. Из особенностей библиотеки отмечается поддержка различных аппаратных архитектур (x86, x86_64, PowerPC, ARM), высокая производительность и совместимость на уровне ABI с GCC и проприетарными OpenMP-компиляторами (http://software.intel.com/en-us/intel-compilers) Intel. Для сборки программы с задействованием OpenMP достаточно указать при компиляции опцию "-fopenmp", а также пути к заголовочному файлу ("-I путь к omp.h") и библиотеке ("-L путь к библиотеке openmp"). - Интегрирован механизм проверки целостности выполнения программы CFI (http://llvm.org/releases/3.7.0/tools/clang/docs/ControlFlowI...) (Control Flow Integrity), нацеленный на выявление некоторых форм неопределённого поведения, которые потенциально могут привести к нарушению потока управления (control flow) в результате атаки на приложение. Представленный метод оптимизирован для минимизации накладных расходов, что позволяет использовать его при сборке релизов. При сборке Chromium с включением CFI наблюдалось замедление менее, чем на 1%, но увеличение размера исполняемого файла на 15%. Для включения следует использовать флаг "-fsanitize=cfi" в сочетании с включением оптимизации на этапе связывания ("-flto"); Основные новшества (http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html) LLVM 3.7: - Новый C++ JIT API для компиляции по запросу (ORC, On Request Compilation), отталкивающийся в функциональности от MCJIT (http://llvm.org/docs/MCJITDesignAndImplementation.html), но созданный для упрощения интеграции новых возможностей и улучшения тестируемости кодовой базы. Из интересных новшеств отмечаются средства отложенной компиляции функций по запросу (function-at-a-time) на системах x86. В состав также входит новая реализация MCJIT API, в том числе режим для симуляции поведения MCJIT (OrcMCJITReplacement). MCJIT оставлен в кодовой базе и продолжает использоваться в качесестве движка JIT (ExecutionEngine) по умолчанию; - Новый бэкенд для компиляции сценариев в байткод BPF (Berkeley Packet Filter), поддерживающий набор расширенных инструкций, представленных в доступной в свежих ядрах Linux виртуальной машине eBPF (http://www.opennet.dev/opennews/art.shtml?num=39959). Собранные BPF-сценарии могут быть загружены в ядро Linux при помощи системного вызова bpf(2) (http://www.opennet.dev/opennews/art.shtml?num=41210) и использованы для создания похожих на модули ядра обработчиков и фильтров. Из отличий расширенного BPF отмечается добавление восьми дополнительных регистров, реализация новых инструкций (call, shift, map hash/array, операции чтения и сохранения в стеке от 1 до 8 байт), добавление 64-разрядных регистров и возможность обращения к ограниченным функциям ядра. Для задействования бэкенда для генерации байткода BPF следует использовать опцию "-target bpf" в Clang или "-march=bpf" в llc; - Для написания модулей для виртуальной машины eBPF представлен фреймворк BCC (https://github.com/iovisor/bcc) (BPF Compiler Collection), предоставляющий средства по написанию сценариев на языке Си, которые затем транслируются в корректные программы BPF. В том числе в BCC предоставляются привязки к подсистемам ядра Linux, позволяющие создавать фильтры для сокетов, классификаторы трафика и обработчики определённой сетевой активности. Для языка Python подготовлен набор биндингов. Кроме того, можно отметить инициированный (http://www.linuxfoundation.org/news-media/announcements/2015...) организацией Linux Foundation проект IO Visor (https://www.iovisor.org/), нацеленный на создание инструментов (https://github.com/iovisor) и инфраструктуры для разработки расширяющих ядро Linux сетевых возможностей и обработчиков ввода/вывода, реализованных в форме модулей BPF. Из параллельно развивающихся проектов, основанных на LLVM, можно отметить: - KLEE (http://klee.llvm.org/) - символьный анализатор и генератор тестовых наборов; - Runtime-библиотека compiler-rt (http://compiler-rt.llvm.org/); - llvm-mc (http://llvm.org/releases/2.6/docs/ReleaseNotes.html#mc) - автогенератор ассемблера, дизассемблера и других связанных с машинным кодом компонентов на основе описаний параметров LLVM-совместимых платформ. - Реализация функционального языка программирования Pure (http://pure-lang.googlecode.com/); - LDC (https://github.com/ldc-developers/ldc) - компилятор для языка D; - Roadsend PHP (http://www.roadsend.com/) - оптимизатор, статический и JIT компилятор для языка PHP; - Виртуальные машины для Ruby: Rubinius (http://rubini.us/) и MacRuby (http://www.macruby.org/); - LLVM-Lua (http://code.google.com/p/llvm-lua/) - FlashCCompiler (http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf) - средство для компиляции кода на языке Си в вид, пригодный для выполнения в виртуальной машине Adobe Flash; - LLDB (http://lldb.llvm.org/) - новая (http://www.opennet.dev/opennews/art.shtml?num=26907) модульная инфраструктура отладки, использующая такие подсистемы LLVM как API для дизассемблирования, Clang AST (Abstract Syntax Tree), парсер выражений, генератор кода и JIT-компилятор. LLDB поддерживает отладку многопоточных программ на языках C, Objective-C и C++; отличается возможностью подключения плагинов и скриптов на языке Python; показывает крайне высокое быстродействие при отладке программ большого размера; - emscripten (https://github.com/kripken/emscripten/wiki) - компилятор биткода LLVM в JavaScript, позволяющий преобразовать для запуска в браузере приложения, изначально написанные на языке Си. Например, удалось запустить Python, Lua, Quake, Freetype; - sparse-llvm (https://github.com/penberg/sparse-llvm) - бэкенд, нацеленный (http://www.opennet.dev/opennews/art.shtml?num=31636) на создание Си-компилятора, способного собирать ядро Linux. - Portable OpenCL (http://www.opennet.dev/opennews/art.shtml?num=32092) - открытая и независимая реализация стандарта OpenCL; - CUDA Compiler (http://www.opennet.dev/opennews/art.shtml?num=33800) - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran; - Julia (http://www.opennet.dev/opennews/art.shtml?num=33315) - открытый динамический язык программирования, использующий наработки проекта LLVM. - Jade (https://github.com/orcc/jade) (Just-in-time Adaptive Decoder Engine) - универсальны... URL: http://lists.llvm.org/pipermail/llvm-announce/2015-September... Новость: http://www.opennet.dev/opennews/art.shtml?num=42894
Ответить \| Правка \| Cообщить модератору

Оглавление

Увидел свет набор компиляторов LLVM 3.7, G.NercY.uR, 10:40 , 02-Сен-15, (1) +1

Увидел свет набор компиляторов LLVM 3.7, G.NercY.uR, 10:43 , 02-Сен-15, (2) +2

Увидел свет набор компиляторов LLVM 3.7, G.NercY.uR, 10:49 , 02-Сен-15, (3) –1

Увидел свет набор компиляторов LLVM 3.7, AnotherReality, 11:31 , 02-Сен-15, (5) +3

Увидел свет набор компиляторов LLVM 3.7, G.NercY.uR, 18:40 , 05-Сен-15, (60)

Увидел свет набор компиляторов LLVM 3.7, Andrey Mitrofanov, 11:17 , 07-Сен-15, (62)

Увидел свет набор компиляторов LLVM 3.7, A.Stahl, 11:42 , 02-Сен-15, (7) –4

Увидел свет набор компиляторов LLVM 3.7, Аноним, 11:48 , 02-Сен-15, (8) –9

Увидел свет набор компиляторов LLVM 3.7, mine, 18:15 , 02-Сен-15, (22) –2

Увидел свет набор компиляторов LLVM 3.7, Аноним, 18:57 , 02-Сен-15, (24) –6

Увидел свет набор компиляторов LLVM 3.7, Аноним, 23:03 , 02-Сен-15, (27) +5
Увидел свет набор компиляторов LLVM 3.7, Аноним, 17:57 , 03-Сен-15, (50) +2

Увидел свет набор компиляторов LLVM 3.7, Аноним, 08:42 , 06-Сен-15, (61)

Увидел свет набор компиляторов LLVM 3.7, Andrey Mitrofanov, 11:23 , 07-Сен-15, (63) +1

Увидел свет набор компиляторов LLVM 3.7, Аноним, 16:11 , 02-Сен-15, (18) +1
Увидел свет набор компиляторов LLVM 3.7, Аноним, 20:07 , 02-Сен-15, (25) –1

Увидел свет набор компиляторов LLVM 3.7, freehck, 12:05 , 02-Сен-15, (13) –4

Увидел свет набор компиляторов LLVM 3.7, Аноним, 16:28 , 02-Сен-15, (20) +4

Увидел свет набор компиляторов LLVM 3.7, freehck, 12:54 , 03-Сен-15, (39) +1

Увидел свет набор компиляторов LLVM 3.7, Аноним, 16:47 , 03-Сен-15, (44)

Увидел свет набор компиляторов LLVM 3.7, freehck, 11:37 , 04-Сен-15, (55)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 15:31 , 05-Сен-15, (56)
Увидел свет набор компиляторов LLVM 3.7, Аноним, 15:39 , 05-Сен-15, (57)
Увидел свет набор компиляторов LLVM 3.7, Aleks Revo, 22:56 , 09-Сен-15, (64)

Увидел свет набор компиляторов LLVM 3.7, Анономс, 08:25 , 03-Сен-15, (32) +2

Увидел свет набор компиляторов LLVM 3.7, Alexey, 16:49 , 03-Сен-15, (45) –2

Увидел свет набор компиляторов LLVM 3.7, Аноним, 10:51 , 04-Сен-15, (54)

Увидел свет набор компиляторов LLVM 3.7, Школьник, 11:49 , 02-Сен-15, (9) –12

Увидел свет набор компиляторов LLVM 3.7, дядя, 11:58 , 02-Сен-15, (11) +1

Увидел свет набор компиляторов LLVM 3.7, bOOster, 12:32 , 02-Сен-15, (16) –7

Увидел свет набор компиляторов LLVM 3.7, Анонимус Сапиенс, 15:07 , 03-Сен-15, (41) +2

Увидел свет набор компиляторов LLVM 3.7, Аноним, 15:36 , 03-Сен-15, (42) +1

Увидел свет набор компиляторов LLVM 3.7, Аноним, 17:55 , 03-Сен-15, (49)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 18:08 , 03-Сен-15, (51) +4
Увидел свет набор компиляторов LLVM 3.7, bOOster, 17:02 , 05-Сен-15, (59) –1

Увидел свет набор компиляторов LLVM 3.7, bOOster, 16:53 , 05-Сен-15, (58) –2

Увидел свет набор компиляторов LLVM 3.7, mine, 18:31 , 02-Сен-15, (23) –2
Увидел свет набор компиляторов LLVM 3.7, Клыкастый, 12:18 , 03-Сен-15, (37)

Увидел свет набор компиляторов LLVM 3.7, GrammarNarziss, 12:05 , 03-Сен-15, (36) +1

Увидел свет набор компиляторов LLVM 3.7, nc, 11:00 , 02-Сен-15, (4) +1

Увидел свет набор компиляторов LLVM 3.7, Нанобот, 16:46 , 02-Сен-15, (21) –3
Увидел свет набор компиляторов LLVM 3.7, Аноним, 07:54 , 03-Сен-15, (31) –1

Увидел свет набор компиляторов LLVM 3.7, nc, 10:03 , 03-Сен-15, (33)

Увидел свет набор компиляторов LLVM 3.7, дядя, 11:40 , 02-Сен-15, (6) +1
Увидел свет набор компиляторов LLVM 3.7, Аноним, 12:02 , 02-Сен-15, (12) –10

Увидел свет набор компиляторов LLVM 3.7, freehck, 12:09 , 02-Сен-15, (14) +12

Увидел свет набор компиляторов LLVM 3.7, Nuzhny, 12:46 , 02-Сен-15, (17) +2
Увидел свет набор компиляторов LLVM 3.7, Аноним, 16:24 , 02-Сен-15, (19)

Увидел свет набор компиляторов LLVM 3.7, Andrey Mitrofanov, 10:15 , 03-Сен-15, (34) +1

Увидел свет набор компиляторов LLVM 3.7, Аноним, 21:09 , 02-Сен-15, (26) +4

Увидел свет набор компиляторов LLVM 3.7, Аноним, 04:17 , 03-Сен-15, (30) –2

Увидел свет набор компиляторов LLVM 3.7, дон Педро, 23:12 , 02-Сен-15, (28)
Увидел свет набор компиляторов LLVM 3.7, Аноним, 23:46 , 02-Сен-15, (29) +1

Увидел свет набор компиляторов LLVM 3.7, Аноним, 11:02 , 03-Сен-15, (35) +7
Увидел свет набор компиляторов LLVM 3.7, Аноним, 17:53 , 03-Сен-15, (48) –1

Увидел свет набор компиляторов LLVM 3.7, анонимус вульгарис, 12:47 , 03-Сен-15, (38)

Увидел свет набор компиляторов LLVM 3.7, Andrey Mitrofanov, 14:22 , 03-Сен-15, (40)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 15:56 , 03-Сен-15, (43)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 17:53 , 03-Сен-15, (47)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 17:52 , 03-Сен-15, (46)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 19:28 , 03-Сен-15, (52)

Увидел свет набор компиляторов LLVM 3.7, Аноним, 10:46 , 04-Сен-15, (53) –1

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

1. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от G.NercY.uR on 02-Сен-15, 10:40

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

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

2. "Увидел свет набор компиляторов LLVM 3.7" +2 +/–

Сообщение от G.NercY.uR on 02-Сен-15, 10:43

Сам же сразу и ответил: Зашёл на фороникс, а там на тебе: http://www.phoronix.com/scan.php?page=article&item=clang-37-...

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

3. "Увидел свет набор компиляторов LLVM 3.7" –1 +/–

Сообщение от G.NercY.uR on 02-Сен-15, 10:49

> Сам же сразу и ответил: Зашёл на фороникс, а там на тебе:
> http://www.phoronix.com/scan.php?page=article&item=clang-37-...
В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc.
Слава разработчикам! Clang'у слава!

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

5. "Увидел свет набор компиляторов LLVM 3.7" +3 +/–

Сообщение от AnotherReality (ok) on 02-Сен-15, 11:31

последнее это сарказм?

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

60. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от G.NercY.uR on 05-Сен-15, 18:40

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

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

62. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Andrey Mitrofanov on 07-Сен-15, 11:17

> Нет, не более чем игра слов на больную тему.
s/игра слов/тролинг/  "Честнее, Владимир, честнее." С собой в тч.

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

7. "Увидел свет набор компиляторов LLVM 3.7" –4 +/–

Сообщение от A.Stahl (ok) on 02-Сен-15, 11:42

>В итоге
В итоге всё равно все используют GCC...

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

8. "Увидел свет набор компиляторов LLVM 3.7" –9 +/–

Сообщение от Аноним (??) on 02-Сен-15, 11:48

Что такое GCC? Google Closure Compiler?

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

22. "Увидел свет набор компиляторов LLVM 3.7" –2 +/–

Сообщение от mine (ok) on 02-Сен-15, 18:15

https://gcc.gnu.org/

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

24. "Увидел свет набор компиляторов LLVM 3.7" –6 +/–

Сообщение от Аноним (??) on 02-Сен-15, 18:57

это который в тихую линкует статически либу под GPL v3 что вызывает автоматом смену лицензии на код в силу вирусности лицензии на библиотеку? или делай свой код под GPL v3 или не компилируй.

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

27. "Увидел свет набор компиляторов LLVM 3.7" +5 +/–

Сообщение от Аноним (??) on 02-Сен-15, 23:03

Дурачек не нужно тут бредить!

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

50. "Увидел свет набор компиляторов LLVM 3.7" +2 +/–

Сообщение от Аноним (??) on 03-Сен-15, 17:57

> это который в тихую линкует статически либу под GPL v3
Сразу видно - грибной сезон начался :)

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

61. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 06-Сен-15, 08:42

о статической линовке libgcc ты не знал? так учись пока не поздно..

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

63. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от Andrey Mitrofanov on 07-Сен-15, 11:23

> о статической линовке libgcc ты не знал? так учись пока не поздно..
Маленький врунишка?
""While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions.

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

18. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

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

> В итоге всё равно все используют GCC
И? Зато гордые птицы-ежики из-за этого "пинка" со стороны llvmовцев, как минимум улучшили сообщения об ошибках. Так что, пусть и дальше не дают уж слишком расслабиться.

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

25. "Увидел свет набор компиляторов LLVM 3.7" –1 +/–

Сообщение от Аноним (??) on 02-Сен-15, 20:07

кто все? в os x, freebsd clang, да и в windows от тоже есть. А если вы про линукс ну так вы можите собирать пакеты и через Clang вам не запрещают. Хорошо когда есть выбор.

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

13. "Увидел свет набор компиляторов LLVM 3.7" –4 +/–

Сообщение от freehck (ok) on 02-Сен-15, 12:05

> В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc.
Скорость развития -- очень хорошая, и разработчики молодцы. Но всё же давайте подождём, когда LLVM будет поддерживать столь же широкий набор архитектур, что и GCC, и тогда уже будем сравнивать, кто быстрее развивается.
По тестам же: мне не понятно, с какими флагами оптимизации запускались те или иные тесты, а для сравнения это очень важно. Более того, использовалась ли статическая компиляция или же JIT?
Мало того, что сравнивать последнюю версию LLVM из SVN со стабильной версией GCC не совсем корректно (ну да ладно, продукт развивающийся, только растёт -- на это можно ещё закрыть глаза), но почему тогда в тестах GCC не используют флаг -O3? Раз уж сравнивать последние достижения, то с обеих сторон. Научные тесты со второй страницы в этой случае очень хочется проверить повторно с -O3.
Если в LLVM использовался его хвалёный JIT, то имеет ли смысл сравнение в скорости компиляции?
Я может конечно не разобрался в интерфейсе фороникса, и где-то про это всё-таки написано. Если так -- покажите, пожалуйста, где именно.

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

20. "Увидел свет набор компиляторов LLVM 3.7" +4 +/–

Сообщение от Аноним (??) on 02-Сен-15, 16:28

> но почему тогда в тестах GCC не используют флаг -O3?
По той же причине, по которой не используют -Ofast. В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности, но значительно (относительно) увеличивают размер кода, что негативно сказывается на его локальности в I$. На практике, с GCC нет смысла использовать уровни выше -O2.
> Если в LLVM использовался его хвалёный JIT
Херню сморозил.

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

39. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от freehck (ok) on 03-Сен-15, 12:54

>> но почему тогда в тестах GCC не используют флаг -O3?
> По той же причине, по которой не используют -Ofast.
-Ofast не используют, потому что он обеспечивает оптимизации, не соответствующие стандарту. -O3 этим не отличается.
> В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности,
Хотелось бы увидеть замеры хотя бы на тех же синтетических тестах. Когда-то давно, когда я сидел на Gentoo, я разницу очень даже чувствовал.
> но значительно (относительно) увеличивают размер кода, что негативно сказывается на его
> локальности в I$.
Что такое I$?
>> Если в LLVM использовался его хвалёный JIT
> Херню сморозил.
Не понимаю, поясните.

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

44. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 03-Сен-15, 16:47

>>> но почему тогда в тестах GCC не используют флаг -O3?
>> По той же причине, по которой не используют -Ofast.
-Ofast не используют, потому что он обеспечивает оптимизации, не соответствующие стандарту.
Не всем и не всегда важно строгое соответствие IEEE 754.
> -O3 этим не отличается.
Ну. Так если он не приводит к нарушению IEEE 754, а его всё равно не используют — в этом что-то есть, не так ли?
>> В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности,
> Хотелось бы увидеть замеры хотя бы на тех же синтетических тестах.
Замечательно. Возьмите хоть SPEC, хоть что хотите, сделайте замеры и поделитесь с нами результатами.
> Когда-то давно, когда я сидел на Gentoo, я разницу очень даже чувствовал.
У меня с gcc 4.9:
% gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
% gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
% diff /tmp/O2-opts /tmp/O3-opts | grep enabled
>   -fgcse-after-reload                 [enabled]
>   -finline-functions                  [enabled]
>   -fipa-cp-clone                      [enabled]
>   -fpredictive-commoning              [enabled]
>   -ftree-loop-distribute-patterns     [enabled]
>   -ftree-loop-vectorize               [enabled]
>   -ftree-partial-pre                  [enabled]
>   -ftree-slp-vectorize                [enabled]
>   -funswitch-loops                    [enabled]
Половина из них копирует базовые блоки или циклы, увеличивая размер кода, так, что теоретический прирост производительности нивелируется возрастанием задержек на более частую перезагрузку линий кэша команд. Вторая половина — та, что относится к Graphite — в реальной жизни просто не работает.
Не поймите меня неправильно, эти оптимизации не бесполезны — когда у вас есть одна или несколько однотипных машин, конфигурация которых не изменяется годами, и одна или несколько специализированных программ, выполняющих на этих машинах расчёты продолжительностью неделю-две на одном наборе данных. Тогда даже несколько процентов ускорения сыграют роль, а программы могут быть написаны таким образом, что они получат реальное ускорение от этих конкретных оптимизаций. Но это совершенно иррелевантно в случае вашей домашней машины с Gentoo и 700 установленными программами, наиболее используемые из которых — текстовый редактор, браузер, почтовый клиент — интерактивны, и большую часть времени простаивают на ожидании ввода-вывода.
>> но значительно (относительно) увеличивают размер кода, что негативно сказывается на его
>> локальности в I$.
> Что такое I$?
Instruction cache.
>>> Если в LLVM использовался его хвалёный JIT
>> Херню сморозил.
> Не понимаю, поясните.
LLVM одинаково хорошо (или одинаково плохо; главное — одинаково) позволяет строить на своей основе как JIT-, так и AOT-трансляторы.
Когда LLVM используется для кодогенерации для Radeon в драйвере, он работает как JIT: драйвер непрерывно формирует поток команд, которые непрерывно транслируются LLVM в другой поток. Другой гипотетический пример: когда исполняется программа на JavaScript, транслятор непрерывно читает из буфера программный код (на JavaScript или байт-код, не суть), который должен исполниться прямо сейчас, и непрерывно транслирует его в машинный код (или загружает уже оттранслированный код из кэша, но это не важно). Ключевое слово — «непрерывное исполнение», и в этот процесс вовлечён транслятор.
Когда LLVM используется фронтэндом Clang для трансляции кода на C или C++, он работает точно так же, как GCC: фронтэнд читает программу на ЯВУ и формирует промежуточное представление, которое затем понижается до машинного кода (записываемого компоновщиком в исполняемый файл), транслируется в другой ЯВУ — опять же, не суть. С выхода Clang (то есть, LLVM; то есть, компоновщика) вы получаете точно такой же исполняемый файл, как и с выхода GCC. Этот файл может быть скомпонован с libc, другими указанными вами библиотеками, но транслятор в его последующем исполнении никакого участия не принимает. Это ELF (или Mach-O, или COFF) с записанным в него машинным кодом.

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

55. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от freehck (ok) on 04-Сен-15, 11:37

Спасибо, я не знал про эти особенности оптимизаций в GCC. Особенно про I$. (Кстати, почему именно такая аббревиатура для него?)
С -O3 в генте, судя по всему, у меня были такие ощущения как раз потому, что я в то время занимался расчётами ГПВРД, а они могли идти сутками напролёт. Возможно, мне стоит пересмотреть ряд своих выводов по поводу оптимизаций. Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang.
> Замечательно. Возьмите хоть SPEC, хоть что хотите, сделайте замеры и поделитесь с
> нами результатами.
Да, было бы неплохо. Но вопрос опять же упирается во время. Я никогда этим не занимался, и не знаю, как произвести корректное сравнение.
На всякий случай хочу уточнить: SPEC - это вот это ли: https://www.spec.org/benchmarks.html
> LLVM одинаково хорошо (или одинаково плохо; главное — одинаково) позволяет строить
> на своей основе как JIT-, так и AOT-трансляторы.
Нет, это-то само собой. Просто когда я читал описание LLVM, я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре. Понятное дело, что можно выполнить этот шаг и сразу при компиляции, но меня удивила нацеленность именно на перенесение AOT в runtime. Ибо JIT нужен в основном для кодогенерации в runtime, а не для того, чтобы процесс компиляции можно было остановить, достигнув только промежуточного представления.

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

56. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 05-Сен-15, 15:31

> Особенно про I$. (Кстати, почему именно такая аббревиатура для него?)
Это не единственная аббревиатура, просто одна из используемых. I - instruction, $ - cache.
> Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang.
Конечно. Каждый случай надо рассматривать индивидуально. возможно, пробовать разные параметры, иногда даже пытаться подогнать код, чтобы облегчить работу компилятору, если это возможно и оправданно.
> SPEC - это вот это ли: https://www.spec.org/benchmarks.html
Да. Это лишь пример. Если у вас есть своя важная задача, можете работать сразу с ней, это может быть полезнее. Иногда стоит и генерируемый в разный случаях код сравнить.
> я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре
Да нет никакой основной концепции. Это фреймворк, конструктор, позволяющий инженерам решать свои задачи удобным им способом. Clang, например, для компилятора C совершенно традиционен.

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

57. "Увидел свет набор компиляторов LLVM 3.7" +/–

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

>Кстати, почему именно такая аббревиатура для него?
IC? Слишком обширно. Integrated circuit, что ли? А тут "cache", $ - сразу сужает диапазон допустимых значений.

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

64. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Aleks Revo (ok) on 09-Сен-15, 22:56

Современное положение дел таково, что там, где это полезно и не приводит к сбоям, пакеты итак собираются с опцией -O3, даже если в make.conf -O2
И наоборот, там, где это приводит к багам, даже при -O3 эти пакеты собираются с опцией -O2.
Не могу сказать, что это касается всего дерева и любого пакета, но такое поведение встречается достаточно часто.

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

32. "Увидел свет набор компиляторов LLVM 3.7" +2 +/–

Сообщение от Анономс on 03-Сен-15, 08:25

Да он выиграл только в тесте SciMark 2 разраб которого не любит GCC и через какое-то время перелапатил все для поддержки Clang со всеми воркераундами.
Ну и разумеется тест скорости компиляции тоже за Clang - юзерам пофиг, а разрабы будут использовать только чтоб быстрее потестить, финальный билд все равно GCC.

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

45. "Увидел свет набор компиляторов LLVM 3.7" –2 +/–

Сообщение от Alexey (??) on 03-Сен-15, 16:49

Если все остальное время ты компилишь в Clang, то и финальный билд будет в Clang.

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

54. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 04-Сен-15, 10:51

Финальный билд делают маинтейнеры дистрибутива, так что нет.

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

9. "Увидел свет набор компиляторов LLVM 3.7" –12 +/–

Сообщение от Школьник (ok) on 02-Сен-15, 11:49

Судя по картинкам по ссылке, недалек уже тот момент, когда gcc натурально можно будет закапывать. Впрочем, ничего удивительного - когда идеология превозмогает над здравым смыслом и начинает диктовать свою волю при выборе инженерных решений, то результат немного предсказуем. В Китае это вовремя понял Дэн Сяопин, в СССР этого, увы, не поняли. Похоже, не понимает этого и Столлман со своей толпой преданных фанатиков, жадно ловящих каждое слово, выходящее из его рта. Ну да ничего, скоро уже поймут, что архитектура gcc, мягко говоря, не поощряющая его переиспользование и расширение, равно как и сомнительные игры с лицензией на gcc runtime обошлись слишком дорого.

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

11. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от дядя on 02-Сен-15, 11:58

иди учись школьник! gcc в любом случае не умрет, а модульную конструкцию из llvm действительно не грех перенять и переймут, не сумлевайся!

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

16. "Увидел свет набор компиляторов LLVM 3.7" –7 +/–

Сообщение от bOOster (ok) on 02-Сен-15, 12:32

Аха, ну ситуация сродни Freeswitch против Астериска. Первый модульный и перспективный, второй древний и корявый. Второй держиться ТОЛЬКО на том что всякой документации гораздо больше находиться в инете чем первый. Станет наоборот - сдохнет тут-же.

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

41. "Увидел свет набор компиляторов LLVM 3.7" +2 +/–

Сообщение от Анонимус Сапиенс on 03-Сен-15, 15:07

Ты дурачок, asterisk и freeswitch это перпендикулярные вещи. Это как холодильник vs стул.

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

42. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от Аноним (??) on 03-Сен-15, 15:36

> Это как холодильник vs стул.
Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно, а вот холодить стулом не получится)!

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

49. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 03-Сен-15, 17:55

> Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно,
ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.

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

51. "Увидел свет набор компиляторов LLVM 3.7" +4 +/–

Сообщение от Аноним (??) on 03-Сен-15, 18:08

> ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.
Только нублы и хомячки сидят на стульях -- эксперты опеннета выбирают диваны!

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

59. "Увидел свет набор компиляторов LLVM 3.7" –1 +/–

Сообщение от bOOster (ok) on 05-Сен-15, 17:02

>> Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно,
> ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.
Да?? а на природе маленький холодильничек хорош, и сидишь на нем, и пиво достаешь… Хотя вам, голодранцам этого не понять...

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

58. "Увидел свет набор компиляторов LLVM 3.7" –2 +/–

Сообщение от bOOster (ok) on 05-Сен-15, 16:53

Ну дурачки срази и отписались…
По факту - как ты "лошадь" не назови - ОНА РЕШАЕТ одну задачу.
А вертикально или перпендикулярно, да хоть в геометрической прогрессии, хотя че я мечу тут рис перед свиньями…. Один фиг безрезультатно...

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

23. "Увидел свет набор компиляторов LLVM 3.7" –2 +/–

Сообщение от mine (ok) on 02-Сен-15, 18:31

Када я вырасту я стану самый-самый. Воть.

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

37. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Клыкастый (ok) on 03-Сен-15, 12:18

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

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

36. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от GrammarNarziss on 03-Сен-15, 12:05

"на-гора" же

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

4. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от nc (ok) on 02-Сен-15, 11:00

Rust забыли в список проектов включить.

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

21. "Увидел свет набор компиляторов LLVM 3.7" –3 +/–

Сообщение от Нанобот (ok) on 02-Сен-15, 16:46

от горе...

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

31. "Увидел свет набор компиляторов LLVM 3.7" –1 +/–

Сообщение от Аноним (??) on 03-Сен-15, 07:54

И D, не забудьте про D.

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

33. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от nc (ok) on 03-Сен-15, 10:03

ldc в списке есть.

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

6. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от дядя on 02-Сен-15, 11:40

Roadsend PHP? С 2012 никаких коммитов

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

12. "Увидел свет набор компиляторов LLVM 3.7" –10 +/–

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

Что в этом clang хорошего? Вчера вышел C++ Builder новый, поставляющийся с этим компилятором по умолчанию, программы теперь медленней станут и толще? :) А плюсы есть какие-нибудь?

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

14. "Увидел свет набор компиляторов LLVM 3.7" +12 +/–

Сообщение от freehck (ok) on 02-Сен-15, 12:09

> Что в этом clang хорошего? Вчера вышел C++ Builder новый, поставляющийся с
> этим компилятором по умолчанию, программы теперь медленней станут и толще? :)
> А плюсы есть какие-нибудь?
Как минимум два. Они прямо в названии и стоят "C++ Builder". :)

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

17. "Увидел свет набор компиляторов LLVM 3.7" +2 +/–

Сообщение от Nuzhny on 02-Сен-15, 12:46

* Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
...
* PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;
Вообще-то это один и тот же проект, он сменил своё название с первого на второе. Можно убедиться в этом здесь: https://github.com/pocl/pocl

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

19. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 02-Сен-15, 16:24

Сейчас прибежит Столлман со своим gcc и будет хвалить LLVM

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

34. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от Andrey Mitrofanov on 03-Сен-15, 10:15

> Сейчас прибежит Столлман со своим gcc и будет хвалить LLVM
Это ты в каждой новости "бегаешь", как ужаленный, а rms уже http://lwn.net/Articles/582242/rss?format=printable похвалил.

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

26. "Увидел свет набор компиляторов LLVM 3.7" +4 +/–

Сообщение от Аноним (??) on 02-Сен-15, 21:09

А чего среди проектов на базе LLVM  RUST не указан? один из самых интересных проектов и не упомянули в новости.

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

30. "Увидел свет набор компиляторов LLVM 3.7" –2 +/–

Сообщение от Аноним (??) on 03-Сен-15, 04:17

Потому что не нужен. Ваш Капитан ...

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

28. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от дон Педро on 02-Сен-15, 23:12

А этот недавний патч для увеличения производительности radeon интегрирован?

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

29. "Увидел свет набор компиляторов LLVM 3.7" +1 +/–

Сообщение от Аноним (??) on 02-Сен-15, 23:46

Apple с LLVM потихоньку наматывает яйца столмана на винт

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

35. "Увидел свет набор компиляторов LLVM 3.7" +7 +/–

Сообщение от Аноним (??) on 03-Сен-15, 11:02

ещё про наручники, кляпы и плёточки пофантазируй. Нравится как айфон вибрирует?

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

48. "Увидел свет набор компиляторов LLVM 3.7" –1 +/–

Сообщение от Аноним (??) on 03-Сен-15, 17:53

> Apple с LLVM
Все бы ничего, только эппл оттуда почти устранился и отдал руль гуглу.

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

38. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от анонимус вульгарис on 03-Сен-15, 12:47

> Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
> PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;
Для танкистов?

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

40. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Andrey Mitrofanov on 03-Сен-15, 14:22

>> Portable OpenCL - открытая
>> PoCL (Portable Computing Language OpenCL) - реализация
> Для танкистов?
Для http:/openforum/vsluhforumID3/104546.html#17 вас, да.

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

43. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 03-Сен-15, 15:56

Хорошая новость и обзор OpenCL,спасибо автору!
Жаль пока не пропатчили LLVM для ускорения драйвера AMD/ATI...

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

47. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 03-Сен-15, 17:53

> Жаль пока не пропатчили LLVM для ускорения драйвера AMD/ATI...
Насчет ускорения: http://www.phoronix.com/scan.php?page=article&item=radeonsi-...
...оно уже втыкает каталисту в половине случаев!

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

46. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 03-Сен-15, 17:52

Много булшита и ни звука про улучшения для бэкэнда AMDGPU. А между тем, LLVM 3.7 требуется для OpenGL 4.1 в новой MESA с RadeonSI.

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

52. "Увидел свет набор компиляторов LLVM 3.7" +/–

Сообщение от Аноним (??) on 03-Сен-15, 19:28

Напиши на сайт amd.com глупец

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

53. "Увидел свет набор компиляторов LLVM 3.7" –1 +/–

Сообщение от Аноним (??) on 04-Сен-15, 10:46

А почему под Win подняли планку с XP до 7-ки? 7-ка же скоро заканчивается! Нужно сразу до 10-ки поднимать, так сказать, расширять поддерживаемые и популярные платформы :-D

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

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

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

Партнёры:

Хостинг:

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

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

1. "Увидел свет набор компиляторов LLVM 3.7"	+1 +/–
Сообщение от G.NercY.uR on 02-Сен-15, 10:40
Фороникс что-то давненько не выдавал нагора сравнения последних компиляторов. Пускай выкладывают, кто-нибудь скажите форониксу об этом плиз.:)
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Увидел свет набор компиляторов LLVM 3.7"	+2 +/–
	Сообщение от G.NercY.uR on 02-Сен-15, 10:43
	Сам же сразу и ответил: Зашёл на фороникс, а там на тебе: http://www.phoronix.com/scan.php?page=article&item=clang-37-...
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Увидел свет набор компиляторов LLVM 3.7"	–1 +/–
	Сообщение от G.NercY.uR on 02-Сен-15, 10:49
	> Сам же сразу и ответил: Зашёл на фороникс, а там на тебе: > http://www.phoronix.com/scan.php?page=article&item=clang-37-... В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc. Слава разработчикам! Clang'у слава!
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "Увидел свет набор компиляторов LLVM 3.7"	+3 +/–
	Сообщение от AnotherReality (ok) on 02-Сен-15, 11:31
	последнее это сарказм?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	60. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от G.NercY.uR on 05-Сен-15, 18:40
	> последнее это сарказм? Нет, не более чем игра слов на больную тему.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	62. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Andrey Mitrofanov on 07-Сен-15, 11:17
	> Нет, не более чем игра слов на больную тему. s/игра слов/тролинг/ "Честнее, Владимир, честнее." С собой в тч.
	Ответить \| Правка \| ^ к родителю #60 \| Наверх \| Cообщить модератору


	7. "Увидел свет набор компиляторов LLVM 3.7"	–4 +/–
	Сообщение от A.Stahl (ok) on 02-Сен-15, 11:42
	>В итоге В итоге всё равно все используют GCC...
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	8. "Увидел свет набор компиляторов LLVM 3.7"	–9 +/–
	Сообщение от Аноним (??) on 02-Сен-15, 11:48
	Что такое GCC? Google Closure Compiler?
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	22. "Увидел свет набор компиляторов LLVM 3.7"	–2 +/–
	Сообщение от mine (ok) on 02-Сен-15, 18:15
	https://gcc.gnu.org/
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	24. "Увидел свет набор компиляторов LLVM 3.7"	–6 +/–
	Сообщение от Аноним (??) on 02-Сен-15, 18:57
	это который в тихую линкует статически либу под GPL v3 что вызывает автоматом смену лицензии на код в силу вирусности лицензии на библиотеку? или делай свой код под GPL v3 или не компилируй.
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	27. "Увидел свет набор компиляторов LLVM 3.7"	+5 +/–
	Сообщение от Аноним (??) on 02-Сен-15, 23:03
	Дурачек не нужно тут бредить!
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	50. "Увидел свет набор компиляторов LLVM 3.7"	+2 +/–
	Сообщение от Аноним (??) on 03-Сен-15, 17:57
	> это который в тихую линкует статически либу под GPL v3 Сразу видно - грибной сезон начался :)
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	61. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Аноним (??) on 06-Сен-15, 08:42
	о статической линовке libgcc ты не знал? так учись пока не поздно..
	Ответить \| Правка \| ^ к родителю #50 \| Наверх \| Cообщить модератору


	63. "Увидел свет набор компиляторов LLVM 3.7"	+1 +/–
	Сообщение от Andrey Mitrofanov on 07-Сен-15, 11:23
	> о статической линовке libgcc ты не знал? так учись пока не поздно.. Маленький врунишка? ""While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions.
	Ответить \| Правка \| ^ к родителю #61 \| Наверх \| Cообщить модератору


	18. "Увидел свет набор компиляторов LLVM 3.7"	+1 +/–
	Сообщение от Аноним (??) on 02-Сен-15, 16:11
	> В итоге всё равно все используют GCC И? Зато гордые птицы-ежики из-за этого "пинка" со стороны llvmовцев, как минимум улучшили сообщения об ошибках. Так что, пусть и дальше не дают уж слишком расслабиться.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	25. "Увидел свет набор компиляторов LLVM 3.7"	–1 +/–
	Сообщение от Аноним (??) on 02-Сен-15, 20:07
	кто все? в os x, freebsd clang, да и в windows от тоже есть. А если вы про линукс ну так вы можите собирать пакеты и через Clang вам не запрещают. Хорошо когда есть выбор.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	13. "Увидел свет набор компиляторов LLVM 3.7"	–4 +/–
	Сообщение от freehck (ok) on 02-Сен-15, 12:05
	> В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc. Скорость развития -- очень хорошая, и разработчики молодцы. Но всё же давайте подождём, когда LLVM будет поддерживать столь же широкий набор архитектур, что и GCC, и тогда уже будем сравнивать, кто быстрее развивается. По тестам же: мне не понятно, с какими флагами оптимизации запускались те или иные тесты, а для сравнения это очень важно. Более того, использовалась ли статическая компиляция или же JIT? Мало того, что сравнивать последнюю версию LLVM из SVN со стабильной версией GCC не совсем корректно (ну да ладно, продукт развивающийся, только растёт -- на это можно ещё закрыть глаза), но почему тогда в тестах GCC не используют флаг -O3? Раз уж сравнивать последние достижения, то с обеих сторон. Научные тесты со второй страницы в этой случае очень хочется проверить повторно с -O3. Если в LLVM использовался его хвалёный JIT, то имеет ли смысл сравнение в скорости компиляции? Я может конечно не разобрался в интерфейсе фороникса, и где-то про это всё-таки написано. Если так -- покажите, пожалуйста, где именно.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	20. "Увидел свет набор компиляторов LLVM 3.7"	+4 +/–
	Сообщение от Аноним (??) on 02-Сен-15, 16:28
	> но почему тогда в тестах GCC не используют флаг -O3? По той же причине, по которой не используют -Ofast. В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности, но значительно (относительно) увеличивают размер кода, что негативно сказывается на его локальности в I$. На практике, с GCC нет смысла использовать уровни выше -O2. > Если в LLVM использовался его хвалёный JIT Херню сморозил.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	39. "Увидел свет набор компиляторов LLVM 3.7"	+1 +/–
	Сообщение от freehck (ok) on 03-Сен-15, 12:54
	>> но почему тогда в тестах GCC не используют флаг -O3? > По той же причине, по которой не используют -Ofast. -Ofast не используют, потому что он обеспечивает оптимизации, не соответствующие стандарту. -O3 этим не отличается. > В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности, Хотелось бы увидеть замеры хотя бы на тех же синтетических тестах. Когда-то давно, когда я сидел на Gentoo, я разницу очень даже чувствовал. > но значительно (относительно) увеличивают размер кода, что негативно сказывается на его > локальности в I$. Что такое I$? >> Если в LLVM использовался его хвалёный JIT > Херню сморозил. Не понимаю, поясните.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	44. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Аноним (??) on 03-Сен-15, 16:47
	>>> но почему тогда в тестах GCC не используют флаг -O3? >> По той же причине, по которой не используют -Ofast. -Ofast не используют, потому что он обеспечивает оптимизации, не соответствующие стандарту. Не всем и не всегда важно строгое соответствие IEEE 754. > -O3 этим не отличается. Ну. Так если он не приводит к нарушению IEEE 754, а его всё равно не используют — в этом что-то есть, не так ли? >> В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности, > Хотелось бы увидеть замеры хотя бы на тех же синтетических тестах. Замечательно. Возьмите хоть SPEC, хоть что хотите, сделайте замеры и поделитесь с нами результатами. > Когда-то давно, когда я сидел на Gentoo, я разницу очень даже чувствовал. У меня с gcc 4.9: % gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts % gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts % diff /tmp/O2-opts /tmp/O3-opts \| grep enabled > -fgcse-after-reload [enabled] > -finline-functions [enabled] > -fipa-cp-clone [enabled] > -fpredictive-commoning [enabled] > -ftree-loop-distribute-patterns [enabled] > -ftree-loop-vectorize [enabled] > -ftree-partial-pre [enabled] > -ftree-slp-vectorize [enabled] > -funswitch-loops [enabled] Половина из них копирует базовые блоки или циклы, увеличивая размер кода, так, что теоретический прирост производительности нивелируется возрастанием задержек на более частую перезагрузку линий кэша команд. Вторая половина — та, что относится к Graphite — в реальной жизни просто не работает. Не поймите меня неправильно, эти оптимизации не бесполезны — когда у вас есть одна или несколько однотипных машин, конфигурация которых не изменяется годами, и одна или несколько специализированных программ, выполняющих на этих машинах расчёты продолжительностью неделю-две на одном наборе данных. Тогда даже несколько процентов ускорения сыграют роль, а программы могут быть написаны таким образом, что они получат реальное ускорение от этих конкретных оптимизаций. Но это совершенно иррелевантно в случае вашей домашней машины с Gentoo и 700 установленными программами, наиболее используемые из которых — текстовый редактор, браузер, почтовый клиент — интерактивны, и большую часть времени простаивают на ожидании ввода-вывода. >> но значительно (относительно) увеличивают размер кода, что негативно сказывается на его >> локальности в I$. > Что такое I$? Instruction cache. >>> Если в LLVM использовался его хвалёный JIT >> Херню сморозил. > Не понимаю, поясните. LLVM одинаково хорошо (или одинаково плохо; главное — одинаково) позволяет строить на своей основе как JIT-, так и AOT-трансляторы. Когда LLVM используется для кодогенерации для Radeon в драйвере, он работает как JIT: драйвер непрерывно формирует поток команд, которые непрерывно транслируются LLVM в другой поток. Другой гипотетический пример: когда исполняется программа на JavaScript, транслятор непрерывно читает из буфера программный код (на JavaScript или байт-код, не суть), который должен исполниться прямо сейчас, и непрерывно транслирует его в машинный код (или загружает уже оттранслированный код из кэша, но это не важно). Ключевое слово — «непрерывное исполнение», и в этот процесс вовлечён транслятор. Когда LLVM используется фронтэндом Clang для трансляции кода на C или C++, он работает точно так же, как GCC: фронтэнд читает программу на ЯВУ и формирует промежуточное представление, которое затем понижается до машинного кода (записываемого компоновщиком в исполняемый файл), транслируется в другой ЯВУ — опять же, не суть. С выхода Clang (то есть, LLVM; то есть, компоновщика) вы получаете точно такой же исполняемый файл, как и с выхода GCC. Этот файл может быть скомпонован с libc, другими указанными вами библиотеками, но транслятор в его последующем исполнении никакого участия не принимает. Это ELF (или Mach-O, или COFF) с записанным в него машинным кодом.
	Ответить \| Правка \| ^ к родителю #39 \| Наверх \| Cообщить модератору


	55. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от freehck (ok) on 04-Сен-15, 11:37
	Спасибо, я не знал про эти особенности оптимизаций в GCC. Особенно про I$. (Кстати, почему именно такая аббревиатура для него?) С -O3 в генте, судя по всему, у меня были такие ощущения как раз потому, что я в то время занимался расчётами ГПВРД, а они могли идти сутками напролёт. Возможно, мне стоит пересмотреть ряд своих выводов по поводу оптимизаций. Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang. > Замечательно. Возьмите хоть SPEC, хоть что хотите, сделайте замеры и поделитесь с > нами результатами. Да, было бы неплохо. Но вопрос опять же упирается во время. Я никогда этим не занимался, и не знаю, как произвести корректное сравнение. На всякий случай хочу уточнить: SPEC - это вот это ли: https://www.spec.org/benchmarks.html > LLVM одинаково хорошо (или одинаково плохо; главное — одинаково) позволяет строить > на своей основе как JIT-, так и AOT-трансляторы. Нет, это-то само собой. Просто когда я читал описание LLVM, я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре. Понятное дело, что можно выполнить этот шаг и сразу при компиляции, но меня удивила нацеленность именно на перенесение AOT в runtime. Ибо JIT нужен в основном для кодогенерации в runtime, а не для того, чтобы процесс компиляции можно было остановить, достигнув только промежуточного представления.
	Ответить \| Правка \| ^ к родителю #44 \| Наверх \| Cообщить модератору


	56. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Аноним (??) on 05-Сен-15, 15:31
	> Особенно про I$. (Кстати, почему именно такая аббревиатура для него?) Это не единственная аббревиатура, просто одна из используемых. I - instruction, $ - cache. > Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang. Конечно. Каждый случай надо рассматривать индивидуально. возможно, пробовать разные параметры, иногда даже пытаться подогнать код, чтобы облегчить работу компилятору, если это возможно и оправданно. > SPEC - это вот это ли: https://www.spec.org/benchmarks.html Да. Это лишь пример. Если у вас есть своя важная задача, можете работать сразу с ней, это может быть полезнее. Иногда стоит и генерируемый в разный случаях код сравнить. > я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре Да нет никакой основной концепции. Это фреймворк, конструктор, позволяющий инженерам решать свои задачи удобным им способом. Clang, например, для компилятора C совершенно традиционен.
	Ответить \| Правка \| ^ к родителю #55 \| Наверх \| Cообщить модератору


	57. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Аноним (??) on 05-Сен-15, 15:39
	>Кстати, почему именно такая аббревиатура для него? IC? Слишком обширно. Integrated circuit, что ли? А тут "cache", $ - сразу сужает диапазон допустимых значений.
	Ответить \| Правка \| ^ к родителю #55 \| Наверх \| Cообщить модератору


	64. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Aleks Revo (ok) on 09-Сен-15, 22:56
	Современное положение дел таково, что там, где это полезно и не приводит к сбоям, пакеты итак собираются с опцией -O3, даже если в make.conf -O2 И наоборот, там, где это приводит к багам, даже при -O3 эти пакеты собираются с опцией -O2. Не могу сказать, что это касается всего дерева и любого пакета, но такое поведение встречается достаточно часто.
	Ответить \| Правка \| ^ к родителю #55 \| Наверх \| Cообщить модератору


	32. "Увидел свет набор компиляторов LLVM 3.7"	+2 +/–
	Сообщение от Анономс on 03-Сен-15, 08:25
	Да он выиграл только в тесте SciMark 2 разраб которого не любит GCC и через какое-то время перелапатил все для поддержки Clang со всеми воркераундами. Ну и разумеется тест скорости компиляции тоже за Clang - юзерам пофиг, а разрабы будут использовать только чтоб быстрее потестить, финальный билд все равно GCC.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	45. "Увидел свет набор компиляторов LLVM 3.7"	–2 +/–
	Сообщение от Alexey (??) on 03-Сен-15, 16:49
	Если все остальное время ты компилишь в Clang, то и финальный билд будет в Clang.
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	54. "Увидел свет набор компиляторов LLVM 3.7"	+/–
	Сообщение от Аноним (??) on 04-Сен-15, 10:51
	Финальный билд делают маинтейнеры дистрибутива, так что нет.
	Ответить \| Правка \| ^ к родителю #45 \| Наверх \| Cообщить модератору


	9. "Увидел свет набор компиляторов LLVM 3.7"	–12 +/–
	Сообщение от Школьник (ok) on 02-Сен-15, 11:49
	Судя по картинкам по ссылке, недалек уже тот момент, когда gcc натурально можно будет закапывать. Впрочем, ничего удивительного - когда идеология превозмогает над здравым смыслом и начинает диктовать свою волю при выборе инженерных решений, то результат немного предсказуем. В Китае это вовремя понял Дэн Сяопин, в СССР этого, увы, не поняли. Похоже, не понимает этого и Столлман со своей толпой преданных фанатиков, жадно ловящих каждое слово, выходящее из его рта. Ну да ничего, скоро уже поймут, что архитектура gcc, мягко говоря, не поощряющая его переиспользование и расширение, равно как и сомнительные игры с лицензией на gcc runtime обошлись слишком дорого.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	11. "Увидел свет набор компиляторов LLVM 3.7"	+1 +/–
	Сообщение от дядя on 02-Сен-15, 11:58
	иди учись школьник! gcc в любом случае не умрет, а модульную конструкцию из llvm действительно не грех перенять и переймут, не сумлевайся!
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	16. "Увидел свет набор компиляторов LLVM 3.7"	–7 +/–
	Сообщение от bOOster (ok) on 02-Сен-15, 12:32
	Аха, ну ситуация сродни Freeswitch против Астериска. Первый модульный и перспективный, второй древний и корявый. Второй держиться ТОЛЬКО на том что всякой документации гораздо больше находиться в инете чем первый. Станет наоборот - сдохнет тут-же.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору