Разница — в двух буквах L. Скомпилировать JVM-байткод в оптимизированный нативный код сложно, gcj тому хороший пример, а скомпилировать байткод LLVM (и проводить с ним различные операции) легко.

GCJ может компилировать JVM-байткод в нативный код, но получается слишком жирно.

А за счет чего это достигается? Где можно почитать о технической стороне вопроса?

На правах дилетанта.

1. Если я не ошибаюсь, то промежуточный код в LLVM не крутится в какой-то сферической машине. Производится его оптимизация, после чего выбранный бэк-энд выдаёт нативный код.

2. Архитектура, позволяющая относительно просто задействовать фрон-энд и бэк-энд для новых языков, и соответственно платформ. От сюда и большое разнообразие фронт-эндов. Хз почему бэк-эндов мало :) При чём бэк-энд, как показывает emscripten, может выдавать не нативный код для платформы, а более высокоуровневый.

В итоге весьма годная и интересная вещь. На линупсоидов, брызжущих слюной и закапывающих clang и llvm только из-за попугаев, смотрю с недоумением.

В Dr.Dobbs была интересная статья. Гугли The Design of LLVM

Если объяснять немного упрощенно, то в чем качественная разница между JVM и LLVM, универсальное представление байт-кода?!

Если упрощенно, то JVM - это виртуальная машина, а LLVM - это компилятор (да, несмотря на название).

То есть llvm выдает в некотором смысле мета код.

Спасибо, ситуация проясняется.

Если быть точным - компилятор это llvm-backend?

Если быть точным - компилятор это llvm-backend?

Нет. llvm-backend - это вообще абстрактное понятие, их много.

Судя по упомянутой статье одним из преимуществ сабжа является унифицированный процесс оптимизации.

унифицированный процесс оптимизации.

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

Вопрос кто всем более/менее в теме: нет ли проекта(дистрибутива или вообще), в котором бы пакеты(программы, библиотеки) предоставлялись в виде байт-кода LLVM и компилировались бы при установке или при вызове/загрузке(ога, .NET)

нет ли проекта(дистрибутива или вообще), в котором бы пакеты(программы, библиотеки) предоставлялись в виде байт-кода LLVM и компилировались бы при установке или при вызове/загрузке(ога, .NET)

Не совсем код LLVM, но близко к нему: http://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html

Ничего инновационного, ЛЛВМ - исследовательский проект компиляторщиков, для компиляторщиков.

Никакой принципиально новой поддержки железа в ЛЛВМ нет. Ни Итаниума, ни видяшек (опенЦЛ, КУДА) - на нём ничего не растёт (пока что, хотя есть утописты). Ни даже какой-нибудь интересной поддержки популярного железа - АМД Оптерон хотя бы, не имеется.

Ни Итаниума, ни видяшек (опенЦЛ, КУДА) - на нём ничего не растёт

Лолшто.

Буду краток

r600

Мне не известно чтобы распространялись приложения в виде байткодов LLVM.

Потому разница в том, что JVM считает что оптимизировать нужно на целевой машине, а LLVM - на машине компиляции

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

смежный (и глупый) вопрос: а есть ли способ сконвертировать JavaScript код в C?

Были попытки поднять ВЛИВ. Я же не говорил, что не было. Утопист один этим занимался, всё работало только на его железе. Пришлось делать свою версию Мезы. Галлиум-компьют вообще так и не взлетел, сколько ни обещали. Ну то есть, то, что взлетело - лучше бы оно вообще никуда не взлетало.

Главная причина в том. Что ЛЛВМ - по сути провальный проект с точки зрения компиляторостроения. Да, какие-то АРМисты смогли что-то себе наклепать из этого. Чего раньше не было по причине бомжеватости АРМа как платформы.

Был проект Итаниума на ЛЛВМ - закрылся.

есть ли способ сконвертировать JavaScript код в C?

Ну, если нужен не просто Си, а эффективный Си - мне такой способ неизвестен. asm.js тривиально (хи-хи) конвертируется в машкод, так что наверняка его можно сконвертировать и в Си. Но для JavaScript «вообще» это вряд ли возможно, если вспомнить, какие трюки «под капотом» у JIT-компиляторов.

Ни Итаниума, ни видяшек (опенЦЛ, КУДА) - на нём ничего не растёт

Лолшто.

Был проект Итаниума на ЛЛВМ - закрылся.

Компиляторы CUDA и OpenCL от Nvidia основаны на LLVM, компилятор OpenCL от AMD - тоже, компилятор OpenCL в Mesa пилят тоже на LLVM. Но всегда найдутся знатоки, у которых «ничего не растёт».

Так можно тоже выискать две строчки и сказать, что ХЛ2 движок основан на первой кваке.

Кстати, видно по говеной производительности видяшных прог, что прошелся чей-то первобытный напильник. Конечно, еще сами по себе ОпенЦЛ и КУДА - говнище. Быстрое преобразование Фурье сливает любому достойному камню. А вообще-то именно на ФФТ должна светиться параллельностью вся эта архитектура видяшная.

Компиляторы CUDA и OpenCL от Nvidia основаны на LLVM, компилятор OpenCL от AMD - тоже, компилятор OpenCL в Mesa пилят тоже на LLVM. Но всегда найдутся знатоки, у которых «ничего не растёт».

Так можно тоже выискать две строчки и сказать, что ХЛ2 движок основан на первой кваке.

/me молча пожал плечами и добавил метку к нику.

Компиляторы CUDA и OpenCL от Nvidia основаны на LLVM, компилятор OpenCL от AMD - тоже, компилятор OpenCL в Mesa пилят тоже на LLVM.

Верно! Ещё от себя добавлю компиляторы Cray. Вопрос, почему?

А ответ простой и совсем не технический. BSD license.

:)

1. Различий много. Основное — байткод JVM очень высокоуровневый и очень сильно заточен под Java, по этой причине все остальные языки на JVM вынуждены следовать той же модели, что и Java, и даже родственный Java C# не может быть без черезжопных извращений портирован на JVM (обратное (Java => CLR), однако, возможно, и сделано). Биткод LLVM — наоборот, как можно более низкоуровневый (практически кроссплатформенный ассемблер, универсальное промежуточное представлениее). А еще JVM — стек-машина, а LLVM — регистровая машина, SSA (Static Single Assignment, представление, очень удобное для реализации многих оптимизаций). JVM-байткод рассчитан исключительно на запуск с рантаймом JVM, LLVM же рассчитана на генерацию нативного кода, в том числе, способного работать без жирного рантайма.

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

2. Ах да, и если бы не LLVM, таких штук, как emscripten, никогда не было бы.

(facepalm mega palm-through-head)

Благодарю за развернутый ответ.

Быстрое преобразование Фурье сливает любому достойному камню

Насмешил, содомит. Ты вообще в вопросе разбираешься?

// Хотя после твоего «in place of @AMD i would seriously drop branch units, and sacrifice caches to FPU and cache streaming units in opterons», я уже ничему не удивляюсь.

А ответ простой и совсем не технический. BSD license.

Это ответ на вопрос «почему эти компиляторы закрытые» %)

закапывающих clang и llvm только из-за попугаев

???