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

[ivagor]

Понятно, но тут скорее проблема не в самом paint, а опять в get/put. В 2.891 все нормально.
Ну и на солнце тоже есть пятна, в оригинальном paint были две ошибки, которые исправил в 2.80 и 2.88. Другое дело, что авторы "классических" программ если напарывались на те ошибки, то могли их обходить.

[ivagor]

1. В 2.99 исправил ошибку GET (была в 2.90-2.98), которая в GRAF при определенных условиях приводила к вылету в бейсик при последующем PAINT.
2. Сделал универсальный вариант GRAF 5.3U, который работает и в 2.5-2.891 и в 2.99. Программа при этом не увеличилась, а даже немного сократилась. Можно резюмировать, что без POKE внутрь массива GET вполне можно обойтись.

Ramiros, еще раз спасибо за багрепорты!

Upd 07.12.2023: 2.99fix - исправлен RENUM

Upd 26.12.2023:
В старых MS бейсиках на очень многих платформах есть баг (на 8080 его исправили в 5.x), проявляющийся при ошибке в вычислении функции VAL (видео). В 2.991 исправил, но пришлось убрать восьмеричные числа, которые были с 2.61 (в 2.5 их не было), т.к. места не хватало. 2.99fix не убираю на случай если кому-то хочется восьмеричных и не так важны ошибки при вычислении VAL.

Upd 27.02.2024: 2.992 - Исправлены/доработаны CLS и определение переполнения порядка числа при его переводе из символьного представления в двоичное.

Upd 09.03.2024: 2.993 - Исправлен RETURN, небольшие опимизации.

2.99x в картотеке

[ivagor]

Решил узнать, сколько быстродействия у медленного Мандельброта крадет зловредное оформление программы. Убрал REM и лишние пробелы, максимально "упаковал" в строки через двоеточние, перенумеровал с минимальным шагом. Алгоритм и все операции остались без изменений.

06Ц 2.5 (Emu) - 403.854 секунды вместо 439.896 у оригинала, на 8% быстрее
06Ц 2.99 (Emu) - 166.913 секунды вместо 176.198 у оригинала, на 5% быстрее
2.99 эффективнее борется с избыточностью программы.

Корвет бейсик 2.0/пзу (Emu80) - 486 секунд (по секундомеру) вместо 564.92 у оригинала (по данным litwr, Emu), на 14% быстрее
Повторюсь, что корветовский бейсик сам не удаляет начальные пробелы в строке, поэтому эффект от уборки мусора больше. У корвета еще остается резерв в виде частичного использования целых.

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

[svofski]

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

Все таки ты оцениваешь этот бенчмарк очень предвзято, имея глубокие познания о том, как работают Бейсики. Мы от тебя узнали, что Корвет тормозит от пробелов и теперь трудно это забыть обратно. Но мне как раз очень легко представить себе, что кто-то писал для Корвета, используя пробелы. Особенно потому, что скорее всего эту фичу кто-то сделал нарочно, чтобы придать Бейсику какое-то подобие структурности.

Ну и смысл бенчмарка по-моему не в запредельной оптимизации, а в сравнении разных величин при фиксированной постоянной.

[ivagor]

1. Работа над ошибками.
Сначала сделал почти правильно. Потом, к сожалению, убрал один символов из "палитры", отсутствующий в 2.5 (и не только в 2.5 и не только на векторе). Это немного влияет на результат, что особенно важно при сравнении с другими компьютерами, поэтому вернул символ в "палитру" (вместо ~ использовал -). Время везде в секундах.

Оригинал:
06Ц 2.5 (Emu) - 453.375
06Ц 2.99 (Emu) - 181.43
Корвет 2.0/пзу (Emu, по данным litwr) - 564.92

Оптимизированный вариант:
06Ц 2.5 (Emu) - 416.214, на 8% быстрее оригинала
06Ц 2.99 (Emu) - 171.905, на 5% быстрее оригинала
Корвет 2.0/пзу (Emu80, по секундомеру) - 501 секунда, на 11% быстрее оригинала

Чтобы не было сомнений приложил исходники.

ты оцениваешь этот бенчмарк очень предвзято

2. На мой взгляд предвзятость - это введение в тест быстродействия нескольких элементов, которые часть бейсиков проигнорируют, а часть будут тратить на них время.
От пробелов тормозят все интерпретаторы, но нюанс в том, что некоторые (потомки msbasic 3.2, в т.ч. векторовский 2.5) убирают часть незначащих пробелов при вводе строки, а часть (более поздние msbasic, в т.ч. корветовский и, например, msxный) не убирают.
Особое оформление исходника - это нормально например в целях обучения. Но если это тест быстродействия и элементы оформления влияют на скорость, то по моему мнению их (элементы оформления) надо минимизировать.
До каких пределов минимизировать - вопрос для обсуждения. Как вариант - минимизировать до достижения максимальной переносимости теста при сохранении его правильной работы.
При таком подходе точно лишние:
1. Куча строк с комментариями, которые часть бейсиков будут пробегать каждый раз в цикле при поиске номера строки, а часть проигнорируют.
2. Пробелы в начале строк.
3. Длинные номера строк.

Пробелы между операторами части бейсиков (но не 2.5) нужны, тут компромисс более-менее понятен.
Разбиение всех операций на индивидуальные строки, без двоеточий - понятно, кому это нужно, но для MSBASICов это тормоз.
Также отмечу, что в подобных тестах целесообразно приводить точность вычислений для каждой платформы. У 2.5 и Корвета (в данном тесте!) 3 байта мантиссы и 1 байт экспоненты, двоичное представление.

[ivagor]

Результаты лучше смотреть не в посте litwr, а на gitlab, т.к. там приведена точность расчетов и на чем тестировали.

[Advertiser]

[ivagor]

Бесконечно можно не только смотреть на огонь, воду и работу других людей, но и обсуждать Мандельброта. На неделе придумал, как еще оптимизировать поиск двухбуквенных переменных (оригинальный Мандельброт за 163.618 секунды, на 10% быстрее 2.99), что позволяет обойти в таблице результатов БК0011. Но резервов по свободному месту уже не было, пришлось пойти на пару небольших компромиссов. Проблема в том, что пока не нашел других программ, в которых эта оптимизация давала бы настолько выраженный эффект, поэтому оставил этот бронепоезд на запасном пути. Тогда решил зайти с другой стороны - раз в других программах новая оптимизация мало что дает, значит основная проблема не в бейсике, а в данной реализации Мандельброта.
Показываю фокус, следите за руками. Берем manlt_optimized_corrected_06С.cas (который с косметическими оптимизациями) и всего лишь добавляем в первую строку нициализацию наиболее используемых переменных - получили manlt_optimized2_06С.cas. И вуаля - он выполняется в 2.99 за 144.509 секунды, чуть опережая даже BBC Basic на BBC Micro, и с запасом обходя БК0011 и Amstrad CPC. Подводя итог можно сказать, что удалось разоблачить и обезвредить диверсионную реализацию Мандельброта. Не стоит воспринимать этот тест слишком серьезно, хотя можно взять на заметку некоторые моменты.
Если важна скорость в векторовских родственниках 2.5 (и в многочисленных родственниках msbasic 3.2 на других компьютерах), то:
1. Минимизируйте число пробелов.
2. Перенумеруйте финальную версию с шагом 1, чтобы получить минимальную длину символьного представления номеров строк.
3. В финальной версии минимизируйте число комментариев.
4. "Упаковывайте" операции в строки через двоеточия.
5. Если переменных много, и некоторые из них используются намного чаще других, то стоит их инициализировать в первую очередь. Для 2.98-2.99 это не касается числовых переменных с однобуквенными именами, они в любом случае будут обрабатываться с максимальной скоростью.

Пункты 1-3 можно доверить роботу.
Пункты 1-4 кроме ускорения одновременно приводят и к сокращению размера программы.

Результаты тестов:
2.5 - 313.279 секунды
2.891 - 257.927 секунды
2.995 - 144.209 секунды
2.996 - 133.606 секунды

[ivagor]

Получилось нечто похожее на красивую трассировку лучей. Списал домашку у Paul Dunn. 5 цветов (в т.ч. "полутоновые" тени), четкие границы квадратов в отражении благодаря точной плавучке. Красота требует жертв, готовьте супервекторы или запасайтесь терпением. Время рисования в 2.5 - примерно 389 минут (6 часов 29 минут), в 2.99 - примерно 165 минут (2 часа 45 минут).

[svofski]

Выглядит феноменально. Немного медленно, но ничего, ведь можно построить рендерфарм из тысяч Векторов и рендерить блокбастеры.

Интересно, насколько реально сделать небо неоднородным, чтобы у сфер макушка как-то выделялась?

[ivagor]

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