Вашу бы энергию на написание крутых демо-эффектов или хотя бы игр)
Вид для печати
Вашу бы энергию на написание крутых демо-эффектов или хотя бы игр)
ё-маё, b2m уже успел и умножение на 10 оптимизнуть
Интересно, что деление выполнено обычным циклом с вычитанием. Видимо для данного алгоритма это быстрее (т.к. результат деления маленький). Можно попробовать и с моим кодом так поиграть...
---------- Post added at 17:29 ---------- Previous post was at 17:21 ----------
Развернул таки цикл в последовательность :)
Кстати, один из множителей всегда меньше 256, иначе было бы переполнение.
---------- Post added at 17:32 ---------- Previous post was at 17:29 ----------
Я думаю, если кардинальных оптимизаций больше не будет, на этом и остановимся.
Остановился на 34405448 тактов - 19.35 сек
Конечно же после разминки разойдутся и поймут что ассемблер - это не тайна за семью печатями, и явят ещё одну Колибри, но уже для РК-86.
Кстати вот новый (точнее незамеченный старый путь) для совершенствования расчета числа Пи, сдавала студентка и я её даже хорошо знаю, в 2009 году, причем успешно:
Думаю из этого куцего описания будет понятно куда можно попробовать дальше двинутся ? Или для ретро-процессоров это не по силам ?Код:; Зачетная задача: пользуясь рядом Тейлора для arctg, подсчитать число пи
; с 100 знаками после запятой.
;
; Расчет числа Пи сделаем по формуле Мачина
;
; 1 1
; pi = 16 arc tg --- -4 arc tg---
; 5 239
;
; arc tg будем вычислять по формуле Тейлора:
;
; 3 5 7 9
; x x x x
; arc tg x = x - --- + --- - --- + --- - ...
; 3 5 7 9
.186
stack segment stack
dw 512 dup (?)
stack ends
data segment
; -------------------------------------------------------------------------------
; Следующие числа указывают сколько цифр числа Пи нужно вычислять
; Я использовала программу MAKESZES.BAS чтобы вычислить эти значения
; в выводимом на экране результате только первые А (в нашем случе 100цифр) являются верными
; This BASIC program was used to calculate the equates for PIF.ASM.
; DEFDBL A-Z
; INPUT "Digits required"; A
; MPVSize = 32 * ((A / (LOG(2) / LOG(10)) + 255) \ 256)
; PRINT "NumDigits = "; A + 64
; PRINT "MPVSize = "; MPVSize
; k = A / .69897
; k = INT(15 + (k + k * .1)) 'floor 1
; PRINT "Last1 = "; k
; k = INT(15 + (A / 2.37)) 'floor 2
; PRINT "Last2 = "; k
;
numDigits=164
mpvSize=74
last1=172
last2=57
Авторство программки конечно же не студентки, а уважаемого гуру:
https://sites.google.com/site/richgel99/Цитата:
; ASMPI by Rich Geldreich, December 1992 - June 1993
; (A FAST all-assembly PI calculator.)
; Thanks to Victor Yui for suggesting the division optimization.
; (This program has only been verified to 10,000 digits.)
https://sites.google.com/site/richge...-pi-calculator
Все что сделала студентка, так это покоцала оригинал (под процессор 286) до требований курса использовать процессор 86.
Теперь же надо тоже самое сделать, но уже покоцав оригинал до уровня команд любимых ретро-процессоров, причем глубокие оптимизации даже приветствуются.
Замечу, что схожие алгоритмы лежат в основе всех TOP-вычислителей числа Пи, но нам более чем будет достаточно для счастья и этого достаточно быстрого алгоритма, мне бы хотелось увидеть результат дальнейшего роста производительности нашей РК-86 в разы!
Попробовал дожать spigot b2mа: 26539359 такта - 14.93 сек
Вложение 54778
Появилось желание повыпендриваться и сделал еще версию оптимизированную для 580ВМ1 и 8085 - в ней используются только общие для этих процов команды. Индивидуально для них можно оптимизировать лучше.
Оптимизированная версия:
на 580ВМ1: 24938659 тактов - 14.03 сек
на 8085: 24082312 такта - 13.55 сек
100 знаков считаются слишком быстро, вот результаты расчета 535 знаков:
1) Версия для 8080
8080 и 580ВМ1 - 755784115 тактов - 7 мин 5 сек;
8085 - 734253062 такта - 6 мин 53 сек;
2) Версия для ВМ1 и 8085
580ВМ1 - 709984370 тактов - 6 мин 39 сек;
8085 - 685592137 тактов - 6 мин 26 сек;
Вложение 54779
Насколько я понимаю, b2m использовал исходник отсюда (надо промотать вниз).
- - - Добавлено - - -
Забыл сразу написать. Еще резервы есть в использовании самомодифицирующегося кода (попробовал, а потом убрал). Кроме того, данный вариант может работать при разрешенных прерываниях, если не на РК (хитрое использование стека также в резерве).
Кардинального ускорения расчета большого количества знаков наверное лучше добиваться использованием другого алгоритма.