forum.opennet.ru

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

Оглавление

Red Hat развивает JIT-компилятор MIR, opennews (??), 21-Янв-20, (0) [смотреть все]

Может всё-таки 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]

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ообщить модератору

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

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

Партнёры:

Хостинг:

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

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


	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ообщить модератору