У меня несколько вопросов про тесты. Можно уточнить, откуда такой термин "полукомпиляторы"? (Сразу майор Томин с полусамоварами вспоминается
Просто если у программы на входе исходный текст, а на выходе машинный код, значит это компилятор. Что там за код генерируется (шитый или обычный) - это уже дело разработчика компилятора, точнее баланса между скоростью компиляции, объемом полученного кода и скоростью его работы. Главное, что это уже не интерпретатор, то есть в момент выполнения программы анализа ее исходного текста уже не производится.

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

И еще вопрос к знатокам: Вильнюсский бейсик умеет оптимизировать выражения? Может он, например, из выражения A=K/K*K+K-K сделать A=K или из A=K/2*3+4-5 сделать A=K*1.5-1?

И несколько моих несущественных соображений по этим тестам:

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

BM 2 - тут тестирование операций сложения и сравнения чисел с плавучкой. Результат не очень надежен, потому что как минимум Amstrad-овский и ZX Spectrum-овский Бейсики константы переводят в плавучку в момент ввода программы и делают тут меньше работы.

BM 3 - почти "честный" тест, по которому можно прикинуть скорость арифметических операций с плавучкой. Но компиляторы тут могут оптимизировать половину операций. Вообще, тут должна быть примерно линейная зависимость скорости от длины мантиссы, то есть Apple-овский бейсик с 32-битной мантиссой должен быть в 1,33 раза медленнее, чем, допустим, ABC 80 c 24-битной мантиссой при условно одинаковом процессоре с одинаковой частотой Но непонятно, как можно отнормировать разные процессоры.

BM 4 - примерно то же, что и 3, но уязвим не только перед компиляторами, но и перед интерпретаторами, переводящими константы в плавучку заранее.

BM 5 - позволяет прикинуть скорость вызовов подпрограмм, но зачем? Основная нагрузка в любой программе создается вычислениями, вес этих вызовов - единицы процентов.

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

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

BM 8 - тестирование трансцендентных функций. Был бы самый "честный" тест, но тут есть общая для всех тестов проблема: никак не учитывается реальная точность вычислений. Если программе нужна промежуточная точность в 8 знаков после запятой, то бейсик, имеющий меньшую точность, просто эту программу не выполнит. Или наврет так, что смысла в результатах не будет. А, как показал пример с Корветом, она может не соответствовать заявленной.