Вычисление числа Пи на ассемблере

[ALS]

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

[rw6hrm]

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

[b2m]

Первые результаты
Радио-86РК, 100 знаков, 53 секунды

Проверялось в эмуляторе, на реале возможно будет немножко другое время.


После оптимизации умножения 25.59 секунды.

[b2m]

Вероятнее всего скорее это непредельный результат

Шутишь? Разве что ivagor найдёт изъяны и оптимизирует на пару тактов
А вообще, было бы интересно, если кто-либо предложил бы свой, более быстрый, вариант.

[Viktor2312]

найдёт изъяны и оптимизирует на пару тактов

Думаю, что и на 100 можно оптимизоровать, тактов.

[b2m]

Кстати, по поводу пределов: максимально возможное число знаков для этого алгоритма, использующего только 16-битную арифметику = 534. Сколько будет считать - незнаю, но сложность этого алгоритма O(N²), так что будет раз в 28-29 дольше.

[Advertiser]

[zebest]

[OFFTOPIC ON]
Надеюсь злостных оверов тут нет, поэтому может кому то интересно узнать,
про ихний сайт www.hwbot.org и одну из дисциплин меряния эмм..., ну вобщем кто быстрее посчитает SUPERPI - 1M и SUPERPI - 32M.
http://hwbot.org/benchmark/superpi_-_1m/
Лучшие резальты справа.
комуу интересно, можете на своих числодробилках запустить, чтобы иметь представление, насколько совремённые процессоры считают быстрее их предшественников
Собственно сам бенч под винду.
На ретро-процах, типа первых пеньков - вполне тоже работает.
Upd: PiFast из той же оперы...

[/OFFTOPIC OFF]

[ivagor]

Оригинал b2m: 90802464 тактов - 51 сек
После оптимизации умножения: 51124904 тактов - 27.76 сек
Может еще пару тактов удастся сбросить

[b2m]

Сообщите пожалуйста что было исправлено

Я догадываюсь, что он сделал. Если проанализировать алгоритм, то основная масса умножений будет на число, меньшее 256. Поэтому количество сдвигов в этих случаях можно уменьшить вдвое (переместив младший байт множителя в старший).

---------- Post added at 16:31 ---------- Previous post was at 16:10 ----------

Заменил pi.rar, теперь 34 секунды. ivagor круче

---------- Post added at 16:51 ---------- Previous post was at 16:31 ----------

Заменил умножение на 10 (без вызова п/п умножения). Теперь 26 секунд. Я круче

---------- Post added at 17:04 ---------- Previous post was at 16:51 ----------

Если я правильно понял алгоритм, там q тоже всегда меньше 256, так что можно ещё пару тактов сэкономить.

[ivagor]

Утром пришлось прерваться на самом интересном месте. Было видно, что еще можно немного дожать. Хотелось в 2 раза обогнать, но не успел, b2m уже оптимизировал.
Тем не менее, предлагаемый вариант выполняется за 43499204 такта - 24.47 сек