Сообщение от voraa
|
А вы думаете действия с BigInt работают напрямую? Там тоже циклы, только скрыты во внутренних библиотеках поддержки этих данных.
|
Скрытыe циклы работают на низком уровне машинного кода на полной скорости, которую способен обеспечить процессор.
А циклы верхнего уровня ни в какое сравнение не идут по производительности и их лучше избегать в узких местах.
Сообщение от voraa
|
А память симулируемой машины? Ее же тоже надо журналировать для отката.
Как быстро переполнится память на машине симуляторе?
|
Вот поэтому у меня операции с памятью никак не поддерживаются, но частично симулируется через графику в Canvas как видеобуфер.
Журналировать каждый доступ к памяти - дело крайне не благодарное. Но для работы со стеком я думаю на минимальном уровне как-то это обеспечить.
В первую очередь, оболочка разрабатывалась для тестирования алгоритмов построения отрезков по Брезенхэму, где запросы к машине - минимальны, нет нужды в рекурсиях или стеке и не требуются тяжёлые вычисления.
Сообщение от Aetae
|
Ну очевидно тут что надо релизовать единый интерфейс n-битного числа, со всеми нужными методами операций как битовых, так и математических, после чего реализовать его для каждого нужного, неважно как: на bigint или arraybuffer, а то и в webassebly закодить.
А потом просто использовать прозрачно в вычислениях не заморачиваясь, что там под капотом, пока это не станет узким местом.
|
Вот потому нужно разработать некий генератор функций развёрнутых циклов.
(Когда-то я уже делал подобное
здесь: Там в «<textarea id=Pattern» псево-языком описывается шаблон генерирования сотен функций…)
При эмуляции работы некоего процессора всегда чего-то не хватает из всего набора языка, так как процессор всегда работает немного иначе, чем можно выразить синтаксисом ЯВУ.
Вот, например, операция
Деления над массивом в JS отсутствует и её приходится реализовывать в цикле явно, хотя на уровне процессора такая инструкция есть и выполняется на порядок быстрее.
Проблема в том, что авторы JS не предусматрели подобные матричные операции на базовом уровне. Что говорить, если процессор может одной командой переставить нужные члены массива, а в ЯВУ нужно явно самому их переставлять.
Так, в процессоре с поддержкой AVX-512 одно машинное слово может представляться как Uint8Array(64), Uint16Array(32), Uint32Array(16), Uint64Array(8) и т.д. То есть, здесь слово выступает как микромассив фиксированной длины и с гарантией, что над всеми членами этого массива практически любая операция будет выполняться параллельно. Сам синтаксис языка не поддерживает такой операции, хотя аппаратно она существует.
Спасибо за ссылку, но там несколько иная тематика.
Сейчас, как говорил выше, очень не хватает набора из Uint16ClampedArray, Int16ClampedArray, Uint32ClampedArray, Int32ClampedArray, Uint64ClampedArray, Int64ClampedArray и т.п. (
сабж)
Всё это есть в архитектурах с поддержкой SIMD, но языки как-то не поспевают в след за процессорами!
Получается, будто объектная модель процессорного машинного кода в узких местах даже богаче, чем у JavaScript.
![Haha](images/smilies/haha.gif)
К сожалению.