А я и так смог ... но это же вроде деление столбиком в двоичной системе???
А я и так смог ... но это же вроде деление столбиком в двоичной системе???
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
По ссылке открывается (если еще нажать на English Version) заметка с названием "High-speed multiplication processing on Z80 (Part 2) Optimization [Z80]", про деление я ничего не заметил.
Решил узнать секрет мастера. Сравнивал m256.com (1175 байт) из архива fast-mandel.7z (14.01.2024) с m256x256 (364 байта, 25.12.2021, файл сейчас не доступен для скачивания, при необходимости могу перевыложить).Сообщение от litwr
Оказалось, что одинаковых параметров расчета и построения в двух программах нет и честного сравнения не получится. При корректном сравнении нужны:
1. Одинаковое количество точек и цветов - нет. litwr считает половину точек и рисует симметрично, в отличие от m256x256, хотя для компенсации можно взять для m256x256 половину времени построения или строить симметрично.
2. Одинаковые масштабы при одинаковом максимуме итераций - нет. По числу итераций одно совпадение - mentry 6, 5, 15 ;9. Масштабы при этом разные.
3. Одинаковые параметры оптимизации программ - нет. litwr оптимизировал по скорости; m256x256 получен из оптимизированного по размеру варианта m128x128. В m256.com довольно много текста, но даже если его полностью убрать, размер останется как минимум вдвое больше по сравнению с m256x256.
Четкое количественное сравнение в таких условиях невозможно.
Неформально сравнил при близких параметрах и "заметно быстрее того, что сделал ivagor в 2021" не получилось. Из секретов мастера поучиться можно разве что некорректному предвзятому подходу, но лучше воздержусь.
Отдельно отмечу формат файла. Бинарники litwrа имеют расширение .com, но не существует операционных систем для вектора, в которых они будут корректно работать. Нормальное функционирование возможно только при запуске из монитора-отладчика. Этот технический момент я не считаю недостатком при сравнении скорости, просто он не документирован и надо его учитывать.
Добавил к исходникам коммент, который показывет как параметры программы (в макросе mentry) пересчитываются в стандартные границы множества Мандельброта.
В mentry легко задать любые параметры, исходники открыты для всех...Код:;x-min = (x0+dx*HSize)/512, x-max = x0/512, y-max = dy*VSize/1024
Ну и зря вы так всё лично. Мне просто было интересно сравнить то, что получилось у меня, с тем что было в софте для Вектора. То, что ваша программка строит Мандельброта медленнее, - это просто факт. У вашего кода есть свои безусловные достоинства. А то, что вы написали, эти факты никак не отменяет.
Кстати, не так давно сделал Мандельброта для Geneve 9640 и выложил результаты на профильном форуме. Среди результатов факт того, что мой код примерно в 200 раз быстрее того, что демонстрировала соответствующая программа для генерации Мандельбротов. И ежу понятна, что та программа имеет на порядок больше полезных функций. Но речь-то про простое сравнение по одному из параметров. Кстати, автор той замечательной программы мне дал несколько ценных подсказок. А в целом фаны той системы даже наградили меня кубком! Что-то похожее было и с тем, как встретили мой код фанаты Амстрада, хотя там было много мандельбротов и оптимизированных по скорости в том числе.
К сожалению, на этом форуме нередки случаи немотивированного хамства. Хотя энтузиаст Спека и БК reddie помог мне очень капитально с оптимизацией для Z80...
Не понял вполне про бинарники. У меня код использует только вызов БДОС, который есть в любом мониторе или CP/M... COM - стандартное расширение для исполнимых файлов CP/M. Не могли бы вы пояснить, что имеете в виду?
Последний раз редактировалось litwr; 20.01.2024 в 13:08.
В таблице результатов Мандельброта litwr есть такое примечание "The number in parentheses after @ is the approximated effective CPU frequency". Использовано это у Apple IIgs, Sinclair QL, Amstrad PCW, Amstrad CPC, БК0011, БК0010, Commodore 128 c Z80, Commodore +4. А остальные компьютеры, у которых процессор тормозится? А у них ничего не написано, ни "не знаю" ни "требует уточнения", ничего.
В число остальных попал и вектор, хотя казалось бы, раз он с 3 МГц уступает корвету с 2.5, значит очевидно торможение есть. Благодаря Emu можно точно определить "эффективную частоту" для конкретных программ, а не среднюю по больнице, как в таблице (точность "эффективных частот" в таблице - отдельный вопрос). Заодно будет видно, какая программа лучше оптимизирована для вектора - чем меньше "эффективная частота", значит тем больше используются тормозные, "неудобные" для вектора команды.
Для m256 использовал встроенное определение времени расчета/рисования (T).
Для m256x256 засекал по брякам в отладчике эмулятора.
По второму рисунку (отличия от первого минимальные - в районе одной сотой, но по второму рисунку результат чуть лучше для litwr и чуть хуже для меня):
"Эффективная частота" m256 - 2.2826 МГц
"Эффективная частота" m256x256 - 2.3748 МГц
Если сравнить с ранее приводившимися результатами (1, 2), то вариант litwr почти на уровне не оптимизированных для вектора программ, мой получше, но даже до 2.4 не дотянул. Предполагаю, что дело или в побочных эффектах оптимизации по размеру или просто я плохо старался (или и то и другое).
Интересная тема эффективная частота. Для Коммодора+4, 64 и 128 (под 8502) - это весьма точная характеристика, не зависящая от используемого набора команд. Поэтому эффективные частоты для +4 и 128 (под 8502) в таблице точны, для +4 эта частота зависит только от выбранного видеорежима. Хотя для 128 (под 8502 и VDC) эффективная частота возможно должна быть чуть пониже из-за возможных циклов регенерации памяти, но скорее эти циклы вставляют в холостые циклы 8502. С этим можно ещё поразбираться. Для систем с Z80 ситуация сложнее, так как эффективная частота может зависeть от исполняемого набора команд. Однако для Амстрада и Коммодора 128 (под Z80) приведенные частоты практически подтверждаются почти всегда и общепризнанны. С MSX сложнее, какое-то время назад в таблице была частота 3.1 для этих систем, но большой статистики не собирал и само понятие ЭЧ для этих систем почему-то не используется. С БК похожая история, но есть некоторая статистика, которая подтверждает приведенные числа как некие ориентировочные средние. Для первых Макинтошей часто приводится эффективная частота, но возможности потестировать эту величину пока мне не представилось, поэтому из таблицы убрал. Аналогичная ситуация с IIgs, но особенности систем на базе семейства процессоров 6502 позволили мне эту частоту оставить. С Вектором практически не знаком, но если вы рекомендуете поставить 2.4, то поставлю.
В таблице эффективная частота величина близкая к иллюстративной. Никаких данных прямо направленных на установление этой характеристики там нет. Она используется для расчета ER процессора, но для 8080 данные, как лучшие, берутся с Корвета. Но и ER - это тоже побочная иллюстративная характеристика.
Мне кажется, мне стало примерно понятна ваша проблема. Вы ищите однозначности там, где её нет. Для некоторых систем практически невозможно сказать даже просто о частоте процессора однозначно, например, для MSX turboR или некоторых моделей PDP-11. В моём проекте просто собираются данные по скорости работе на одном фиксированном алгоритме. Если кто из ценителей Вектора найдет возможным сделать код быстрее, это будет отражено в результатах.
Что до скорости моего кода, то могу обратить ваше внимание на одно важное обстоятельство. Все коды в проекте используют абсолютно одинаковую математику, что, в частности, требует 60 лишних циклов в главном цикле для Вектора для сброса нулевого бита в индексе массива. Этого легко избежать, что сделало бы код процентов на 20% быстрее, но это слегка изменило бы математику, хотя визуальный результат остался бы практически неотличимым.
Идея измерять эффективную частоту по конкретной программе - это реально интересно. Но не факт, что код лучше использующий особенности тормозов будет быстрее того, что просто эффективнее реализует алгоритм. Поэтому ваши расчеты никак прямо скорость работы кода не отражают.
Неправильно. Ищу приближение к объективной истине. Например если нельзя однозначно определить единственную эффективную частоту (а в подавляющем числе случаев так и будет), то надо приводить диапазон.
Алгоритм и реализация алгоритма - разные вещи. Фиксация каких-то одних деталей реализации при упускании других - это вопрос субъективного выбора.
2.4 лучше, чем ничего, но еще лучше 2.23-2.45 (и эти цифры тоже требуют уточнения).
Если не читать User Manual, то невозможно. А если почитать, то возможно.
Последний раз редактировалось ivagor; 27.01.2024 в 11:02. Причина: исправил фразу
Реально для Вектора или БК нужно не просто диапазон, а диапазон с вероятностями. Нужно всесь имещийся софт прогнать и это вычислить, а потом ещё делать поправки на новые коды. Поэтому и пишу, что эффективная частота - это для многих систем лишь иллюстративный параметр. Коммодоры тут скорее исключение. А вы требуете типа убрать лучики от солнца на рисунке,
Давайте тут конкретно. Речь о конкретных кодах. Какие могут быть разные реализации, если хотим идентичный результат?
Поставил 2.4 по Вашему требованию. Если кто будет жаловаться, переведу стрелки на Вас.
Японский знаете? Круто! Проблема в том, что общепринятой точки зрения тут нет. Некоторые и таких похоже большинство считают R800 чем-то типа Риска, где команды исполняются за такт. И если рассматривать проц как черный ящик это вполне верно. В реальности имеем усеченный Z800 с учетверенной внутренней частотой. Эту внутреннюю частоту можно считать глубинным уровнем реализации, которая никак до юзера не доходит. Что-то похожее имеем и для TMS9995. И ещё имеем маркетинговые стратегии, которые пудрят мозги выбранными важными параметрами, но эти параметры, как правило, реальны, они лишь выбраны как самые узнаваемые.
Последний раз редактировалось litwr; 28.01.2024 в 11:37.
Я хочу единообразного добросовестного подхода.
Смотрите исходники и сравнивайте, если интересно.
Я выдвигал требование поставить 2.4 для вектора? Можно ссылку?
Потрясающие откровения. Ну а то, что они не соответствуют User Manual - это проблемы User Manual и тех, кто ему верит (я в их числе).
Последний раз редактировалось ivagor; 28.01.2024 в 12:20.
Мне понравилась 256-байтная дема morph (автор Gogin, Сергей Смирнов) для спека с Мультиматогрофа 2024. Для вектора цифры те же, но в другом порядке - 265 байт.
Upd 11.05.2024: 256 байт
Последний раз редактировалось ivagor; 11.05.2024 в 08:25. Причина: 256 байт
KTSerg(08.06.2024), metamorpho(11.05.2024), svofski(10.05.2024)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
