Бейсики для Вектора-06Ц и клонов

[ivagor]

Если порядок окончания расчетов не совпадет с тем, что ожидает мастер, то на мой взгляд это приведет лишь к задержке по времени (снижению эффективности), но не к нарушению работы.
Отвлекаясь от векторпанка можно вспомнить про КУВТы, там была какая-никакая локалка и при большом желании можно было организовать распределенные вычисления.

[Advertiser]

[svofski]

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

Как ты видишь ситуацию, когда два воркера закончили +/- одновременно и стали делать BSAVE ? И как распределять задачи, если воркеров меньше 32 ?

Что-то ЛВС-ное мы запускали через EMU, но детали как-то подзабылись. Идея с магнитофонами мне нравится больше, потому что просто понятней с чем имеем дело.

[ivagor]

Как ты видишь ситуацию, когда два воркера закончили +/- одновременно и стали делать BSAVE ?

Воркеры должны делать BSAVE только когда получат приглашение (через BLOAD) от мастера.

И как распределять задачи, если воркеров меньше 32 ?

Если серьезно, то со всех точек зрения реалистичным мне представляется вариант с двумя векторами, соединенными через магнитофонный интерфейс. Мастер рендерит половину, посылает (BSAVE) приглашение второму, дальше проблем нет.

- - - Добавлено - - -

Все же добавлю про дальше. Когда второй (или 3й, 4й и т.д.) готов, то он посылает (BSAVE) мастеру ответ. И тогда мастер ожидает 3 файла собственно с картинкой.
Возвращаясь чуть ранее - мастер должен посылать копии приглашений второму (3му, 4му, ...) пока тот не ответит, на случай если воркер отстает со своей частью рендера.

- - - Добавлено - - -

Возвращаясь чуть ранее - мастер должен посылать копии приглашений второму (3му, 4му, ...) пока тот не ответит, на случай если воркер отстает со своей частью рендера.

Но тут потребуется патчнуть BLOAD на тему таймаута, как ты написал ранее.

[svofski]

Виртуальных Векторов мы можем насоединять и два и все 32. Правда в винде черт ногу сломит как это сделать, может быть под маком или линуксом это проще будет организовать.

Как в твоей схеме разрешается конфликт я все равно не понимаю. Если сервер отправит приглашение чуть раньше времени, получатель его не услышит и тогда сервер будет ждать ответа вечно. Ну никак не обойтись без таймаута.

- - - Добавлено - - -

А, вижу, ты тоже написал про таймаут. Ну вот.. Может быть проще тогда сервер сделать не на бейсике, раз уж такие дела.

[ivagor]

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

[svofski]

И ничего не надо патчить, лишь бы оператор был рядом.

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

Есть еще вариант -- сервер ждет загрузки без имени, то есть первого попавшегося. Когда веркер заканчивает, он начинает делать BSAVE со случайными интервалами между повторами. Рано или поздно всем достанется таймслот, но может быть придется ждать очень долго, в основном из-за того, что клиент не знает продолжать ему или таки наконец заткнуться. И надо позаботиться, чтобы рандомайз был разный на всех веркерах. Еще при таком подходе не понятно, как раздавать новые задачи, если веркеров меньше 32.

BLOAD ведь делает опрос клавиш для останова оператором. Нельзя поками сделать в этом месте патч с вызовом счетчика? Чтобы не новую версию Бейсика писать. Тут не нужен какой-то изощренный таймер. Нет ответа минуту, стоп.

[ivagor]

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

[svofski]

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

[ivagor]

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

Попутно заметил, что в 2.98 слегка поломал RENUM, пофиксил.

Upd 13.12.2023: Оптимизированная версия SPGIANTRTX2.cas
Время рисования в 2.99:
SPGIANTRTX.cas - примерно 3 часа 24 минуты
SPGIANTRTX2.cas - примерно 2 часа 57 минут

[svofski]

Вах!