Телеграмм чат группы compilerdev страница 1793

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Compiler Development

996 membersпожаловаться на группу

2020 December 02

BD

Berkus Decker in Compiler Development

Довольно прикладной вопрос: неужели c++ компиляторы не умеют в частичную компиляцию?
Например, изменил одну букву в стринг литерале, он не может понять, что только это нужно заменить? Или есть какие-то тонкости, которые эту возможность убивают? Или может тогда компиляция становится очень сложной и долгой, и быстрее будет почти всегда просто скомпилировать как обычно?

умеют в incremental compilation, но не все. посмотри в выхлоп препроцессора (это то что компилятор получает на вход) и ужаснись.

источник

01:10пожаловаться #1

BD

Berkus Decker in Compiler Development

обычно три строки превращаются в пару мегабайт текста

источник

01:10пожаловаться #2

E

EgorBo in Compiler Development

https://lemire.me/blog/2020/10/20/ridiculously-fast-unicode-utf-8-validation/

Daniel Lemire's blog

Ridiculously fast unicode (UTF-8) validation

One of the most common “data type” in programming is the text string. When programmers think of a string, they imagine that they are dealing with a list or an array of characters. It is often a “good enough” approximation, but reality is more complex. The characters must be encoded into bits in some way. Most … Continue reading Ridiculously fast unicode (UTF-8) validation

мы кстати тестили свой алгоритм валидации утф8 и он оказался быстрее :)

источник

01:14пожаловаться #3

M

MaxGraey in Compiler Development

https://lemire.me/blog/2020/10/20/ridiculously-fast-unicode-utf-8-validation/

Daniel Lemire's blog

Ridiculously fast unicode (UTF-8) validation

One of the most common “data type” in programming is the text string. When programmers think of a string, they imagine that they are dealing with a list or an array of characters. It is often a “good enough” approximation, but reality is more complex. The characters must be encoded into bits in some way. Most … Continue reading Ridiculously fast unicode (UTF-8) validation

Эта не та валидация)

источник

01:14пожаловаться #4

А⚙

Антон ⚙️ in Compiler Development

мы кстати тестили свой алгоритм валидации утф8 и он оказался быстрее :)

На каких строках вы сравнивали эти алгоритмы? По 4 байта?

источник

01:15пожаловаться #5

BD

Berkus Decker in Compiler Development

мы кстати тестили свой алгоритм валидации утф8 и он оказался быстрее :)

крутяк, а в чем разница?

источник

01:15пожаловаться #6

E

EgorBo in Compiler Development

Антон ⚙️

На каких строках вы сравнивали эти алгоритмы? По 4 байта?

на разных all-latin, mostly-latin, на других данных наш хуже

источник

01:15пожаловаться #7

h

hazer_hazer in Compiler Development

Кстати, ещё вопросек.

Когда такие большие япы, как плюсы, принтят кусок кода, где ворнинг/ошибка, они используют CST или кусок кода вырезают?

источник

01:16пожаловаться #8

BD

Berkus Decker in Compiler Development

Эта не та валидация)

в компиле тебе не надо ничего большого валидировать - у тебя лексер читает входной утф-8 поток и сразу же расставляет спаны, отвалидировать что идентификатор в спане подходит под правила идентификатора - дешево (даже для идентификатора длиной под килобайт, и часто у вас такие попадаются в сорцах?)

источник

01:17пожаловаться #9

E

EgorBo in Compiler Development

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

источник

01:17пожаловаться #10

BD

Berkus Decker in Compiler Development

Кстати, ещё вопросек.

Когда такие большие япы, как плюсы, принтят кусок кода, где ворнинг/ошибка, они используют CST или кусок кода вырезают?

LLVM использует Source buffer - это весь исходник в памяти + спаны

источник

01:19пожаловаться #11

h

hazer_hazer in Compiler Development

LLVM использует Source buffer - это весь исходник в памяти + спаны

То есть и clang соответственно...
А что насчет g++ не знаете? 😳

источник

01:20пожаловаться #12

BD

Berkus Decker in Compiler Development

То есть и clang соответственно...
А что насчет g++ не знаете? 😳

не знаю, туда не закапывался, до совсем недавних версий он не был эталоном по репортингу ошибок

источник

01:21пожаловаться #13

M

MaxGraey in Compiler Development

в компиле тебе не надо ничего большого валидировать - у тебя лексер читает входной утф-8 поток и сразу же расставляет спаны, отвалидировать что идентификатор в спане подходит под правила идентификатора - дешево (даже для идентификатора длиной под килобайт, и часто у вас такие попадаются в сорцах?)

Недёшево, вообще недешего. Дело в том что там используется разряженная интервальная таблица которую проходят либо quick search ам или пакуют в в префиксное дерево. В любом случае нужно брать каждый codepoint для идентификатора и искать по этой таблице. При чем таблицы две - одна используется для первого символа, остальная для оставшейся части.

источник

01:22пожаловаться #14

BD

Berkus Decker in Compiler Development

Недёшево, вообще недешего. Дело в том что там используется разряженная интервальная таблица которую проходят либо quick search ам или пакуют в в префиксное дерево. В любом случае нужно брать каждый codepoint для идентификатора и искать по этой таблице. При чем таблицы две - одна используется для первого символа, остальная для оставшейся части.

но поскольку иденты короткие - итоговая стоимость невелика. пока оно не начнет у меня в профайлере занимать первые строчки, вообще не буду париться. особенно для пробного ЯП - вы не забывайте что тут не все пишут industrial grade compilers. и контекст дискуссии тоже.

источник

01:24пожаловаться #15

M

MaxGraey in Compiler Development

но поскольку иденты короткие - итоговая стоимость невелика. пока оно не начнет у меня в профайлере занимать первые строчки, вообще не буду париться. особенно для пробного ЯП - вы не забывайте что тут не все пишут industrial grade compilers. и контекст дискуссии тоже.

Ну да, порой забываю. В любом случае для toy language можно всем этим пренебречь и спользовать стандартные строки везде

источник

01:26пожаловаться #16

BD

Berkus Decker in Compiler Development

так то я согласен что все эти копошения со строками в итоге сжирают кучу памяти и времени - не даром LLVM утыкан всякими SmallVec, SmallString etc

источник

01:27пожаловаться #17

M

MaxGraey in Compiler Development

так то я согласен что все эти копошения со строками в итоге сжирают кучу памяти и времени - не даром LLVM утыкан всякими SmallVec, SmallString etc

Ну SmallVec сделан дял экономии памяти, а для ускорения доступа и добавления элементов маленькие массивы, там просто используется статический фиксированный массив для всех элементов мень 16 скажем (обычно граница через шаблонный параметр задается)

источник

01:29пожаловаться #18

M

MaxGraey in Compiler Development

Ну SmallVec сделан дял экономии памяти, а для ускорения доступа и добавления элементов маленькие массивы, там просто используется статический фиксированный массив для всех элементов мень 16 скажем (обычно граница через шаблонный параметр задается)

И это как раз пример того, как жертвуют памятью в угоду скорости)

источник

01:29пожаловаться #19

PS

Peter Sovietov in Compiler Development

«Ужасы нашего городка» :)



BEAM/C generated a single C function for each Erlang module. Local calls within the module were made by explicitly pushing the return address to the Erlang stack followed by a goto to the label of the called function. (Strictly speaking, the calling function stores the return address to BEAM register and the called function pushes that register to the stack.)

Calls to other modules were done similarly by using the GCC extension that makes it possible to take the address of a label and later jumping to it. Thus an external call was made by pushing the return address to the stack followed by a goto to the address of a label in another C function.

Отсюда: http://blog.erlang.org/the-road-to-the-jit/

blog.erlang.org

The Road to the JIT

As long as Erlang has existed, there has always been the need and the
ambition to make it faster. This blog post is a history lesson that
outlines the major Erlang implementations and attempts to improve
the performance of Erlang.

источник

01:32пожаловаться #20