Представлен (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
Фороникс что-то давненько не выдавал нагора сравнения последних компиляторов.
Пускай выкладывают, кто-нибудь скажите форониксу об этом плиз.:)
Сам же сразу и ответил: Зашёл на фороникс, а там на тебе: http://www.phoronix.com/scan.php?page=article&item=clang-37-...
> Сам же сразу и ответил: Зашёл на фороникс, а там на тебе:
> http://www.phoronix.com/scan.php?page=article&item=clang-37-...В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc.
Слава разработчикам! Clang'у слава!
последнее это сарказм?
> последнее это сарказм?Нет, не более чем игра слов на больную тему.
> Нет, не более чем игра слов на больную тему.s/игра слов/тролинг/ "Честнее, Владимир, честнее." С собой в тч.
>В итогеВ итоге всё равно все используют GCC...
Что такое GCC? Google Closure Compiler?
https://gcc.gnu.org/
это который в тихую линкует статически либу под GPL v3 что вызывает автоматом смену лицензии на код в силу вирусности лицензии на библиотеку? или делай свой код под GPL v3 или не компилируй.
Дурачек не нужно тут бредить!
> это который в тихую линкует статически либу под GPL v3Сразу видно - грибной сезон начался :)
о статической линовке libgcc ты не знал? так учись пока не поздно..
> о статической линовке 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.
> В итоге всё равно все используют GCCИ? Зато гордые птицы-ежики из-за этого "пинка" со стороны llvmовцев, как минимум улучшили сообщения об ошибках. Так что, пусть и дальше не дают уж слишком расслабиться.
кто все? в os x, freebsd clang, да и в windows от тоже есть. А если вы про линукс ну так вы можите собирать пакеты и через Clang вам не запрещают. Хорошо когда есть выбор.
> В итоге, слушайте ну Clang очень успешно и динамично за столь короткий путь развития догнал (а в большинстве этих пусть и синтетических, но тестов даже перегнал) gcc.Скорость развития -- очень хорошая, и разработчики молодцы. Но всё же давайте подождём, когда LLVM будет поддерживать столь же широкий набор архитектур, что и GCC, и тогда уже будем сравнивать, кто быстрее развивается.
По тестам же: мне не понятно, с какими флагами оптимизации запускались те или иные тесты, а для сравнения это очень важно. Более того, использовалась ли статическая компиляция или же JIT?
Мало того, что сравнивать последнюю версию LLVM из SVN со стабильной версией GCC не совсем корректно (ну да ладно, продукт развивающийся, только растёт -- на это можно ещё закрыть глаза), но почему тогда в тестах GCC не используют флаг -O3? Раз уж сравнивать последние достижения, то с обеих сторон. Научные тесты со второй страницы в этой случае очень хочется проверить повторно с -O3.
Если в LLVM использовался его хвалёный JIT, то имеет ли смысл сравнение в скорости компиляции?
Я может конечно не разобрался в интерфейсе фороникса, и где-то про это всё-таки написано. Если так -- покажите, пожалуйста, где именно.
> но почему тогда в тестах GCC не используют флаг -O3?По той же причине, по которой не используют -Ofast. В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности, но значительно (относительно) увеличивают размер кода, что негативно сказывается на его локальности в I$. На практике, с GCC нет смысла использовать уровни выше -O2.
> Если в LLVM использовался его хвалёный JIT
Херню сморозил.
>> но почему тогда в тестах GCC не используют флаг -O3?
> По той же причине, по которой не используют -Ofast.-Ofast не используют, потому что он обеспечивает оптимизации, не соответствующие стандарту. -O3 этим не отличается.
> В GCC включаемые с -O3 оптимизации на практике редко дают сколько-нибудь существенный прирост производительности,
Хотелось бы увидеть замеры хотя бы на тех же синтетических тестах. Когда-то давно, когда я сидел на Gentoo, я разницу очень даже чувствовал.
> но значительно (относительно) увеличивают размер кода, что негативно сказывается на его
> локальности в I$.Что такое I$?
>> Если в LLVM использовался его хвалёный JIT
> Херню сморозил.Не понимаю, поясните.
>>> но почему тогда в тестах 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) с записанным в него машинным кодом.
Спасибо, я не знал про эти особенности оптимизаций в GCC. Особенно про I$. (Кстати, почему именно такая аббревиатура для него?)
С -O3 в генте, судя по всему, у меня были такие ощущения как раз потому, что я в то время занимался расчётами ГПВРД, а они могли идти сутками напролёт. Возможно, мне стоит пересмотреть ряд своих выводов по поводу оптимизаций. Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang.> Замечательно. Возьмите хоть SPEC, хоть что хотите, сделайте замеры и поделитесь с
> нами результатами.Да, было бы неплохо. Но вопрос опять же упирается во время. Я никогда этим не занимался, и не знаю, как произвести корректное сравнение.
На всякий случай хочу уточнить: SPEC - это вот это ли: https://www.spec.org/benchmarks.html> LLVM одинаково хорошо (или одинаково плохо; главное — одинаково) позволяет строить
> на своей основе как JIT-, так и AOT-трансляторы.Нет, это-то само собой. Просто когда я читал описание LLVM, я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре. Понятное дело, что можно выполнить этот шаг и сразу при компиляции, но меня удивила нацеленность именно на перенесение AOT в runtime. Ибо JIT нужен в основном для кодогенерации в runtime, а не для того, чтобы процесс компиляции можно было остановить, достигнув только промежуточного представления.
> Особенно про I$. (Кстати, почему именно такая аббревиатура для него?)Это не единственная аббревиатура, просто одна из используемых. I - instruction, $ - cache.
> Однако, в связи с этим, опять же было бы интересно посмотреть сравнение -O2 и -O3, даже в отрыве от Clang.
Конечно. Каждый случай надо рассматривать индивидуально. возможно, пробовать разные параметры, иногда даже пытаться подогнать код, чтобы облегчить работу компилятору, если это возможно и оправданно.
> SPEC - это вот это ли: https://www.spec.org/benchmarks.html
Да. Это лишь пример. Если у вас есть своя важная задача, можете работать сразу с ней, это может быть полезнее. Иногда стоит и генерируемый в разный случаях код сравнить.
> я так понял, что основная концепция его -- это распространения промежуточного представления кода для AOT-трансляции непосредственно в runtime на целевой архитектуре
Да нет никакой основной концепции. Это фреймворк, конструктор, позволяющий инженерам решать свои задачи удобным им способом. Clang, например, для компилятора C совершенно традиционен.
>Кстати, почему именно такая аббревиатура для него?IC? Слишком обширно. Integrated circuit, что ли? А тут "cache", $ - сразу сужает диапазон допустимых значений.
Современное положение дел таково, что там, где это полезно и не приводит к сбоям, пакеты итак собираются с опцией -O3, даже если в make.conf -O2И наоборот, там, где это приводит к багам, даже при -O3 эти пакеты собираются с опцией -O2.
Не могу сказать, что это касается всего дерева и любого пакета, но такое поведение встречается достаточно часто.
Да он выиграл только в тесте SciMark 2 разраб которого не любит GCC и через какое-то время перелапатил все для поддержки Clang со всеми воркераундами.
Ну и разумеется тест скорости компиляции тоже за Clang - юзерам пофиг, а разрабы будут использовать только чтоб быстрее потестить, финальный билд все равно GCC.
Если все остальное время ты компилишь в Clang, то и финальный билд будет в Clang.
Финальный билд делают маинтейнеры дистрибутива, так что нет.
Судя по картинкам по ссылке, недалек уже тот момент, когда gcc натурально можно будет закапывать. Впрочем, ничего удивительного - когда идеология превозмогает над здравым смыслом и начинает диктовать свою волю при выборе инженерных решений, то результат немного предсказуем. В Китае это вовремя понял Дэн Сяопин, в СССР этого, увы, не поняли. Похоже, не понимает этого и Столлман со своей толпой преданных фанатиков, жадно ловящих каждое слово, выходящее из его рта. Ну да ничего, скоро уже поймут, что архитектура gcc, мягко говоря, не поощряющая его переиспользование и расширение, равно как и сомнительные игры с лицензией на gcc runtime обошлись слишком дорого.
иди учись школьник! gcc в любом случае не умрет, а модульную конструкцию из llvm действительно не грех перенять и переймут, не сумлевайся!
Аха, ну ситуация сродни Freeswitch против Астериска. Первый модульный и перспективный, второй древний и корявый. Второй держиться ТОЛЬКО на том что всякой документации гораздо больше находиться в инете чем первый. Станет наоборот - сдохнет тут-же.
Ты дурачок, asterisk и freeswitch это перпендикулярные вещи. Это как холодильник vs стул.
> Это как холодильник vs стул.Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно, а вот холодить стулом не получится)!
> Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно,ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.
> ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.Только нублы и хомячки сидят на стульях -- эксперты опеннета выбирают диваны!
>> Дык – дураку понятно, что холодльник лучше (на/в нем сидеть можно,
> ИЧСХ, только дypaк и будет сидеть на холодильнике вместо стула.Да?? а на природе маленький холодильничек хорош, и сидишь на нем, и пиво достаешь… Хотя вам, голодранцам этого не понять...
Ну дурачки срази и отписались…
По факту - как ты "лошадь" не назови - ОНА РЕШАЕТ одну задачу.
А вертикально или перпендикулярно, да хоть в геометрической прогрессии, хотя че я мечу тут рис перед свиньями…. Один фиг безрезультатно...
Када я вырасту я стану самый-самый. Воть.
> недалек уже тот момент, когда gcc натурально можно будет закапыватьа зачем? чем плох выбор?
ну и просто - я вот не вижу поводов закапывать. в нём стала проприетарная лицензия? разбежалась команда? долго и интесивно косячат и не исправляют баги годами? нет. так что за повод закапывать? результаты тестов?
"на-гора" же
Rust забыли в список проектов включить.
от горе...
И D, не забудьте про D.
ldc в списке есть.
Roadsend PHP? С 2012 никаких коммитов
Что в этом clang хорошего? Вчера вышел C++ Builder новый, поставляющийся с этим компилятором по умолчанию, программы теперь медленней станут и толще? :) А плюсы есть какие-нибудь?
> Что в этом clang хорошего? Вчера вышел C++ Builder новый, поставляющийся с
> этим компилятором по умолчанию, программы теперь медленней станут и толще? :)
> А плюсы есть какие-нибудь?Как минимум два. Они прямо в названии и стоят "C++ Builder". :)
* Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
...
* PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;Вообще-то это один и тот же проект, он сменил своё название с первого на второе. Можно убедиться в этом здесь: https://github.com/pocl/pocl
Сейчас прибежит Столлман со своим gcc и будет хвалить LLVM
> Сейчас прибежит Столлман со своим gcc и будет хвалить LLVMЭто ты в каждой новости "бегаешь", как ужаленный, а rms уже http://lwn.net/Articles/582242/rss?format=printable похвалил.
А чего среди проектов на базе LLVM RUST не указан? один из самых интересных проектов и не упомянули в новости.
Потому что не нужен. Ваш Капитан ...
А этот недавний патч для увеличения производительности radeon интегрирован?
Apple с LLVM потихоньку наматывает яйца столмана на винт
ещё про наручники, кляпы и плёточки пофантазируй. Нравится как айфон вибрирует?
> Apple с LLVMВсе бы ничего, только эппл оттуда почти устранился и отдал руль гуглу.
> Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
> PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;Для танкистов?
>> Portable OpenCL - открытая
>> PoCL (Portable Computing Language OpenCL) - реализация
> Для танкистов?Для http:/openforum/vsluhforumID3/104546.html#17 вас, да.
Хорошая новость и обзор OpenCL,спасибо автору!Жаль пока не пропатчили LLVM для ускорения драйвера AMD/ATI...
> Жаль пока не пропатчили LLVM для ускорения драйвера AMD/ATI...Насчет ускорения: http://www.phoronix.com/scan.php?page=article&item=radeonsi-...
...оно уже втыкает каталисту в половине случаев!
Много булшита и ни звука про улучшения для бэкэнда AMDGPU. А между тем, LLVM 3.7 требуется для OpenGL 4.1 в новой MESA с RadeonSI.
Напиши на сайт amd.com глупец
А почему под Win подняли планку с XP до 7-ки? 7-ка же скоро заканчивается! Нужно сразу до 10-ки поднимать, так сказать, расширять поддерживаемые и популярные платформы :-D