Производительность LLVM библиотек

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

что за бред я прочитал

Go никакого отношения к llvm не имеет. Есть gccgo, который gcc и есть просто go, который собственный, притащенный с plan9.

Стоит ли придерживаться написанию своей программы на том яп, на котором написана необходимая крупная библиотека или просто забить на практически неразличимую потерю полимеров? Много ли попугаев при этом теряется?

2 раза перечитал, нихера не понял. Если либа написана на C++, например, и нет биндингов, то будет довольно проблематично писать на чем-то, кроме С++. А попугаю вполне могут «потерятся» при наличии кучи слоев абстракций.

Я ничего не понял.

Т.е. при наличии биндингов производительность та же. А то, что эти библиотеки подцеплены к тому же расту через LLVM - не повод для беспокойства?

Думается, тебе стоит почитать, что такое llvm :)))

Плохо реагирую на слово виртуальная машина) Вопрос решён, спим спокойно :)

через этот самый LLVM

Сильно ли замедляется работа из-за этой виртуальной машины?

Омайгадэбл! ТС, учи матчасть.

Сильно ли замедляется работа из-за этой виртуальной машины?

Если не углубляться в подробности, то LLVM (как «технология») позволяет гонять код как на виртуальной машине, так и заранее его компилировать в машинный код. Я поленился проверять, но 99,99% что в твоём случае это будет как раз машинный код.

Стоит ли придерживаться написанию своей программы на том яп, на котором написана необходимая крупная библиотека или просто забить на практически неразличимую потерю полимеров?

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

Сильно ли замедляется работа из-за этой виртуальной машины?

Зависит от того, какие ее фичи используются. Если используется оптимизатор и требуется быстрая компиляция, то можно вручную выбрать нужные пассы, чтобы работало быстро.

Еще одну лалку затралили буквами «VM» в названии «LLVM».

Особенно это касается новых языков go и rust.

второй да, а вот к первому официальный компилятор 6g/8g и полуофициальный gccgo — не на LLVM. но из экспериментальных на конференциях были доклады про какие-то свои велосипеды на LLVM, получались быстрее процентов на 10-30% от 6g какой-то версии (во время 1.2, ЕМНИП, так что всё мерять надо). хелловорд на последнем 6g официальном 1.4.2 весит 2Мб.

Сильно ли замедляется работа из-за этой виртуальной машины?

нет, т.к. эта виртуальная машина — LOW LEVEL (=LL в LLVM) и работает во время компиляции. то есть, это VM времени компиляции, поэтому собранный бинарник тем же растом VM не содержит, у него 0 зависимостей.

Стоит ли придерживаться написанию своей программы на том яп, на котором написана необходимая крупная библиотека или просто забить на практически неразличимую потерю полимеров?

штоа?

Много ли попугаев при этом теряется?

померяй.

Много ли попугаев при этом теряется?

Если именно в попугаях: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp