forum.opennet.ru - "Red Hat развивает JIT-компилятор MIR" (139)

"Red Hat развивает JIT-компилятор MIR"

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

"Red Hat развивает JIT-компилятор MIR"	+/–
Сообщение от opennews (??), 21-Янв-20, 09:51
В компании Rad Hat ведётся разработка нового легковесного JIT-компилятора MIR, обеспечивающего выполнение кода, предварительно преобразованного в промежуточное представление MIR (Medium Internal Representation, не путать с другим промежуточным представлением MIR (mid-level IR), применяемым в компиляторе Rust). Проект нацелен на предоставление основы для реализации быстрых и компактных интерпретаторов и JIT. Код проекта написан на языке Си и распространяется под лицензией MIT... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52223
Ответить \| Правка \| Cообщить модератору

Оглавление

Может всё-таки JIR , Аноним (1), 09:51 , 21-Янв-20, (1) +19

jinr , РэдХэд (?), 14:16 , 21-Янв-20, (47) +1

Бинарник собранный gcc 25 мегабайт Что там Эти тоже забыли стрипнуть , Аноним (2), 09:55 , 21-Янв-20, (2) +4

Это размер КОДА самого компилятора, Имя (?), 11:11 , 21-Янв-20, (20) +4

LLVM посчитать забыли, там гигабайт 20 , Аноним (2), 11:13 , 21-Янв-20, (21) +2

А точно не 100500 https packages debian org jessie libllvm3 5, Аноним84701 (ok), 13:46 , 21-Янв-20, (43) –1
Как это Пакет с либой весит 7 мегов , Аноним (-), 14:27 , 21-Янв-20, (53) –1

Для начала необходимо выяснить, что именно они имели в виду Если это зависимост, Аноним (2), 14:42 , 21-Янв-20, (65) –2

да какая разница, если статичная линковка, то это очень круто, Аноним (23), 11:27 , 21-Янв-20, (23)

Очередная перепись нечитавших новость сс1 правда ни разу не статистически слинк, Аноним84701 (ok), 14:47 , 21-Янв-20, (66) +2

Тут уже предлагают libllvm сравнивать Давайте тогда libcc1 считать вместо этого, Аноним (2), 15:02 , 21-Янв-20, (74)

Кто и с чем предалагает Те, кому для сборки LLVM нужны десятки гигабайт , могут, Аноним84701 (ok), 15:15 , 21-Янв-20, (75) +1

Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт Приход, Аноним (2), 15:18 , 21-Янв-20, (76)

Ну например вот это вот из недавнего самосбора кастом с clang, lld-gold, без, Аноним84701 (ok), 15:39 , 21-Янв-20, (78)

А что такое старьё то В 1 поток Я много чего раньше собирал в tmpfs, включая к, Аноним (2), 16:08 , 21-Янв-20, (80)

Ну дык - собирайте без LTO А то получается как в том анекдоте Доктор, если я д, Аноним84701 (ok), 00:16 , 22-Янв-20, (105)

Подключайте десятки гигабайт свопа -- tmpfs swap работает всё равно быстрее ext4, Michael Shigorin (ok), 19:42 , 21-Янв-20, (98)

Использовать журналируемые ФС для временных файлов а сборка именно их и создаёт, юникснуб (?), 19:25 , 23-Янв-20, (135)

Чем оно лучше GNU Lightning , Аноним (3), 09:57 , 21-Янв-20, (3) –1

Разные подход к снаряду, в GNU Lightning нет промежуточного языка Тут в пору спр, GentooBoy (ok), 09:18 , 22-Янв-20, (118)

Это что же, у нас будут интерпретаторы Си и Си Они понимают что через полгода, A.Stahl (ok), 10:01 , 21-Янв-20, (4) –2

так а по какой такой понятной причине , наше имя легион (?), 10:14 , 21-Янв-20, (7)

У тебя есть подкроватный сервер Вот и попробуй выпилить оттуда Лисп и сам всё, A.Stahl (ok), 10:16 , 21-Янв-20, (8)

eix -I lispNo matches foundну в принципе да, нельзя вытеснить того, чего нет, Аноним (149), 23:29 , 25-Янв-20, (149)

а если найду простите не удержался , Michael Shigorin (ok), 23:38 , 25-Янв-20, (150)

Не вытеснят из-за порогов вхождения в Питоны и Пыхи , Аноним (19), 11:09 , 21-Янв-20, (19) +3

Си прост, да и Си не сложен пока не возиться с шаблонами и не городить что-то , A.Stahl (ok), 11:34 , 21-Янв-20, (26) –2

Трoллинг глупостью в 2020 году смотрится уже немного архаично, не находите , Аноним (37), 12:44 , 21-Янв-20, (37) –2

Ну так и не тролльте , Аноним (-), 14:36 , 21-Янв-20, (62) +6

Интересно, а зачем использовать C , если не использовать его нетривиальные возм, юникснуб (?), 19:26 , 23-Янв-20, (136)

Понятия не имею о чём ты говоришь Хочешь -- используй, не хочешь -- не использу, A.Stahl (ok), 19:45 , 23-Янв-20, (142)

С утверждением хочешь - используй спорить даже не собираюсь Но я говорил про , юникснуб (?), 15:03 , 24-Янв-20, (147)

Для простых задач тяжеловес Си ничем не хуже других языков Совсем Более то, A.Stahl (ok), 15:39 , 24-Янв-20, (148)

R уже есть , Аноним (48), 14:21 , 21-Янв-20, (48) –1

В каком месте R вообще замена си Эт ж надо такое придумать , Аноним (-), 14:30 , 21-Янв-20, (58) +1

Есть такое малознакомое понятие как ИТ безопасность, вот именно по этому понятию, Аноним (48), 14:23 , 21-Янв-20, (51)

Такая безопасность работает только при условии, что у злоумышленника не хватит, Аноним (37), 14:27 , 21-Янв-20, (54) +1

У людей имеющих элементарные понятия ИТ безопасности вся память, включая дискову, Аноним (131), 15:36 , 22-Янв-20, (131) +2
Садись, опять двойка Речь идет о выделении оперативной память в режиме RX для ис, Аноним (132), 16:06 , 22-Янв-20, (132)

Не противоречит Современные приличные JIT делают простую вещь сначала выделяют, юникснуб (?), 19:29 , 23-Янв-20, (137) +1

Скачай уже наконец TCC и вот оно счастье D Он таки это самое умеет, прям в рид, Аноним (-), 14:29 , 21-Янв-20, (56)

TCC - GPL А это резко ограничивает возможности его применения Собственно, мне , funny.falcon (?), 21:11 , 21-Янв-20, (102) –2

Не очень ффтыкаю как GPL компилера в режиме интерпретера ограничивает что-то , Аноним (-), 04:19 , 22-Янв-20, (109)

Подумали в своё время умные люди и создали Perl , nelson (??), 16:31 , 21-Янв-20, (82) +6

Забавно, но нет Perl создавался для решения задач, которые при создании C ещё не, юникснуб (?), 19:31 , 23-Янв-20, (138)

Красноперые решили потролить неудачников из каноникала , Аноним (5), 10:13 , 21-Янв-20, (5) +10

скромные боги тихо собирают МИР , Аноним (16), 10:55 , 21-Янв-20, (16) –4

Зачем захватывать мир, если можно сделать свой , Аноним (37), 14:28 , 21-Янв-20, (55) +1

Весьма валидный пойнт Но LLVM с шлангом они кажется все-таки малость подтроллил, Аноним (-), 14:40 , 21-Янв-20, (63) +2

Остальное время будет добрано на целевых компьютерах во время выполнения , Аноним (6), 10:13 , 21-Янв-20, (6) +4

Исполнение MIR с использованием JIT должно быть не более чем на 30 медленнее, ч, Moomintroll (ok), 10:31 , 21-Янв-20, (9)

про компиляцию в внутреннее представление JIT намеренно умолчали или не знали о, Аноним (27), 11:35 , 21-Янв-20, (27) –2

Закон сохранения энергии Или как вариант, код будет передаваться на облака Red, bw (ok), 10:50 , 21-Янв-20, (15) –1

Интересно, по какому закону сохранения этот frontend будет работать без интерн, Аноним (37), 11:33 , 21-Янв-20, (25)

Зачем столько новых промежуточных представлений Уже существующих недостаточно , Аноним (10), 10:31 , 21-Янв-20, (10) +3

Это не считая того, что выходной x86 -64 код - тоже промежуточное представление, Аноним (12), 10:43 , 21-Янв-20, (12) +4
Фатальный недостаток-с с у всех же , Урри (?), 17:56 , 21-Янв-20, (87)

Эпическое ненужно , Аноним (12), 10:42 , 21-Янв-20, (11) –1

С другой стороны они все верят что именно их xIT будет праивть миром В то время, Аноним (14), 10:48 , 21-Янв-20, (14)

а почему нельзя просто скомпилировать бинарник ну или два бинарника для x86-64 , X5asd5 (?), 11:20 , 21-Янв-20, (22) +3

Почему бы не погуглить, зачем нужен jit , Аноним (30), 11:44 , 21-Янв-20, (30) –2

а почему бы сразу не написать сюда на форум, действительно, зачем же нужен jit , X5asd5 (?), 12:14 , 21-Янв-20, (33)

Потому что в принципе бессмысленно что-то объяснять, если человек не знает, где , Аноним (30), 12:36 , 21-Янв-20, (35) +1

Там где нет денег сделать из MVP и POC проекта полноценное решение Тут всем на п, Аноним (100), 20:37 , 21-Янв-20, (100)

Господи, откуда вы беретесь , Аноним (30), 10:55 , 22-Янв-20, (122) +1

вам лучше этого не знать, поверьте, господи (?), 19:34 , 23-Янв-20, (139)

Значит пользователь ПК потратил недостаточно денег на оперативную память, чтобы , Аноним (19), 17:46 , 21-Янв-20, (83) –1
Дык известно же что производители железа просто щемят программистов этим вот и в, Аноним (100), 20:38 , 21-Янв-20, (101) –1

Потому что в языке с динамической типизацией проблематично просчитать все возмож, Аноним (-), 14:33 , 21-Янв-20, (61) –5

Вот с этого момента можно дальше не читать - уровень содержимого примерно такой , Аноним (73), 14:59 , 21-Янв-20, (73) +4
вообще первоначальный тезис был про С другой стороны они все верят что именно , X5asd5 (?), 22:30 , 21-Янв-20, (104)

В C есть такая штука как dynamic, почитайте https docs microsoft com ru-ru d, господи (?), 19:38 , 23-Янв-20, (140)

Уже есть numba Она даже cuda умеет Результаты так себе, скажем, cython обеспеч, Аноним (2), 12:35 , 21-Янв-20, (34) –1
так cython УЖЕ естьправда жизни состоит в том что в том месте где живут питоны и, 0ffh (??), 18:36 , 21-Янв-20, (93) –1

унас_было_14_стандартов жпг Но идея годная Если взлетит, будет хорошо , Аноним (13), 10:45 , 21-Янв-20, (13) +5
Я не понял, там названия кончились что ли , Ваш Анонимус (?), 11:06 , 21-Янв-20, (17) +7

Они хотят крутое название из трех букв н р C компиляторы pcc, tcc, lcc, gc, neAnonim (?), 11:35 , 21-Янв-20, (28)

Пусть обратятся к Russian Hackers, они подскажут И даже отправят туда , Аноним (37), 12:47 , 21-Янв-20, (38) –2

Ушли у батьки Столлмана конпилятор Эх, успеют корпорасты реализовать задумки и, myhand (ok), 11:07 , 21-Янв-20, (18)

К тем, кто будет использовать старый gcc 8212 выедут специально обученные люд, Аноним (37), 11:30 , 21-Янв-20, (24) –1

А чому не в Nigeria , Аноним (32), 12:14 , 21-Янв-20, (32) –1

Потому что название не толерантное , Аноним (37), 12:41 , 21-Янв-20, (36) +3

1 стандарт, Аноним (30), 11:43 , 21-Янв-20, (29) –1

Пока код ISO на присвоят 8212 не стандарт , Аноним (37), 13:06 , 21-Янв-20, (39) +1

А если ISO выпустят релиз, а все остальные на эту бамажку покладут известно что,, господи (?), 19:41 , 23-Янв-20, (141)

я что не понял - чем оно от вм и байткода ллвм отличается кроме того что написан, Аноним (103), 22:18 , 21-Янв-20, (103) –1

Какая-то детская фиксация на цифре 100 В сто раз быстрее, меньше Прям как м, Аноним (31), 12:00 , 21-Янв-20, (31)

Современные физики и инженеры с их 171 разница величин оценивается как минимум, Аноним (37), 13:07 , 21-Янв-20, (40) +2

На два порядка Логарифмы складываются , Аноним (19), 17:53 , 21-Янв-20, (86) +2

Ну а что, иногда даже правда Нацепит экзоскелет - и подымет , Аноним (-), 14:41 , 21-Янв-20, (64)

ну, хотя бы, подходящий язык для реализации выбрали, а не хипстерскую растишку, , nelson (??), 13:38 , 21-Янв-20, (41) –1

говорят люди, не имеющие понятия ни о расте, ни о системного программировани, Owlet (?), 13:46 , 21-Янв-20, (42) +4

Это всё гуманитарные дисциплины, и настоящему айтишнику их знать не надо Вот фи, Аноним (37), 14:22 , 21-Янв-20, (50) +1
растишка - это диверсия в сфере разработки системного ПО язычёк, в котором мани, nelson (??), 15:52 , 21-Янв-20, (79) +4

Растишка переносит отлов багов с адресной арифметикой с этапа исполнения на этап, Анончик (?), 12:46 , 22-Янв-20, (124)

GCC и сейчас это до некоторой степени делает Хоть и несколько своеобразно Заче, Аноним (67), 14:47 , 21-Янв-20, (67)

речь о промежуточном представлении для компиляции JIT-компилятором а в случае с, nelson (??), 16:11 , 21-Янв-20, (81)

Насколько я понял идею этой штуки - это предлагается как некий IR, более логичны, Аноним (-), 04:26 , 22-Янв-20, (110)

Просто llvm очень жирный и долго работает перегоняя свой ir в наивный код Автор, Анончик (?), 12:49 , 22-Янв-20, (125)

Вообще всякие JIT нужны для того, чтобы не светить исходниками клиентам, для чег, None (??), 13:57 , 21-Янв-20, (44) –8

Опять пятнадцатицентовые из оракла Унылые и однообразные, как всегда , Аноним (37), 14:24 , 21-Янв-20, (52) –2

Еще один убийца джавы Весело год начался Один выкатывает очередного убийцу мей, Урри (?), 14:01 , 21-Янв-20, (45)
как всегда 8212 в libjit нашли Фатальный Недостаток , arisu (ok), 14:12 , 21-Янв-20, (46) +1

Судя по описанию - достаточно разные штуки , Аноним (67), 14:48 , 21-Янв-20, (68)

авторы сами срвнивают свой продукт с gcc jit и llvm про libjit и firm же стыдл, arisu (ok), 14:57 , 21-Янв-20, (72) +3

Они об этом прямым текстом говорят, предсказатель вы наш If we implement more , господи (?), 19:48 , 23-Янв-20, (143) +1

ты плохой, ненастоящий господи потому что глупый очень , arisu (ok), 19:51 , 23-Янв-20, (144)

Хм, непосредственно править байт код хм , Аноним (49), 14:22 , 21-Янв-20, (49)

В текстовом виде 8212 это уже не байт-код, а лайн-код , Аноним (37), 14:30 , 21-Янв-20, (59) +1
Ассемблер же правят А это чем хуже , Аноним (67), 14:49 , 21-Янв-20, (69)

Тут просто кто то спросил чем ЭТО лучше чем JAVA байт код , Аноним (49), 14:54 , 21-Янв-20, (71) –1

Ну например JAVA выросла в адского переусложненного монстра который подразумевае, Аноним (-), 04:28 , 22-Янв-20, (111)

ЭЭ братан, не надо сравнивать тёплое с мягким, ты знаешь как компилируется сишны, Аноним (-), 14:30 , 21-Янв-20, (57) –1
Затея интересная, точно будет полезна для JIT-изации и получения переносимого пр, erthink (ok), 14:30 , 21-Янв-20, (60) +4

Там речь идет про LLVM IR он тоже довольно простой, особых проблем быть не долж, GentooBoy (ok), 08:29 , 22-Янв-20, (114)

такова печальная судьба больных NIH-синдромом пусть хрюкается, сам этого захоте, arisu (ok), 08:52 , 22-Янв-20, (116)

Ну все немного сложнее, изначально это был пет проект как я понимаю Потом шапка, GentooBoy (ok), 09:25 , 22-Янв-20, (120)

на всякий случай я не имел в виду ничего негативного просто автор сознательно, arisu (ok), 09:33 , 22-Янв-20, (121)

Вы принципиально неправы На всякий уточню - в MIR только самые простые инструк, erthink (ok), 11:50 , 22-Янв-20, (123) +1

Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir О, Анончик (?), 12:58 , 22-Янв-20, (126)

Теоретически конечно можно генерировать более простой llvm ir Но практически э, erthink (ok), 14:19 , 22-Янв-20, (129)

Да вы правы, будут проблемы , GentooBoy (ok), 13:35 , 22-Янв-20, (127)

следующая версия будет содержать все инструкции D, Аноним (128), 13:57 , 22-Янв-20, (128)

Понимая сарказм, уточню на всякий - никакая следующая версия MIR не может подде, erthink (ok), 14:25 , 22-Янв-20, (130)

Что значит сренегерировать , Аноним (70), 14:54 , 21-Янв-20, (70)
Это все что надо знать о нужности современных язычков , Аноним (77), 15:31 , 21-Янв-20, (77) +1

ну дак не на расте же писать, у тех девственниц истерика случается при виде указ, Аноним (84), 17:48 , 21-Янв-20, (84) +2

ГНУтые поделия постепенно выбрасываются, скоро и ядро перелицензируют на какой-н, kernel_panic (??), 18:46 , 21-Янв-20, (96) –4
А для питона будет , Анонимныйаноним (?), 19:03 , 21-Янв-20, (97) –7

В ложку питона сколько бочек мёда не докидывай - всё равно питоном останется , Led (ok), 00:20 , 22-Янв-20, (107) +8
Для какой-нибудь обкоцаной недо-версии с более-менее статическими типами и без в, Аноним (-), 04:29 , 22-Янв-20, (112)

Лучше бы Red Hat развивал ZFS, выкупив её у Oracle , rc.conf (?), 20:09 , 21-Янв-20, (99)
Я просто оставлю это здесь https github com wasmerio wasmer, GentooBoy (ok), 08:52 , 22-Янв-20, (115) +1

ну и зачем ты напачкал , arisu (ok), 08:57 , 22-Янв-20, (117)

Может кто то поиграть захочет с теми же яйцами только в профиль , GentooBoy (ok), 09:21 , 22-Янв-20, (119)

Но WASM же делает то же самое Нахера , s9gf4ult (ok), 19:37 , 22-Янв-20, (134)

и ллвм делает почти тоже самое, даже больше Если кто знает - напишите зачем оно, Аноним (103), 13:53 , 24-Янв-20, (145)

MIR предлагает простой универсальный компактный JIT с пермиссивной лицензией, ко, erthink (ok), 14:22 , 24-Янв-20, (146)

Можно, наверное, написать ридер mir-ir для Схемы, если там так мало инструкций , Lockywolf (ok), 00:15 , 03-Фев-20, (151)

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

1. "Red Hat развивает JIT-компилятор MIR" +19 +/–

Сообщение от Аноним (1), 21-Янв-20, 09:51

Может всё-таки JIR?

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

47. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от РэдХэд (?), 21-Янв-20, 14:16

jinr? :)

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

2. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от Аноним (2), 21-Янв-20, 09:55

Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть?

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

20. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от Имя (?), 21-Янв-20, 11:11

Это размер КОДА самого компилятора

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

21. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним (2), 21-Янв-20, 11:13

LLVM посчитать забыли, там гигабайт 20.

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

43. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним84701 (ok), 21-Янв-20, 13:46

> LLVM посчитать забыли, там гигабайт 20.
А точно не 100500?
.
>  27M 15 дек.   llvm-7.0.1.src.tar.xz
>  57M 11 янв.  llvm70/lib/libLLVM-7.so
https://packages.debian.org/jessie/libllvm3.5
>     Installed Size    29,817.0 kB

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

53. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (-), 21-Янв-20, 14:27

> LLVM посчитать забыли, там гигабайт 20.
Как это? Пакет с либой весит 7 мегов?

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

65. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от Аноним (2), 21-Янв-20, 14:42

>> LLVM посчитать забыли, там гигабайт 20.
> Как это? Пакет с либой весит 7 мегов?
Для начала необходимо выяснить, что именно они имели в виду. Если это зависимость, которую этот код будет использовать для компиляции и только она, то логично будет сравнивать с равноценным кодом из gcc (он тоже умеет во всё то же, что и llvm, и даже лучше). А то выглядит как очередное сравнение тёплого с мягким и ни у кого из них не возникает никаких вопросов, главное результат и красивые слайдики.
А компиляторы llvm в процессе сборки действительно потребляют десятки гигабайт, и на диске там не 7 мегабайт в результате выходит.

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

23. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (23), 21-Янв-20, 11:27

да какая разница, если статичная линковка, то это очень круто

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

66. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним84701 (ok), 21-Янв-20, 14:47

>> Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть?
> да какая разница, если статичная линковка, то это очень круто
Очередная перепись нечитавших новость?
> Here are the notes for each table row:
> [1]: Wall time of compilation of sieve code (without any include file and with using the memory file system for GCC).
> [2]: The best wall time of 10 runs.
> [3]: The stripped sizes of cc1 for GCC, and the MIR core and interpreter or generator for MIR.
сс1 (правда ни разу не статистически слинкованный) размер из того же gcc9, плюс-минус лапоть, совпадает с приведенным в табличке.

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

74. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (2), 21-Янв-20, 15:02

Тут уже предлагают libllvm сравнивать. Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.

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

75. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним84701 (ok), 21-Янв-20, 15:15

> Тут уже предлагают libllvm сравнивать.
Кто и с чем предалагает?
> Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.
Те, кому для сборки LLVM нужны "десятки гигабайт", могут сравнивать что хотят и с чем хотят – кто же им запретит-то? o_O

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

76. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (2), 21-Янв-20, 15:18

>потребляет десятки гигабайт
Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?

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

78. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним84701 (ok), 21-Янв-20, 15:39

>>потребляет десятки гигабайт
> Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?
Ну например вот это вот:
>  57M 11 янв.  llvm70/lib/libLLVM-7.so
из недавнего  "самосбора" (кастом с clang, lld-gold, без доков, санитайзеров и lldb - конченый результат  ~ 400МБ) , сборка в tmpfs с лимитом в 5GB, на машинке с аж 8GB ОЗУ.
Брат^W все нормально собралось в фоне.

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

80. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (2), 21-Янв-20, 16:08

А что такое старьё то? В 1 поток? Я много чего раньше собирал в tmpfs, включая компиляторы  и браузеры, но теперь так не получается. Правда, llvm вроде собирается (в 4 потока), но я как-то проследил сколько данных записано на диск в процессе. А какие таргеты? Бэкенды вроде NVPTX? Это может быть очередной регрессий по типу регулярных проблем gcc с lto?

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

105. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним84701 (ok), 22-Янв-20, 00:16

> Я много чего раньше собирал в tmpfs, включая компиляторы  и браузеры, но теперь так не получается.
Ну дык - собирайте без LTO.
А то получается как в том анекдоте "Доктор, если я делаю вот так вот …" ;)
Или clang с lto=thin (которое "ThinLTO compilation is a new type of LTO that is both scalable and incremental"), если так  хочется.
LTO конечно вещь, но заметная оптимизация (не 3%-5% как в Огнелисе, вперемежку с регрессиями http://hubicka.blogspot.com/2018/12/even-more-fun-with-build...)  получается только в довольно специфичных случаях, а вот ресурсов оно жрет ой-ёй-ёй.
> А что такое старьё то?
"за надом!" (с) народный аноним
Ну и  вроде бы: "Релиз набора компиляторов LLVM 7.0 - OpenNET 19 Sep 2018".
Но могу предложить LLVM + Clang 8 (давно собирал, но  тоже все нормально собиралось).
Или относительно свежий LLVM+Clang 9 (тут уже обрезаны таргеты, зато собран с lto=thin, конечный результат со всеми санитайзерами и lldb ~ 800МБ).
Единственно, собирался долго, но памяти оставалось еще с пару ГБ.
Но вообще, в том же фрибсд  "обпиливают" связку clang + llvm 9, собирающей всю систему и большую часть портов, до 70-80 МБ.
> В 1 поток?
В 3 - 4.
> А какие таргеты? Бэкенды вроде NVPTX?

Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - Mips
    mips64     - Mips64 [experimental]
    mips64el   - Mips64el [experimental]
    mipsel     - Mipsel
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

> Это может быть очередной регрессий по типу регулярных проблем gcc с lto?
Я собирал clang самим clang-ом. LLVM+Clang 7/8 без LTO, LLVM+Clang 9 с "-flto=thin".

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

98. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Michael Shigorin (ok), 21-Янв-20, 19:42

> Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт.
Подключайте десятки гигабайт свопа -- tmpfs+swap работает всё равно быстрее ext4, например.

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

135. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от юникснуб (?), 23-Янв-20, 19:25

Использовать журналируемые ФС для временных файлов (а сборка именно их и создаёт, там ничего такого невосполнимого-ценного нет) вообще не очень мудрая идея. ;)

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

3. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (3), 21-Янв-20, 09:57

Чем оно лучше GNU Lightning?

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

118. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от GentooBoy (ok), 22-Янв-20, 09:18

Разные подход к снаряду, в GNU Lightning нет промежуточного языка.
Тут в пору спросить чем лучше wasm or polyglot

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

4. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от A.Stahl (ok), 21-Янв-20, 10:01

Это что же, у нас будут интерпретаторы Си и Си++? Они понимают что через полгода после релиза питонисты и прочие ПХПшники начнут массово убивать себя от безысходности? Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...

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

7. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от наше имя легион (?), 21-Янв-20, 10:14

так а по какой такой понятной причине? ;)

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

8. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от A.Stahl (ok), 21-Янв-20, 10:16

У тебя есть "подкроватный" сервер? Вот и попробуй выпилить оттуда Лисп и сам всё поймёшь.

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

149. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (149), 25-Янв-20, 23:29

# eix -I lisp
No matches found

ну в принципе да, нельзя вытеснить того, чего нет

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

150. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Michael Shigorin (ok), 25-Янв-20, 23:38

> # есть закурить?
> No matches found
"а если найду?"
>>> ну в принципе да, нельзя вытеснить того, чего нет
(простите (не . удержался))

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

19. "Red Hat развивает JIT-компилятор MIR" +3 +/–

Сообщение от Аноним (19), 21-Янв-20, 11:09

Не вытеснят из-за порогов вхождения в Питоны и Пыхи.

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

26. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от A.Stahl (ok), 21-Янв-20, 11:34

> Не вытеснят из-за порогов вхождения в Питоны и Пыхи.
Си прост, да и Си++ не сложен пока не возиться с шаблонами и не городить что-то нетривиальное с наследованием. "Питоны и Пыхи" просто станут не нужны. Я во всяком случае не вижу никаких их преимуществ.

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

37. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от Аноним (37), 21-Янв-20, 12:44

Трoллинг глупостью в 2020 году смотрится уже немного архаично, не находите?

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

62. "Red Hat развивает JIT-компилятор MIR" +6 +/–

Сообщение от Аноним (-), 21-Янв-20, 14:36

Ну так и не тролльте.

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

136. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от юникснуб (?), 23-Янв-20, 19:26

Интересно, а зачем использовать C++, если не использовать его нетривиальные возможности? Захотелось просто так в ногу пострелять?

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

142. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от A.Stahl (ok), 23-Янв-20, 19:45

Понятия не имею о чём ты говоришь. Хочешь -- используй, не хочешь -- не используй.

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

147. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от юникснуб (?), 24-Янв-20, 15:03

> Понятия не имею о чём ты говоришь. Хочешь -- используй, не хочешь
> -- не используй.
С утверждением "хочешь - используй" спорить даже не собираюсь. Но я говорил про это:
>> Си++ не сложен пока не возиться с шаблонами и не городить что-то нетривиальное с наследованием.
Для решения простых задач C++ (речь не о лабораторных работах первокурсников, разумеется, а реальных потребностях) зачастую не оптимален в качестве инструмента: дольше разработка, больше риски ошибок. Опять же, существую языки, изначально заточенные для работы в той или иной области... C++ - тяжеловес-универсал, нужный тогда, когда другие перестают справляться. Он ценнен как раз своими возможностями вроде упомянутых вами множественного наследования и template'ов (которые сравнивать с generic-типами в языках типа Java язык не повернётся). И говорить о C и C++ в одном контексте, право слово, почти всегда некорректно.

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

148. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от A.Stahl (ok), 24-Янв-20, 15:39

>Для решения простых задач C++ зачастую не оптимален в качестве инструмента: дольше разработка, больше риски ошибок.
Для простых задач "тяжеловес" Си++ ничем не хуже других языков. Совсем. Более того: внятное объявление типов и очевидная работа с памятью пресекают бОльшую часть ошибок ещё на этапе до компиляции. И это более заметно именно на небольших проектах. На больших проектах всё равно придётся обложиться планами, тестами т.п.
>И говорить о C и C++ в одном контексте, право слово, почти всегда некорректно.
Может и так, но они оба входят во множество хороших и привычных языков программирования и использовались мной именно в этом контексте.

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

48. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (48), 21-Янв-20, 14:21

R уже есть..

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

58. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (-), 21-Янв-20, 14:30

В каком месте R вообще замена си? Эт ж надо такое придумать! :)

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

51. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (48), 21-Янв-20, 14:23

> Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...
Есть такое малознакомое понятие как ИТ безопасность, вот именно по этому понятию интерпретаторов, тем более с JIT на серверах у людей не будет.

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

54. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (37), 21-Янв-20, 14:27

Такая "безопасность" работает только при условии, что у злоумышленника не хватит квалификации собрать статический бинарник под целевую платформу. То есть — от пользователей Kali, разве что.

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

131. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним (131), 22-Янв-20, 15:36

У людей имеющих элементарные понятия ИТ безопасности вся память, включая дисковую подсистему, выделяется или exec,ro или noexec,rw. Это требование DAC.
А запуск бинаря через:
  /lib/ld-linux.so.2 /tmp/virus
У дистрибутивах для людей не работает.

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

132. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (132), 22-Янв-20, 16:06

> Такая "безопасность" работает только при условии, что у злоумышленника не хватит квалификации собрать статический бинарник под целевую платформу.
Садись, опять двойка.
Речь идет о выделении оперативной память в режиме RX для исполняемых программ, RW для изменяемых данных или только R для не изменяемых данных. Это базовые, обязательные требования DAC. Выделять оперативную память в режиме WX категорически запрещается!
Использование JIT противоречит этим правилам изменяя исполняемую область памяти.
Как с этим всем связаны уязвимости с переполнение буфера местным двоечника тоже объяснять надо?

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

137. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от юникснуб (?), 23-Янв-20, 19:29

Не противоречит. Современные приличные JIT делают простую вещь: сначала выделяют память как RW, потом меняют права на (R)X. Все довольны.

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

56. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (-), 21-Янв-20, 14:29

> Это что же, у нас будут интерпретаторы Си и Си++?
Скачай уже наконец TCC и вот оно счастье :D. Он таки это самое умеет, прям в ридми написано.
И таки да - он таки сперва компилит, потом запускает. Хоть и быстро и оптимизации рядом не стояли с gcc и шлангом, но по сравнению с питоном и пыхом... :)))

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

102. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от funny.falcon (?), 21-Янв-20, 21:11

TCC - GPL. А это резко ограничивает возможности его применения. Собственно, мне кажется, потому он и не взлетел в качестве платформы для массового JIT.

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

109. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (-), 22-Янв-20, 04:19

Не очень ффтыкаю как GPL компилера "в режиме интерпретера" ограничивает что-то. Код с ним при этом не линкуется.
А если это про более серьезную кодогенерацию - там скорее "ограничивает" общая тривиальность конструкции, все заточено на быстрый компил и простой код компилера. Но вот оптимальность такого кода по сравнению с gcc/clang... гм...

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

82. "Red Hat развивает JIT-компилятор MIR" +6 +/–

Сообщение от nelson (??), 21-Янв-20, 16:31

>> Это что же, у нас будут интерпретаторы Си и Си++?
Подумали в своё время умные люди и создали Perl.

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

138. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от юникснуб (?), 23-Янв-20, 19:31

Забавно, но нет.
Perl создавался для решения задач, которые при создании C ещё не были толком актуальны, а при создании C++ не рассматривались как основные.

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

5. "Red Hat развивает JIT-компилятор MIR" +10 +/–

Сообщение от Аноним (5), 21-Янв-20, 10:13

>MIR
Красноперые решили потролить неудачников из каноникала.

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

16. "Red Hat развивает JIT-компилятор MIR" –4 +/–

Сообщение от Аноним (16), 21-Янв-20, 10:55

... скромные боги тихо собирают МИР ...

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

55. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (37), 21-Янв-20, 14:28

Зачем захватывать мир, если можно сделать свой?

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

63. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним (-), 21-Янв-20, 14:40

Весьма валидный пойнт. Но LLVM с шлангом они кажется все-таки малость подтроллили.

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

6. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от Аноним (6), 21-Янв-20, 10:13

> Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;
Остальное время будет добрано на целевых компьютерах во время выполнения.

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

9. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Moomintroll (ok), 21-Янв-20, 10:31

>> Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;
> Остальное время будет добрано на целевых компьютерах во время выполнения.
Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2");

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

27. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от Аноним (27), 21-Янв-20, 11:35

про компиляцию в внутреннее представление JIT намеренно умолчали? или не знали о таком?

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

15. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от bw (ok), 21-Янв-20, 10:50

Закон сохранения энергии.
Или как вариант, код будет передаваться на "облака" RedHat и этот MIR, на самом деле, просто frontend.

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

25. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (37), 21-Янв-20, 11:33

Интересно, по какому закону сохранения этот "frontend" будет работать без интернета (а он будет).

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

10. "Red Hat развивает JIT-компилятор MIR" +3 +/–

Сообщение от Аноним (10), 21-Янв-20, 10:31

Зачем столько новых промежуточных представлений? Уже существующих недостаточно?

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

12. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от Аноним (12), 21-Янв-20, 10:43

Это не считая того, что выходной x86(-64) код - тоже промежуточное представление, внутри проца оно совершенно иное :D

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

87. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Урри (?), 21-Янв-20, 17:56

Фатальный недостаток-с(с) у всех же.

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

11. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (12), 21-Янв-20, 10:42

> Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2")
Эпическое ненужно.

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

14. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (14), 21-Янв-20, 10:48

С другой стороны они все верят что именно их xIT будет праивть миром. В то время пока рынок не могут поделить .NET реализация и Java реализация, а они блин были первые выдумщики.
Осталось только дождаться когда Python и PHP выпустит свой Just-In-Time транслаторы и все мир будет счастлив.

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

22. "Red Hat развивает JIT-компилятор MIR" +3 +/–

Сообщение от X5asd5 (?), 21-Янв-20, 11:20

а почему нельзя просто скомпилировать бинарник?
ну или два бинарника: для x86-64 и для aarch64 .

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

30. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от Аноним (30), 21-Янв-20, 11:44

Почему бы не погуглить, зачем нужен jit?

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

33. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от X5asd5 (?), 21-Янв-20, 12:14

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

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

35. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (30), 21-Янв-20, 12:36

Потому что в принципе бессмысленно что-то объяснять, если человек не знает, где используются скрипты

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

100. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (100), 21-Янв-20, 20:37

Там где нет денег сделать из MVP и POC проекта полноценное решение?
Тут всем на помощь и приходят полурешения на JIT

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

122. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (30), 22-Янв-20, 10:55

Господи, откуда вы беретесь?

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

139. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от господи (?), 23-Янв-20, 19:34

вам лучше этого не знать, поверьте

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

83. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (19), 21-Янв-20, 17:46

Значит пользователь ПК потратил недостаточно денег на оперативную память, чтобы запускаемая программа имела бы предсказуемую производительность, управляемые характеристики.

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

101. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (100), 21-Янв-20, 20:38

Дык известно же что производители железа просто щемят программистов этим вот и все

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

61. "Red Hat развивает JIT-компилятор MIR" –5 +/–

Сообщение от Аноним (-), 21-Янв-20, 14:33

> а почему нельзя просто скомпилировать бинарник?
Потому что в языке с динамической типизацией проблематично просчитать все возможные изменения переменных, например, на этапе компиляции. Просто по Тюрингу - компилер не может вынести вердикт о том чего будет с вон той переменной дальше. И поэтому не может сгенерить сколь-нибудь эффективный код, всегда надо предусматривать что переменная внезапно полностью сменила тип. А это стало быть конкретный кус кода навешивать придется. Медленный и жирный.
Потому что в случае eval() надо еще... внезапно притащить с собой ВЕСЬ КОМПИЛЕР. В рантайме. Ну или как eval() то выполнять без этого? :)

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

73. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от Аноним (73), 21-Янв-20, 14:59

> Просто по Тюрингу
Вот с этого момента можно дальше не читать - уровень содержимого примерно такой же: "слышал звон".

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

104. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от X5asd5 (?), 21-Янв-20, 22:30

>> а почему нельзя просто скомпилировать бинарник?
> Потому что в языке с динамической типизацией проблематично просчитать все возможные изменения
> переменных, например, на этапе компиляции. Просто по Тюрингу - компилер не
> может вынести вердикт о том чего будет с вон той переменной
> дальше. И поэтому не может сгенерить сколь-нибудь эффективный код, всегда надо
> предусматривать что переменная внезапно полностью сменила тип. А это стало быть
> конкретный кус кода навешивать придется. Медленный и жирный.
> Потому что в случае eval() надо еще... внезапно притащить с собой ВЕСЬ
> КОМПИЛЕР. В рантайме. Ну или как eval() то выполнять без этого?
> :)
вообще первоначальный тезис был про
"""С другой стороны они все верят что именно их xIT будет праивть миром. В то время пока рынок не могут поделить .NET реализация и Java реализация, а они блин были первые выдумщики."""
а автор уже лишь только потом добавил в сообщение про Python и PHP.
а в .NET и Java какие нафиг ещё динамические типизации? это когда ты делаешь абсолютно всю программу через переменные лишь только Оbject-типа, а затем уже будешь через рефлексию/и/кастования вызывать нужный тебе метод? :-)

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

140. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от господи (?), 23-Янв-20, 19:38

В C# есть такая штука как dynamic, почитайте: https://docs.microsoft.com/ru-ru/dotnet/api/system.dynamic.d...
В JRE по крайней мере до недавнего времени всё было более грустно, но я не слежу за ней последние годы внимательно.

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

34. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (2), 21-Янв-20, 12:35

Уже есть numba. Она даже cuda умеет. Результаты так себе, скажем, cython обеспечивает производительность равную си, а тут может ещё и хуже в зависимости от условий стать.

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

93. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от 0ffh (??), 21-Янв-20, 18:36

так cython УЖЕ есть
правда жизни состоит в том что в том месте где живут питоны и пыхи - самое место итерпретаторам
а всякие ускорители выполнения они конечно хорошо - но ускорители написания - как бы важнее

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

13. "Red Hat развивает JIT-компилятор MIR" +5 +/–

Сообщение от Аноним (13), 21-Янв-20, 10:45

(унас_было_14_стандартов.жпг)
Но идея годная. Если взлетит, будет хорошо.

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

17. "Red Hat развивает JIT-компилятор MIR" +7 +/–

Сообщение от Ваш Анонимус (?), 21-Янв-20, 11:06

Я не понял, там названия кончились что ли?

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

28. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от neAnonim (?), 21-Янв-20, 11:35

Они хотят "крутое" название из трех букв. н.р ( C компиляторы: pcc, tcc, lcc, gcc..) итд по другим пунктам

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

38. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от Аноним (37), 21-Янв-20, 12:47

> Они хотят "крутое" название из трех букв.
Пусть обратятся к Russian Hackers, они подскажут. И даже отправят туда.

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

18. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от myhand (ok), 21-Янв-20, 11:07

> под лицензией MIT ... не исключается возможность портирования GCC на использование
Ушли у батьки Столлмана конпилятор...
Эх, успеют корпорасты реализовать задумки из "Право прочесть" к 2096-му году.

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

24. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (37), 21-Янв-20, 11:30

> Ушли у батьки Столлмана конпилятор...
К тем, кто будет использовать старый gcc — выедут специально обученные люди, настучат по почкам и отправят в Siberia.

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

32. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (32), 21-Янв-20, 12:14

А чому не в Nigeria?

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

36. "Red Hat развивает JIT-компилятор MIR" +3 +/–

Сообщение от Аноним (37), 21-Янв-20, 12:41

Потому что название не толерантное.

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

29. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (30), 21-Янв-20, 11:43

+1 стандарт

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

39. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (37), 21-Янв-20, 13:06

Пока код ISO на присвоят — не стандарт.

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

141. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от господи (?), 23-Янв-20, 19:41

А если ISO выпустят релиз, а все остальные на эту бамажку покладут известно что, то это всё равно будет стандарт? ;) Многие вещи стандартизируют задним числом, если вы не в курсе. В том числе и в ISO.

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

103. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (103), 21-Янв-20, 22:18

я что не понял - чем оно от вм и байткода ллвм отличается кроме того что написано другими людьми и имеет меньшее окружение?

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

31. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (31), 21-Янв-20, 12:00

Какая-то детская фиксация на цифре 100. В сто раз быстрее, меньше... Прям как "мой папа в сто раз сильнее твоего, он машину одной рукой поднимет".

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

40. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним (37), 21-Янв-20, 13:07

Современные физики и инженеры с их «разница величин оценивается как минимум в два порядка» недалеко от них ушли.

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

86. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним (19), 21-Янв-20, 17:53

На два порядка. Логарифмы складываются.

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

64. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (-), 21-Янв-20, 14:41

Ну а что, иногда даже правда. Нацепит экзоскелет - и подымет.

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

41. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от nelson (??), 21-Янв-20, 13:38

>> Код проекта написан на языке Си
ну, хотя бы, подходящий язык для реализации выбрали, а не хипстерскую растишку, уже норм.
>> в будущем планируется реализовать возможность генерации MIR для WebAssembly, байткода Java, CIL (Common Intermediate Language), Rust и C++
в случае с растишкой - это правильное решение, всё равно этому языку ничего не светит в системном программировании, а пилить веб-фреймворки хипстерам будет сподручнее на языке, транслируемом в представление для последуюшей JIT-компиляции вот этим вот JIT-компилятором MIR, к примеру.
транслировать же С и С++ в промежуточное представление... хз. зачем, если есть жаба.

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

42. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от Owlet (?), 21-Янв-20, 13:46

> всё равно этому языку ничего не светит в системном программировании
... говорят люди, не имеющие понятия ни о расте, ни о системного программировании...

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

50. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (37), 21-Янв-20, 14:22

Это всё гуманитарные дисциплины, и настоящему айтишнику их знать не надо. Вот философия Unix — это да, без неё — вон из профессии.

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

79. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от nelson (??), 21-Янв-20, 15:52

растишка - это диверсия в сфере разработки системного ПО. язычёк, в котором манипуляция объектамм в памяти осуществляется посредством костылей, придуманных для неосиляторов адресной арифметики, объективно не нужен

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

124. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Анончик (?), 22-Янв-20, 12:46

Растишка переносит отлов багов с адресной арифметикой с этапа исполнения на этап компиляции. Вот такая простая идея.
А нужно ему или нет каждый решает сам.

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

67. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (67), 21-Янв-20, 14:47

> транслировать же С и С++ в промежуточное представление... хз. зачем, если есть жаба.
GCC и сейчас это до некоторой степени делает. Хоть и несколько своеобразно.
Зачем? А затем что компилеру целящему в более чем 1 архитектуру удобнее сперва сгенерить код "абстрактно" а потом это уже транслировать в конкретный набор команд с их особенностями. Вообще совсем целиком переписывать вообще все пути кода под каждую новую архитектуру несколько утомительно.

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

81. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от nelson (??), 21-Янв-20, 16:11

речь о промежуточном представлении для компиляции JIT-компилятором. а в случае с GCC дело не только в трансляции под разные архитектуры. абстрактное представление позволяет также добавить поддержку нового ЯПа

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

110. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (-), 22-Янв-20, 04:26

Насколько я понял идею этой штуки - это предлагается как некий IR, более логичный и юзабельный чем LLVMовский. В том числе в этом вроде бы предполагается возможность притащить "абстрактный" бинарник а на целевой платформе его перегнать в нативный относительно малой кровью.
В случае LLVM они подобные юзкейсы не предусмотрели как класс, насколько я понимаю. Что довольно странно, но жираф большой, ему видней. В этом местя есть некий шанс подстебать этих господ, занвя кусочек "их" ниши.

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

125. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Анончик (?), 22-Янв-20, 12:49

Просто llvm очень жирный и долго работает перегоняя свой ir в наивный код. Автор делает тоже самое только его реализация маленькая и быстро делает наивный код за счёт минимальной оптимизации.

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

44. "Red Hat развивает JIT-компилятор MIR" –8 +/–

Сообщение от None (??), 21-Янв-20, 13:57

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

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

52. "Red Hat развивает JIT-компилятор MIR" –2 +/–

Сообщение от Аноним (37), 21-Янв-20, 14:24

Опять пятнадцатицентовые из оракла. Унылые и однообразные, как всегда.

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

45. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Урри (?), 21-Янв-20, 14:01

Еще один убийца джавы?
Весело год начался. Один выкатывает очередного убийцу мейка, эти выкатывают убийцу джавы. Кто у нас будет следующим, очередной шел?

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

46. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от arisu (ok), 21-Янв-20, 14:12

как всегда — в libjit нашли Фатальный Недостаток.

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

68. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (67), 21-Янв-20, 14:48

Судя по описанию - достаточно разные штуки.

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

72. "Red Hat развивает JIT-компилятор MIR" +3 +/–

Сообщение от arisu (ok), 21-Янв-20, 14:57

> Судя по описанию - достаточно разные штуки.
авторы сами срвнивают свой продукт с gcc(jit) и llvm. про libjit и firm же стыдливо умолчали — потому что не вышло бы тогда броского сравнения. и пришлось бы признаться, что MIR стали делать только потому, что libjit и firm под мерзкой, ненавистной корпорастам GPL.
ах, ну да: ещё MIR героически внедрил инновацию отказа от SSA. SSA чуть позже завезут — когда придётся докидывать оптимизаций; но уже без шума и помпы. запомните этот твит.

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

143. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от господи (?), 23-Янв-20, 19:48

Они об этом прямым текстом говорят, предсказатель вы наш: "If we implement more optimizations, SSA transition is possible when additional time for expensive in/out SSA passes will be less than additional time for non-SSA optimization implementation".
Ну или вы хотели как-то странно пошутить, но не вышло. Сочувствую, со всеми бывает.

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

144. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от arisu (ok), 23-Янв-20, 19:51

ты плохой, ненастоящий господи. потому что глупый очень.

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

49. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (49), 21-Янв-20, 14:22

> Промежуточный код MIR может быть представлен в бинарном и текстовом (читаемом) виде.
Хм, непосредственно править байт код ... хм.

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

59. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (37), 21-Янв-20, 14:30

В текстовом виде — это уже не байт-код, а лайн-код.

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

69. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (67), 21-Янв-20, 14:49

> Хм, непосредственно править байт код ... хм.
Ассемблер же правят. А это чем хуже?

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

71. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (49), 21-Янв-20, 14:54

> Ассемблер же правят. А это чем хуже?
Тут просто кто то спросил чем ЭТО лучше чем JAVA байт код.

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

111. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (-), 22-Янв-20, 04:28

Ну например JAVA выросла в адского переусложненного монстра который подразумевает немеряный рантайм и либы и половина перечисленных в сабже юзкейсов на основе жабы просто не выглядит жизнеспособно.

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

57. "Red Hat развивает JIT-компилятор MIR" –1 +/–

Сообщение от Аноним (-), 21-Янв-20, 14:30

>В текущем виде реализация MIR во многим опережает изначально поставленные цели: проведённые тесты показали, что производительность компиляции в MIR быстрее "GCC -O2" в 178 раз
ЭЭ братан, не надо сравнивать тёплое с мягким, ты знаешь как компилируется сишный код. Сначала, идёт добавление заголовочных файлов, затем работает синтаксический и лексический анализаторы, затем код ассемблируется, только после, всего этого ассемблерный код синтаксиса, трушно Юниксового AT&T, превращается в бинарь.
>производительность исполнения отстаёт от нативного кода на 6%, размер кода меньше в 144 раза
Конечно, интерпретируемая Природа всегда медленее компилируемой природы.
>реализация MIR JIT составляет 16 тысяч строк кода.
Это не показатель. Разработчики GCC пишут на С++.

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

60. "Red Hat развивает JIT-компилятор MIR" +4 +/–

Сообщение от erthink (ok), 21-Янв-20, 14:30

Затея интересная, точно будет полезна для JIT-изации и получения переносимого промежуточного во многих случаях. Однако, MIR целенаправленно содержит минимальный набор инструкций без SIMD, CMOV, FFS/CLZ/CTZ/POPCOUNT, SIN/COS и т.д. Получается этакий PDP-11 с поддержкой 32/64-битных операндов.
Такое "обрезание" совершенно оправдано назначением MIR и позволяет в разы сократить как объем кода, так и затраты на оптимизацию. Но нужно видеть и обратную сторону медали:
- при трансляции из GCC и LLVM в MIR для каждого builtin-а придется выбирать одно из трех: инлайнить цепочку инструкций, оформлять вызов к runtime-библиотеки (которую нужно поддерживать и поставлять отдельно), генерировать ошибку (т.е. нарушать совместимость с GCC/LLVM).
- использование продвинутых инструкций CPU всех определенного в MIR минимума потребует затрат на вызов функции (и связанного с этим пере-распределения регистров).
- оптимизация MIR-представления до уровня GCC/LLVM будет очень дорогой, так как требуется восстановление/распознание builtin/intrinsic-паттернов из россыпи простых MIR-инструкций и runtime-вызовов.
Поэтому на некоторых задач MIR будет вносить существенное замедление и никогда не сможет догнать GCC/LLVM. Это совершенно не проблема, и даже не недостаток, а осознанный компромисс. Главное потом не устраивать героическую битву с этим компромиссом (как в JVM).

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

114. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от GentooBoy (ok), 22-Янв-20, 08:29

>- при трансляции из GCC и LLVM в MIR для каждого builtin-а придется выбирать одно из трех: инлайнить цепочку инструкций, оформлять вызов к runtime-библиотеки (которую нужно поддерживать и поставлять отдельно), генерировать ошибку (т.е. нарушать совместимость с GCC/LLVM).
Там речь идет про  LLVM IR он тоже довольно простой, особых проблем быть не должно.
> - оптимизация MIR-представления до уровня GCC/LLVM будет очень дорогой, так как требуется восстановление/распознание builtin/intrinsic-паттернов из россыпи простых MIR-инструкций и runtime-вызовов.
Этого делать не планируеться, MIR это на подобии C1 из JVM.Вся эта работа изначально делалась для Ruby. Там сейчас подобие C2 из JVM  на основе LLVM/GCC, а теперь пилят  C1. Хотя сомневаюсь что Ruby что то поможет.
Будем надеяться что у Владимира Макарова получиться, но работа очень большая в одного можно зарюхаться.

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

116. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от arisu (ok), 22-Янв-20, 08:52

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

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

120. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от GentooBoy (ok), 22-Янв-20, 09:25

Ну все немного сложнее, изначально это был пет проект как я понимаю. Потом шапка разрешыла работать фултайм. Ну а идея была в том что бы добавить в  Ruby  jit,  хотя у  core team очень странное видение, они хотят все свое без внешних зависимостей.

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

121. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от arisu (ok), 22-Янв-20, 09:33

(на всякий случай: я не имел в виду ничего негативного. просто автор сознательно пошёл в NIH-территорию, а там Свои, Особые Правила. ;-)

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

123. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от erthink (ok), 22-Янв-20, 11:50

>>- при трансляции из GCC и LLVM в MIR для каждого builtin-а придется выбирать одно из трех: инлайнить цепочку инструкций, оформлять вызов к runtime-библиотеки (которую нужно поддерживать и поставлять отдельно), генерировать ошибку (т.е. нарушать совместимость с GCC/LLVM).
> Там речь идет про  LLVM IR он тоже довольно простой, особых
> проблем быть не должно.
Вы принципиально неправы. На всякий уточню:
- в MIR только самые простые инструкции, см. https://github.com/vnmakarov/mir/blob/master/mir.h
- в LLVM IR в 2 раза больше базовых типов данных, в ~10 раз больше базовых инструкций и несколько сотен intrinsic-ов, см. https://llvm.org/docs/LangRef.html
- невозможно "просто так" преобразовать LLVM IR в MIR, возникают масса проблем, в том числе обозначенные мной.
- с GIMPLE в GCC ровно тоже самое.

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

126. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Анончик (?), 22-Янв-20, 12:58

Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir. О полном один в один переносе речь конечно не идёт.
Если вы уже залезли в репу то посмотрите что там сделано в llvm2mir

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

129. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от erthink (ok), 22-Янв-20, 14:19

> Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir.
> О полном один в один переносе речь конечно не идёт.
Теоретически конечно можно генерировать "более простой llvm ir".
Но практически это не имеет ценности:
- вы должны обучить каждый ir-генератор (условный clang или rust) генерировать такой куцый ir (фактический отдельный диалект LLVM IR).
- соответственно вы должны выпилить из условного rust все возможности связанные с расширенными инструкциями сделав куцый вариант условного rust.
- совместимость с таким куцым условным rust потребует правки исходников.

> Если вы уже залезли в репу то посмотрите что там сделано в
> llvm2mir
Посмотрел, там ровно то, что я описал в первоначальном комментарии.
Есть чуть конкретнее, то llvm2mir просто сообщает "unsupported/unimplemented" почти во всех случаях, о которых я говорю.
Собственно это явно описано в README проекта, только в других формулировках.

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

127. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от GentooBoy (ok), 22-Янв-20, 13:35

Да вы правы, будут проблемы.

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

128. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (128), 22-Янв-20, 13:57

следующая версия будет содержать все инструкции :D

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

130. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от erthink (ok), 22-Янв-20, 14:25

> следующая версия будет содержать все инструкции :D
Понимая сарказм, уточню на всякий:
- никакая следующая версия MIR не может поддерживать "все инструкции" LLVM IR, ибо тогда MIR потеряет смысл и превратиться в LLVM.
- следующие версии llvm2mir очевидно будут поддерживать большие IR-инструкций и интринисков, но большинство из них вынуждено будет транслировать в вызовы дополнительной runtime-библиотеки.

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

70. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (70), 21-Янв-20, 14:54

Что значит "сренегерировать"?

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

77. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от Аноним (77), 21-Янв-20, 15:31

>В компании Rad Hat ведётся разработка нового легковесного JIT-компилятора MIR
>Код проекта написан на языке Си
Это все что надо знать о нужности современных язычков...

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

84. "Red Hat развивает JIT-компилятор MIR" +2 +/–

Сообщение от Аноним (84), 21-Янв-20, 17:48

ну дак не на расте же писать, у тех девственниц истерика случается при виде указателя.

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

96. "Red Hat развивает JIT-компилятор MIR" –4 +/–

Сообщение от kernel_panic (??), 21-Янв-20, 18:46

ГНУтые поделия постепенно выбрасываются, скоро и ядро перелицензируют на какой-нибудь MIT.

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

97. "Red Hat развивает JIT-компилятор MIR" –7 +/–

Сообщение от Анонимныйаноним (?), 21-Янв-20, 19:03

А для питона будет?

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

107. "Red Hat развивает JIT-компилятор MIR" +8 +/–

Сообщение от Led (ok), 22-Янв-20, 00:20

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

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

112. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (-), 22-Янв-20, 04:29

Для какой-нибудь обкоцаной недо-версии с более-менее статическими типами и без всяких eval... ?

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

99. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от rc.conf (?), 21-Янв-20, 20:09

Лучше бы Red Hat развивал ZFS, выкупив её у Oracle.

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

115. "Red Hat развивает JIT-компилятор MIR" +1 +/–

Сообщение от GentooBoy (ok), 22-Янв-20, 08:52

Я просто оставлю это здесь https://github.com/wasmerio/wasmer

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

117. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от arisu (ok), 22-Янв-20, 08:57

ну и зачем ты напачкал?

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

119. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от GentooBoy (ok), 22-Янв-20, 09:21

Может кто то поиграть захочет с теми же яйцами только в профиль.

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

134. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от s9gf4ult (ok), 22-Янв-20, 19:37

Но WASM же делает то же самое. Нахера?

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

145. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Аноним (103), 24-Янв-20, 13:53

>Но WASM же делает то же самое. Нахера?
и ллвм делает почти тоже самое, даже больше. Если кто знает - напишите зачем оно нужно при наличии ллвм и остального?

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

146. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от erthink (ok), 24-Янв-20, 14:22

>>Но WASM же делает то же самое. Нахера?
> и ллвм делает почти тоже самое, даже больше. Если кто знает -
> напишите зачем оно нужно при наличии ллвм и остального?
MIR предлагает простой универсальный компактный JIT с пермиссивной лицензией, который легко использовать, поддерживать и интегрировать. При этом для более 90% задач выдается более 90% скорости от полноценной "нативной" оптимизации.
1. Использование MIR в условном вашем проекте потребует в ~5 раз меньше усилий в сравнении с LLVM.
При этом не возникает пропорции "один рябчик (ваш код) и один конь (код LLVM)". Вам в разы проще поддерживать ваш проект и "владеть" вашим кодом.
2. Добавление и поддержка новой CPU-архитектуры в MIR требует в 50-100 раз меньше работы в сравнении с LLVM или GCC.
3. Если взять средний интерпретатор, то основное падение производительности происходит в циклах при работе с нативными машинными типами данных. Использование MIR позволяет получить тут более 90% от нативной оптимизации LLVM, но для этого потребуется в 5-10 раз меньше ресурсов, как при интеграции MIR, так и при работе MIR в runtime.
Как-то так.

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

151. "Red Hat развивает JIT-компилятор MIR" +/–

Сообщение от Lockywolf (ok), 03-Фев-20, 00:15

Можно, наверное, написать ридер mir-ir для Схемы, если там так мало инструкций. И получится компилятор Руби в Схему. Отличное решение, я считаю.

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

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

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

Партнёры:

Хостинг:

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

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

1. "Red Hat развивает JIT-компилятор MIR"	+19 +/–
Сообщение от Аноним (1), 21-Янв-20, 09:51
Может всё-таки JIR?
Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Red Hat развивает JIT-компилятор MIR"	+1 +/–
	Сообщение от РэдХэд (?), 21-Янв-20, 14:16
	jinr? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Red Hat развивает JIT-компилятор MIR"	+4 +/–
Сообщение от Аноним (2), 21-Янв-20, 09:55
Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть?
Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Red Hat развивает JIT-компилятор MIR"	+4 +/–
	Сообщение от Имя (?), 21-Янв-20, 11:11
	Это размер КОДА самого компилятора
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Red Hat развивает JIT-компилятор MIR"	+2 +/–
	Сообщение от Аноним (2), 21-Янв-20, 11:13
	LLVM посчитать забыли, там гигабайт 20.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Red Hat развивает JIT-компилятор MIR"	–1 +/–
	Сообщение от Аноним84701 (ok), 21-Янв-20, 13:46
	> LLVM посчитать забыли, там гигабайт 20. А точно не 100500? . > 27M 15 дек. llvm-7.0.1.src.tar.xz > 57M 11 янв. llvm70/lib/libLLVM-7.so https://packages.debian.org/jessie/libllvm3.5 > Installed Size 29,817.0 kB
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Red Hat развивает JIT-компилятор MIR"	–1 +/–
	Сообщение от Аноним (-), 21-Янв-20, 14:27
	> LLVM посчитать забыли, там гигабайт 20. Как это? Пакет с либой весит 7 мегов?
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	65. "Red Hat развивает JIT-компилятор MIR"	–2 +/–
	Сообщение от Аноним (2), 21-Янв-20, 14:42
	>> LLVM посчитать забыли, там гигабайт 20. > Как это? Пакет с либой весит 7 мегов? Для начала необходимо выяснить, что именно они имели в виду. Если это зависимость, которую этот код будет использовать для компиляции и только она, то логично будет сравнивать с равноценным кодом из gcc (он тоже умеет во всё то же, что и llvm, и даже лучше). А то выглядит как очередное сравнение тёплого с мягким и ни у кого из них не возникает никаких вопросов, главное результат и красивые слайдики. А компиляторы llvm в процессе сборки действительно потребляют десятки гигабайт, и на диске там не 7 мегабайт в результате выходит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним (23), 21-Янв-20, 11:27
	да какая разница, если статичная линковка, то это очень круто
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	66. "Red Hat развивает JIT-компилятор MIR"	+2 +/–
	Сообщение от Аноним84701 (ok), 21-Янв-20, 14:47
	>> Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть? > да какая разница, если статичная линковка, то это очень круто Очередная перепись нечитавших новость? > Here are the notes for each table row: > [1]: Wall time of compilation of sieve code (without any include file and with using the memory file system for GCC). > [2]: The best wall time of 10 runs. > [3]: The stripped sizes of cc1 for GCC, and the MIR core and interpreter or generator for MIR. сс1 (правда ни разу не статистически слинкованный) размер из того же gcc9, плюс-минус лапоть, совпадает с приведенным в табличке.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним (2), 21-Янв-20, 15:02
	Тут уже предлагают libllvm сравнивать. Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Red Hat развивает JIT-компилятор MIR"	+1 +/–
	Сообщение от Аноним84701 (ok), 21-Янв-20, 15:15
	> Тут уже предлагают libllvm сравнивать. Кто и с чем предалагает? > Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт. Те, кому для сборки LLVM нужны "десятки гигабайт", могут сравнивать что хотят и с чем хотят – кто же им запретит-то? o_O
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним (2), 21-Янв-20, 15:18
	>потребляет десятки гигабайт Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним84701 (ok), 21-Янв-20, 15:39
	>>потребляет десятки гигабайт > Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что? Ну например вот это вот: > 57M 11 янв. llvm70/lib/libLLVM-7.so из недавнего "самосбора" (кастом с clang, lld-gold, без доков, санитайзеров и lldb - конченый результат ~ 400МБ) , сборка в tmpfs с лимитом в 5GB, на машинке с аж 8GB ОЗУ. Брат^W все нормально собралось в фоне.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним (2), 21-Янв-20, 16:08
	А что такое старьё то? В 1 поток? Я много чего раньше собирал в tmpfs, включая компиляторы и браузеры, но теперь так не получается. Правда, llvm вроде собирается (в 4 потока), но я как-то проследил сколько данных записано на диск в процессе. А какие таргеты? Бэкенды вроде NVPTX? Это может быть очередной регрессий по типу регулярных проблем gcc с lto?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	105. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним84701 (ok), 22-Янв-20, 00:16
	> Я много чего раньше собирал в tmpfs, включая компиляторы и браузеры, но теперь так не получается. Ну дык - собирайте без LTO. А то получается как в том анекдоте "Доктор, если я делаю вот так вот …" ;) Или clang с lto=thin (которое "ThinLTO compilation is a new type of LTO that is both scalable and incremental"), если так хочется. LTO конечно вещь, но заметная оптимизация (не 3%-5% как в Огнелисе, вперемежку с регрессиями http://hubicka.blogspot.com/2018/12/even-more-fun-with-build...) получается только в довольно специфичных случаях, а вот ресурсов оно жрет ой-ёй-ёй. > А что такое старьё то? "за надом!" (с) народный аноним Ну и вроде бы: "Релиз набора компиляторов LLVM 7.0 - OpenNET 19 Sep 2018". Но могу предложить LLVM + Clang 8 (давно собирал, но тоже все нормально собиралось). Или относительно свежий LLVM+Clang 9 (тут уже обрезаны таргеты, зато собран с lto=thin, конечный результат со всеми санитайзерами и lldb ~ 800МБ). Единственно, собирался долго, но памяти оставалось еще с пару ГБ. Но вообще, в том же фрибсд "обпиливают" связку clang + llvm 9, собирающей всю систему и большую часть портов, до 70-80 МБ. > В 1 поток? В 3 - 4. > А какие таргеты? Бэкенды вроде NVPTX? Registered Targets: aarch64 - AArch64 (little endian) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) hexagon - Hexagon lanai - Lanai mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel msp430 - MSP430 [experimental] nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX sparc - Sparc sparcel - Sparc LE sparcv9 - Sparc V9 systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore > Это может быть очередной регрессий по типу регулярных проблем gcc с lto? Я собирал clang самим clang-ом. LLVM+Clang 7/8 без LTO, LLVM+Clang 9 с "-flto=thin".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Michael Shigorin (ok), 21-Янв-20, 19:42
	> Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Подключайте десятки гигабайт свопа -- tmpfs+swap работает всё равно быстрее ext4, например.
	Ответить \| Правка \| К родителю #76 \| Наверх \| Cообщить модератору


	135. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от юникснуб (?), 23-Янв-20, 19:25
	Использовать журналируемые ФС для временных файлов (а сборка именно их и создаёт, там ничего такого невосполнимого-ценного нет) вообще не очень мудрая идея. ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Red Hat развивает JIT-компилятор MIR"	–1 +/–
Сообщение от Аноним (3), 21-Янв-20, 09:57
Чем оно лучше GNU Lightning?
Ответить \| Правка \| Наверх \| Cообщить модератору


	118. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от GentooBoy (ok), 22-Янв-20, 09:18
	Разные подход к снаряду, в GNU Lightning нет промежуточного языка. Тут в пору спросить чем лучше wasm or polyglot
	Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Red Hat развивает JIT-компилятор MIR"	–2 +/–
Сообщение от A.Stahl (ok), 21-Янв-20, 10:01
Это что же, у нас будут интерпретаторы Си и Си++? Они понимают что через полгода после релиза питонисты и прочие ПХПшники начнут массово убивать себя от безысходности? Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...
Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от наше имя легион (?), 21-Янв-20, 10:14
	так а по какой такой понятной причине? ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от A.Stahl (ok), 21-Янв-20, 10:16
	У тебя есть "подкроватный" сервер? Вот и попробуй выпилить оттуда Лисп и сам всё поймёшь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	149. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Аноним (149), 25-Янв-20, 23:29
	# eix -I lisp No matches found ну в принципе да, нельзя вытеснить того, чего нет
	Ответить \| Правка \| Наверх \| Cообщить модератору


	150. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от Michael Shigorin (ok), 25-Янв-20, 23:38
	> # есть закурить? > No matches found "а если найду?" >>> ну в принципе да, нельзя вытеснить того, чего нет (простите (не . удержался))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Red Hat развивает JIT-компилятор MIR"	+3 +/–
	Сообщение от Аноним (19), 21-Янв-20, 11:09
	Не вытеснят из-за порогов вхождения в Питоны и Пыхи.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	26. "Red Hat развивает JIT-компилятор MIR"	–2 +/–
	Сообщение от A.Stahl (ok), 21-Янв-20, 11:34
	> Не вытеснят из-за порогов вхождения в Питоны и Пыхи. Си прост, да и Си++ не сложен пока не возиться с шаблонами и не городить что-то нетривиальное с наследованием. "Питоны и Пыхи" просто станут не нужны. Я во всяком случае не вижу никаких их преимуществ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Red Hat развивает JIT-компилятор MIR"	–2 +/–
	Сообщение от Аноним (37), 21-Янв-20, 12:44
	Трoллинг глупостью в 2020 году смотрится уже немного архаично, не находите?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Red Hat развивает JIT-компилятор MIR"	+6 +/–
	Сообщение от Аноним (-), 21-Янв-20, 14:36
	Ну так и не тролльте.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	136. "Red Hat развивает JIT-компилятор MIR"	+/–
	Сообщение от юникснуб (?), 23-Янв-20, 19:26
	Интересно, а зачем использовать C++, если не использовать его нетривиальные возможности? Захотелось просто так в ногу пострелять?
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору