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

[litwr]

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

[Advertiser]

[Sancho45]

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



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

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

это 3000

[Sancho45]

1000

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