1.1, Аноним (-), 22:16, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
LLVM — это хорошо. А еще лучше будет, когда со шлангом можно генту собрать, полностью.
| |
|
2.18, Я. Р. Ош (?), 00:24, 14/03/2017 [^] [^^] [^^^] [ответить]
| +9 +/– |
Собирай, я разрешаю. Патчи добавишь в апстрим. Потом займись поддержкой сборки icc - поинтереснее будет.
| |
2.22, Аноним (-), 07:04, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А еще лучше будет, когда со шлангом можно генту собрать, полностью.
А что конкретно не собирается? Костыли для GCC?
| |
|
3.62, anonymous (??), 15:53, 15/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
ядро шлангом не собирается. Оно рассчитано на несовместимое нестандартизированное поведение gcc.
| |
|
|
|
2.3, Аноним (-), 22:28, 13/03/2017 [^] [^^] [^^^] [ответить]
| +13 +/– |
Раньше API ломали при смене второй цифры, теперь первой :)
| |
|
1.4, Аноним (-), 22:39, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ну сделали нумерацию как у apple сейчас, с учетом того что пилят инженеры эпла молодцом, сделали себе удобно.
| |
1.5, Аноним (-), 22:40, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"...Повышены требования к минимальным версиям компиляторов. Для сборки LLVM теперь необходимы как минимум GCC 4.8 ..."
Ого! а я-то думал он сам себя умеет собирать...
| |
|
2.8, angra (ok), 22:55, 13/03/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Умеет. Даже кросскомпиляцию самого себя умеет. Но в большинстве случаев для бутстрапа используется gcc.
| |
2.17, Сифилис (?), 23:45, 13/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
на macOS и *BSD не нужен gcc, для линукса жизненно необходимо как и часть системы.
| |
|
3.23, Аноним (-), 07:05, 14/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> жизненно необходимо как
> и часть системы.
Вы что-то путаете, гражданчик. GCC только для ядра нужен, из-за его (GCC) специфичных костылей.
| |
|
4.29, qqq (??), 09:16, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
да ты что? для начала глянь, сколько софта у тебя с libstdc++ слинковано, а потом уже чушь про "только для ядра" неси
| |
|
5.30, Анончик (?), 09:38, 14/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> да ты что? для начала глянь, сколько софта у тебя с libstdc++
> слинковано, а потом уже чушь про "только для ядра" неси
При чём тут libstdc++? Это стандартная крестовая либа, да, она поставляется и собирается вместе с GCC, но у LLVM тоже есть libc++, на которую вполне успешно переползла фряха и которую вроде как юзает макось.
Но это всё лирика, суть же в том, что GCC умеет в GNU-специфичные расширения и инструкции, которые не являются частью стандарта языка, плюс для определённых конструкций GCC генерирует определённый ассемблерный код. И вот на эти особенности компиляции и гнутые расширения и завязана часть экосистемы линукса, в том числе ядро, иксы, часть иксодров, glibc и т.п..
| |
|
6.43, qqq (??), 13:51, 14/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
вот когда во всех дистрибутивах все и вся будет собирано шлангом, тогда и можно будет говорить про "только ядро". а пока-что рановато
| |
|
7.64, Мойша (??), 13:34, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ну, пол года назад на генте не удалось скомпилировать clang'ом только ядро, глибцы и какие-то сетевые библиотеки, а также poppler(целью было скомпилировать полностью укомплектованную плазму со всеми kde-applications). Сейчас возможно даже лучше стало.
| |
|
|
|
6.61, Аноним (-), 08:53, 15/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> В libcxx++ не нужен libstdc++
xx++ - это уже четырежды плюс! Новый язык?
| |
|
|
|
|
|
1.10, Аноним (10), 22:55, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –16 +/– |
зачем этот шланг нужен вообще? Ресурсы процессора девать наверное сейчас некуда, мало жирных и тормозных описаний абстракций c++, так нужно ещё такты процессора забивать ненужной прослойкой эмулятора виртуального кода.
| |
|
2.11, Аноним (-), 23:05, 13/03/2017 [^] [^^] [^^^] [ответить]
| +7 +/– |
>зачем этот шланг нужен вообще? Ресурсы процессора девать наверное сейчас некуда, мало жирных и тормозных описаний абстракций c++, так нужно ещё такты процессора забивать ненужной прослойкой эмулятора виртуального кода.
Какая-такая "прослойка", какие такты, какой эмулятор? То, что вы описываете - это какой-то корявых интерпретатор. Даже в версии JIT нет никаких "эмуляторов", байт-код компилируется в момент запуска и после этого является самым обыкновенным нативным кодом. Не нравится JIT, можно откомпилировать сразу нативный бинарник, такой же самый, как сделает GCC.
| |
2.19, leap42 (ok), 02:13, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> жирных и тормозных описаний абстракций c++
ахахах - а в каких языках нежирные тогда - python? java?
| |
|
3.24, Аноним (-), 07:06, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
>>> жирных и тормозных описаний абстракций c++
> ахахах - а в каких языках нежирные тогда - python? java?
Pure C, Lua?
| |
|
4.26, Ordu (ok), 08:23, 14/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Pure C
Ты знаешь современный компилятор Pure C, который не использует промежуточного кода для компиляции и при этом не только под x86 умеет генерить код?
| |
|
5.63, жопка3 (?), 22:59, 16/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
Лучше не так, лучше спросить знает ли он компилятор Pure C(что это такое - не понятно), написанный не на C++ :)
| |
|
|
|
|
1.12, Штунц (?), 23:09, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно в момент запуска? И так каждый раз, в каждый момент запуска. Зачем?
| |
|
2.13, Аноним (-), 23:22, 13/03/2017 [^] [^^] [^^^] [ответить]
| +11 +/– |
> Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно
> в момент запуска? И так каждый раз, в каждый момент запуска.
> Зачем?
Прежде всего - есть опция компилировать сразу в машинный код. Преимуществом jit является по большому счету портируемость и всяческие оптимизации. Если есть сферический компилятор С(++), то он откомпилирует программу под конкретную архитектуру и даже под конкретную ее версию. Например, под i386. Этот код не запустится под ARM и не сможет использовать какие-то наборы инструкций, например, MMX, которые появились позже i386, но которые возможно имеются на компьютере пользователя. JIT, теоретически, может обеспечить подобное (не надо мне рассказывать, что написание кросс-платформенного кода сложнее hello world'a - это нетривиальная задача, я в курсе). Помимо этого JIT-компиляторы имеют множество метрик и профилировщиков, которые могут каким-то образом оптимизировать результат в зависимости от определенных условий.
В случае LLVM это еще и множество бэкэндов, т.е. список аппаратных архитектур, в которые можно транслировать байт-код. То есть, есть 2 независимых процесса -- генерация байт-кода из языка программирования и генерация нативного кода из байт-кода. И поскольку байт-код универсальный, это дает возможность создать комбинацию компилятора языка и архитектуры, для которой классического компилятора не существует.
| |
|
3.15, O01eg (?), 23:39, 13/03/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).
| |
|
4.16, Аноним (-), 23:41, 13/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).
Например?
| |
4.45, Аноним (-), 14:27, 14/03/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Байткод LLVM как язык - кроссплатформенный. Байткод конкретных приложений, генерируемый Clang'ом - нет. Проблема тут в том, что код на C неизбежно привязывается к целевой платформе после того, как проходит стадию препроцессинга. И уже этот некроссплатформенный после-C компилируется в байткод.
| |
|
3.20, anonymous (??), 04:13, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
Т.е. очень хорошо нацелен на решение задачи
"как бы пошире распространять бинарники, не отдавая исходники"
| |
|
4.21, Вареник (?), 06:05, 14/03/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Проприетарщина живет на паре-тройке аппаратных платформ, ей хватает. Плюс мобильники, но там вполне без шланга решены вопросы распространения.
| |
4.25, Аноним (-), 08:02, 14/03/2017 [^] [^^] [^^^] [ответить] | +5 +/– | Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми ... большой текст свёрнут, показать | |
|
5.35, Аноним (-), 10:46, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
Все хорошо, заисключением одного момента - времени старта приложения
| |
|
6.36, Аноним (-), 11:04, 14/03/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Да, тут нужно найти баланс, взвесить за и против Для сложного приложения, котор... большой текст свёрнут, показать | |
|
7.38, Аномсис (?), 11:40, 14/03/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Не забывайте, что биткод(или байткод) в память загрузится полностью и будет отъедать её.
Плюс скомпилированные куски кода, что в сумме приведёт к большему потреблению памяти.
Ну и плюс ко всему этому -- память будет потреблять ещё виртуальная машина, которая будет осуществлять JIT компиляцию.
| |
|
8.40, Аноним (-), 12:16, 14/03/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Я могу ошибаться по поводу LLVM, но нет никакой необходимости грузить в память в... текст свёрнут, показать | |
|
7.44, Аноним (-), 14:08, 14/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я думал, нативный бинарник сначала ммапится в память по определённым смещениям, и лишь потом загружается в память физически постранично по мере надобности. Неиспользуемые страницы, если что, могут быть "сброшены" обратно на диск.
Может, вопрос больше в занимании памяти на диске этим разросшимся бинарником?
| |
|
6.39, PnDx (ok), 11:57, 14/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше) в post-install пакета. Профит (для ≈10% софта, где есть чего ловить). Неужели ещё не докумекали до такого варианта?
Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).
| |
|
7.52, Вареник (?), 15:14, 14/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше)
> в post-install пакета. Профит (для ≈10% софта, где есть чего ловить).
> Неужели ещё не докумекали до такого варианта?
> Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).
АОТ. В Андроиде внедрили, в основной Жабе пытаются внедрить.
LLVM позволяет (пока реально в пакетах никто не пользуется, как и JIT).
| |
|
6.51, Вареник (?), 15:12, 14/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Все хорошо, заисключением одного момента - времени старта приложения
Можно сделать по типу АОТ - только один раз при инсталляции на конкретную архитектуру.
В этом смысле LLVM весьма гибкий.
| |
6.54, freehck (ok), 16:13, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Все хорошо, заисключением одного момента - времени старта приложения
А разве LLVM сразу после окончания выполнения программы теряет уже скомпилированный нативный код? Насколько я помню описание LLVM, вроде ж сохранять должен.
Дисклеймер: LLVM не пользуюсь, только читал.
| |
|
5.37, Аномсис (?), 11:23, 14/03/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию быстро.
Но с LLVM можно полученный биткод запустить не только через JIT, а полноценно скомпилировать под свою архитектуру.
При этом скорость компиляции должна быть намного быстрее, чем непосредственно из исходников, т.к. архитектурно-независимая оптимизация уже была проведена на этапе преобразования в биткод. И остаётся только архитектурно-зависимая оптимизация.
Если бы появился дистрибутив, где пакеты распространялись бы в биткоде LLVM, то по скорости компиляции он был бы быстрее аналогичных действий в Gentoo, а по результату не хуже.
| |
|
6.47, Аноним (-), 14:42, 14/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию
> быстро.
Зависит от уровня абстракции байткода от нативного. В принципе, самые «жирные» оптимизации как раз делаются еще до или при преобразовании в байт-код.
Да и не нужно валивать все в кучу и сравнивать с JIТами JaбкоСкрипта, Луа, Питона и т.д., где JITу действительно нужно в реальном времени скомпилировать «от и до».
| |
|
5.55, freehck (ok), 16:29, 14/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми исходниками
> в виде бинарников, кроме случаев типа Gentoo, которые как раз меньшинство.
> И когда собирают пакет, то его компилируют очень осторожно, образно говоря,
> чтобы он запустился и на 6 летнем Core2 Duo, и на
> свежем i7. Ни обладатели i7, ни обладатели свеженького AMD Ryzen ничего
> из их новых наборов команд использовать не смогут, т.к. выхлоп традиционного
> компилятора - это неизменный монолит, а вот JIT тут мог бы
> быть полезен.
Ну, в большинстве случаев AOT не является проблемой для пользователя. Чесслово, у меня i7 с 8ю потоками выполнения: я не сильно страдаю от того, что некоторые программы выполняются неоптимально. Критичные долгоработающие демоны можно и перекомпилировать, если что. Тут делов как бы не много: apt-get source, поправить флаги и pbuilder натравить. Но это, опять же, в исключительных случаях.
JIT, хоть и является весьма старой технологией, стал модным трендом относительно недавно.
В принципе, промежуточное представление компилируемой программы в байткоде есть и в GCC. Даже, если память не изменяет, их целых два: Generic и Gimple. После второго за дело берутся бэкенды, производящие компиляцию уже в конечную архитектуру.
В общем, идеи-то старые. Если бы они были действительно востребованы, в GCC их бы реализовали уже давно. Однако на деле, влияние JIT-а не сильно сказывается на работе.
Популярность LLVM во многом обусловлена пермиссивной лицензией. Именно поэтому корпорации активно вбухивают деньги в проекты для него.
> Преимущества LLVM лежат больше в плоскости многообразия архитектур и языков программирования
Поподробнее можно?
| |
5.56, Crazy Alex (ok), 16:53, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
Для этого AOT нужен, а не JIT. То есть оконяательная стадия компиляции на целевой машине - да, компиляция при каждом запуске - нет.
| |
|
|
|
2.48, adolfus (ok), 14:47, 14/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Никакого нет. Даже наоборот. Оптимизация на уровне абстрактной RISC-машины не исключает необходимости оптимизации для конкретной архитектуры, поскольку реальные архитектуры отличаются друг от друга более, чем существенно.
Парадигма LLVM позволяет быстро начать производить код для новых архитектур -- для этого достаточно написать эмулятор абстрактного RISC-процессора LLVM. Плюс здесь только один -- гибкость, а все остальное в минусах по самое горло. И среди этих минусов два очень важных -- время компиляции и качество оптимизации. С учетом того, что в процессе развития СВТ как памяти, так и производительности все более и более не хватает, с практической точки зрения парадигму LLVM нельзя считать хорошей.
| |
|
1.27, Ноне (?), 08:54, 14/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +17 +/– |
>более агрессивное устранение бесполезного кода
Собираешь программу, а бинарник получаетя нулевого размера, и понимаешь что-то в этой жизни пошло не так :)
| |
|
2.31, GlorySmith (?), 09:39, 14/03/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>>более агрессивное устранение бесполезного кода
> Собираешь программу, а бинарник получаетя нулевого размера, и понимаешь что-то в этой
> жизни пошло не так :)
Так это же будет идеальная программа - ни одной ошибки!
| |
2.34, Аноним (-), 10:46, 14/03/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ваш код был рассмотрен, проверен и вынесен вердикт - идите на курсы программирования в <здесь название школы, куда проприетарастский компилятор вас посылает оглядываясь на то какая школа заплатила за рекламу в вашем регионе>.
| |
|
|
2.50, Вареник (?), 15:06, 14/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> инвесторы любят большие числа, да.
- График роста версий, уходящий в небеса.
| |
|
|