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

[ivagor]

Там даже несколько библиотек плавучки, хотя для вектора с 8080 имеют смысл только две. И над выбором не придется особо думать, микрософтовская библиотека (фактически аналог математики в 2.5) лучше. У zpu8080 проблема с плавучкой в ненативности, она точная, но очень уж медленная. При любой реализации пузырей, даже на асме, я бы максимально постарался отабличить.

[Advertiser]

[ivagor]

Уточненные и расширенные результаты тестирования неспешного Мандельброта. Исправил "палитру" символов (при копировании исходника в нее на каком-то этапе затесался лишний пробел). Доработал определение времени прогона.

06Ц (Emu/VV/v06x):
2.5 - 439.896 секунды, между спеком и +4
2.98fix - 176.198 секунды, между БКшками

06Ц (Emu80):
2.5 - 439.976 секунды, между спеком и +4
2.98fix - 176.218 секунды, между БКшками


Дополнительно протестировал 6128 (Emu/VV):
1.0 (пзу) - 388.618 секунды, между C64 и 800XL (на 11.5% быстрее 2.5 на 06Ц)
2.5 - 393.371 в Emu/393.391 в VV, между 800XL и dragon (на 10.5% быстрее 2.5 на 06Ц)
2.98fix - 166.394 секунды, между БКшками (на 5.5% быстрее 2.98fix на 06Ц)

Отмечу, что по разнице скорости на 06Ц и 6128 можно оценивать степень покомандной (не алгоритмической) оптимизированности под векторовское торможение. Если для 2.5 эта разница 10.5%, то для 2.98fix 5.5%, потому что в 2.98 в критичных местах MOV R,R/INR/DCR максимально заменены на альтернативные варианты. Еще можно добавить, что если оптимизировать 2.98 с использованием команд 8085, то он обойдет результат БК0011.

[ivagor]

Чуть подробнее про влияние векторовского торможения. Интересующиеся историей вектора наверняка помнят фрагмент из описания прототипа: "Эффективная тактовая частота - 2.4 МГц"
Т.е. на какой частоте должен был бы работать 8080 без торможения, чтобы соответствовать вектору на 3 МГц. Посмотрим, какой "эффективной тактовой частоте" соответствуют бейсики при выполнении Мандельброта. Результаты с торможением приведены в предыдущем посте, а результаты без торможения позволяет получить Emu, если в конфиге закомментировать adjust=4

06Ц без торможения (Emu)
2.5 - 327.855 секунд
2.98fix - 143.85 секунд

Сравнивая с "тормозными" результатами получаем, что для 2.5 эффективная частота=2.2359 МГц, для 2.98fix=2.4492 МГц.
2.5 можно отнести к плохо оптизированным под вектор программам, коэффициент торможения 0.7453 просто неприличный.
Что касается 2.98fix, то в совокупности с еще одной программой - расчет знаков Пи по алгоритму spigot считаю, что "эффективная частота" 2.43-2.45+ (коэффициент торможения 0.81-0.82) для вектора - это показатель хорошей оптимизации.
Возвращясь к авторской оценке считаю ее адекватной для умеренно оптимизированных для вектора программ. И у меня самого даже есть пример такой программы - "старый" Мандельброт на асме, в котором что-то оптимизировано, а что-то как написано первый раз так и осталось. И для того Мандельброта (не помню, выкладывал ли на форум, но точно посылал svofski) получался коэффициент торможения практически ровно 0.8, т.е. "эффективная частота" 2.4 МГц.

[ivagor]

В завершение для полноты картины еще BASCOM. Тут менее точно, т.к. засекал по секундомеру.
06Ц (Emu, mdos34) - 98 секунд, между ABC 802 и BBC Master (mode 7), т.е. вышел на второе место в том списке
06Ц без торможения (Emu, mdos34) - 74 секунды
"Эффективная частота" в данном случае=2.27 МГц, коэффициент торможения 0.76.
Ну и немного спорта:
6128 (Emu, ОС6128) - 87 секунд, первое место перед ABC 802.

[thetrik]

Перевел программу (и пофиксил некоторые баги)из журнала Радиолюбитель 8-1991:

Посылаю программу для настройки телевизоров, написанную для ПЭВМ "Вектор". Коротко о себе: ученик 11-го класса средней школы N244 г.Киева ОНИЩЕНКО Игорь.

[ivagor]

Простой (даже слишком простой) тестик, зато понятно и видно, что тестировали и как тестировали.
Время выполнения в секундах:
Amstrad CPC - 27
VIC-20 - 34
C64 - 40/38
TI-99/4A - 77
ZX Spectrum - 87
Siclair QL - 39
Atari 800XL - 50
Apple II - 36
06Ц (2.5) - 45
06Ц (2.98fix) - 21

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

[ivagor]

Медленному Мандельброту (1, 2, 3, 4) понадобился эпилог.
После простенького тестика решил еще раз взглянуть на результаты Мандельброта и глаз зацепился за удивительно медленный Корвет. Решил сам проверить и получилось вот что:
Корвет, Бейсик 2.0/пзу (Emu80) - 493 секунды (по секундомеру)
По сравнению с результатом, который привел litwr (564.92 секунды) разница очень большая. Насколько помню процессор корвета не тормозится при обращении к пзу и основному озу, а один такт ожидания добавляется при обращении к (некоторым?) портам. Даже если emu80 не 100% точен такая погрешность не могла набежать.
Какое это имеет отношение к вектору - неспешного Мандельброта протестировал только из-за наличия результатов для нескольких компьютеров. Но получается, что тем результатам нельзя доверять, печальная история.

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

Кажется понял основную причину такой разницы. Часть интерпретаторов (а компиляторам это без разницы) при вводе удаляет лишние пробелы в начале строки, а часть не удаляет. Векторовский 2.5 удаляет, а корветовские 1.1 и 2.0 - не удаляют. В оригинале щедро насыпали пробелов в начале строк внутри циклов, на самом напряженном участке, вероятно чтобы максимально затормозить незадачливые интерпретаторы. litwr не удалял эти пробелы из корветовской версии, я удалял. Ну а векторовские 2.5-2.98 сами удаляют эти пробелы, как уже написал, поэтому заметно опередили корвет, хотя проц корвета чуть быстрее.

[Ramiros]

ivagor, используя Basic2_98fix попробовал порисовать в GRAF V5.3, есть большие проблемы с GET/PUT и PAINT, артифачит и даже вылетает в бейсик во время заливки. В 2.5 проблем нет.

[ivagor]

Ramiros, спасибо за багрепорт, но вряд ли я смогу поправить в данном случае.
В get/put проблема понятна, но места для исправления нет. Скорее всего придется ограничится добавлением в readme описания ограничения. Ограничение совместимости в данном случае это плата за скорость и компактность, увы.
А для paint хотелось бы увидеть конкретный пример зависания или вылета, у меня пока не получилось воспроизвести.
Для graf 5.3 (и других подобных программ, которых я пока не знаю) могу порекомендовать более консервативный 2.891.

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

Наверно стоит написать, в чем проблема с put в graf 5.3. Там две картинки для последующих put получают не через get, а с помощью poke в массив. А внутренний формат хранения картинок get/put в 2.98 другой, иначе невозможно было сделать быстрый байтово-пиксельный get/put. Для совместимости в graf 5.3 пришлось бы добавить в poke детект того, что пишем в область памяти определенную как массив, предположить, что это для будущего put и преобразовывать на ходу записываемые значения. И это решение тоже было бы не универсальным, т.к. можно написать программу, которая будет делать poke в область массива, но не для put. Повторюсь, признаю, что 2.98 несовместим с graf 5.3, используйте 2.891.

[Ramiros]

Ramiros,
А для paint хотелось бы увидеть конкретный пример зависания или вылета, у меня пока не получилось воспроизвести.

Ошибку можно воспроизвести легко, простейший вариант - сначала залить весь экран красным, а потом синим.

Подозреваю что пэинту не хватает буфера для запоминания всех препятствий.