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

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

Отправлено opennews , 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.me/opennews/art.shtml?num=39959). Собранные BPF-сценарии могут быть загружены в ядро Linux при помощи системного вызова bpf(2) (http://www.opennet.me/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.me/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.me/opennews/art.shtml?num=31636) на создание Си-компилятора, способного собирать ядро Linux.

-  Portable OpenCL (http://www.opennet.me/opennews/art.shtml?num=32092) -  открытая и независимая реализация стандарта OpenCL;

-  CUDA Compiler (http://www.opennet.me/opennews/art.shtml?num=33800) - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;

-  Julia (http://www.opennet.me/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.me/opennews/art.shtml?num=42894


Содержание

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

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено G.NercY.uR , 02-Сен-15 10:43 
Сам же сразу и ответил: Зашёл на фороникс, а там на тебе: http://www.phoronix.com/scan.php?page=article&item=clang-37-...

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено G.NercY.uR , 02-Сен-15 10:49 
> Сам же сразу и ответил: Зашёл на фороникс, а там на тебе:
> http://www.phoronix.com/scan.php?page=article&item=clang-37-...

В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc.

Слава разработчикам! Clang'у слава!


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено AnotherReality , 02-Сен-15 11:31 
последнее это сарказм?

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено G.NercY.uR , 05-Сен-15 18:40 
> последнее это сарказм?

Нет, не более чем игра слов на больную тему.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Andrey Mitrofanov , 07-Сен-15 11:17 
> Нет, не более чем игра слов на больную тему.

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено A.Stahl , 02-Сен-15 11:42 
>В итоге

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 11:48 
Что такое GCC? Google Closure Compiler?

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено mine , 02-Сен-15 18:15 
https://gcc.gnu.org/

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 18:57 
это который в тихую линкует статически либу под GPL v3 что вызывает автоматом смену лицензии на код в силу вирусности лицензии на библиотеку? или делай свой код под GPL v3 или не компилируй.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 23:03 
Дурачек не нужно тут бредить!

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 17:57 
> это который в тихую линкует статически либу под GPL v3

Сразу видно - грибной сезон начался :)


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 06-Сен-15 08:42 
о статической линовке libgcc ты не знал? так учись пока не поздно..

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Andrey Mitrofanov , 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.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 16:11 
> В итоге всё равно все используют GCC

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 20:07 
кто все? в os x, freebsd clang, да и в windows от тоже есть. А если вы про линукс ну так вы можите собирать пакеты и через Clang вам не запрещают. Хорошо когда есть выбор.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено freehck , 02-Сен-15 12:05 
> В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc.

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

По тестам же: мне не понятно, с какими флагами оптимизации запускались те или иные тесты, а для сравнения это очень важно. Более того, использовалась ли статическая компиляция или же JIT?

Мало того, что сравнивать последнюю версию LLVM из SVN со стабильной версией GCC не совсем корректно (ну да ладно, продукт развивающийся, только растёт -- на это можно ещё закрыть глаза), но почему тогда в тестах GCC не используют флаг -O3? Раз уж сравнивать последние достижения, то с обеих сторон. Научные тесты со второй страницы в этой случае очень хочется проверить повторно с -O3.

Если в LLVM использовался его хвалёный JIT, то имеет ли смысл сравнение в скорости компиляции?

Я может конечно не разобрался в интерфейсе фороникса, и где-то про это всё-таки написано. Если так -- покажите, пожалуйста, где именно.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 16:28 
> но почему тогда в тестах GCC не используют флаг -O3?

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

> Если в LLVM использовался его хвалёный JIT

Херню сморозил.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено freehck , 03-Сен-15 12:54 
>> но почему тогда в тестах GCC не используют флаг -O3?
> По той же причине, по которой не используют -Ofast.

-Ofast не используют, потому что он обеспечивает оптимизации, не соответствующие стандарту. -O3 этим не отличается.

> В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности,

Хотелось бы увидеть замеры хотя бы на тех же синтетических тестах. Когда-то давно, когда я сидел на Gentoo, я разницу очень даже чувствовал.

> но значительно (относительно) увеличивают размер кода, что негативно сказывается на его
> локальности в I$.

Что такое I$?

>> Если в LLVM использовался его хвалёный JIT
> Херню сморозил.

Не понимаю, поясните.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 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) с записанным в него машинным кодом.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено freehck , 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, а не для того, чтобы процесс компиляции можно было остановить, достигнув только промежуточного представления.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 05-Сен-15 15:31 
> Особенно про I$. (Кстати, почему именно такая аббревиатура для него?)

Это не единственная аббревиатура, просто одна из используемых. I - instruction, $ - cache.

> Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang.

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

> SPEC - это вот это ли: https://www.spec.org/benchmarks.html

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

> я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре

Да нет никакой основной концепции. Это фреймворк, конструктор, позволяющий инженерам решать свои задачи удобным им способом. Clang, например, для компилятора C совершенно традиционен.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 05-Сен-15 15:39 
>Кстати, почему именно такая аббревиатура для него?

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Aleks Revo , 09-Сен-15 22:56 
Современное положение дел таково, что там, где это полезно и не приводит к сбоям, пакеты итак собираются с опцией -O3, даже если в make.conf -O2

И наоборот, там, где это приводит к багам, даже при -O3 эти пакеты собираются с опцией -O2.

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Анономс , 03-Сен-15 08:25 
Да он выиграл только в тесте SciMark 2 разраб которого не любит GCC и через какое-то время перелапатил все для поддержки Clang со всеми воркераундами.
Ну и разумеется тест скорости компиляции тоже за Clang - юзерам пофиг, а разрабы будут использовать только чтоб быстрее потестить, финальный билд все равно GCC.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Alexey , 03-Сен-15 16:49 
Если все остальное время ты компилишь в Clang, то и финальный билд будет в Clang.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 04-Сен-15 10:51 
Финальный билд делают маинтейнеры дистрибутива, так что нет.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Школьник , 02-Сен-15 11:49 
Судя по картинкам по ссылке, недалек уже тот момент, когда gcc натурально можно будет закапывать. Впрочем, ничего удивительного - когда идеология превозмогает над здравым смыслом и начинает диктовать свою волю при выборе инженерных решений, то результат немного предсказуем. В Китае это вовремя понял Дэн Сяопин, в СССР этого, увы, не поняли. Похоже, не понимает этого и Столлман со своей толпой преданных фанатиков, жадно ловящих каждое слово, выходящее из его рта. Ну да ничего, скоро уже поймут, что архитектура gcc, мягко говоря, не поощряющая его переиспользование и расширение, равно как и сомнительные игры с лицензией на gcc runtime обошлись слишком дорого.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено дядя , 02-Сен-15 11:58 
иди учись школьник! gcc в любом случае не умрет, а модульную конструкцию из llvm действительно не грех перенять и переймут, не сумлевайся!

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

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Анонимус Сапиенс , 03-Сен-15 15:07 
Ты дурачок, asterisk и freeswitch это перпендикулярные вещи. Это как холодильник vs стул.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 15:36 
> Это как холодильник vs стул.

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 17:55 
> Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно,

ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.



"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 18:08 
> ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.

Только нублы и хомячки сидят на стульях -- эксперты опеннета выбирают диваны!



"Увидел свет набор компиляторов LLVM 3.7"
Отправлено bOOster , 05-Сен-15 17:02 
>> Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно,
> ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.

Да?? а на природе маленький холодильничек хорош, и сидишь на нем, и пиво достаешь… Хотя вам, голодранцам этого не понять...


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено bOOster , 05-Сен-15 16:53 
Ну дурачки срази и отписались…
По факту - как ты "лошадь" не назови - ОНА РЕШАЕТ одну задачу.
А вертикально или перпендикулярно, да хоть в геометрической прогрессии, хотя че я мечу тут рис перед свиньями…. Один фиг безрезультатно...

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено mine , 02-Сен-15 18:31 
Када я вырасту я стану самый-самый. Воть.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Клыкастый , 03-Сен-15 12:18 
> недалек уже тот момент, когда gcc натурально можно будет закапывать

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено GrammarNarziss , 03-Сен-15 12:05 
"на-гора" же

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено nc , 02-Сен-15 11:00 
Rust забыли в список проектов включить.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Нанобот , 02-Сен-15 16:46 
от горе...

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 07:54 
И D, не забудьте про D.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено nc , 03-Сен-15 10:03 
ldc в списке есть.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено дядя , 02-Сен-15 11:40 
Roadsend PHP? С 2012 никаких коммитов

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

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено freehck , 02-Сен-15 12:09 
> Что в этом clang хорошего? Вчера вышел C++ Builder новый, поставляющийся с
> этим компилятором по умолчанию, программы теперь медленней станут и толще? :)
> А плюсы есть какие-нибудь?

Как минимум два. Они прямо в названии и стоят "C++ Builder". :)


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Nuzhny , 02-Сен-15 12:46 
* Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
...
* PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;

Вообще-то это один и тот же проект, он сменил своё название с первого на второе. Можно убедиться в этом здесь: https://github.com/pocl/pocl


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 16:24 
Сейчас прибежит Столлман со своим gcc и будет хвалить LLVM

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Andrey Mitrofanov , 03-Сен-15 10:15 
> Сейчас прибежит Столлман со своим gcc и будет хвалить LLVM

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 21:09 
А чего среди проектов на базе LLVM  RUST не указан? один из самых интересных проектов и не упомянули в новости.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 04:17 
Потому что не нужен. Ваш Капитан ...

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено дон Педро , 02-Сен-15 23:12 
А этот недавний патч для увеличения производительности radeon интегрирован?

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 02-Сен-15 23:46 
Apple с LLVM потихоньку наматывает яйца столмана на винт

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 11:02 
ещё про наручники, кляпы и плёточки пофантазируй. Нравится как айфон вибрирует?

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

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


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено анонимус вульгарис , 03-Сен-15 12:47 
> Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
> PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;

Для танкистов?


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Andrey Mitrofanov , 03-Сен-15 14:22 
>> Portable OpenCL - открытая
>> PoCL (Portable Computing Language OpenCL) - реализация
> Для танкистов?

Для http:/openforum/vsluhforumID3/104546.html#17 вас, да.


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 15:56 
Хорошая новость и обзор OpenCL,спасибо автору!

Жаль пока не пропатчили LLVM для ускорения драйвера AMD/ATI...


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 17:53 
> Жаль пока не пропатчили LLVM для ускорения драйвера AMD/ATI...

Насчет ускорения: http://www.phoronix.com/scan.php?page=article&item=radeonsi-...

...оно уже втыкает каталисту в половине случаев!


"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 17:52 
Много булшита и ни звука про улучшения для бэкэнда AMDGPU. А между тем, LLVM 3.7 требуется для OpenGL 4.1 в новой MESA с RadeonSI.

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 03-Сен-15 19:28 
Напиши на сайт amd.com глупец

"Увидел свет набор компиляторов LLVM 3.7"
Отправлено Аноним , 04-Сен-15 10:46 
А почему под Win подняли планку с XP до 7-ки? 7-ка же скоро заканчивается! Нужно сразу до 10-ки поднимать, так сказать, расширять поддерживаемые и популярные платформы :-D