BD
написать простой пример llvm pass для блога чтобы векторизовать цикл? Неее, лучше написать парсер для сасета Си -_-
на год посмотри
Size: a a a
2020 February 02
E
на год посмотри
и?
E
ллвм давно уже был
E
компиляторщиков хлебом не корми - дай парсер написать :)
МБ
У LLVM долго с автовекторизацией было плохо. Кроме того, человек хотел в алгоритме векторизации разобраться, а не в интерфейсе LLVM. Разные цели
МБ
не знаю, читали или нет, но вот чувак делал микропарсер сабсета Си чисто для автовекторизации — https://leiradel.github.io/2011/05/05/Auto-Vectorization-1.html
Спасибо
BD
компиляторщиков хлебом не корми - дай парсер написать :)
статью не читай, компиляторщиков осуждай, да да
E
статью не читай, компиляторщиков осуждай, да да
факт
BD
факт
там больше всего поучителен итог, этим оно и ценно )
E
где-то у меня есть ветка в которой я запилил автовекторизацию в дотнет :)
AT
Недавно наткнулся. В чём-то в тему.
BD
где-то у меня есть ветка в которой я запилил автовекторизацию в дотнет :)
молодец, хвалю
AS
компиляторщиков хлебом не корми - дай парсер написать :)
Ноуп. Мне бы рантайм делать в разы приятнее делать. Или jit-ы
E
Ноуп. Мне бы рантайм делать в разы приятнее делать. Или jit-ы
мужик
C
Ноуп. Мне бы рантайм делать в разы приятнее делать. Или jit-ы
🤔интересно, есть уже что-то готовое?
AS
🤔интересно, есть уже что-то готовое?
В процессе
KR
Система ownership-borrowing в Rust - частный случай линейных (аффинных) типов. В Clean линейные типы всегда были, в Haskell хотят добавить. Есть пейпер, но фактически встроить в GHC - сложно. Поэтому пока ждём-с.
В Clean другие умолчания кажется. Т.е. если мы пишем
Start = z
where z = 1
То z - это обычное значение, не уникальное. Или я неправ?
Start = z
where z = 1
То z - это обычное значение, не уникальное. Или я неправ?
AT
В Clean другие умолчания кажется. Т.е. если мы пишем
Start = z
where z = 1
То z - это обычное значение, не уникальное. Или я неправ?
Start = z
where z = 1
То z - это обычное значение, не уникальное. Или я неправ?
Думаю, правы. Не очень понимаю, к чему Вы клоните. 😊
KR
Думаю, правы. Не очень понимаю, к чему Вы клоните. 😊
Можно сказать, что я перечитал на ночь про всякие мультиклеты и т.д. Но меня последнее время складывается ощущение, что следующий системный язык, который может заменить C, должен быть сделан на базе чего-то Клинообразного. Rust тут не подходит по ряду причин - слишком сложный, жёстко задана последовательность исполнения (EPIC/EDGE, OOO процессоры работают не так).
Но для системного языка требуются другие умолчания - достаточно очевидно, что в нём база памяти - это стек, а не куча. Он же должен быть близок к железу, предсказуем и быстр.
Но для системного языка требуются другие умолчания - достаточно очевидно, что в нём база памяти - это стек, а не куча. Он же должен быть близок к железу, предсказуем и быстр.
МБ
Можно сказать, что я перечитал на ночь про всякие мультиклеты и т.д. Но меня последнее время складывается ощущение, что следующий системный язык, который может заменить C, должен быть сделан на базе чего-то Клинообразного. Rust тут не подходит по ряду причин - слишком сложный, жёстко задана последовательность исполнения (EPIC/EDGE, OOO процессоры работают не так).
Но для системного языка требуются другие умолчания - достаточно очевидно, что в нём база памяти - это стек, а не куча. Он же должен быть близок к железу, предсказуем и быстр.
Но для системного языка требуются другие умолчания - достаточно очевидно, что в нём база памяти - это стек, а не куча. Он же должен быть близок к железу, предсказуем и быстр.
Почему очевидно? Системный язык должен позволять писать/читать memory mapped io (без учёта всякого x86 legacy) и позволять дать гарантии на задержки в последовательностях этих чтений и записей, в том числе, при возникновении прерываний. Остальное, вроде как, не особо критично.
И уже из этого надо исходить. По идее, можно придумать, как это всё и с кучей сделать.
И уже из этого надо исходить. По идее, можно придумать, как это всё и с кучей сделать.