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

[Mdesk]

Реплика Apple I, Synertek 6502 CPU @ 1.023 MHz:
1000 знаков, вычисления – 1 мин. 52 сек., вычисления + вывод на экран – 2 мин. 17 сек.

Исходник (Мэчин/Тейлор) взял по последней ссылке в предыдущем сообщении. В нем в 930 строке вместо "ldx #-1" написал "ldx #$FF", а то ассемблер ругался.
Ассемблер и линковщик взял с 6502.org (cc65 от Ullrich von Bassewitz), потому что автор исходника им пользовался - получил бинарник.
Из бинарника HEX-редактором и текстовым редактором сделал командный файл для Apple I (это текст, как если бы мы вводили данные в память компа с клавиатуры).
Этот командный файл утилитой toaiff от Mike Willegal преобразовал в AIFF звуковой файл (собрал эту утилиту для WIN32).
Звуковой файл грузим в реплику Apple I и радуемся.

[litwr]

Mdesk, благодарности вам за интересные результаты. Получается, что по Мачину 8-битки более чем 2 раза быстрее считают, чем по "затвору" ("шпиготу"). Что подтвердило исходное мнение уважаемого perestoronin'a. Осталось уважаемому ivagor'y перевести всё на 8080 и Вектор выдаст 100 знаков секунд за 0.7 или даже меньше. Однако, формула Стёрмера ещё быстрее и через те же арктангентсы. А если кто реализует подход Чудновских на 8-битном "камне", то должно быть ещё быстрее.
Добавлю ещё, что впечатлен тем, как в 1949 30-тонная махина компьютера Eniac с помощью четырех энтузиастов, которые выступали и в качестве внешней памяти компьютера, в течении 70 часов (без сна?) считала π до более чем 2000 знаков, что даёт примерно 17 часов на 1000 знаков. http://jerkwerks.com/pi-day-rematch-apple-ii-vs-hp-41c/

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

А вот немного негатива. В оригинальной статье Рабиновича и Вагона (http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf) по затворному алгоритму приводится программа на паскале. Она правильно считает 100 знаков, но неправильно 1000 - там какая-то ошибка, математики не довели программу... Поэтому, просьба к уважаемому Mdesk, сообщите последние 8 знаков из расчёта.

[Mdesk]

Mdesk, сообщите последние 8 знаков из расчёта

64201989

[LeoN65816]

В оригинальной статье Рабиновича и Вагона (http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf) по затворному алгоритму приводится программа на паскале.

Перевёл эту прогу на паскакале сначала на Бейсик АГАТа (хотел в дальнейшем перевести на асм). Прогнал в эмуле. Всегда даёт лишний (лидирующий) ноль. Для 10 посчитал 10 знаков, для 100 посчитал 102 знака, для 1000 посчитал 1019 знаков... Гдей-то глюк...

[litwr]

64201989

9 - это 1001 цифра, получилась восточная сказка. По Мачину плохо, что трудно заранее определить минимальное число итераций для заданного числа цифр. И в алгоритме использовалась 256-значная система счисления, "затвор" так не может - он сразу ответ печатает, а не сначала накапливает, а потом переводит в 10-й вид.

Перевёл эту прогу на паскакале сначала на Бейсик АГАТа (хотел в дальнейшем перевести на асм). Прогнал в эмуле. Всегда даёт лишний (лидирующий) ноль. Для 10 посчитал 10 знаков, для 100 посчитал 102 знака, для 1000 посчитал 1019 знаков... Гдей-то глюк...

Сначала проще с паскалем разобраться, хороший компилятор fpc есть для всех платформ. 100 знаков считает правильно, хотя и с лидирующим нулем - всего 101 знак. А с 1000 - полная ерунда, больше половины знаков неверны. Но ваш результат совсем другой, с вставкой лишних нулей, но вроде бы с правильными прочими цифрами - что-то слегка не так перевели. Проблема с 1000 знаков в том, что нужно все переменные делать типа longint. Авторы наверное использовали паскаль, где тип integer 32-битный. Проверил на 3000 и 9000 знаков, с longint - все правильно.
Почти уверен, что оптимизированный "затвор", выдающий по 4 цифры за раз, быстрее исходного, хотя возможно он потребует чуть меньше памяти, 6.67 байт на цифру, вместо 7. А есть ещё "затвор без границ", но на его реализации даже спецы из HP больше 3000 знаков не смогли получить.
В https://rosettacode.org/wiki/Pi эта программка использует вспомогательную процедуру, в каком-то не совсем чистом паскале, но не работает совсем. Кстати, туда можно коды 6502, 8080, ... вставить, пока ещё не занято место.

[litwr]

https://www.youtube.com/watch?v=wlcG...ature=youtu.be
z80 112 MHz в действии.

[HardWareMan]

Чегото не пойму я. https://ru.wikipedia.org/wiki/Acorn_Atom

[litwr]

Подключил человек из Голландии к своему Атому крутой сопроцессор и получает удовольствие от скорости и даже этим удовольствием делится.
http://stardot.org.uk/forums/viewtopic.php?f=44&t=8852

[litwr]

Кто-то ранее интересовался самым крутым 8-битным процессором 6809. Сделал и для него "затвор". Побыстрее 6502 из-за второго аккумулятора, но в целом впечатление неоднозначное. Какой-то 6809 неуклюжий: обратный порядок байт тормозит арифметику, с памятью работает медленнее, чем 6502, индексные регистры медленные, пересылка одного аккумулятора в другой занимает 6 (!) тактов, ... Если бы MOSTEC не разогнали, то уверен, что там бы сделали что-то гораздо более качественное.
http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html

[litwr]

Есть очень необычный способ посчитать пи, использую клеточную колонию - http://pentadecathlon.com/lifeNews/2...lculators.html. Примерно миллион клеток за примерно 280 миллиардов поколений смогли посчитать 3 знака на средненьком ПК. Картинка с сайта явно высчитана на сверхмощном суперкомпьютере. На обычном на три знака ушло почти два часа при минимуме требуемой памяти 8 ГБ. Хотя другая программа справилась минут за 40. Прикрепляю свою картинку. На картинке с сайта знаки пи в верху, но сильно размазаны из-за уменьшения. Размеры этого клеточного компьютера 163841х114689, в экран не влезет. Прикрепляемая картинка уменьшена в 128 раз, цифры отчетливо видны.

При закачке на сайт картинка сменила размер и формат, поэтому прикрепляю её в zip-архиве.
xlife-pi.zip