Без двух больших таблиц расчет замедляется примерно на четыре с половиной процента, я про это писал. Про делители и множители надо смотреть.
Да, корвет и орион-128 почти на 2% быстрее вектора в расчете пи spigotом.
Без двух больших таблиц расчет замедляется примерно на четыре с половиной процента, я про это писал. Про делители и множители надо смотреть.
Да, корвет и орион-128 почти на 2% быстрее вектора в расчете пи spigotом.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Прямо не могу представить, чтобы такие большие проценты и всего 4-5%. И насколько реально, что быстрее, нужен конкретный код, чтобы сказать, а не гадать и предполагать. Вот и обращаюсь к Вам как к эксперту по 8080 помочь сделать лучший код для Вектора. Упоминавшийся швед 4 месяца оптимизировал для RSX-11 и мы с ним реально хорошо разогнали расчет. Хотя он в итоге остался недоволен, типа под Юникс буферизация автоматически идёт, а в его любимой RSX нужно самому писать и память большую для буфера выделять, что запрещено правилом 4. Если у Вас реально получится на 15% ускорить, то это обгонит БК... Вам достаточно выложить код без больших таблиц, способный считать столько знаков, сколько поместится в памяти. С другой строны, хорошо уже, что и пообщались.Без Вашего деления мой код был бы совсем никакой. Я его даже амстрадникам выложил, у них в базе был совсем тормозной алгоритм.
Кажется писал уже, что на Tandy 100 скроллинг экрана занимает почти секунду - рекордный тормоз, но первый мобильник, мог 20 часов работать от батареек. Вывод на экран можно и под условной компиляцией сделать. У меня в кодах для CP/M+ всегда использую БДОС, хотя БИОС быстрее.
Надо уточнить, что автор алгоритма быстрой процедуры деления - blackmirror. Процедура действительно новаторская, не находил аналогов/прототипов, я ее потом и в 3d крутилке и в рейкастере использовал.
В ближайшее время я вряд ли займусь spigotом и если займусь, то, как уже писал, не в рамках ограничений, с которыми я не согласен.
Последний раз редактировалось ivagor; 07.06.2020 в 06:48.
Зачем заходить еще на один круг? Для 100 цифр быстрее, для 1000 цифр медленнее.
Так сами круги и провоцируете. Вот и сейчас написали, что что-то быстрее. Но алгоритмы разные. Как можно сравнить программу, где используются большие таблицы, с программой, где не используются? У БК памяти нет на такие таблицы. А если взять, например, MSX, то получится, что под бейсиком памяти нет, а под досом есть - и будет странная заметная разница для доса и бейсика. А процессор тот же. Поэтому в спорте и нужны правила.
Правила в соревнованиях нужны. Если предполагается привлечение широкого круга участников, то правила предварительно обсуждаются, и принимается устраивающий большинство компромисс. И это не исключает того, что любой человек, несогласный с правилами, может "играть" так, как считает нужным.
Большие таблицы - это одно из средств ускорения расчета. В память вектора влезают большие таблицы - используем, в БК-0010 не влезают - не используем. У 1801ВМ2 есть команды умножения и деления - используем, у 8080 нет - не используем.
Если в разных программных окружениях в рамках одного компьютера доступны разные возможности (например разный размер памяти), то я выберу вариант, который обеспечит максимальное быстродействие.
Если есть желание сравнить, как влияет размер памяти (или поддержка каких-то команд или турбо-режим или еще что-то) в рамках одного компьютера - сравниваем.
Есть еще вариант - когда человек обладает абсолютно точным знанием, как нужно делать и сам по себе является эталоном правильности. Этот случай я обсуждать не буду, он выходит за рамки ретрокомпьютеров.
Как-то вы всё усложняете. У меня просто бенчмарк процессора и, естественно, далеко не идеальный. Но с претензией, что коды наилучшие. Естественно, размер памяти не должен влиять на бенчмарк процессора, иначе мы некоторые системы, напаример, БК, ставим в нечестную позицию. Поэтому и правила, чтобы процессоры тестировались на одинаковых алгоритмах, а иначе получится соревнование алгоритмов. Для Apple II делали какую-то приставку, где было много ПЗУ (мегабайты) с таблицами для логарифмов и т.п. и получали с ней отличные скорости для вещественных чисел, только эти скорости к обычным 6502 или 65816 имели очень небольшое (скорее никакое) отношение.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)