SergeySerge11

Это вообще правильно?

Да, это правильно и это по сути единственный адекватный способ отмены долгоиграющих операций.
Когда-то давно у потоков был метод Abort, но его удалили, тк его использование очень часто приводило к неприятным багам.
Ну и пихать проверку cancellation token повсюду не обязательно.

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

Безопасно - никак, если эта неуправляемая функция не предоставляет интерфейс для отмены.
Даже если бы и был способ (тот же Abort), то прерывание неуправляемого кода очень вероятно приведёт к утечке ресурсов (в лучшем случае не будет освобождена динамическая память)

//...declarations and initializations omitted
           do
           {
               //...some code omitted
               if (j != i)
               {
                   swap(i, j);
                   i = j; 
               }
           } while (j != i);

Не работает, потому что вы сначала присваете j значение i, если они не равны, а потом, в условии продолжения цикла, сравниваете их значения. Естественно, они будут равны и выход их цикла получится на первой же итерации. Проверять i==j как условие выхода из цикла надо чуть раньше, например, так:

//...declarations and initializations omitted
           do
           {
               //...some code omitted
               if (j != i)
               {
                   swap(i, j);
                   i = j; 
               }
               else break;
           } while (true);

Ну, а что до второго вопроса, то в .NET, начиная с 6.0 есть класс System.Collections.Generic.PriorityQueue<TElement,...

Есть простой трюк сильно упростить задачу: Измените переходы из "конечной" вершины - она теперь с вероятностью 100% будет вести только в саму себя. Таким образом, процесс хотя бы раз достигший вершины, навсегда в ней останется.

А вопрос из задачи (если его понимать как: минимальное количество шагов, чтобы хотя бы раз посетить конечную вершину с вероятностью >99%) становится эквивалентен: минимальное количество шагов, чтобы быть в конечной вершине с вероятностью не меньше 99%.

А тут уже надо найти минимальное число k, такое что соответствующее значение в матрице A^k было бы > 0.99. A тут - это матрица переходов.

Можно или в тупую умножать матрицу саму на себя, пока значение в строке начальной вершины и столбце конечной вершины не станет достаточно большим. Это будет O(N^3*ответ). Или можно делать хитро: бинарным поиском перебирайте степень, а внутри логарифмическим возведением в степень считайте A^k. Это будет O(N^3*log(ответ)^2).

// в откладке показывает TRUE, но как-будто false отрбатывает

Предположу, что это просто глюк дебаггера. У меня он вообще не может прочитать значение Ptr и пишет вот что:

Failed to read static field: Статическая переменная недоступна, поскольку еще не инициализирована. (Исключение из HRESULT: 0x8013131A). The error code is CORDBG_E_STATIC_VAR_NOT_AVAILABLE, or 0x8013131A.

Может быть, дебаггер пытается разыменовать указатель

Но если попытаться вывести в консоль значение Ptr, то будет 0:

unsafe {
  void* x = null; // Можно выводить и Env.Ptr - будет тот же результат
  Console.WriteLine((nint)x); // 0
}

В risc вроде там куча csr регистров

Вот на этом месте остановись. RISC -- это не конкретный набор инструкций и регистров, это принцип организации набора инструкций. RISC-процессоры все разные, возьми крнкретный и разбирайся с ним, не вали их все в одну кучу, не ставь на вопрос теги процессоров которые не имеют к нему отношения.

на разных компиляторах одна си операция ассемблируется то в комбинацию lui + addi, то в комбинацию auipc +addi

Ты указал ARM в тегах, но у ARM нет инструкций lui и auipc. Такие инструкции есть у RISC-V.
Если ты посмотришь в The RISC-V Instruction Set Manual, раздел 2.4 Integer Computational Instructions, то увидишь, что опкод lui загружает константу собранную из 20 битов непосредственного значения из инструкции и 12 нулевых младших битов в целевой регистр, а auipc прибавляет такую же точно константу к PC и загружает в целевой регистр результат сложения, и в этом вся разница между ними.

где какая используется не совсем понимаю.

lui используется для генерации констант, которые не зависят от того, где расположен код, а auipc для генерации констант, которые двигаются вместе с кодом. Т.е. Если ты хочешь вызвать функцию, которая находится дальше чем ±2К от точки вызова, ты можешь сгенерировать её адрес инструкцией auipc, и полученный код будет работать одинаково, независимо от того, по какому адресу он будет размещён. А если тебе надо поместить в регистр константу, например 0x12345678, то ты можешь это сделать парой инструкций lui rd, 0x12345 ; addi rd, rd, 0x678 и значение константы будет всегда одинаковым, вне зависимости от того, где будет этот код.

Каким образом одинаковые адреса различаются. Или они просто не могут быть одинаковыми(типа ос позаботиться)?

Если есть MMU и он используется ОС, то есть и виртуальные адреса и они могут быть одинаковыми у разных процессов. Если MMU нет или он не используется, то ОС размещает все процессы в одном адресном пространстве, нет смысла говорить отдельно о виртуальных адресах, поскольку они равны физическим, адреса выделяемые ОС разным процессам могут быть как одинаковыми (например несколько процессов запущенных из одного исполняемого образа могут использовать один и тот же код и константные данные), так и разными (например изменяемые данные разные у всех процессов, а стеки разные у всех потоков).

Как они в tlb обрабатываются, если вдруг они реально могут быть одинаковыми, и там нету ни каких дополнительных индексов процесса)

Выбери конкретную процессорную архитектуру -- обсудим. у многих RISC-архитектур есть ASID, который идентифицирует адресное пространство и записывается вместе с виртуальным адресом в TLB. Но в любом случае ASID -- это просто оптимизация для повышения производительности, когда он отсутствует или переполняется ОС должна сбрасывать содержимое TLB при переключении адресного пространства.

У ARM есть регистры TTBR с примерно той же функцией, что и cr3 в x86.
У RISC-V есть CSR satp, содержащий ASID и базовый адрес корневого каталога страничных таблиц. Об этом можно прочитать в разделе 4.1.12 Supervisor Address Translation and Protection (satp) Register спецификации The RISC-V Instruction Set Manual Volume II: Privi....

Почему нужно 512-356 байт нулями заполнять, почему нельзя продолжить дальше. Ведь следующая после 86*4 байт инструкция(или переменная) будет выровнена

А вот еслы бы ты тупо взял и прочитал документацию на директиву .p2align, то у тебя таких вопросов не было бы. Потому что никто не заполняет 512-356 байт после. .p21lign выравнивает текущий адрес по заданной степени двойки. Обычно для этого есть аппаратные причины, например базовый регистр таблицы векторов прерываний может иметь 9 младших бит зафиксированных в 0. Или вот по границе страницы MMU выравнивают данные в ELF-файлах, чтобы можно было установить отдельно разрешения RX для кода и констант и RW для изменяемых данных.

для получения элемента допустим table[index_nBit] можно применять операцию ИЛИ вместо сложения. Что быстрее. В этом ли дело

Нет, не в этом.

Какой смысл команды dup в JVM байт коде?

Жаль что ты не программировал на калькуляторе МК 60. Это целая эпоха.

Значит есть разные пути к вычислению арифметики. Например если тебе надо возвести в квадрат число 5 на регистровой машине - то ты должен загрузить регистр R1 числом. Потом регистр R2. И потом найти такую команду умножения которая свяжет регистры R1 и R2 и перемножит и сохранит еще где-то результат. В силу современного зоопарка процессоров практически нереально создать такой абстрактный байткод который бы эффективно отображался на опкоды разных железяк. Поэтому решили забить на регистровую машину. И использовать стек как хранилище операндов для операций. Разумеется в JVM есть и аналоги регистров но с ними не выполняются операции. ЕМНИП. Если хошь что-то сложить или вызвать функцию - то положи на стек и там-же получи результат. И если вернуться к возведению числа 5 в квадрат это может быть так

положить 5 на стек.
дублировать
вызвать функцию умножения

На каком-нибудь языке Forth это было-бы тремя командами
5 DUP * .
Результат - на вершине стека.

Это кратко записывается. Но это несет абсолютно ту-же смысловую нагрузку для арифметики.

Почему их только 256 может быть?

А чорт его знает. Так решили. Решили что 256 регистров это капец какой максимум для процедуры или функции. Послушай ради интереса видосы про процессор Эльбрус. Там тоже интересно с регистрами сделано.

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

Я думаю что твое предположение о том какой код соберет JIT не совсем верное.
Вместо спора я предлагаю взять какой-то тестовый сценарий и подсмотреть какой
будет собран код. Я знаю что скептики Java обычно после изучения вопроса глубже
меняют свою точку зрения. Ну по крайней мере перестают считать Java
"медленным покемоном". Java действительно была слоупоком во времена Jdk 1.1.
Но щас это не так.

Несколько лет назад я мерял производительность floating-point вычислений на приложении
которое рендерит зеркальные шары. И разница между С++ и Java была не сильно большая.
10 секунд на сях и 12 секунд на втором языке соотв. Хотя этот тест узкий и он просто
показывает частный случай.