forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Релиз набора компиляторов LLVM 4.0, opennews (??), 13-Мрт-17, (0) [смотреть все]

LLVM 8212 это хорошо А еще лучше будет, когда со шлангом можно генту собрать, Аноним (-), 22:16 , 13-Мрт-17, (1) +1 //

Зачем , Crazy Alex (ok), 22:48 , 13-Мрт-17, (6) +4 //

Надо , кельвин (?), 22:55 , 13-Мрт-17, (9) +3 //

кому , Нанобот (ok), 10:04 , 14-Мрт-17, (32)

Мне, Аноним (-), 18:03 , 21-Май-17, (66)

Собирай, я разрешаю Патчи добавишь в апстрим Потом займись поддержкой сборки i, Я. Р. Ош (?), 00:24 , 14-Мрт-17, (18) +9 //

icc и правда интереснее, когда сделаешь , Аноним (-), 19:00 , 14-Мрт-17, (58) –1

А что конкретно не собирается Костыли для GCC , Аноним (-), 07:04 , 14-Мрт-17, (22) //

ядро шлангом не собирается Оно рассчитано на несовместимое нестандартизированно, anonymous (??), 15:53 , 15-Мрт-17, (62)

И каким теперь образом узнать, где поломали API , Аноним (-), 22:24 , 13-Мрт-17, (2) +1 //

Раньше API ломали при смене второй цифры, теперь первой , Аноним (-), 22:28 , 13-Мрт-17, (3) +13

ну сделали нумерацию как у apple сейчас, с учетом того что пилят инженеры эпла м, Аноним (-), 22:39 , 13-Мрт-17, (4)
Повышены требования к минимальным версиям компиляторов Для сборки LLVM тепе, Аноним (-), 22:40 , 13-Мрт-17, (5) //

умеет clang 3 1 собирает , кельвин (?), 22:53 , 13-Мрт-17, (7)
Умеет Даже кросскомпиляцию самого себя умеет Но в большинстве случаев для бутс, angra (ok), 22:55 , 13-Мрт-17, (8) +2
на macOS и BSD не нужен gcc, для линукса жизненно необходимо как и часть систем, Сифилис (?), 23:45 , 13-Мрт-17, (17) //

Вы что-то путаете, гражданчик GCC только для ядра нужен, из-за его GCC специф, Аноним (-), 07:05 , 14-Мрт-17, (23) –1 //

да ты что для начала глянь, сколько софта у тебя с libstdc слинковано, а пото, qqq (??), 09:16 , 14-Мрт-17, (29)

При чём тут libstdc Это стандартная крестовая либа, да, она поставляется и со, Анончик (?), 09:38 , 14-Мрт-17, (30) –1

вот когда во всех дистрибутивах все и вся будет собирано шлангом, тогда и можно , qqq (??), 13:51 , 14-Мрт-17, (43) +1

Ну, пол года назад на генте не удалось скомпилировать clang ом только ядро, глиб, Мойша (??), 13:34 , 30-Мрт-17, (64)

В libcxx не нужен libstdc , Сифилис (?), 20:17 , 14-Мрт-17, (59)

xx - это уже четырежды плюс Новый язык , Аноним (-), 08:53 , 15-Мрт-17, (61)

зачем этот шланг нужен вообще Ресурсы процессора девать наверное сейчас некуда,, Аноним (10), 22:55 , 13-Мрт-17, (10) –16 //

Какая-такая прослойка , какие такты, какой эмулятор То, что вы описываете - эт, Аноним (-), 23:05 , 13-Мрт-17, (11) +7
ахахах - а в каких языках нежирные тогда - python java , leap42 (ok), 02:13 , 14-Мрт-17, (19) //

Pure C, Lua , Аноним (-), 07:06 , 14-Мрт-17, (24) //

Ты знаешь современный компилятор Pure C, который не использует промежуточного ко, Ordu (ok), 08:23 , 14-Мрт-17, (26) +1

Лучше не так, лучше спросить знает ли он компилятор Pure C что это такое - не по, жопка3 (?), 22:59 , 16-Мрт-17, (63)

Кто может объяснить, какой плюс от преобразования в машинные инструкции непосред, Штунц (?), 23:09 , 13-Мрт-17, (12) +4 //

Прежде всего - есть опция компилировать сразу в машинный код Преимуществом jit , Аноним (-), 23:22 , 13-Мрт-17, (13) +11 //

В случае LLVM байт-код не универсальный Это не аналог JVM и CLR хотя жаль , O01eg (?), 23:39 , 13-Мрт-17, (15) –3 //

Например , Аноним (-), 23:41 , 13-Мрт-17, (16) +1
Байткод LLVM как язык - кроссплатформенный Байткод конкретных приложений, генер, Аноним (-), 14:27 , 14-Мрт-17, (45) –2

Т е очень хорошо нацелен на решение задачи как бы пошире распространять бинар, anonymous (??), 04:13 , 14-Мрт-17, (20) //

Проприетарщина живет на паре-тройке аппаратных платформ, ей хватает Плюс мобиль, Вареник (?), 06:05 , 14-Мрт-17, (21) –2
Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми , Аноним (-), 08:02 , 14-Мрт-17, (25) +5

Write Once, Run Everywhere , Аноним (-), 10:37 , 14-Мрт-17, (33)
Все хорошо, заисключением одного момента - времени старта приложения, Аноним (-), 10:46 , 14-Мрт-17, (35)

Да, тут нужно найти баланс, взвесить за и против Для сложного приложения, котор, Аноним (-), 11:04 , 14-Мрт-17, (36) –1

Не забывайте, что биткод или байткод в память загрузится полностью и будет отъе, Аномсис (?), 11:40 , 14-Мрт-17, (38) +2

Я могу ошибаться по поводу LLVM, но нет никакой необходимости грузить в память в, Аноним (-), 12:16 , 14-Мрт-17, (40) –1

Возможно вы правы Я тоже не знаю полностью они грузятся или частями по мере необ, Аномсис (?), 12:33 , 14-Мрт-17, (41)

Я думал, нативный бинарник сначала ммапится в память по определённым смещениям, , Аноним (-), 14:08 , 14-Мрт-17, (44) –1

Оформить уже 769 докомпиляцию транслятор в инструкции местного CPU, назовит, PnDx (ok), 11:57 , 14-Мрт-17, (39) +1

АОТ В Андроиде внедрили, в основной Жабе пытаются внедрить LLVM позволяет пока, Вареник (?), 15:14 , 14-Мрт-17, (52) –1

Можно сделать по типу АОТ - только один раз при инсталляции на конкретную архите, Вареник (?), 15:12 , 14-Мрт-17, (51) –1
А разве LLVM сразу после окончания выполнения программы теряет уже скомпилирован, freehck (ok), 16:13 , 14-Мрт-17, (54)

JIT хуже оптимизирует, т к работает в реальном времени и должен производить опт, Аномсис (?), 11:23 , 14-Мрт-17, (37) +3

Зависит от уровня абстракции байткода от нативного В принципе, самые 171 жирн, Аноним (-), 14:42 , 14-Мрт-17, (47) +1
всё так, только про генту не надо - она вообще не о том, Crazy Alex (ok), 16:55 , 14-Мрт-17, (57)

Верно, но с небольшим уточнением Многие С либы, в частности, криптогроафическ, zfs (??), 15:42 , 14-Мрт-17, (53)
Ну, в большинстве случаев AOT не является проблемой для пользователя Чесслово, , freehck (ok), 16:29 , 14-Мрт-17, (55) +1
Для этого AOT нужен, а не JIT То есть оконяательная стадия компиляции на целево, Crazy Alex (ok), 16:53 , 14-Мрт-17, (56)

оптимизaция по sizeof L , L , L , хотя бы , fail_ (?), 23:33 , 13-Мрт-17, (14) –1
Никакого нет Даже наоборот Оптимизация на уровне абстрактной RISC-машины не ис, adolfus (ok), 14:47 , 14-Мрт-17, (48) –1

Собираешь программу, а бинарник получаетя нулевого размера, и понимаешь что-то в, Ноне (?), 08:54 , 14-Мрт-17, (27) +17 //

Не тем занимаешься в жизни, похоже , qsdg (ok), 09:06 , 14-Мрт-17, (28)
Так это же будет идеальная программа - ни одной ошибки , GlorySmith (?), 09:39 , 14-Мрт-17, (31) +2
Ваш код был рассмотрен, проверен и вынесен вердикт - идите на курсы программиров, Аноним (-), 10:46 , 14-Мрт-17, (34) +2 //

- Где у меня ошибка - В ДНК , Вареник (?), 15:06 , 14-Мрт-17, (49)

SystemD бы так собирать , Kodir (ok), 20:43 , 14-Мрт-17, (60) –2

репы 3,9 4,0 5,0 для деба бунтыhttp apt llvm org , Аноним (-), 13:25 , 14-Мрт-17, (42) –1
инвесторы любят большие числа, да , Аноним (-), 14:37 , 14-Мрт-17, (46) //

- График роста версий, уходящий в небеса , Вареник (?), 15:06 , 14-Мрт-17, (50)

LLVM 4 0 включен в базовую систему FreeBSD 11-STABLE , iZEN (ok), 09:53 , 03-Апр-17, (65)

Сообщения [Сортировка по времени | RSS]

12. "Релиз набора компиляторов LLVM 4.0" +4 +/–

Сообщение от Штунц (?), 13-Мрт-17, 23:09

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

Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз набора компиляторов LLVM 4.0" +11 +/–

Сообщение от Аноним (-), 13-Мрт-17, 23:22

> Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно
> в момент запуска? И так каждый раз, в каждый момент запуска.
> Зачем?
Прежде всего - есть опция компилировать сразу в машинный код. Преимуществом jit является по большому счету портируемость и всяческие оптимизации. Если есть сферический компилятор С(++), то он откомпилирует программу под конкретную архитектуру и даже под конкретную ее версию. Например, под i386. Этот код не запустится под ARM и не сможет использовать какие-то наборы инструкций, например, MMX, которые появились позже i386, но которые возможно имеются на компьютере пользователя. JIT, теоретически, может обеспечить подобное (не надо мне рассказывать, что написание кросс-платформенного кода сложнее hello world'a - это нетривиальная задача, я в курсе). Помимо этого JIT-компиляторы имеют множество метрик и профилировщиков, которые могут каким-то образом оптимизировать результат в зависимости от определенных условий.
В случае LLVM это еще и множество бэкэндов, т.е. список аппаратных архитектур, в которые можно транслировать байт-код. То есть, есть 2 независимых процесса -- генерация байт-кода из языка программирования и генерация нативного кода из байт-кода. И поскольку байт-код универсальный, это дает возможность создать комбинацию компилятора языка и архитектуры, для которой классического компилятора не существует.

Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз набора компиляторов LLVM 4.0" –3 +/–

Сообщение от O01eg (?), 13-Мрт-17, 23:39

В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).

Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз набора компиляторов LLVM 4.0" +1 +/–

Сообщение от Аноним (-), 13-Мрт-17, 23:41

>>В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).
Например?

Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз набора компиляторов LLVM 4.0" –2 +/–

Сообщение от Аноним (-), 14-Мрт-17, 14:27

Байткод LLVM как язык - кроссплатформенный. Байткод конкретных приложений, генерируемый Clang'ом - нет. Проблема тут в том, что код на C неизбежно привязывается к целевой платформе после того, как проходит стадию препроцессинга. И уже этот некроссплатформенный после-C компилируется в байткод.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

20. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от anonymous (??), 14-Мрт-17, 04:13

Т.е. очень хорошо нацелен на решение задачи
  "как бы пошире распространять бинарники, не отдавая исходники"

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

21. "Релиз набора компиляторов LLVM 4.0" –2 +/–

Сообщение от Вареник (?), 14-Мрт-17, 06:05

Проприетарщина живет на паре-тройке аппаратных платформ, ей хватает. Плюс мобильники, но там вполне без шланга решены вопросы распространения.

Ответить | Правка | Наверх | Cообщить модератору

25. "Релиз набора компиляторов LLVM 4.0" +5 +/–

Сообщение от Аноним (-), 14-Мрт-17, 08:02

>Т.е. очень хорошо нацелен на решение задачи
>"как бы пошире распространять бинарники, не отдавая исходники"
Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми исходниками в виде бинарников, кроме случаев типа Gentoo, которые как раз меньшинство. И когда собирают пакет, то его компилируют очень осторожно, образно говоря, чтобы он запустился и на 6 летнем Core2 Duo, и на свежем i7. Ни обладатели i7, ни обладатели свеженького AMD Ryzen ничего из их новых наборов команд использовать не смогут, т.к. выхлоп традиционного компилятора - это неизменный монолит, а вот JIT тут мог бы быть полезен. Это вряд ли мега-фича для большинства линукс-пакетов. Преимущества LLVM лежат больше в плоскости многообразия архитектур и языков программирования, ну и просто более свежий и чистый дизайн, который не имеет в себе 30 летнего наследия, как у GCC.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

33. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от Аноним (-), 14-Мрт-17, 10:37

Write Once, Run Everywhere!

Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от Аноним (-), 14-Мрт-17, 10:46

Все хорошо, заисключением одного момента - времени старта приложения

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

36. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от Аноним (-), 14-Мрт-17, 11:04

>Все хорошо, заисключением одного момента - времени старта приложения
Да, тут нужно найти баланс, взвесить за и против. Для сложного приложения, которое работает долго и получит преимущество, используя все аппаратные возможности ЦП, игра определенно стоит свеч - время старта несущественно на фоне времени работы.
Кстати, есть сценарии, когда JIT может сэкономить память - это жирные бинарники, содержащие в себе кучу кода. Допустим, запускается такой бинарник с определенными параметрами, это соответствует определенному графу выполнения программы. JIT компилирует код by demand - то есть не компилирует все сразу, а делает это по мере того, как требуется запускать все еще некомпилированный код. И если в данном сценарии требуется лишь маленький кусочек функциональности, то ровно на это кусочек увеличится memory footprint процесса. Полностью нативный бинарник будет загружен сразу же и полностью, даже если и 95% его не будет использована.

Ответить | Правка | Наверх | Cообщить модератору

38. "Релиз набора компиляторов LLVM 4.0" +2 +/–

Сообщение от Аномсис (?), 14-Мрт-17, 11:40

Не забывайте, что биткод(или байткод) в память загрузится полностью и будет отъедать её.
Плюс скомпилированные куски кода, что в сумме приведёт к большему потреблению памяти.
Ну и плюс ко всему этому -- память будет потреблять ещё виртуальная машина, которая будет осуществлять JIT компиляцию.

Ответить | Правка | Наверх | Cообщить модератору

40. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от Аноним (-), 14-Мрт-17, 12:16

>> Не забывайте, что биткод(или байткод) в память загрузится полностью и будет отъедать её.
Я могу ошибаться по поводу LLVM, но нет никакой необходимости грузить в память весь байткод. Это - всего лишь бинарные данные в файле, JIT их читает и аллоцирует память для результатов своей работы по мере продвижения. Это так даже в Windows, где раннер .net является частью загрузчика exe-файлов, которые можно запустить "дабл-кликом", без какого-либо внешнего раннера (как в java, например). Любой современный формат исполняемых файлов дает возможность создавать секции, которые вообще не будут спроцированы и загружены в адресное пространство процесса. Не говоря уже о бинарниках вроде джавовских.

Ответить | Правка | Наверх | Cообщить модератору

41. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от Аномсис (?), 14-Мрт-17, 12:33

Возможно вы правы.
Я тоже не знаю полностью они грузятся или частями по мере необходимости.
Конечно тут многое от виртуальной машины зависит.

Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от Аноним (-), 14-Мрт-17, 14:08

Я думал, нативный бинарник сначала ммапится в память по определённым смещениям, и лишь потом загружается в память физически постранично по мере надобности. Неиспользуемые страницы, если что, могут быть "сброшены" обратно на диск.
Может, вопрос больше в занимании памяти на диске этим разросшимся бинарником?

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

39. "Релиз набора компиляторов LLVM 4.0" +1 +/–

Сообщение от PnDx (ok), 14-Мрт-17, 11:57

Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше) в post-install пакета. Профит (для ≈10% софта, где есть чего ловить). Неужели ещё не докумекали до такого варианта?
Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

52. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от Вареник (?), 14-Мрт-17, 15:14

> Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше)
> в post-install пакета. Профит (для ≈10% софта, где есть чего ловить).
> Неужели ещё не докумекали до такого варианта?
> Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).
АОТ. В Андроиде внедрили, в основной Жабе пытаются внедрить.
LLVM позволяет (пока реально в пакетах никто не пользуется, как и JIT).

Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от Вареник (?), 14-Мрт-17, 15:12

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

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

54. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от freehck (ok), 14-Мрт-17, 16:13

> Все хорошо, заисключением одного момента - времени старта приложения
А разве LLVM сразу после окончания выполнения программы теряет уже скомпилированный нативный код? Насколько я помню описание LLVM, вроде ж сохранять должен.
Дисклеймер: LLVM не пользуюсь, только читал.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

37. "Релиз набора компиляторов LLVM 4.0" +3 +/–

Сообщение от Аномсис (?), 14-Мрт-17, 11:23

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

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

47. "Релиз набора компиляторов LLVM 4.0" +1 +/–

Сообщение от Аноним (-), 14-Мрт-17, 14:42

> JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию
>  быстро.
Зависит от уровня абстракции байткода от нативного. В принципе, самые «жирные» оптимизации как раз делаются еще до или при преобразовании в байт-код.
Да и не нужно валивать все в кучу и сравнивать с JIТами JaбкоСкрипта, Луа, Питона и т.д., где JITу действительно нужно в реальном времени скомпилировать «от и до».

Ответить | Правка | Наверх | Cообщить модератору

57. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от Crazy Alex (ok), 14-Мрт-17, 16:55

всё так, только про генту не надо - она вообще не о том

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

53. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от zfs (??), 14-Мрт-17, 15:42

> выхлоп традиционного компилятора - это неизменный монолит
Верно, но с небольшим уточнением. Многие С++ либы, в частности, криптогроафические пользуются такой фичей: https://gcc.gnu.org/wiki/FunctionMultiVersioning

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

55. "Релиз набора компиляторов LLVM 4.0" +1 +/–

Сообщение от freehck (ok), 14-Мрт-17, 16:29

> Открою сейчас тайну - большинство пользователей 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 лежат больше в плоскости многообразия архитектур и языков программирования
Поподробнее можно?

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

56. "Релиз набора компиляторов LLVM 4.0" +/–

Сообщение от Crazy Alex (ok), 14-Мрт-17, 16:53

Для этого AOT нужен, а не JIT. То есть оконяательная стадия компиляции на целевой машине - да, компиляция при каждом запуске - нет.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

14. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от fail_ (?), 13-Мрт-17, 23:33

оптимизaция по sizeof(L!, L@, L#), хотя бы ?!

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

48. "Релиз набора компиляторов LLVM 4.0" –1 +/–

Сообщение от adolfus (ok), 14-Мрт-17, 14:47

Никакого нет. Даже наоборот. Оптимизация на уровне абстрактной RISC-машины не исключает необходимости оптимизации для конкретной архитектуры, поскольку реальные архитектуры отличаются друг от друга более, чем существенно.
Парадигма LLVM позволяет быстро начать производить код для новых архитектур -- для этого достаточно написать эмулятор абстрактного RISC-процессора LLVM. Плюс здесь только один -- гибкость, а все остальное в минусах по самое горло. И среди этих минусов два очень важных -- время компиляции и качество оптимизации. С учетом того, что в процессе развития СВТ как памяти, так и производительности все более и более не хватает, с практической точки зрения парадигму LLVM нельзя считать хорошей.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

12. "Релиз набора компиляторов LLVM 4.0"	+4 +/–
Сообщение от Штунц (?), 13-Мрт-17, 23:09
Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно в момент запуска? И так каждый раз, в каждый момент запуска. Зачем?
Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Релиз набора компиляторов LLVM 4.0"	+11 +/–
	Сообщение от Аноним (-), 13-Мрт-17, 23:22
	> Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно > в момент запуска? И так каждый раз, в каждый момент запуска. > Зачем? Прежде всего - есть опция компилировать сразу в машинный код. Преимуществом jit является по большому счету портируемость и всяческие оптимизации. Если есть сферический компилятор С(++), то он откомпилирует программу под конкретную архитектуру и даже под конкретную ее версию. Например, под i386. Этот код не запустится под ARM и не сможет использовать какие-то наборы инструкций, например, MMX, которые появились позже i386, но которые возможно имеются на компьютере пользователя. JIT, теоретически, может обеспечить подобное (не надо мне рассказывать, что написание кросс-платформенного кода сложнее hello world'a - это нетривиальная задача, я в курсе). Помимо этого JIT-компиляторы имеют множество метрик и профилировщиков, которые могут каким-то образом оптимизировать результат в зависимости от определенных условий. В случае LLVM это еще и множество бэкэндов, т.е. список аппаратных архитектур, в которые можно транслировать байт-код. То есть, есть 2 независимых процесса -- генерация байт-кода из языка программирования и генерация нативного кода из байт-кода. И поскольку байт-код универсальный, это дает возможность создать комбинацию компилятора языка и архитектуры, для которой классического компилятора не существует.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Релиз набора компиляторов LLVM 4.0"	–3 +/–
	Сообщение от O01eg (?), 13-Мрт-17, 23:39
	В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Релиз набора компиляторов LLVM 4.0"	+1 +/–
	Сообщение от Аноним (-), 13-Мрт-17, 23:41
	>>В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль). Например?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Релиз набора компиляторов LLVM 4.0"	–2 +/–
	Сообщение от Аноним (-), 14-Мрт-17, 14:27
	Байткод LLVM как язык - кроссплатформенный. Байткод конкретных приложений, генерируемый Clang'ом - нет. Проблема тут в том, что код на C неизбежно привязывается к целевой платформе после того, как проходит стадию препроцессинга. И уже этот некроссплатформенный после-C компилируется в байткод.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	20. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от anonymous (??), 14-Мрт-17, 04:13
	Т.е. очень хорошо нацелен на решение задачи "как бы пошире распространять бинарники, не отдавая исходники"
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	21. "Релиз набора компиляторов LLVM 4.0"	–2 +/–
	Сообщение от Вареник (?), 14-Мрт-17, 06:05
	Проприетарщина живет на паре-тройке аппаратных платформ, ей хватает. Плюс мобильники, но там вполне без шланга решены вопросы распространения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Релиз набора компиляторов LLVM 4.0"	+5 +/–
	Сообщение от Аноним (-), 14-Мрт-17, 08:02
	>Т.е. очень хорошо нацелен на решение задачи >"как бы пошире распространять бинарники, не отдавая исходники" Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми исходниками в виде бинарников, кроме случаев типа Gentoo, которые как раз меньшинство. И когда собирают пакет, то его компилируют очень осторожно, образно говоря, чтобы он запустился и на 6 летнем Core2 Duo, и на свежем i7. Ни обладатели i7, ни обладатели свеженького AMD Ryzen ничего из их новых наборов команд использовать не смогут, т.к. выхлоп традиционного компилятора - это неизменный монолит, а вот JIT тут мог бы быть полезен. Это вряд ли мега-фича для большинства линукс-пакетов. Преимущества LLVM лежат больше в плоскости многообразия архитектур и языков программирования, ну и просто более свежий и чистый дизайн, который не имеет в себе 30 летнего наследия, как у GCC.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	33. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-17, 10:37
	Write Once, Run Everywhere!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от Аноним (-), 14-Мрт-17, 10:46
	Все хорошо, заисключением одного момента - времени старта приложения
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	36. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от Аноним (-), 14-Мрт-17, 11:04
	>Все хорошо, заисключением одного момента - времени старта приложения Да, тут нужно найти баланс, взвесить за и против. Для сложного приложения, которое работает долго и получит преимущество, используя все аппаратные возможности ЦП, игра определенно стоит свеч - время старта несущественно на фоне времени работы. Кстати, есть сценарии, когда JIT может сэкономить память - это жирные бинарники, содержащие в себе кучу кода. Допустим, запускается такой бинарник с определенными параметрами, это соответствует определенному графу выполнения программы. JIT компилирует код by demand - то есть не компилирует все сразу, а делает это по мере того, как требуется запускать все еще некомпилированный код. И если в данном сценарии требуется лишь маленький кусочек функциональности, то ровно на это кусочек увеличится memory footprint процесса. Полностью нативный бинарник будет загружен сразу же и полностью, даже если и 95% его не будет использована.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Релиз набора компиляторов LLVM 4.0"	+2 +/–
	Сообщение от Аномсис (?), 14-Мрт-17, 11:40
	Не забывайте, что биткод(или байткод) в память загрузится полностью и будет отъедать её. Плюс скомпилированные куски кода, что в сумме приведёт к большему потреблению памяти. Ну и плюс ко всему этому -- память будет потреблять ещё виртуальная машина, которая будет осуществлять JIT компиляцию.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от Аноним (-), 14-Мрт-17, 12:16
	>> Не забывайте, что биткод(или байткод) в память загрузится полностью и будет отъедать её. Я могу ошибаться по поводу LLVM, но нет никакой необходимости грузить в память весь байткод. Это - всего лишь бинарные данные в файле, JIT их читает и аллоцирует память для результатов своей работы по мере продвижения. Это так даже в Windows, где раннер .net является частью загрузчика exe-файлов, которые можно запустить "дабл-кликом", без какого-либо внешнего раннера (как в java, например). Любой современный формат исполняемых файлов дает возможность создавать секции, которые вообще не будут спроцированы и загружены в адресное пространство процесса. Не говоря уже о бинарниках вроде джавовских.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от Аномсис (?), 14-Мрт-17, 12:33
	Возможно вы правы. Я тоже не знаю полностью они грузятся или частями по мере необходимости. Конечно тут многое от виртуальной машины зависит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от Аноним (-), 14-Мрт-17, 14:08
	Я думал, нативный бинарник сначала ммапится в память по определённым смещениям, и лишь потом загружается в память физически постранично по мере надобности. Неиспользуемые страницы, если что, могут быть "сброшены" обратно на диск. Может, вопрос больше в занимании памяти на диске этим разросшимся бинарником?
	Ответить \| Правка \| К родителю #36 \| Наверх \| Cообщить модератору


	39. "Релиз набора компиляторов LLVM 4.0"	+1 +/–
	Сообщение от PnDx (ok), 14-Мрт-17, 11:57
	Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше) в post-install пакета. Профит (для ≈10% софта, где есть чего ловить). Неужели ещё не докумекали до такого варианта? Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	52. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от Вареник (?), 14-Мрт-17, 15:14
	> Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше) > в post-install пакета. Профит (для ≈10% софта, где есть чего ловить). > Неужели ещё не докумекали до такого варианта? > Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо). АОТ. В Андроиде внедрили, в основной Жабе пытаются внедрить. LLVM позволяет (пока реально в пакетах никто не пользуется, как и JIT).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от Вареник (?), 14-Мрт-17, 15:12
	> Все хорошо, заисключением одного момента - времени старта приложения Можно сделать по типу АОТ - только один раз при инсталляции на конкретную архитектуру. В этом смысле LLVM весьма гибкий.
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	54. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от freehck (ok), 14-Мрт-17, 16:13
	> Все хорошо, заисключением одного момента - времени старта приложения А разве LLVM сразу после окончания выполнения программы теряет уже скомпилированный нативный код? Насколько я помню описание LLVM, вроде ж сохранять должен. Дисклеймер: LLVM не пользуюсь, только читал.
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	37. "Релиз набора компиляторов LLVM 4.0"	+3 +/–
	Сообщение от Аномсис (?), 14-Мрт-17, 11:23
	JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию быстро. Но с LLVM можно полученный биткод запустить не только через JIT, а полноценно скомпилировать под свою архитектуру. При этом скорость компиляции должна быть намного быстрее, чем непосредственно из исходников, т.к. архитектурно-независимая оптимизация уже была проведена на этапе преобразования в биткод. И остаётся только архитектурно-зависимая оптимизация. Если бы появился дистрибутив, где пакеты распространялись бы в биткоде LLVM, то по скорости компиляции он был бы быстрее аналогичных действий в Gentoo, а по результату не хуже.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	47. "Релиз набора компиляторов LLVM 4.0"	+1 +/–
	Сообщение от Аноним (-), 14-Мрт-17, 14:42
	> JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию > быстро. Зависит от уровня абстракции байткода от нативного. В принципе, самые «жирные» оптимизации как раз делаются еще до или при преобразовании в байт-код. Да и не нужно валивать все в кучу и сравнивать с JIТами JaбкоСкрипта, Луа, Питона и т.д., где JITу действительно нужно в реальном времени скомпилировать «от и до».
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от Crazy Alex (ok), 14-Мрт-17, 16:55
	всё так, только про генту не надо - она вообще не о том
	Ответить \| Правка \| К родителю #37 \| Наверх \| Cообщить модератору


	53. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от zfs (??), 14-Мрт-17, 15:42
	> выхлоп традиционного компилятора - это неизменный монолит Верно, но с небольшим уточнением. Многие С++ либы, в частности, криптогроафические пользуются такой фичей: https://gcc.gnu.org/wiki/FunctionMultiVersioning
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	55. "Релиз набора компиляторов LLVM 4.0"	+1 +/–
	Сообщение от freehck (ok), 14-Мрт-17, 16:29
	> Открою сейчас тайну - большинство пользователей 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 лежат больше в плоскости многообразия архитектур и языков программирования Поподробнее можно?
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	56. "Релиз набора компиляторов LLVM 4.0"	+/–
	Сообщение от Crazy Alex (ok), 14-Мрт-17, 16:53
	Для этого AOT нужен, а не JIT. То есть оконяательная стадия компиляции на целевой машине - да, компиляция при каждом запуске - нет.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	14. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от fail_ (?), 13-Мрт-17, 23:33
	оптимизaция по sizeof(L!, L@, L#), хотя бы ?!
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	48. "Релиз набора компиляторов LLVM 4.0"	–1 +/–
	Сообщение от adolfus (ok), 14-Мрт-17, 14:47
	Никакого нет. Даже наоборот. Оптимизация на уровне абстрактной RISC-машины не исключает необходимости оптимизации для конкретной архитектуры, поскольку реальные архитектуры отличаются друг от друга более, чем существенно. Парадигма LLVM позволяет быстро начать производить код для новых архитектур -- для этого достаточно написать эмулятор абстрактного RISC-процессора LLVM. Плюс здесь только один -- гибкость, а все остальное в минусах по самое горло. И среди этих минусов два очень важных -- время компиляции и качество оптимизации. С учетом того, что в процессе развития СВТ как памяти, так и производительности все более и более не хватает, с практической точки зрения парадигму LLVM нельзя считать хорошей.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору