Emu80 v.4

[Pyk]

svofski, сегодня, к сожалению, был занят, успел только потестировать готовые сборки с патчем.
На Intel, похоже, деление 64-разрядных чисел не дает мало-мальски заметного прироста производительности. Пробовал запускать в XP на Core2Duo 6420 2,13 ГГц 10-летней давности. Загрузка процессора на gigascreen demo колеблется в районе 35-41%10-16% как с патчем, так и без. Возможно, с патчем процента на 2 меньше - понять сложно. Завтра могу попробовать еще на Atom'е 1,6 ГГц.
barsik же от патча эффект тем более не почувствует, поскольку он работает в конфигурации "Специалиста", в которой не используется ВИ53.
А код я еще посмотрю в плане производительности. Меня пока несколько удивляет, почему именно эта процедура вызывается так часто, что затмевает все другие места, где встречается 64-битное деление. Возможно, просто специфика апогеевской программы, которая очень часто читает значения счетчиков (на какой программе проверялось, кстати?)


barsik, после прочтения последних ваших сообщений возникла одна идея. Не запущены ли у вас случайно параллельно с эмулятором какие-то DOS-программы (они запросто могут отбирать 100% процессорного времени)? Или про какие ресурсо-жрущие программы вы говорите? Просто загрузка порядка 30% на Специалисте - это довольно большой запас производительности...

[Advertiser]

[svofski]

Pyk, да мы никуда не опаздываем. Я проверял все на Апогее. Не знаю, почему, просто наугад. И первая попавшаяся там демка с гигаскрином меня заинтересовала тем, как она будет выглядеть на ЭЛТ.

Между вызовами updateState() по-моему 17500 циклов времени, а делитель 945. Это важный момент, потому что одно на другое не делится и, если неправильно считать количество тиков, выходит свист. В вычислении тиков до моего вмешательства уже прослеживаются какие-то следы борьбы ;) Вызывается я думаю он в обычных количествах, это же таймер. Еще подумал, что даже сохраняя 64-битное время, незачем там вычислять количество тиков в каждом счетчике. Достаточно сделать это в головном модуле один раз за троих.

Я сначала разбирал gperftools, но они не показывали причину вызовов __udivmoddi4(). Тогда я прибег к дедовскому способу: ctrl+c в отладчике, это всегда работает. Вообще я и сам удивлен, что на rpi3 это такая тяжкая операция, возможно я недожал какие-то архитектурно-специфические опции. Но, глядя правде в глаза, незачем там 64 бита иметь. При вот этих значениях, 17500/945, хватило бы на самом деле и 16.

[Pyk]

svofski, смутила меня все-таки относительно высокая загрузка процессора, попробовал сейчас еще раз на том же Core2Duo - неизменно получаются уже другие цифры: 13-16% без патча и 10-13% с патчем на том же гигаскрине. Откуда я взял лишние 30% при тестировании час назад, не понял

[svofski]

Откуда я взял лишние 30% при тестировании час назад, не понял

Не знаю На rpi3 Специалист съедает ~25%.