Тема началась здесь и продолжилась тут, а теперь пришло время отделить ее от zpu8080.
Скомпилировал TJpgDec с использованием z88dk и такой вариант работает порезвее.
Лена - 2:19
Попугаи - 2:02
Резервы для ускорения еще есть.
Вид для печати
Тема началась здесь и продолжилась тут, а теперь пришло время отделить ее от zpu8080.
Скомпилировал TJpgDec с использованием z88dk и такой вариант работает порезвее.
Лена - 2:19
Попугаи - 2:02
Резервы для ускорения еще есть.
И для полного счастья цифры по z88dk+picojpeg.
Лена - 0:57
Попугаи - 1:11
Сильно быстрее, но чего мне это стоило. Чуть выражение посложнее и sccz80 начинает генерить пургу. С gcczpu8080 такого нет, баги из него давно вычистили. На мой взгляд если переносить на 8080 что-то сложнее hello world, то надо или ориентироваться на zpu или (если очень нужна скорость) быть готовым искать и обходить ошибки sccz80 из z88dk.
- - - Добавлено - - -
Можно позавидовать z80никам, у них есть sdcc. В процессе адаптации picojpeg там тоже нашлась ошибка, но ее скоро исправили, с z88dk такого ждать не приходится.
Правильно ли я понимаю, что код для 8080, сгенеренный zcc из z88dk, эффективнее, чем от gcczpu8080?
Кстати, если можно, пару слов о том, что такое gcczpu8080.
По критерию скорости на данной задаче - да, но надо принимать во внимание, что zpu8080 - интерпретатор, а sccz80 генерирует нативный 8080 код. Зато zpu заметно опережает по критерию размера. Да и по скорости отставание совсем не на порядок, 3-5 раз на jpeg (при работе с 32 битными ближе к 3, при работе с 8-16 битными - ближе к 5). А на некоторых задачах (например мандельброт и пи) zpu8080 даже быстрее.Цитата:
Сообщение от Oleg N. Cher
Репозиторий, тема на форуме, думаю из этих ссылок в основном понятно, может и svofski дополнительно прокомментирует.Цитата:
Сообщение от Oleg N. Cher
Ассемблиризировал 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 сравнить с использованием асмовских подпрограмм, но еще одной адаптации под компилятор я пока не потяну, там другие правила передачи параметров, надо переделывать.
Сравнил 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 сравнительно неторопливый.Цитата:
Сообщение от Oleg N. Cher
Не следил, насколько быстро обновляют ZSDCC вслед за SDCC, а это весьма важный момент, т.к. в том же picojpeg напарывался на ошибку компилятора, но к счастью ее вскоре поправили.Цитата:
Сообщение от Oleg N. Cher
Еще немного про sccz80. Кроме 8080 и z80 он умеет компилировать и для 8085 с использованием недокументированных инструкций. К сожалению с опцией -m8085 опять возникают странные проблемы с невнятными сообщениями, я не стал бороться и сравнил более раннюю версию без ассемблерных вставок. Вариант для 8085 на 162 байта короче варианта для 8080 и на 1-2% быстрее. Сравнивал в конфиге 6128Ц в emu, если сравнивать 6128 с 06Ц, то выигрыш конечно больше за счет mov, inr/dcr и переходов.
Широта охвата процов это здорово, но лучше бы эту энергию пустили на исправление ошибок компилятора.
К сожалению, компилятор слишком сложная программа, чтобы развивать её безошибочно.
Я стараюсь и не жалею на это времени как можно более подробно и на как можно меньшем исходнике воспроизвести баг и донести до разрабов в виде тикета. Даже если мои проекты не взлетят, польза от этого будет другим юзерам. Всячески призываю репортить баги.
SDCC довольно стабильный, но не удивился бы какому-то багу в сложном коде со вложенными циклами. Такой баг и воспроизвести-то трудно - стОит убрать пару строчек кода, и он исчезает.
Пример цветного JPEGа в режиме 64 цвета (2 бита/канал). На реале на элт будет мерцать, на жк скорее всего не будет, там хитро, а в эмуляторе лучше смотреть в emu80. В процессе рисования выглядит странновато (2 картинки рисуются параллельно, одна с грубыми цветами, другая психоделическая), но когда нарисует перейдет в режим 64 цвета.
На реале ч/б элт действительно мерцает, как фпс не хватает. На жк телике мерцания нет, хотя есть какое-то "брожение", типа волны - не волны... но это понятно, что от телика зависит.
Жаль картинка слишком пёстрая и пиксели крупные, контрастные. Не позволяет реально оценить количество одновременно отображаемых цветов.
Цвета лучше видно на вот этой штуке.
8 оттенков желтого это хорошо, а 16 серого - лучше. Благодаря последним достижениям в исследовании оттенков серого в ч/б режиме стало возможно сделать соответствующую версию jpegа. В качестве примера безотказная Лена.
Вложение 75236
Можно посмотреть в эмуляторах VV или Emu80 (начиная с версии 40355) в ч/б режиме или на реалах (подходят и 06Ц и .02, 06Ц подходит чуть лучше).
Раз скачал текущий z88dk, значит надо было попробовать собрать Лену. После небольшой доработки напильником собралось и решил оптимизировать ассемблерные процедуры. Получилось ускорить до 23 секунд, формально прогресс есть, но все равно слишком медленно.
А 50 ещё лучше, особенно если Лена безотказная.Цитата:
Сообщение от ivagor
Кстати в v06x-godot в наши дни можно выбрать шейдер bw.Цитата:
Сообщение от ivagor
Про поддержку обесцвеченного режима в v06x я знал, но т.к. в отличие от Emu80 и VV у тебя оттенки серого не по схеме ч/б видеовыхода вектора, а по стандартной формуле (.1B+.3R+.6G), то я думал, что не подойдет. Но оказывается, что если для градиента всех оттенков серого действительно не подходит, то конкретные "универсальные" 16 цветов (1, 2) более-менее подходят не только для 06Ц и .02, но и для стандартной формулы. Это очень здорово и резко увеличивает смысл использования этих цветов/оттенков. Оказывается с этой палитрой можно получить сравнительно равномерные 16 оттенков серого не только при подключении 06Ц и .02 к ч/б телевизору (или в VV и Emu80), но и при подключении 6128++ к ч/б ТВ и при подключении любого вектора к цветному ТВ с зажиманием цвета до 0 (или в v06x).