LINUX.ORG.RU

Вышел LLVM 3.1

 


0

5

После 6 месяцев, прошедших с выпуска LLVM 3.0, представлен очередной релиз проекта LLVM 3.1. LLVM (Low Level Virtual Machine) — универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями. Может использоваться как оптимизирующий компилятор этого байткода в машинный код для различных архитектур либо для его интерпретации и JIT-компиляции (для некоторых платформ).

Некоторые изменения:

  • значительно расширена поддержка C++'11 в компиляторе Clang;
  • AddressSanitizer — инструмент для поиска ошибок работы с памятью, позволяющий обнаруживать типичные ошибки при программировании на Си и Си++, такие как выход за границы буфера и т.п.;
  • в генератор кода добавлена поддержка так называемых «связок инструкций», позволяющих значительно повысить качество генерируемого кода для архитектур процессоров VLIW;
  • улучшена работа MIPS и ARM бэкенда;
  • помимо основных функций, этот релиз включает в себя улучшение производительности, исправление ошибок и другие усовершенствования.

Напоминаю, что LLVM позволяет компилировать программы написанные на языках С, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end. В рамках проекта разработан фронтенд Clang для языков C и C++ и версия GCC, использующие llvm в качестве бэкенда. В Glasgow Haskell Compiler также реализована компиляция посредством llvm, существует ещё множество программ, использующих данную инфраструктуру.

>>> Подробности

★★★★★

Проверено: tazhate ()

оптимизирующий компилятор этого байткода в машинный код для различных архитектур либо для его интерпретации и JIT-компиляции

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

проект нужен только для того чтобы хоть как-то портировать программы между языками. пример: bullet (c++) => emscripten => ammo (js). производительность не ахти какая но работает. для простенькой физики с webgl хватает http://chandlerprall.github.com/Physijs/

punya ★★ ()

LLVM позволяет компилировать программы написанные на языках […] Python, Ruby, JavaScript

А где бы почитать, про компиляцию программ на скриптовых языках с помощью llvm? Нагуглить почему-то удаётся лишь всякую фигню: обёртки для апи и т.д.

Apple-ch ★★ ()
Ответ на: комментарий от punya

что только не придумают чтобы не выполнять полноценную оптимизацию в машинный код сразу

Код на языках программирования C и C++ невозможно оптимизировать сразу. Однопроходной компилятор-оптимизатор доступен только для паскалеподобных языков со строгой статической системой типов.

iZEN ★★★★★ ()

релиз включает в себя улучшение производительности

интересно посмотреть бенчмарки, надо будет похороникс поставить

wota ★★ ()

Посоны, а насколько годен llvm для явы? Если я например lorsource им скомпилю оно будет меньше потреблять оперативы или нет?

anonymous ()
Ответ на: комментарий от iZEN

со строгой статической системой типов

А что такое статическая система типов? Пример не-статической системы типов.

Kroz ★★★★★ ()

Python, Ruby, JavaScript

Какое-то лютое 4.2

Тем более LLVM не предоставляет вообще ничего, что помогло бы с разработкой рантайма динамического языка.

tensai_cirno ★★★★★ ()
Ответ на: комментарий от tensai_cirno

Тем более LLVM не предоставляет вообще ничего, что помогло бы с разработкой рантайма динамического языка.

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

sadov ()
Ответ на: комментарий от Kroz

А что такое статическая система типов? Пример не-статической системы типов.

Scheme, Python, Ruby и пр.

encyrtid ★★★★★ ()
Ответ на: комментарий от Kroz

А что такое статическая система типов?

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

iZEN ★★★★★ ()

Сейчас снова набегут угорелые фаны GCC и будут рассказывать, какой плохой и ущербный LLVM+Clang и какой хороший и полный GCC...

alex-w ★★★★★ ()
Ответ на: комментарий от alex-w

Да ты просто GPL ненавидишь на самом деле :}

Deleted ()
Ответ на: комментарий от O02eg

GPL то? Хорошее конечно. Кто же спорит :}

Deleted ()
Ответ на: комментарий от iZEN

Однопроходной компилятор-оптимизатор

зачем?

AVL2 ★★★★★ ()
Ответ на: комментарий от tensai_cirno

Тем более LLVM не предоставляет вообще ничего, что помогло бы с разработкой рантайма динамического языка.

ВМ, сборщик мусора?

AVL2 ★★★★★ ()

Напоминаю, что LLVM позволяет компилировать программы написанные на языках С, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end
Python, Ruby, JavaScript

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

pevzi ★★★★★ ()

[добавлю огня]
пилится также фронтенд для D, FreePascal
[/добавлю огня]

Atlant ★★★★★ ()
Ответ на: комментарий от AVL2

Вроде был проект под названием high level virtual machine, но благополучно сдох.

Gorthauer ★★★★★ ()
Ответ на: комментарий от iZEN

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

Так C/C++ такой и есть.
В таком случае фразы «Код на языках программирования C и C++ невозможно оптимизировать сразу.» и «Однопроходной компилятор-оптимизатор доступен только для паскалеподобных языков со строгой статической системой типов.» не стыкуются. Или я чего-то не понимаю?

Kroz ★★★★★ ()
Ответ на: комментарий от encyrtid

Scheme, Python, Ruby и пр.

Сорри, плохо знаком. PHP? JavaScript?

Kroz ★★★★★ ()
Ответ на: комментарий от AVL2

Это там далеко не самое важное. Вся соль в комплекте оптимизаций, которые там есть. Но это абсолютно всё заточено на статику. LLVM же представляет из себя абстрактный процессор с бесконечным количеством регистров.

tensai_cirno ★★★★★ ()
Ответ на: комментарий от punya

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

Может не всем нравится анальный секс?

Divius ★★ ()
Ответ на: комментарий от AVL2

ВМ, сборщик мусора?

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

Begemoth ★★★★★ ()
Ответ на: комментарий от Begemoth

Не угадал. Виртуальная машина IA-32

это что? gcc не предоставляет виртуальную машину.

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

это что? gcc не предоставляет виртуальную машину.

Это одна из основых его целевых архитектур.

Begemoth ★★★★★ ()
Ответ на: комментарий от iZEN

было исключительно сложно было прочитать мой камент двусмысленно но ты справился. я говорил: сразу - с точки зрения пользователя. gcc -march=native ... - я получаю не байткод на какую-то llvm а полноценный оптимизированный под мой процессор машинный код

llvm + jit компиляция = программа может оказаться быстрее только если машинный код ущербен. например дистрибутив бинарный x86_64 где все пакеты получены с использованием набора команд для x86_64 а у тебя процессор архитектуры бульдозер. sse4.2 не входит в x86_64 и машинный код не будет использовать это расширение а llvm будет если в программе заложена такая возможность. ниосиляторы генты закупились оперативкой, сговорились и хотят llvm. а я говорю - не нужно и ущербно

punya ★★ ()
Ответ на: комментарий от punya

не выполнять полноценную оптимизацию

Ты хоть одну книжку о компиляторах читал? Оптимизация на уровне промежуточного кода стандартная практика. Тотже gcc имеет внутренее промежуточное представление.

для того чтобы хоть как-то портировать программы между языками

Это-то как раз побочный эффект.

theos ★★★ ()
Ответ на: комментарий от Divius

что ты сказал - я вообще не понял. с точки зрения пользователя что llvm есть его нет - глазу не заметно. вопрос абсолютно в другом: пользователи не хотят слазить с теплого насиженного места - как правило производной дебиана и изучать генту но производительность их не устраивает. они хотят чтобы «оно что-то там себе оптимизировало и я никак в этом не участвовал». вот это и есть по-русски что такое llvm. это смешно и ущербно

punya ★★ ()
Ответ на: комментарий от Begemoth

ну а сборщика мусора в LLVM вообще нет.

Зато есть готовые решения для использования, так что это вроде и не проблема

Виртуальная машина IA-32 ничуть не хуже подходит

Не шлангуйте, сильно хуже. Все таки абстрактная виртуальная машина с бесконечным числом регистров != ia-32 где банально не все комбинации регистров можно использовать. Ну и портабельность, опять же.

Хотя да, по сравнению с CLR | JVM гораздо ниже уровнем.

theos ★★★ ()
Ответ на: комментарий от punya

с точки зрения пользователя что llvm есть его нет

А причем здесь пользователи? LLVM - внезапно, только для девелоперов интересен. А для девелоперов он предоставляет например, инструмент для анализа кода (да, не единственный в своем роде, но тем не менее.) И вообще одна из его задач была эффективная реализация OpenCL на процессоре. А при чем здесь дебиан или гента вообще не понятно.

вот это и есть по-русски что такое llvm

Да вы упороты.

theos ★★★ ()
Ответ на: комментарий от punya

Вы так говорите как будто clang не умеет -march -mcpu или асемблерных вставок. Или Вы не вполне поняли как работает clang и сейчас газифицируете лужу...

Да! Кстате! При gcc -march=native получается не один, а целая куча промежуточного байткода. Просто gcc его не показывает.

yurkis ()
Ответ на: комментарий от theos

llvm - байткод который выполняется эффективнее чем распространяемые бинарники собранные один раз и для всех. очевидно что llvm-байткодный дистрибутив ожидает нас

punya ★★ ()
Ответ на: комментарий от punya

очевидно что llvm-байткодный дистрибутив ожидает нас

Android?

Anonymous ★★★★★ ()
Ответ на: комментарий от yurkis

И...

целая куча промежуточного байткода. Просто gcc его не показывает.

... Вы его видите? Он Вам чем-то мешает?

anonymous ()

Ититский кот. То меня тут убедили, что LLVM не умеет нтерпретировать свой код, а тут пишут обратное! Что творится?

demmsnt ()
Ответ на: комментарий от iZEN

Ага...

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

А вот сейчас они (типы данных) так и скачут... Так и скачут... То int'ом, то float'ом прикидываются...

anonymous ()
Ответ на: комментарий от theos

Зато есть готовые решения для использования, так что это вроде и не проблема

Отдельные или в составе реализаций языков?

Все таки абстрактная виртуальная машина с бесконечным числом регистров

Да вот только большинство ВМ - стековые, а не регистровые.

Хотя да, по сравнению с CLR | JVM гораздо ниже уровнем.

О чём и речь.

Begemoth ★★★★★ ()
Ответ на: комментарий от punya

очевидно что llvm-байткодный дистрибутив ожидает нас

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

theos ★★★ ()
Ответ на: комментарий от Begemoth

Да вот только большинство ВМ - стековые, а не регистровые.

Трехадресные ВМ тоже вполне себе популярны. Тотже Dalvik. И вообще, какая разница?

Отдельные

Отдельные

theos ★★★ ()
Ответ на: комментарий от iZEN

А! Вот откуда началось...

Код на языках программирования C и C++ невозможно оптимизировать сразу. Однопроходной компилятор-оптимизатор доступен только для паскалеподобных языков со строгой статической системой типов.

А что здесь означает «сразу»? Тот же gcc состоит из front-end'а (синтаксический анализ) и back-end'а в виде RTL (Register Transfer Language). Именно на уровне RTL происходит оптимизация для конкретного процессора, на основании заданных правил.

На уровне запуска gcc и что там дальше оптимизация будет не сразу. На уровне RTL — сразу.

anonymous ()
Ответ на: комментарий от yurkis

вот то что вы сказали я ниразу не спорю. я указывал на понятное слово «native» которое указывает на применение всех фич моего процессора. взял gcc/clang - собрал бинарник для своей расширенной архитектуры. проблем 0. а тут начнуться проблемы типа «не компилится байткод». плевались на systemd за бинарные логи? llvm предоставляет вам новый уровень анального секаса!

punya ★★ ()
Ответ на: комментарий от Begemoth

Да вот только большинство ВМ - стековые, а не регистровые.

Parrot, dalvik, dis, nekoVM, luajit и многие другие — таки регистровые.
«Большинство ВМ» — не CLR/JVM всё-таки.

quantum-troll ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.