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

[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% быстрее
Повторюсь, что корветовский бейсик сам не удаляет начальные пробелы в строке, поэтому эффект от уборки мусора больше. У корвета еще остается резерв в виде частичного использования целых.

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

[Advertiser]

[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 байт экспоненты, двоичное представление.