Тема началась здесь и продолжилась тут, а теперь пришло время отделить ее от zpu8080.
Скомпилировал TJpgDec с использованием z88dk и такой вариант работает порезвее.
Лена - 2:19
Попугаи - 2:02
Резервы для ускорения еще есть.
Тема началась здесь и продолжилась тут, а теперь пришло время отделить ее от zpu8080.
Скомпилировал TJpgDec с использованием z88dk и такой вариант работает порезвее.
Лена - 2:19
Попугаи - 2:02
Резервы для ускорения еще есть.
Последний раз редактировалось ivagor; 16.03.2021 в 22:01. Причина: обновил архив, добавил очистку экрана
Oleg N. Cher (16.03.2021), svofski (16.03.2021)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
И для полного счастья цифры по z88dk+picojpeg.
Лена - 0:57
Попугаи - 1:11
Сильно быстрее, но чего мне это стоило. Чуть выражение посложнее и sccz80 начинает генерить пургу. С gcczpu8080 такого нет, баги из него давно вычистили. На мой взгляд если переносить на 8080 что-то сложнее hello world, то надо или ориентироваться на zpu или (если очень нужна скорость) быть готовым искать и обходить ошибки sccz80 из z88dk.
- - - Добавлено - - -
Можно позавидовать z80никам, у них есть sdcc. В процессе адаптации picojpeg там тоже нашлась ошибка, но ее скоро исправили, с z88dk такого ждать не приходится.
Oleg N. Cher (16.03.2021)
Правильно ли я понимаю, что код для 8080, сгенеренный zcc из z88dk, эффективнее, чем от gcczpu8080?
Кстати, если можно, пару слов о том, что такое gcczpu8080.
Последний раз редактировалось Oleg N. Cher; 16.03.2021 в 22:24.
По критерию скорости на данной задаче - да, но надо принимать во внимание, что zpu8080 - интерпретатор, а sccz80 генерирует нативный 8080 код. Зато zpu заметно опережает по критерию размера. Да и по скорости отставание совсем не на порядок, 3-5 раз на jpeg (при работе с 32 битными ближе к 3, при работе с 8-16 битными - ближе к 5). А на некоторых задачах (например мандельброт и пи) zpu8080 даже быстрее.
Репозиторий, тема на форуме, думаю из этих ссылок в основном понятно, может и svofski дополнительно прокомментирует.
Oleg N. Cher (17.03.2021)
Ассемблиризировал z88dk+picojpeg до уровня gcczpu8080+picojpeg
Лена - 0:32
Попугаи - 0:43
В итоге на мой взгляд пациент (jpeg на 8080) не совсем мертв, даже без полного перевода на асм.
Раз sccz80 позволяет компилировать и для z80, то почему бы не попробовать. Эффект есть, но весьма небольшой: на 284 байта короче и на 3-4% быстрее. Надо принять во внимание, что я сравнил скорости работы вариантов для 8080 и z80 в конфиге вектора с z80 (в emu80, он поддерживает векторовское торможение для z80). Если сравнивать работу варианта для 8080 в конфигах 8080 и z80, то исполнение на z80 ускоряет (за счет mov r,r; inr/dcr) на 12-15%. Хорошо бы еще и sdcc сравнить с использованием асмовских подпрограмм, но еще одной адаптации под компилятор я пока не потяну, там другие правила передачи параметров, надо переделывать.
Последний раз редактировалось ivagor; 20.03.2021 в 13:15.
Сравнил sccz80 в режиме z80 с sdcc z80 без ассемблерных процедур. sdcc примерно на 5% быстрее (тестировал в векторовском конфиге в emu80).
Рекомендую именно ZSDCC - ту версию SDCC, которая модифицирована командой z88dk. Там более расширенный набор правил для peephole-оптимизатора. На одном моём проекте я имею выигрыш между ZSDCC и SDCC в размере кода на ~1 Кб, что очень немало.
Да, используйте высокий --max-allocs-per-node40000
Лучше не ниже 20000. Хотя это серьёзно снижает скорость компиляции. У меня уже давно два набора скриптов - под отладочную компиляцию и под релизную.
Код:IF EXIST .debug SET Opt=--max-allocs-per-node20 IF NOT EXIST .debug SET Opt=-SO3 --opt-code-size --max-allocs-per-node100000
sdcc и без увеличения max-allocs-per-node сравнительно неторопливый.
Не следил, насколько быстро обновляют ZSDCC вслед за SDCC, а это весьма важный момент, т.к. в том же picojpeg напарывался на ошибку компилятора, но к счастью ее вскоре поправили.
Еще немного про sccz80. Кроме 8080 и z80 он умеет компилировать и для 8085 с использованием недокументированных инструкций. К сожалению с опцией -m8085 опять возникают странные проблемы с невнятными сообщениями, я не стал бороться и сравнил более раннюю версию без ассемблерных вставок. Вариант для 8085 на 162 байта короче варианта для 8080 и на 1-2% быстрее. Сравнивал в конфиге 6128Ц в emu, если сравнивать 6128 с 06Ц, то выигрыш конечно больше за счет mov, inr/dcr и переходов.
Широта охвата процов это здорово, но лучше бы эту энергию пустили на исправление ошибок компилятора.
К сожалению, компилятор слишком сложная программа, чтобы развивать её безошибочно.
Я стараюсь и не жалею на это времени как можно более подробно и на как можно меньшем исходнике воспроизвести баг и донести до разрабов в виде тикета. Даже если мои проекты не взлетят, польза от этого будет другим юзерам. Всячески призываю репортить баги.
SDCC довольно стабильный, но не удивился бы какому-то багу в сложном коде со вложенными циклами. Такой баг и воспроизвести-то трудно - стОит убрать пару строчек кода, и он исчезает.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)