π-затвор, нужна помощь железом и при возможности с оптимизацией

[litwr]

3дравствуйте!
Позапускал π-затвор на эмуляторах, но неуверен вполне в их точности. Не мог бы кто-нибудь помочь своим Корветом? Нужно запустить программу pi-8080.com из папки korvet архива пакета #41 - в этой же папке есть и образ загрузочного диска с этой программой. Собираю данные для 100, 1000 и 3000 цифр (последний расчет занимает почти час) - программа печатает число секунд в конце работы - это мне и нужно. Сам проект здесь - https://litwr2.github.io/pi-spigot-benchmark/pi-spigot-benchmark.html - архив и исходники в конце страницы. Заранее благодарю за поддержку. Хорошо бы ещё фотку с экрана срезультатом - типа http://litwr.atspace.com/3.jpg
Если ivagor и b2m, которые когда-то активно поработали над π-затвором, окажутся здесь, то им возможно будет интересно глянуть на коды 8080 и 8085. Мой код деления - это практически копия их кодов. Код 8085 в https://github.com/litwr2/rosetta-pi-spigot/tree/master/tandy-100 . Буду очень признателен, если кто поможет разогнать коды для 8080 или 8085. Можно и просто предложить свой код, который быстрее и соответствует 4-м ограничениям на программы проекта.
Со мной связался человек из Германии, хочет купить Корвет на ebay. Если кому интересно пишите.

[Sancho45]

Так пойдет ?
Загрузка с ExtRom, на флоповод не хочу заморачиваться...

https://i.ibb.co/mTckVnd/20200530-183229.jpg (https://ibb.co/mTckVnd)

1000 и 3000 в процессе

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

это 3000

https://i.ibb.co/W5WgW71/20200530-191648.jpg (https://ibb.co/W5WgW71)

[Sancho45]

1000
https://i.ibb.co/NsyLmL6/20200530-193024.jpg (https://ibb.co/NsyLmL6)

[ivagor]

Исходники не смотрел, но 100%, что версии для 8080 и 8085 не оптимальные, т.к. векторовская и для ПК-6128Ц быстрее.

[Arix]

Нужно запустить программу pi-8080.com из папки korvet архива пакета #41 - в этой же папке есть и образ загрузочного диска с этой программой.
А где эта папка? Если это "pk8020 dump disk collection by Dmitriy Krautsov", у меня там после 40 идет сразу 42. Да и просто поиском я у себя этой программы не нашёл. Подкиньте пожалуйста.

[litwr]

Так пойдет ?
Загрузка с ExtRom, на флоповод не хочу заморачиваться...

1000 и 3000 в процессе

это 3000

Все получилось супер! Большая вам благодарность. Обогнали таки дорогой Коммодор-128 с Z80, а его кое-где массово под СР/М закупали - им бы Корветы лучше пошли. :) И дисководы у Корвета получше сверхдорогих коммодорских.
Эмулятор b2m показал очень хорошую точность, отклонение таймингов менее 1%. Это можно списать и на особенности аппаратуры. Если b2m это читает, то могу посоветовать, при тестировании эмулятора запускать программу с таймингами и проверять их по секундомеру - у меня эмулятор на π--затворе также примерно на 1% оказался быстрее. Хотя ещё возможно, что вы просто не чистили экран перед запуском на 1000 и 3000 цифр, хотя это максимум секунда всего, всей разницы не покроет. Вот у первого в мире мобильного компьютера (Tandy 100), скороллинг экрана занимает примерно секунду...
Обновил таблицы - http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html


Исходники не смотрел, но 100%, что версии для 8080 и 8085 не оптимальные, т.к. векторовская и для ПК-6128Ц быстрее.

Так уверены про 3000 цифр? ;) А нет ли у вас версии для Корвета? Хотя там у меня для таймингов получился какой-то тяжеловатый код, который перемещаю в стек... Но его можно взять готовым, всё корветное под условной компиляцией - найти и прикрепить к векторной программе легко. А что неоптимальные - это понятно, вопрос только практически или теоретически неоптимальные? Если практически, то нужен код-подтверждение.


А где эта папка? Если это "pk8020 dump disk collection by Dmitriy Krautsov", у меня там после 40 идет сразу 42. Да и просто поиском я у себя этой программы не нашёл. Подкиньте пожалуйста.
Открывайте ссылку на π-затворные таблицы, а там в конце страницы ссылка на архив 41.

[ivagor]

Так уверены про 3000 цифр? А нет ли у вас версии для Корвета? Хотя там у меня для таймингов получился какой-то тяжеловатый код, который перемещаю в стек... Но его можно взять готовым, всё корветное под условной компиляцией - найти и прикрепить к векторной программе легко. А что неоптимальные - это понятно, вопрос только практически или теоретически неоптимальные? Если практически, то нужен код-подтверждение.
litwr, может я путаю, но на момент работы над версией для вектора были две контрольные точки: 100 и 1000, других я не делал. На мой взгляд 1000 - сравнительно универсальный вариант, без проблем влезает на экраны большинства компьютеров. Конечно можно результат с бОльшим числом цифр выводить/сохранять как-то иначе.
Что касается неоптимальности и конкретного кода - код все тот же (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=849604&viewfull=1#post849604).
Я обещал b2mу не делать версий для других компов, кроме вектора (и клонов), поэтому других версий нет. Но примерно оценить, как тот код работал бы на корвете, можно.
Векторовская версия:
100 - 2.7568 сек
1000 - 280.9320 - 4 мин 40.9320 сек

В emu можно изменить тактовую в конфиге вектора на 2.5 МГц и отключить векторовское торможение. Тогда получатся такие цифры:
100 - 2.6968 сек
1000 - 275.7000 - 4 мин 35.7000 сек
Для корвета, если постараться, будет даже чуть-чуть быстрее, т.к. можно использовать вывод на текстовой экран 64x16.

Т.е. заметно быстрее Вашей текущей версии, а 100 цифр - быстрее БК0010. Если бы в 2016 векторовская версия отставала от БК - я бы продолжил оптимизацию. Как я понимаю, с тех пор БКшная версия стала побыстрее, а мой вариант Вы отбросили (вероятно из-за сравнения по варианту 3000 цифр, который я не делал), в итоге 8080 проиграл 1801ВМ1, ловко получилось.

[litwr]

litwr, может я путаю, но на момент работы над версией для вектора были две контрольные точки: 100 и 1000, других я не делал. На мой взгляд 1000 - сравнительно универсальный вариант, без проблем влезает на экраны большинства компьютеров. Конечно можно результат с бОльшим числом цифр выводить/сохранять как-то иначе.
Что касается неоптимальности и конкретного кода - код все тот же (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=849604&viewfull=1#post849604).
Я обещал b2mу не делать версий для других компов, кроме вектора (и клонов), поэтому других версий нет. Но примерно оценить, как тот код работал бы на корвете, можно.
Векторовская версия:
100 - 2.7568 сек
1000 - 280.9320 - 4 мин 40.9320 сек

В emu можно изменить тактовую в конфиге вектора на 2.5 МГц и отключить векторовское торможение. Тогда получатся такие цифры:
100 - 2.6968 сек
1000 - 275.7000 - 4 мин 35.7000 сек
Для корвета, если постараться, будет даже чуть-чуть быстрее, т.к. можно использовать вывод на текстовой экран 64x16.

Т.е. заметно быстрее Вашей текущей версии, а 100 цифр - быстрее БК0010. Если бы в 2016 векторовская версия отставала от БК - я бы продолжил оптимизацию. Как я понимаю, с тех пор БКшная версия стала побыстрее, а мой вариант Вы отбросили (вероятно из-за сравнения по варианту 3000 цифр, который я не делал), в итоге 8080 проиграл 1801ВМ1, ловко получилось.

Вектор - хороший компьютер, было бы очень хорошо данные по нему также добавить к базе по π-затвору. Только там программа должна считать не менее 3000 цифр и поэтому большие таблицы для умножения (больше 10 КБ) не используются, нужно как вторую цель иметь побольше цифр. Нельзя иметь разные варианты программы для расчета разного числа цифр, алгоритм должен быть одинаков для всех случаев. Нужно использовать стандартную процедуру вывода - на расчете 3000 цифр её влияние на скорость совсем незначительно. Насколько помню, у Вашего алгоритма нельзя было в делителе иметь число, большее 32767...
При общих условиях можно будет объективно сравнить быстродействие, а пока сравниваем разные коды, сказать, что Вектор обогнал БК, - это скорее неверно.
Только что запустил Ваш код на эмуляторе b2m. Это первый раз, когда вектор-программу запускаю. :) Опять не удержусь от замечаний автору эмулятора. Недавно эмулировал Роботрон, но после запуска Вектора эмулятор остается в папке с дисками для Роботрона - хорошо бы каждой эмулируемой машине иметь свой каталог по-умолчанию. Возможно это где-то и реально прописать, но хорошо бы чтобы папка эмулируемого компьютера была сразу где-то прописана дефолтом.
----EDIT----
По моим расчетам без торможение дожно быть примерно на 10% быстрее. Это так считаю, потому что такое же в точности видеоторможение есть и на Амстрадах. И Ваши данные показывают примерно 1.8% - что-то не сходится.

[ivagor]

программа должна считать не менее 3000 цифр и поэтому большие таблицы для умножения (больше 10 КБ) не используются, нужно как вторую цель иметь побольше цифр. Нельзя иметь разные варианты программы для расчета разного числа цифр, алгоритм должен быть одинаков для всех случаев. Нужно использовать стандартную процедуру вывода
Не согласен со всеми этими пунктами. Особенно интересно по отношению к вектору звучит требование про стандартную процедуру вывода.


По моим расчетам без торможение дожно быть примерно на 10% быстрее. Это так считаю, потому что такое же в точности видеоторможение есть и на Амстрадах. И Ваши данные показывают примерно 1.8% - что-то не сходится.
Для amstrada cpc стандартная оценка учета торможения сводится к "эквивалентной" частоте 3.2 или 3.3 вместо 4 МГц. Т.е. это 80% или 82.5%. Это средняя по больнице оценка и в конкретных случаях отличия могут быть и в большую и в меньшую сторону.
Посмотрим, что получится для вектора, если применить к нему амстрадовские коэффициенты.
3*.8=2.4; 3*.825=2.475
А что получилось на примере затвора (на примере 1000 цифр, чтобы уменьшить погрешность): есть результаты для 2.5 МГц без торможения и для 3 МГц с тормозами.
k=275.7000/280.9320=0.9814, 2.5*k=2.4534. Т.е. при расчете 1000 цифр с использованием данного алгоритма быстродействие вектора эквивалентно частоте 2.4534 МГц. Это коэффициент 2.4534/3=.8178 или 81.78%. Довольно близко к амстрадовским оценкам, не знаю, что Вас смущает.

[litwr]

Не согласен со всеми этими пунктами. Особенно интересно по отношению к вектору звучит требование про стандартную процедуру вывода.
Это Вы написали про якобы неоптимальность кода. Предложил всего лишь показать это практически. Сейчас ваш код быстрее на 15%, но полагаю, что если убрать большие таблицы и добавить поддержку больших делителей, то это его замедлит процентов на 20% или даже больше. У меня со шведом недавно был спор про вывод цифр на экран. Но у него позиция была покрепче, он жаловался на то, что сетевые соединения очень тормозят вывод. И это правда, старые ваксы, пдп11 даже на 3000 цифр через телнет выводят очень медленно, вывод может занимать до 15%. Поэтому сейчас в таблицах можно выбирать отдельные тайминги по чистому расчету и выводу. Это в большинстве случаев делается по формуле, но можно при наличие данных и вбивать точные числа - нужно запускать программу без вывода на экран. А для персоналок даже с медленным выводом на экран, время вывода менее 1% от всего времени работы программы на 3000 цифр. В чем проблема?
Но главное, конечно, что есть база программ, которые позволяют сравнивать разные архитектуры на лучших кодах. Было бы интересно, если бы вы приняли участие. Очень удивлюсь, если Вектор обгонит БК0010 на 3000 цифр.


Для amstrada cpc стандартная оценка учета торможения сводится к "эквивалентной" частоте 3.2 или 3.3 вместо 4 МГц. Т.е. это 80% или 82.5%. Это средняя по больнице оценка и в конкретных случаях отличия могут быть и в большую и в меньшую сторону.
Посмотрим, что получится для вектора, если применить к нему амстрадовские коэффициенты.
3*.8=2.4; 3*.825=2.475
А что получилось на примере затвора (на примере 1000 цифр, чтобы уменьшить погрешность): есть результаты для 2.5 МГц без торможения и для 3 МГц с тормозами.
k=275.7000/280.9320=0.9814, 2.5*k=2.4534. Т.е. при расчете 1000 цифр с использованием данного алгоритма быстродействие вектора эквивалентно частоте 2.4534 МГц. Это коэффициент 2.4534/3=.8178 или 81.78%. Довольно близко к амстрадовским оценкам, не знаю, что Вас смущает.
Конечно, это всё гадание на кофейной гуще. Но вроде бы в любом случае получается, что Корвет чуть быстрее Векторa.

[ivagor]

Сейчас ваш код быстрее на 15%, но полагаю, что если убрать большие таблицы и добавить поддержку больших делителей, то это его замедлит процентов на 20% или даже больше.
Без двух больших таблиц расчет замедляется примерно на четыре с половиной процента, я про это писал (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=850395&viewfull=1#post850395). Про делители и множители надо смотреть.


Но вроде бы в любом случае получается, что Корвет чуть быстрее Векторa.
Да, корвет и орион-128 почти на 2% быстрее вектора в расчете пи spigotом.

[litwr]

Без двух больших таблиц расчет замедляется примерно на четыре с половиной процента, я про это писал (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=850395&viewfull=1#post850395). Про делители и множители надо смотреть.

Да, корвет и орион-128 почти на 2% быстрее вектора в расчете пи spigotом.

Прямо не могу представить, чтобы такие большие проценты и всего 4-5%. И насколько реально, что быстрее, нужен конкретный код, чтобы сказать, а не гадать и предполагать. Вот и обращаюсь к Вам как к эксперту по 8080 помочь сделать лучший код для Вектора. Упоминавшийся швед 4 месяца оптимизировал для RSX-11 и мы с ним реально хорошо разогнали расчет. Хотя он в итоге остался недоволен, типа под Юникс буферизация автоматически идёт, а в его любимой RSX нужно самому писать и память большую для буфера выделять, что запрещено правилом 4. Если у Вас реально получится на 15% ускорить, то это обгонит БК... Вам достаточно выложить код без больших таблиц, способный считать столько знаков, сколько поместится в памяти. С другой строны, хорошо уже, что и пообщались. :) Без Вашего деления мой код был бы совсем никакой. Я его даже амстрадникам выложил, у них в базе был совсем тормозной алгоритм.
Кажется писал уже, что на Tandy 100 скроллинг экрана занимает почти секунду - рекордный тормоз, но первый мобильник, мог 20 часов работать от батареек. Вывод на экран можно и под условной компиляцией сделать. У меня в кодах для CP/M+ всегда использую БДОС, хотя БИОС быстрее.

[ivagor]

Надо уточнить, что автор алгоритма быстрой процедуры деления - blackmirror. Процедура действительно новаторская, не находил аналогов/прототипов, я ее потом и в 3d крутилке и в рейкастере использовал.
В ближайшее время я вряд ли займусь spigotом и если займусь, то, как уже писал, не в рамках ограничений, с которыми я не согласен.

[litwr]

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

[ivagor]

Зачем заходить еще на один круг? Для 100 цифр быстрее, для 1000 цифр медленнее.

[litwr]

Зачем заходить еще на один круг? Для 100 цифр быстрее, для 1000 цифр медленнее.

Так сами круги и провоцируете. Вот и сейчас написали, что что-то быстрее. Но алгоритмы разные. Как можно сравнить программу, где используются большие таблицы, с программой, где не используются? У БК памяти нет на такие таблицы. А если взять, например, MSX, то получится, что под бейсиком памяти нет, а под досом есть - и будет странная заметная разница для доса и бейсика. А процессор тот же. Поэтому в спорте и нужны правила.

[ivagor]

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

Большие таблицы - это одно из средств ускорения расчета. В память вектора влезают большие таблицы - используем, в БК-0010 не влезают - не используем. У 1801ВМ2 есть команды умножения и деления - используем, у 8080 нет - не используем.
Если в разных программных окружениях в рамках одного компьютера доступны разные возможности (например разный размер памяти), то я выберу вариант, который обеспечит максимальное быстродействие.
Если есть желание сравнить, как влияет размер памяти (или поддержка каких-то команд или турбо-режим или еще что-то) в рамках одного компьютера - сравниваем.

Есть еще вариант - когда человек обладает абсолютно точным знанием, как нужно делать и сам по себе является эталоном правильности. Этот случай я обсуждать не буду, он выходит за рамки ретрокомпьютеров.

[litwr]

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

Большие таблицы - это одно из средств ускорения расчета. В память вектора влезают большие таблицы - используем, в БК-0010 не влезают - не используем. У 1801ВМ2 есть команды умножения и деления - используем, у 8080 нет - не используем.
Если в разных программных окружениях в рамках одного компьютера доступны разные возможности (например разный размер памяти), то я выберу вариант, который обеспечит максимальное быстродействие.
Если есть желание сравнить, как влияет размер памяти (или поддержка каких-то команд или турбо-режим или еще что-то) в рамках одного компьютера - сравниваем.

Есть еще вариант - когда человек обладает абсолютно точным знанием, как нужно делать и сам по себе является эталоном правильности. Этот случай я обсуждать не буду, он выходит за рамки ретрокомпьютеров.

Как-то вы всё усложняете. У меня просто бенчмарк процессора и, естественно, далеко не идеальный. Но с претензией, что коды наилучшие. Естественно, размер памяти не должен влиять на бенчмарк процессора, иначе мы некоторые системы, напаример, БК, ставим в нечестную позицию. Поэтому и правила, чтобы процессоры тестировались на одинаковых алгоритмах, а иначе получится соревнование алгоритмов. Для Apple II делали какую-то приставку, где было много ПЗУ (мегабайты) с таблицами для логарифмов и т.п. и получали с ней отличные скорости для вещественных чисел, только эти скорости к обычным 6502 или 65816 имели очень небольшое (скорее никакое) отношение.