Отечественные компьютеры: быстродействие

[avivanov76]

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

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

И еще вопрос к знатокам: Вильнюсский бейсик умеет оптимизировать выражения? Может он, например, из выражения 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 знаков после запятой, то бейсик, имеющий меньшую точность, просто эту программу не выполнит. Или наврет так, что смысла в результатах не будет. А, как показал пример с Корветом, она может не соответствовать заявленной.

[vladtru]

У меня несколько вопросов про тесты.

Очень рад вашему появлению на форуме. Такого квалифицированного и заинтересованного «коллеги-оппонента» в этой теме как раз очень не хватает – большинство старожилов форума, как я понимаю, мало интересуются Бейсиком и считают использование его для тестов баловством, предпочитая тесты на ассемблере. И напрасно – Бейсик использовать намного проще и пищи для размышлений тесты на нём дают ничуть не меньше. Тем более целый ряд – 8 тестов, каждый с небольшими отличиями от предыдущего (кроме, конечно, ВМ8).

Ваши вопросы абсолютно «в точку». Да, у этих тестов есть, так сказать, особенности, которые нужно учитывать при анализе результатов. Впрочем, подобные особенности точно так же присутствуют и во всех других тестах, на любых языках. Как раз в Бейсике их можно достаточно легко и быстро выявить и учесть.

Термин «полукомпилятор» взят из англоязычных источников – в частности, статей о ABC80 и ABC800. У них также используется термин «прекомпилятор», который мне кажется менее понятным. В нашей литературе 80-х-90-х обычно писалось нечто вроде «интерпретатор компилирующего типа», что отчасти правильно (транслятор такого типа действительно похож и на интерпретатор (по принципу взаимодействия с программистом), и на компилятор (по принципу трансляции)), но несколько длинно и парадоксально. Формально я вполне согласен, что это скорее компилятор (он действительно предварительно транслирует программу в некий код, который выполняется значительно быстрее, чем интерпретация). Сам термин «полукомпилятор» я лично почти всегда помещаю в кавычки и использую как условный для обозначения компиляторов подобного типа (которые в качестве стандартных Бейсиков за рубежом встречались крайне редко – я, например, кроме указанных в таблице ABC80/800 и DAI PC больше вообще не нашёл). По сути этот термин достаточно правильный (по крайней мере, я не знаю, как лучше выразить его одним словом) – по интерфейсу пользователя он практически не отличается от интерпретатора (в отличие от классических компиляторов) и по скорости работы полученных программ также далёк от этих классических компиляторов (но всё же компилятор); кстати, по принципу работы «что вижу, то и считаю» (вычисление «в лоб», без всякой оптимизации) он также похож на интерпретатор. Обычно компиляторами у нас всё же назывались (каковы особенности терминологии сейчас – не знаю) настоящие компиляторы, преобразующие исходную программу именно в машинный код, который выполнялся в десятки и сотни раз быстрее, чем при интерпретации (конечно, при целочисленных переменных).

Можно было бы назвать такие компиляторы, скажем, «упрощёнными компиляторами» - но и этот термин далеко не идеален (можно возразить – какой же он упрощенный, если сочетает в себе и удобную среду разработки, как у интерпретатора, и компилятор, пусть и не очень быстрый, да и по размеру мало отличается от многих компиляторов).

Компиляция у вильнюсского Бейсика выполняется только после внесения изменений в программу, в остальных случаях сразу запускается исполнение шитого кода (кроме того, можно вообще сохранить на ленту или диск только «скомпилированную» программу, без исходной, а потом загрузить её и запустить – т.н. двоичный формат (BIN)). Поэтому время компиляции, естественно, в результаты тестов не включено.

Никакие выражения вильнюсский Бейсик, конечно, не оптимизирует – в этом смысле он ничем не отличается от классического интерпретатора (как написал программист, так и исполняет, никакой самодеятельности). Впрочем, если есть сомнения – это очень легко проверить на эмуляторе.

ВМ1. Не совсем понятно, что вас смутило в вильнюсском Бейсике – при целочисленных переменных он выполняет тест примерно в 10 раз быстрее, чем при вещественных. Соответственно, у меня, например, нет подозрений, что он как-то «хитрит» и чего-то пытается в этом операторе ускорить. Наоборот – вильнюсский Бейсик в ПЗУ БК-0010-01 в этом тесте даже явно уступает многим 8-битным интерпретаторам, что говорит о том, что он честно суммирует вещественные переменные и константы двойной точности. А если эти подозрения относятся к Бейсику-87 для БК-0010, так он вообще не поддерживает целочисленные вычисления. Да и вряд ли при объёме 9 Кбайт (и жёсткой задаче минимизации объема – он же должен был загружаться в ОЗУ пользователя размером всего 16 Кбайт) там стали бы использовать какие-то подобные «трюки».

ВМ2. Да, эти тесты в классическом виде, к сожалению, не учитывают таких особенностей разных Бейсиков (и я об этом сразу написал в комментариях – в начале темы на форуме). Поэтому было бы очень интересно сделать более «честное» тестирование с учётом подобных моментов: из того, что известно на данный момент – вынести все константы за пределы циклов, заменив их переменными; убрать деление из всех тестов (чтобы иметь более реальные результаты в целочисленных тестах – там деление выполняется почти всегда с плавающей точкой, что резко снижает результат); убрать возведение в степень в ВМ8 (которое выполняется по-разному на разных ПК – где-то всегда с помощью логарифмических функций, а где-то – и с помощью простого умножения (при небольшой целой степени)); возможно, убрать циклы FOR из ВМ6 и ВМ7.

ВМ3. Да, это действительно один из самых полезных и объективных тестов. Насколько я понимаю, ни один из представленных в таблице «полукомпиляторов» (и компилятор на «Спектруме») никаких оптимизаций не делает. А по поводу разницы в скорости у Бейсиков с разной точностью пока ничего толком не ясно – я уже приводил в теме на форуме свой маленький эксперимент, когда разница между почти одинаковыми ПК с майкрософтовскими Бейсиками разной точности (мантисса 32 и 24 бита) оказалась даже в самом сложном тесте – ВМ8 – всего 15%. А в других тестах у них показатели почти одинаковые (и чем проще операции в тестах, тем сильнее «размазывается» разница из-за наличия других операторов, мало зависимых от разрядности чисел). В общем, этот вопрос пока остаётся открытым.

ВМ4. Действительно, снова константы внутри цикла, и много (хотя и простые, что существенно сглаживает различия). Кстати, кроме «Амстрада» и «Спектрума» предварительное преобразование констант выполняют также MSX и «Корвет» (у всех у них присвоение переменной любой константы занимает от 0,7 («Амстрад») до 1,9 («Корвет») мс). Точно не выполняют «Вектор» и Apple IIe (у них для «распознавания» сложных чисел требуется просто огромное время – например, «Вектор» преобразует 3,1415926 аж 45 миллисекунд (!), а Apple IIe – 30 мс (они же число 1000 распознают соответственно за 4,7 и 4,4 мс). А вот у BBC Micro результаты странные – простые числа (А=1000) распознаются 1,1 мс, а сложные (А=3.1415926) – 4,4 мс, т.е. и то, и другое намного быстрее (особенно Пи), чем у «Вектора» и «Яблока», что пока непонятно – может, ВВС использует какой-то промежуточный формат (скажем, BCD, если он вообще даст какое-то ускорение)?

ВМ5. У большинства Бейсиков пара GOSUB/RETURN и вправду выполняется очень быстро (при небольшой длине программы, когда на поиск строк не тратится много времени). Но есть и более медленные – скажем, Бейсик ZX Spectrum и Бейсик ДВК НЦ.

ВМ6. Этот тест фактически нужен для определения на основе разницы ВМ7-ВМ6 скорости работы с массивами. На практике результат ВМ6 и ВМ7 сильно зависит от скорости выполнения цикла FOR, которая у разных ПК отличается достаточно сильно (например, у Амстрада и Спектрума, имеющих почти одинаковый по скорости процессор – в 4,4 раза; очень медленный FOR и у Бейсика-11, что сильно снижает показатели всех протестированных на нём ПК).

ВМ7. Этот тест фактически имитирует более сложные тесты вроде вычисления Пи или простых чисел (которые также использовались для сравнения быстродействия Бейсиков и ПК). Ну и позволяет оценить скорость работы с массивами.

ВМ8. Это самый «нечестный» тест! Из-за уже упомянутой разницы в алгоритме вычисления степеней. Честный – это ВМ8М (тоже самое, но без возведения в степень). Конечно, при интерпретации результатов точность нужно как-то учитывать (хотя пока неясно как), особенно при большой разнице в точности вычислений. А у «Корвета» скорость вычислений сложных функций просто отличная – он, например, вычисляет синус за 22 мс (BBC Micro, имеющий вдвое более мощный процессор – за 25 мс, Apple IIe - 27 мс). Но «Амстрад» ещё быстрее – всего 14,5 мс! Возможно, причина таких странных показателей – как раз разные методы вычислений (ряды Тейлора, полиномы Чебышева, CORDIC). Например, известно, что Бейсики от Майкрософт используют ряды Тейлора, а Бейсики ZX81 и ZX Spectrum - Чебышева. Где используется CORDIC – не знаю.

Кстати, арифметические операции «Корвет» в режиме двойной точности вычисляет с очень высокой точностью (16 знаков), а вот синусы и логарифмы – всего 6-8 знаков, остальные разряды – неверные.

[MM]

С точки зрения написания управляющего софта был бы полезен тест, заполняющий массив переменных А(0)...А(1023) сначала числом 0, потом числом 32767, всё в цикле FOR. Здесь как раз ослабляется так любимое маркетологами кэширование и измеряется реальная скорость работы с массивом, очень полезная для функций DSP. Заполнять следует массив целочисленных переменных.

[avivanov76]

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

И их можно понять: выполнение программы на Бейсике очень отличается от выполнения программы непосредственно процессором. Фактически это уже другой компьютер - Бейсик-машина. Представьте, что нужно посчитать сумму 100 целых чисел от 0 до 500. Код на ассемблере (давно не брал в руки шашек, но надеюсь не сильно наврал):

DATA	DB здесь 100 чисел
START	DI
	LD SP, DATA
	LD B, 100
	LD DE, 0
LOOP	POP HL
	ADD HL, DE
	EX DE, HL
	DJNZ LOOP
	EI

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

Программа на Бейсике выглядит проще:

100 DATA здесь 100 чисел
110 SUM = 0
120 FOR I = 0 TO 100
130 READ A
140 SUM = SUM + A
150 NEXT

Но при её выполнении будет работать не 9 инструкций, а огромный массив кода, который и близко на ассемблерный не похож. Будет выполняться чтение текста, будут создаваться структуры данных для переменных и операторов READ и FOR, числа будут преобразовываться в плавучку, будет выполняться поиск строк и т.д. Ни о каких регистрах и ни о какой предсказуемости речь вообще не идет.

Поэтому, гоняя тесты на Бейсике мы в основном исследуем производительность Бейсик-машины и ловкость программистов при её реализации. А производительность эта невысока и любой, кто писал на Бейсике что-то серьёзнее учебных программ, задумывался об альтернативах. Да и не были пользователи так уж привязаны к встроенным Бейсикам (у кого-то вообще был Фокал, Apple II выпускался с 2 вариантами Бейсика). Для ZX Spectrum компиляторов штук 5 было. То есть, результаты в этих тестах - это частный случай.

ВМ1. С этим тестом я облапошился, похоже, смотрел на число в одной строке, а комментарий прочел из другой. Посыпаю голову пеплом Но вообще тут есть странность. В 1 и 2 тестах в цикле 3 действия: прибавить к переменной единицу, сравнить с константой и выполнить переход. Однако цикл FOR работает быстрее. Для интерпретаторов это можно объяснить наличием структуры данных, в которой сохраняется адрес перехода, а поиск номера строки выполняется один раз. Но почему тогда эта разница сохраняется в компилируемых версиях, где адреса строк должны становиться известны в момент компиляции?

ВМ4. У BBC основной формат двоичный, чтобы преобразовать его в двоично-десятичный придется почти столько же времени потратить, как на перевод из текстового представления.

ВМ7. Как он может имитировать вычисление Пи? Оператором M(L)=A? Там и массивы то не нужны.

ВМ8. Мог бы быть честным, поскольку возведение в степень, логарифм и синус перебивают по времени другие операторы. Но, естественно, при одинаковых алгоритмах. CORDIC вроде в HP-шных калькуляторах популярен. И вроде он был в МК-85 http://www.computer-museum.ru/histussr/mk_85_1.htm

У Корвета видимо, просто берется меньшее число членов ряда для синусов и логарифмов.

[HardWareMan]

Поэтому, гоняя тесты на Бейсике мы в основном исследуем производительность Бейсик-машины и ловкость программистов при её реализации.

У соседей был вот такой Былинный тред про советские Бэйсики. Почитайте, занятная ситуация. Статистический анализ показывает совпадения прямо таки здоровых кусков в теле, иногда даже расположенного в тех же местах.

Скрытый текст

Задумал я тут написать простую программку, которая будет считать процент "заимствования" кода одной программы в другой (применительно к 8080 процессору). Вот что мне подумалось - так программа может быть перетранслирована в новую память, то адреса могут сбится, т.е. все переходы (J*, C*), если они встречаются в большем повторяющемся куске кода, следует считать совпадающими, не взирая на используемый адрес. Тоже самое касается команд чтения записи данных из памяти - LDA/STA и SHLD/LHLD. Вопрос возникает по поводу LXI - по идее в HL также можно загрузить адрес переменной и потом обращаться к ней через регистр M, т.е. такие команды тоже надо считать заведомо совпадающими? В связи с этим - чтобы исключить ложные срабатывания минимальную длину заведомо повторяющегося участка следует принять за 4 байта или даже за 5...

* * *

вот результаты, полученные по этой методике (сравнивал бейсики с альтаиром 4К и 8К, а также TRS-80 LEVEL1):

              size alt4k alt8k t80-l1
BAS-CIR.RKS   9750 25.18 47.70  2.52
BAS-GR.RKS    9542 25.73 48.75  2.58
BAS-KBH.RKS   8342 29.36 55.32  2.85
BAS-MAG.RKS   8710 26.06 48.46  2.90
BAS-MAG2.RKS  8582 26.45 49.14  2.90
BAS-MIC2.RKS  8198 28.35 53.48  3.04
BAS-MICR.RKS  8199 28.34 53.47  3.04
BAS-NEW.RKS  10518 23.38 44.50  2.46
BAS-RDK.RKS   3334  7.02 11.85 18.72
BAS-S.RKS     7798 31.16 59.25  3.03
BAS-SG.RKS   10518 23.32 44.23  2.41
BAS-SPEC.RKS  8198 29.82 56.40  2.90
BAS-SRV.RKS   8966 27.36 51.81  2.79
BASIC-A.RKS   6758 36.09 68.42  3.17
BASIC.RKM     6662 36.60 69.44  3.00
BASIC.RKP     8200 27.68 51.43  3.11
BASIC.RKS    16390 15.12 28.57  1.53
BASIC1.RKS   16390 15.08 28.52  1.53
BASIC2.RKS   16390 15.12 28.57  1.53
BASIC3.RKS    6758 36.06 68.42  3.23
BASIC80.RKR   6665 36.70 68.99  3.00
BASICMUS.RKR 10741 22.56 42.35  1.86
BASICPC.RKR   8201 28.30 53.33  3.07
BASICSER.RKR  7433 32.73 62.06  2.95
BASIC_OK.RKR  8201 28.23 53.46  2.83
BASIC_PR.RKR  7433 32.69 62.14  2.95
BASIC_RK.RKR  6847 35.65 67.17  2.99
BASMIC.RKR    6601 36.90 69.84  2.97
BASMIC87.RKS 17207 13.26 25.06  1.64
BASMIKR.RKR   8202 27.69 51.43  3.11

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

вот самый длинный повторяющийся кусок (165 байт) в BASIC_PR.RKR из altair8k:

BASIC_PR.RKR loaded : 7433 bytes
altair8k.bin loaded : 8192 bytes
62.14 percent copy (max=165 maxa=0x11DF maxb=0x137A)
0x11DF 0x02 | 0x137A 0x02
0x11E0 0x7E | 0x137B 0x7E
0x11E1 0x23 | 0x137C 0x23
0x11E2 0xB7 | 0x137D 0xB7
0x11E3 0xCA | 0x137E 0xCA
0x11E4 0x07 | 0x137F 0xA6
0x11E5 0x12 | 0x1380 0x13
0x11E6 0xE5 | 0x1381 0xE5
0x11E7 0xEB | 0x1382 0xEB
0x11E8 0x1E | 0x1383 0x1E
0x11E9 0x08 | 0x1384 0x08
0x11EA 0x1F | 0x1385 0x1F
0x11EB 0x57 | 0x1386 0x57
0x11EC 0x79 | 0x1387 0x79
0x11ED 0xD2 | 0x1388 0xD2
0x11EE 0xF4 | 0x1389 0x93
0x11EF 0x11 | 0x138A 0x13
0x11F0 0xD5 | 0x138B 0xD5
0x11F1 0x11 | 0x138C 0x11
0x11F2 0x00 | 0x138D 0x00
0x11F3 0x00 | 0x138E 0x00
0x11F4 0x19 | 0x138F 0x19
0x11F5 0xD1 | 0x1390 0xD1
0x11F6 0xCE | 0x1391 0xCE
0x11F7 0x00 | 0x1392 0x00
0x11F8 0x1F | 0x1393 0x1F
0x11F9 0x4F | 0x1394 0x4F
0x11FA 0x7C | 0x1395 0x7C
0x11FB 0x1F | 0x1396 0x1F
0x11FC 0x67 | 0x1397 0x67
0x11FD 0x7D | 0x1398 0x7D
0x11FE 0x1F | 0x1399 0x1F
0x11FF 0x6F | 0x139A 0x6F
0x1200 0x78 | 0x139B 0x78
0x1201 0x1F | 0x139C 0x1F
0x1202 0x47 | 0x139D 0x47
0x1203 0x1D | 0x139E 0x1D
0x1204 0x7A | 0x139F 0x7A
0x1205 0xC2 | 0x13A0 0xC2
0x1206 0xE6 | 0x13A1 0x85
0x1207 0x11 | 0x13A2 0x13
0x1208 0xEB | 0x13A3 0xEB
0x1209 0xE1 | 0x13A4 0xE1
0x120A 0xC9 | 0x13A5 0xC9
0x120B 0x43 | 0x13A6 0x43
0x120C 0x5A | 0x13A7 0x5A
0x120D 0x51 | 0x13A8 0x51
0x120E 0x4F | 0x13A9 0x4F
0x120F 0xC9 | 0x13AA 0xC9
0x1210 0xCD | 0x13AB 0xCD
0x1211 0xF2 | 0x13AC 0x91
0x1212 0x12 | 0x13AD 0x14
0x1213 0x01 | 0x13AE 0x01
0x1214 0x20 | 0x13AF 0x20
0x1215 0x84 | 0x13B0 0x84
0x1216 0x11 | 0x13B1 0x11
0x1217 0x00 | 0x13B2 0x00
0x1218 0x00 | 0x13B3 0x00
0x1219 0xCD | 0x13B4 0xCD
0x121A 0x02 | 0x13B5 0xA1
0x121B 0x13 | 0x13B6 0x14
0x121C 0xC1 | 0x13B7 0xC1
0x121D 0xD1 | 0x13B8 0xD1
0x121E 0xEF | 0x13B9 0xEF
0x121F 0xCA | 0x13BA 0xCA
0x1220 0xD3 | 0x13BB 0xC9
0x1221 0x02 | 0x13BC 0x02
0x1222 0x2E | 0x13BD 0x2E
0x1223 0xFF | 0x13BE 0xFF
0x1224 0xCD | 0x13BF 0xCD
0x1225 0x8A | 0x13C0 0x29
0x1226 0x12 | 0x13C1 0x14
0x1227 0x34 | 0x13C2 0x34
0x1228 0x34 | 0x13C3 0x34
0x1229 0x2B | 0x13C4 0x2B
0x122A 0x7E | 0x13C5 0x7E
0x122B 0x32 | 0x13C6 0x32
0x122C 0x49 | 0x13C7 0xE8
0x122D 0x12 | 0x13C8 0x13
0x122E 0x2B | 0x13C9 0x2B
0x122F 0x7E | 0x13CA 0x7E
0x1230 0x32 | 0x13CB 0x32
0x1231 0x45 | 0x13CC 0xE4
0x1232 0x12 | 0x13CD 0x13
0x1233 0x2B | 0x13CE 0x2B
0x1234 0x7E | 0x13CF 0x7E
0x1235 0x32 | 0x13D0 0x32
0x1236 0x41 | 0x13D1 0xE0
0x1237 0x12 | 0x13D2 0x13
0x1238 0x41 | 0x13D3 0x41
0x1239 0xEB | 0x13D4 0xEB
0x123A 0xAF | 0x13D5 0xAF
0x123B 0x4F | 0x13D6 0x4F
0x123C 0x57 | 0x13D7 0x57
0x123D 0x5F | 0x13D8 0x5F
0x123E 0x32 | 0x13D9 0x32
0x123F 0x4C | 0x13DA 0xEB
0x1240 0x12 | 0x13DB 0x13
0x1241 0xE5 | 0x13DC 0xE5
0x1242 0xC5 | 0x13DD 0xC5
0x1243 0x7D | 0x13DE 0x7D
0x1244 0xD6 | 0x13DF 0xD6
0x1245 0x00 | 0x13E0 0x00
0x1246 0x6F | 0x13E1 0x6F
0x1247 0x7C | 0x13E2 0x7C
0x1248 0xDE | 0x13E3 0xDE
0x1249 0x00 | 0x13E4 0x00
0x124A 0x67 | 0x13E5 0x67
0x124B 0x78 | 0x13E6 0x78
0x124C 0xDE | 0x13E7 0xDE
0x124D 0x00 | 0x13E8 0x00
0x124E 0x47 | 0x13E9 0x47
0x124F 0x3E | 0x13EA 0x3E
0x1250 0x00 | 0x13EB 0x00
0x1251 0xDE | 0x13EC 0xDE
0x1252 0x00 | 0x13ED 0x00
0x1253 0x3F | 0x13EE 0x3F
0x1254 0xD2 | 0x13EF 0xD2
0x1255 0x5A | 0x13F0 0xF9
0x1256 0x12 | 0x13F1 0x13
0x1257 0x32 | 0x13F2 0x32
0x1258 0x4C | 0x13F3 0xEB
0x1259 0x12 | 0x13F4 0x13
0x125A 0xF1 | 0x13F5 0xF1
0x125B 0xF1 | 0x13F6 0xF1
0x125C 0x37 | 0x13F7 0x37
0x125D 0xD2 | 0x13F8 0xD2
0x125E 0xC1 | 0x13F9 0xC1
0x125F 0xE1 | 0x13FA 0xE1
0x1260 0x79 | 0x13FB 0x79
0x1261 0x3C | 0x13FC 0x3C
0x1262 0x3D | 0x13FD 0x3D
0x1263 0x1F | 0x13FE 0x1F
0x1264 0xFA | 0x13FF 0xFA
0x1265 0x09 | 0x1400 0xA8
0x1266 0x11 | 0x1401 0x12
0x1267 0x17 | 0x1402 0x17
0x1268 0x7B | 0x1403 0x7B
0x1269 0x17 | 0x1404 0x17
0x126A 0x5F | 0x1405 0x5F
0x126B 0x7A | 0x1406 0x7A
0x126C 0x17 | 0x1407 0x17
0x126D 0x57 | 0x1408 0x57
0x126E 0x79 | 0x1409 0x79
0x126F 0x17 | 0x140A 0x17
0x1270 0x4F | 0x140B 0x4F
0x1271 0x29 | 0x140C 0x29
0x1272 0x78 | 0x140D 0x78
0x1273 0x17 | 0x140E 0x17
0x1274 0x47 | 0x140F 0x47
0x1275 0x3A | 0x1410 0x3A
0x1276 0x4C | 0x1411 0xEB
0x1277 0x12 | 0x1412 0x13
0x1278 0x17 | 0x1413 0x17
0x1279 0x32 | 0x1414 0x32
0x127A 0x4C | 0x1415 0xEB
0x127B 0x12 | 0x1416 0x13
0x127C 0x79 | 0x1417 0x79
0x127D 0xB2 | 0x1418 0xB2
0x127E 0xB3 | 0x1419 0xB3
0x127F 0xC2 | 0x141A 0xC2
0x1280 0x3D | 0x141B 0xDC
0x1281 0x12 | 0x141C 0x13
0x1282 0xE5 | 0x141D 0xE5
0x1283 0x21 | 0x141E 0x21

[свернуть]

А так как практически у всех Бейсиков уши растут из одного места, то алгоритмы у них соответственно в большинстве случаев похожи. И тут уже не важно почему так (то ли реально краденный код, то ли просто методичка одна на всех была), просто есть факт. И тут уже у машин на одном процессоре скорость будет близкая и зависеть от тактовой частоты.

[litwr]

Интересное исследование, но это именно быстродействие программ на бэйсике, которые использовались гораздо реже программ на ассемблере, на котором написан и сам бэйсик. Не совсем корректно писать, что это быстродействие именно железа. Можно писать, что бэйсик БК может обогнать GW-Basic на IBM PC XT. Но это одиночный, вырванный даже из контекста сравнения бэйсиков результат. GW-Basic удобный, продуманный инструмент, отражающий лучшие идеи того времени в реализации бейсиков. В нем удобно редактировать, работать с графикой, файлами разной структуры, текстом и т.п. На БК имеем сделанный наспех инструмент годный только для начального обучения и математических расчетов с неудобным, обрезанным синтаксисом (оператор в строку, нет развёстки сокращенных слов). С файлами на БК работать невозможно, с текстами почти невозможно. Памяти почти нет, что сводит работу с графикой к фикции и заставляет программиста писать уродующие программы сокращения вместо нормальных служебных слов. Сравниваем типа Волгу и Вольво с моторами одинаковой мощности: с хорошим форсажем и наладкой Волга с грохотом может объехать Вольво. Хотя для любителей быстрой езды Microsoft предлагала компилятор, повышающий скорость раз в 5. Компилятоы бейсика были и на других платформах, они повышали скорость не менее, чем в 2.5 раза.
Мои наблюдения показывают, что скорость работы компьютеров конца 70-х и до конца 80-х определялась прежде всего скоростью работы с памятью. У 6502 это чуть больше такта на обращение, у i8080/z80/i8088 - чуть меньше 4 тактов, у БК 12-14 тактов (6-7 на байт). Сами команды распадаются на отдельныe обращения к памяти, например, команда загрузки аккумулятора у 6502 LDA $1000 состоит из 3-х байт и делает одно обращение к памяти - итого 4 такта, команда загрузки регистровой пары в 8080/z80 ld hl,(1000) состоит из 3-х байт и делает два обращение к памяти - примерно 20 тактов, команда пересылки слова БК mov (R0)+,(R1)+ состоит из слова (2 байта) и делает два обращение к памяти - примерно 36-42 такта. За счет более ёмких команд БК может иметь преимущество перед z80 и Со за счет меньшего времени на выборку команд. Но далеко не всегда нескольким командам z80 можно сопоставить одну на К1801ВМ1. Работа с байтами и битами на БК намного медленнее, чем на z80 или 6502. Поэтому по арифметике, пересылке данных, работе с массивами слов и т.п. БК на 4МГц примерно соответствует z80 на 3.2 без торможения, но во многих ситуациях процентов до 50 медленнее.
Интересны были бы дополнительные сведения по 6809 - лучшему 8-битному процессору с аппаратным умножением и многообразной системой адресации. Его почему-то использовали с заниженными (искусcтвенно?) частотами (800 КГц).
Тестам на бейсике определенно не хватает теста со строками - это проверка качества работы с памятью. Строки требуют её выделять динамически, проводить массовые копирования, уборку мусора, ...

Можно уточнить, откуда такой термин "полукомпиляторы"?

Термины разные, а суть одна - в предварительной подготовке текста перед исполнением. Все без исключения бэйсики переводят сначала текст в свой внутренний формат, как минимум, заменяя служебные слова на сокращения, делая ссылки на начала строк и т.п. Некоторые в этом заходят дальше, чем другие, делая помимо лексического, элементы синтаксического анализа - это уже полукомпиляция. Называть полукомпиляцию компиляцией не позволяет ее привязанность к ПЗУ компьютера. Грань между полукомпиляцией и компиляцией в системах пи-кода, ява, дот-нет или даже скрытой компиляцией программ на языках сценариев и похожих (рубин, питон, хаскель, ...) очень тонкая.
Поддержу форт - этот язык определенно проще бэйсика. Трансляторы форта есть почти на всех системах и они похожи друг на друга гораздо больше чем бейсики. Получается почти идеальное средство для подобного тестирования, уступающее только реализации строго заданных алгоритмов на ассемблере.

[Advertiser]

[vladtru]

Но при её выполнении будет работать не 9 инструкций, а огромный массив кода

Вот-вот, абсолютно точно! Только выводы из этого вы делаете не совсем правильные . В этом как раз огромное достоинство Бейсика, как тестовой платформы – он позволяет очень быстро и просто (и довольно точно) измерить скорость работы ПК буквально двумя-тремя операторами (например, тесты ВМ2 и ВМ3). И то что при этом будут выполняться большие куски разнообразного кода – это просто великолепно, поскольку позволяет определить скорость не нескольких машинных команд, а среднюю скорость самых разных процедур, использующих и работу с памятью, и регистры, и 8-битные данные, и 16-32-битные (и даже с плавающей точкой!) и т.д. Бейсик выполняет те же самые действия, которые встречаются и во множестве других серьёзных программ: поиск в массиве текстовых цепочек, преобразование данных (из «текстового» в числовой и наоборот, из одной системы счисления в другую), арифметические вычисления (в т.ч. с плавающей запятой), работу с таблицами и т.д. Как можно всё это сделать на ассемблере (и главное, зачем?), причём с учётом особенностей разных процессоров – я представляю себе с трудом. Фактически подобная ассемблерная программа и будет состоять из таких же точно «кусков кода», которые выполняются и в интерпретаторе Бейсика.

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

Кстати, для тех, кто считает обязательным тестирование скорости только на ассемблере хочу напомнить, что Бейсик для простых ПК 80-х – это и есть самая главная программа на ассемблере! То есть, тестируя производительность Бейсика, мы как раз непосредственно измеряем скорость работы самой популярной, наиболее используемой ассемблерной программы на этих ПК!

Единственный момент, мешающий сравнивать разные ПК тестами Бейсика – сомнения насчёт одинаковости (или оптимальности) используемых алгоритмов и приёмов для разных процессоров. Но, во-первых, эти сомнения никуда не денутся и при использовании тестов на других языках (в том числе ассемблере). А во-вторых, как я уже не раз писал (вот и HardWareMan привёл ссылки на один из источников такой информации) – Бейсики БОЛЬШИНСТВА домашних ПК 80-х (включая и советские) имеют одинаковое происхождение – от первых Бейсиков «Майкрософт», написанных ещё для «Альтаира» и других первых ПК, что с большой вероятностью означает большую близость использованных в них алгоритмов работы (что вполне подтверждается и на практике). Причём это относится к Бейсикам для разных процессоров (8080, Z80, 6502, 6809 и х86). Из популярных у нас ПК другое происхождение только у BBC Basic (для BBC Micro и Acorn Electron), Locomotive Basic (Amstrad CPC), Sinclair Basic (ZX81 и ZX Spectrum) и Atari Basic (Atari XL/XE). Ну и конечно, вполне самостоятельны Бейсики-«полукомпиляторы» и Бейсики для PDP-11-совместимых процессоров.

Безусловно, разные версии Бейсиков от «Майкрософт» имеют некоторые отличия и по функциям, и по скорости, но, как видно из разных таблиц (общей, а также для «Форума» («Корвета»), «Роботрона-1715» и др.), они обычно достаточно близки по скорости (разница между разными микрософтовскими Бейсиками на одном ПК редко превышает 5-6%).

Не совсем понял вашу мысль о том, что «гоняя тесты на Бейсике мы в основном исследуем производительность Бейсик-машины и ловкость программистов при её реализации». А чем отличаются в этом плане тесты на других языках? Их результаты также зависят от ловкости программистов, писавших трансляторы (для ЯВУ) или оптимальности алгоритмов и эффективности их реализации для конкретного процессора (на всех языках). Вы же сами писали, что компилятор может вообще оптимизировать какие-то выражения, вплоть до полного их исключения, если их результат нигде дальше не используется. Так что этот «недостаток» никак нельзя считать специфическим именно для Бейсика. Как раз Бейсик здесь вызывает меньше всего сомнений – он-то уж точно ничего не оптимизирует и не исключает, выполняя программу именно так, как написано.

Кстати, если рассматривать эффективность компиляторов – у них разница бывает просто огромной. Например, майкрософтовский компилятор Бейсика для CP/M может ускорять выполнение программ относительно интерпретатора всего в несколько раз, а, скажем, Турбо-Паскаль или Фортран в тех же условиях – в десятки раз.

Альтернативные интерпретаторы, «полукомпиляторы» («полуинтерпретаторы») и компиляторы, конечно, на многих ПК были. Но вот массового их применения (сравнимого с использованием стандартного Бейсика, «зашитого» в ПЗУ или поставляемого вместе с ПК) – я уверен, не было и в помине. Скажем, на том же «Спектруме» их была целая куча – и я лично когда-то пробовал разбираться со многими, но основная их часть – это какие-то поделки, очень неудобные в использовании, да ещё и имеющие значительные ограничения и отличия в выполнении разных функций от стандартного Бейсика. Вряд ли эти «компиляторы» массово использовались для чего-либо, кроме «попробовать и забыть». Были и более приятные версии, но все они намного сложнее (и менее привычны) стандартного Бейсика, так что особого смысла в их применении не было: для простых задач вполне хватало и обычного Бейсика, а для сложных (типа игр) всё равно почти всегда использовался ассемблер.

ВМ1. В реализации циклов FOR/NEXT в большинстве интерпретаторов явно и однозначно используются какие-то приёмы, позволяющие ускорить их выполнение. Например, на «Векторе» (достаточно типичном интерпретаторе «майкрософтовского» происхождения) ДВА достаточно сложных оператора – FOR и NEXT, причём расположенных в разных строках, выполняются всего за 1,6 мс (если указан только предел цикла и в виде константы), что равно времени исполнения ОДНОГО простейшего оператора присваивания (А=В). Соответственно, скорее всего (но не точно), Бейсик не ищет в каждой итерации переменную цикла в памяти, а хранит её конкретный адрес в какой-то специальной области (таблице или стеке), что позволяет ускорить её поиск. Другое наблюдение по Бейсику «Вектора» - самая простая команда распознавания чисел (типа А=1) выполняется у него за 3,3 мс (а присваивание более сложных чисел – до десятков мс), что также однозначно означает, что Бейсик не распознаёт каждый раз шаг и предел цикла (время исполнения цикла при большом числе повторений абсолютно не зависит от сложности констант в операторе FOR), а хранит однажды распознанные константы также в какой-то специальной области. Кроме того, скорее всего, действительно используется и готовый адрес строки с FOR, поскольку запоминать где-то вместо него номер строки (на который «переходит» оператор NEXT в конце цикла) просто нет большого смысла.

То есть, как я понимаю, для каждого цикла FOR где-то в служебной области памяти создаётся запись типа: имя переменной цикла (по нему NEXT определяет, к какому FOR он относится) и её адрес в памяти, шаг цикла и предел цикла (во внутреннем формате для констант либо адрес в памяти для переменных), адрес расположения сроки (или даже оператора в строке) с командой FOR. Тогда из более менее серьёзных действий оператору FOR (или NEXT) остаётся только выполнить сложение шага с текущим значением переменной цикла и сравнить её с пределом цикла. Вот на это и требуется сравнительно небольшое время порядка 1,5 мс (ну, ещё надо найти в «таблице циклов» свой цикл по имени переменной, но это должно быть достаточно быстро – почти у всех Бейсиков значащими являются только два первых символа имени).

Если сравнить время выполнения цикла для целых и вещественных переменных (а такие данные в таблице есть для Amstrad CPC и «Корвета»), то вполне логично FOR с целой переменной выполняется намного быстрее – у «Амстрада» в 2 с лишним раза (0,5 мс вместо 1,1), у «Корвета» - в 1,7 раза (1 мс вместо 1,7). То есть сложение целых чисел выполняется намного быстрее, чем вещественных, но время цикла всё же остаётся достаточно большим (и оно значительно больше, чем у «полукомпиляторов» с целочисленным FOR), что всё-таки оставляет сомнения насчёт логики работы FOR/NEXT у интерпретаторов (возможно, у них всё же в каждой итерации происходит поиск переменной цикла в памяти обычным способом или обычный поиск строки с FOR).

Кстати, чего гадать - нетрудно найти дизассемблированный (с комментариями) текст программы для разных Бейсиков и посмотреть, как там работают FOR и NEXT.


Насчёт разницы между ВМ1 и ВМ2 у «полукомпиляторов» вы подметили очень интересно – у вильнюсского Бейсика как раз разницы практически нет, что говорит об одинаковости действий в циклах FOR и IF и подтверждает предположения о логике работы FOR/NEXT в интерпретаторах (т.е. то, что, по сути, никаких «долгих» действий, кроме сложения и сравнения чисел с плавающей запятой, они не выполняют). А вот у других «полукомпиляторов» (ABC80, ABC800 и DAI PC) и «компилятора» ZX Spectrum разница есть, и немалая – до 2-5 раз. И объяснить это я лично пока не могу – если только, действительно, «полукомпилятор» как-то оптимизирует выполнение цикла, заменяя постоянное прибавление шага к переменной цикла и сравнение её с пределом заранее вычисленным числом повторений (если переменная цикла в теле не используется). Либо в каких-то других моментах логика работы зарубежных «полукомпиляторов» значительно отличается от вильнюсского Бейсика (но это вряд ли).

...остальной текст не влезает - добавлю позже...

...не могу добавить текст, пока кто-нибудь не ответит - пишет, что превышена допустимая длина сообщения (10000 символов)...

[litwr]

Вот ещё пример, показывающий как ошибочно переносить данные по быстродействию на бейсике на весь компьютер. Хорошо знаком с ретрокомпьютерами Коммодор серий 64, 264, 128. Прогоним тесты на 64 и 264. На 64 они будут выполняться примерно на 25% быстрее, а тесты со строками пройдут и вовсе раза в два быстрее. Но на 64-м процессор работает на 25% медленнее! Процессоры и объемы памяти аппаратно идентичные, бэйсики почти одинаковые. В 264 добавлены несколько новых команд. Можно смело писать, что 64 в раза полтора быстрее на 3 года более позднего компьютера? А действительность гораздо сложнее, в 264 используют для бейсика всю ОЗУ (60 КБ), а в 64-м только 37 КБ. Это требует в 264 при каждом обращении к памяти для чтения использовать процедуры установки правильного банка памяти. А со строками может и вообще получиться конфуз. В 64 и 264 разные уборщики мусoра. В 64-м уборщик работает очень быстро до полного исчерпания памяти, потом происходит задержка на подчистку. В 264 память подчищают сразу. Поэтому чтобы реально сравнить эти почти одинаковые бейсики на почти одинаковых компьютерах на одинаковых строковых операциях нужны тесты, которые периодически заполняют всю динамическую память. Программы на машинных кодах, например, для математических расчетов могут выполняться на 264-х до 2.5 рах быстрее и это отражает реальное быстродействие железа, но не всего, а только процессоров. Скорость видео, имеющая определяющее значение для игр и графических программ, сравнить в целом почти невозможно. Можно использовать для сравнения объемы видеопамяти и скорость перерисовки всего экрана, но это не даст всей картины.
Кстати, компиляторы для коммодоровского бейсика очень качественные и позволяют пратически любою программу переносить в машинный код без усилий. Но машинный код там обычно не чистый, а на основе пи-кода, что ускоряет не так сильно как можно подумать. Вот на Амстраде с компиляторами для ПЗУ-бейсика похуже, но там работа с компиляторами - это уровень СР/М.
Бейсик это всего лишь одна из прикладных программ класса трансляторов. Трансляторы устроены весьма специфично и не похожи, например, на текстовые редакторы, базы данных, программы рисования и др. Чтобы говорить о скорости компьютера в целом, надо собирать данные по разным программам и не забыть про игры.
А вот пример, показывающий, как мало значения имели программы на чистом бейсике. Как много вы таких программ найдёте в архивах для БК и других компьютеров? Для некоторых компьютеров существуют большие архивы, но это, как правило, какие-то личные наработки и фирменные примеры, с маленькой ценностью. Для большиства, как уже писалось, бейсик был просто средой (ОС) для запуска нужных программ. Бейсики делались наспех, копировались с других машин, а их помещение в ПЗУ не позволяло их затем обновлять. Некоторые преимущества бейсика Амстрада и БК объесняются и их более поздним появлением, разработчиков не так гнали требованиями маркетологов и т.п.
Добавлю ещё о качестве бейсика в БК. Самый интересный и мощный оператор resume, возможности которого превосходят даже современную работу с ошибками через исключения - тут как, бывает, случилось полшага назад, на БК очевидно не присутствует. Собирался писать текстовый редактор на этом бейсике - невозможно.

[vladtru]

Продолжение.

ВМ4. Вообще, малые различия в тестах ВМ3 и ВМ4 у тех ПК, которые не используют предварительное преобразование чисел, очень подозрительны. На первый взгляд, кажется, что ВМ4 у них должен выполняться намного дольше (в каждом цикле надо дополнительно распознавать 4 константы). Но никакого другого разумного объяснения, кроме того, что константы простые и распознаются быстро (а на нахождение в памяти переменных у ВМ3 также тратится немалое время), у меня нет. Кстати, по этим тестам хорошо видно, что все представленные в таблице интерпретаторы и «полукомпиляторы» абсолютно равнодушны к какой-либо оптимизации выражений – даже такой «шикарный» случай, как K/К*К+К-К (что в результате действительно даёт просто К) они вычисляют без всякого упрощения (если бы это было не так, то ВМ3 выполнялся бы радикально быстрее ВМ4).

И ещё разница между ВМ4 и ВМ3 позволяет довольно точно определить Бейсики, у которых выполняется предварительное преобразование констант во внутренний формат (что положительно влияет на их быстродействие и ставит в этих тестах в не совсем равные условия с теми Бейсиками, которые такого не делают). То есть, если ВМ4 меньше или равно ВМ3 (т.е. константы уже находятся в программе в готовом виде, и их не надо преобразовывать из символьного формата или искать в памяти), то предварительное преобразование почти наверняка выполняется. Судя по таблице, такое преобразование есть у таких ПК или Бейсиков: IBM 5100, Memotech MTX-500, Robotron 1715M (BASIC Ver: R-BWS SCPX V.1/0), Wang 2200T, Z80A 4 МГц (Microsoft Basic 5.2), ZX Spectrum, ZX81, Корвет ПК8010/8020. Есть оно также у Amstrad CPC, MSX/MSX2 и SVI-328, хотя результат ВМ4 у них почему-то больше ВМ3.

То есть, судя по всему, одно из отличий Бейсиков от «Майкрософт» - наличие или отсутствие предварительного преобразования чисел, что надо учитывать при анализе результатов (это отчасти объясняет, например, заметное преимущество «Корвета» над другими советскими ПК с таким же процессором, но без предварительного преобразования). С другой стороны, в этих тестах, скорее всего, предварительное преобразование влияет на результат не так уж сильно – по причине простоты используемых констант (вот если бы внутри циклов задействовались числа вроде Пи или е, то влияние распознавания констант было бы намного больше).

Ну а по поводу BBC Micro могу ещё сказать, что, очень может быть, его высокая скорость распознавания чисел достигается вполне «честно» и просто связана с использованием какого-то радикально более быстрого алгоритма преобразования из символьного формата в «плавающую точку» (я, например, считаю, что тратить на распознавание 8-значного числа Пи около 45 миллисекунд (как делает «Вектор») – это уж чересчур).

ВМ7. Здесь, конечно, я был не совсем точен – речь идёт скорее о сравнении ВМ7 с тестами типа пузырьковой сортировки (там работа с массивом + условные переходы и циклы) или нахождения простых чисел (деление, циклы, условные переходы). А под словом «имитирует» имелась в виду похожесть по составу операторов и по соотношению результатов на разных ПК.

ВМ8. Я так понимаю, что почти у всех ПК тех лет для вычисления синусов и логарифмов используются ряды Тейлора. Правда, разница в скорости иногда довольно значительная (прежде всего, между майкрософтовскими Бейсиками для 6502 и BBC Бейсиком – майкрософтовский значительно быстрее при равной тактовой частоте) – но это вполне может быть вызвано разностью конкретных использованных алгоритмов (хотя и странно, учитывая более позднее появление BBC Basic). Ещё одно отличие – отдельные версии Бейсика используют для вещественных чисел в качестве внутреннего не двоичный формат, а двоично-десятичный (BCD), что также, возможно, влияет на скорость. Во всяком случае, и MSX/MSX2, и Wang-2200VP (использующие BCD) как раз имеют относительно низкую скорость вычисления сложных функций (хотя она может быть связана и с высокой точностью вычислений, характерной для этих компьютеров).

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

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

Я тоже считаю, что не надо придавать этим тестам слишком большого значения в плане сравнения скорости ПК в целом - понятно же, что IBM PC был (или должен был быть) быстрее дешёвых 8-битных ПК (хотя кто его знает - по тестам Бейсика - не очень-то ) или "Амига" была в разы быстрее БК-0010 и Amstrad CPC. Конечно, корректно в этом смысле сравнивать только ПК с одинаковыми или почти одинаковыми Бейсиками (а это в основном компьютеры, тестировавшиеся на Бейсике-11, а также с Бейсиками от Майкрософт и одинаковыми процессорами).

И, безусловно, кроме скорости, были отличия также в возможностях Бейсиков и самих ПК (наличие дисководов, жестких дисков и т.п.), которые в этой таблице не рассматриваются. Хотя Бейсики наших основных ПК (БК, УКНЦ, Корвета, Вектора) – далеко не худшие в плане возможностей (при сравнении с большинством недорогих ПК – намного лучше).

Ваша критика Бейсика БК мне кажется преувеличенной – эта версия очень близка к Бейсику MSX, который, насколько я понимаю, был ближайшим родственником упомянутого вами GW-Basic. Бейсик БК поддерживает целые числа, а также вещественные одинарной и двойной точности, может работать с двоичными, восьмеричными и шестнадцатеричными константами, имеет почти весь набор операторов Бейсика MSX (в том числе графических). У меня лично к нему 3 существенных претензии – невозможность размещения нескольких операторов в строке (что для меня вообще необъяснимо, но, видимо, для этого были какие-то важные причины; причём 9-килобайтный вильнюсский Бейсик такого ограничения не имел!), отсутствие операторов задания типа переменных (особенно DEF INT, что вынуждает добавлять знаки «процент» ко всем целым переменным, которые на БК использовались очень часто по причине во много раз большей скорости работы, чем у вещественных) и отсутствие математики одинарной точности (все вычисления с переменными не только двойной, но и одинарной точности делаются в режиме двойной точности, что сильно снижает скорость; впрочем, точно также было и у Бейсика MSX). Зато у Бейсика БК самая высокая точность вычислений среди всех представленных в таблице компьютеров (до 17 десятичных знаков). Да, памяти он требует много, и размер программ небольшой, но его обычно достаточно, да и скорость работы просто великолепная (с целочисленными переменными).

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

Я согласен, что программы на Бейсике в сумме использовались, пожалуй, реже, чем программы на ассемблере (в основном за счёт игр), но сам-то бейсик, как вы верно заметили – тоже программа на ассемблере. И я думаю, что среди программ на ассемблере (даже включая игры) именно Бейсик был одной из самых популярных и востребованных: на Бейсике писалось отнюдь не мало программ (уж точно больше, чем на ассемблере) – для энтузиастов, которым было интересно заниматься программированием, это однозначно был основной язык, в сфере обучения – тоже, да и готовые программы на Бейсике (даже игры) использовались совсем не редко.

Насчёт производительности процессоров совершенно разного типа (6502/6809, Z80/8080, x86, PDP-11-совместимых) есть разные данные, но достаточно большой массив результатов для Бейсика как раз даёт очень даже близкую к реальности картину именно их средней скорости, а также производительности при сложных вычислениях. И эти результаты вполне соответствуют теоретическим рассуждениям насчёт скорости работы с памятью, числа тактов на команду, наличия разных способов адресации, разрядности процессоров и т.д.


...опять не могу ничего добавить, пока кто-то не ответит - лимит длины сообщения исчерпан

[avivanov76]

А так как практически у всех Бейсиков уши растут из одного места, то алгоритмы у них соответственно в большинстве случаев похожи

Вот это меня натолкнуло на мысль "взять всё и поделить" В смысле, если алгоритмы похожи, значит время выполнения одного теста относительно другого должно отличаться примерно в одинаковое число раз для разных Бейсиков, так? То есть можно поделить скорость в каждом из тестов на скорость в том тесте, которому мы доверяем больше всего, например в BM3 (желательно, чтобы скорость в выбранном тесте не была слишком маленьким числом, потому что наверняка в этом случае ошибка измерения больше). После этого можно построить график относительной скорости. Если у разных Бейсиков похожие реализации, то линии графиков будут лежать рядом или даже совпадать.

В качестве опорного я взял результат 3-го теста, так что там всегда единица. Получилось вот что: Бейсики для 8080 правда очень похожи. Я даже потерял линию для "Апогея БК-01", так как она совпала с линией для "Корвета" - похоже это один и тот же Бейсик. У Бейсиков для 6502 заметный разнобой в тестах BM1 (в 2 раза) и BM8 (в 4 раза). У Бейсиков для Z80 более менее совпали только 4 и 5 тесты, в остальных разброс большой. А уж у PDP-11 и того хлеще. Общую картинку я не стал рисовать - такой телефонный кабель получается, что ничего не разберешь.

Кстати, становятся наглядно видны особенности Бейсиков типа ускорения за счёт перевода констант в плавучку заранее в BM4, медленная работа с массивами в BM6 или оптимизация трансцендентных функций в BM8.

В этом как раз огромное достоинство Бейсика, как тестовой платформы – он позволяет очень быстро и просто (и довольно точно) измерить скорость работы ПК буквально двумя-тремя операторами

У меня ощущение (возможно ошибочное), что Вы как-то странно смотрите на измерение скорости - без учета реального выхлопа программы.

Программу на ассемблере я привел не в качестве теста, а примера того, что в основном Вы измеряете работу интерпретатора Бейсика. Для решения поставленной задачи (сложить 100 чисел) нужно где-то 3800 тактов для Z80. Но на Бейсике эта задача решается раз в 100 медленнее (или 10, если есть поддержка целых чисел). Остальные 90-99% времени выполняются алгоритмы, которые к решению задачи не имеют отношения. Ну, за исключением самых "тяжелых" тестов.

Бенчмарки же практически всегда реализуют либо конкретный алгоритм, либо смесь инструкций, характерную для определенной задачи. Например, смесей Гибсона было 8 штук (чаще использовались деловые и научные). А на суперкомпьютерах решают в основном системы уравнений, поэтому и тесты там на решение уравнений (LINPACK). А пытаться сравнивать ассемблерную программу, реализующую алгоритм интерпретатора Бейсика, с ассемблерной программой, реализующей любой другой алгоритм просто некорректно.