Струны и пряди в MoarVM

Насколько я понимаю, тот факт, что MoarVM реализует цепочки (иначе говоря, объединение двух строк приведет только к созданию цепочки, состоящей из ссылок на исходные строки), на самом деле является деталью реализации.

Вы можете реализовать язык программирования Raku без необходимости реализации цепочек. Следовательно, по крайней мере, насколько мне известно, это невозможно проанализировать.

Был PR, чтобы выставить nqp :: op, который фактически объединит нити в одну строку, но это было отклонено / закрыто: https://github.com/rakudo/rakudo/pull/3975

При запуске кода Raku на Rakudo с бэкэндом MoarVM есть ли способ распечатать информацию о том, как данный Str хранится в памяти изнутри запущенной программы?

Мое обоснованное предположение - да, как описано ниже для App::MoarVM модулей. Тем не менее, мое образование пришло из степени, которую я получил в Невидимом университете, и волшебник исключил меня за то, что я слишком много гадал, так что ...

В частности, мне любопытно, есть ли способ узнать, сколько нитей в настоящее время составляют Str (будь то интроспекция Raku, NQP или что-то, что имеет доступ к уровню MoarVM (существует ли такая вещь во время выполнения?).

Я на 99,99% уверен, что нити - это просто деталь реализации бэкэнда, и без особых уловок MoarVM не будет доступа Raku или NQP к этой информации. Тем не менее, читайте дальше.

Если нет возможности получить доступ к этой информации во время выполнения

Я вижу, что есть доступ во время выполнения через MoarVM.

есть ли способ получить это через вывод одного из флагов командной строки Rakudo, таких как --target или --tracing? Или через отладчик?

Я на 99,99% уверен, что есть несколько способов.

Например, в файле ops.c MoarVM есть несколько строк кода отладки, которые начинаются с _ 3_.

Возможно, более интересным является то, что кажется настоящей золотой жилой сложных функций отладки и профилирования, встроенных в MoarVM. Плюс то, что кажется специфическими модулями Rakudo, которые управляют эти функции, предположительно, через код Raku. Чтобы найти около дюжины статей, в которых обсуждаются некоторые аспекты этих функций, я предлагаю прочитать блог Timotimo. Просматривая github, я вижу текущие коммиты, связанные с функциями отладки MoarVM в течение многих лет и вплоть до 2021 года.

Наконец, управляет ли MoarVM количеством Strands в заданной Str?

да. Я вижу, что код обработки строк (некоторые ссылки приведены ниже), который был написан samcv (чрезвычайно умным и осторожным) и, как мне кажется, рассмотрен jnthn, имеет логику, ограничивающую количество цепочек.

Я часто слышу (или говорю), что одна из суперспособностей Раку заключается в том, что он может индексировать строки Unicode за время O (1), но я думал о патологическом случае, и мне кажется, что это будет O (n) .

Да, если бэкэнд, поддерживающий пряди, не управлял количеством прядей.

Но для MoarVM я думаю, что цель состоит в том, чтобы установить абсолютную верхнюю границу с помощью _ 4_ в MVMString.h файле MoarVM и логика, которая проверяет это (и другие характеристики строк; см. это else if заявление в качестве примера). Но логика достаточно сложна, а мой C достаточно скуден, так что я даже близко не могу выразить уверенность в этом, даже если я могу сказать, что это, по-видимому, является намерением.

Например, (^$n).map({~rand}).join кажется, что он создаст Str с длиной, пропорциональной $n, которая состоит из $n нитей.

Я на 95% уверен, что строки, построенные такими простыми соединениями, будут O(1).

Это основано на моем мнении, что операция соединения строки уровня Raku / NQP обрабатывается _ 11_, и мои попытки понять, что делает этот код.

Но я знаю, что можно сгладить Strand-ed Str; сделает ли MoarVM что-то подобное в этом случае?

Если вы прочтете код, то обнаружите, что он обрабатывает очень изощренно.

Или я неправильно понял что-то более важное?

Я почти уверен, что неправильно понял что-то базовое, поэтому я не буду комментировать, есть ли у вас. :)