Интересно, ведь есть ещё два варианта роста быстродействия сборки монитора RT11 под XM:
Первое, если запускать VRUN - попробовать не мелочиться - сразу 64 Кб
Можно чем-то другим подправить...Сообщение от form
Второе, MACRO ведь оверлейная программа, так? Интересно, исходники MACRO доступны? Если оверлеи перекомпоновать с ключом /V ...
Сделать версию под мониторы расширенной памяти.
Да посмотреть разницу...
В моём случае запуск производился не прямым использованием VRUN. И он не требует вмешательства в файл запускаемой программы. Но да, интересно попробовать дать MACRO 64 кб и посмотреть на результат.
Для второго сценария. Совсем не факт, что будет ускорение, я бы даже поставил на то, что возможно замедление. Почему. Упрощённый пример. Есть программа, у которой есть корневой сегмент и два оверлея. Их размеры - корень - 4 кб, оверлеи 5 и 6 кб. Без /V потребный размер памяти - 10 кб (корень плюс больший по размеру оверлей), с /V потребный размер памяти будет 16 кб (окно для корня - 8 кб и окно для оверлеев - 8 кб). То есть (грубо, ибо см ниже) будет доступно не 64-10 -> 54 кб, а 64-16 -> 48 кб.
Плюс к этому. Если в первом сценарии с динамической памятью всё просто (над границей 10 кб и выше), то втором случае потребуется создавать третье окно (надо окном оверлеев) и выделять память в нём - то есть - если программа работает И с оверлеями И с динамической памятью, просто так переключиться на оверлеи, резидентные в памяти, не получится - код работы с динамической памятью, как минимум, должен знать об этом. Не скажу, как сделана работа с динамической памятью в MACRO, но хороший шанс, что не заработает.
Вообще-то ускорение с MACRO /V должно быть за счёт того, что сам файл MACRO не читается с тома. Особенно сее заметно было бы на реальном диске, особенно если он в единственном экземпляре(типа DWВремя мотания головок весьма изрядно. На флеш-накопители - эффект скорее всего мало заметен будет.
Возможно существует MACRO специально сгенерённый под монитор расширенной памяти?(отсутствие оверлеев совсем, буфера данных в том числе в расширенной памяти) Тут должна быть максимальная производительность.
Вообще то там основная дисковая активность - это динамическая память. MACRO создаёт временный файл и когда памяти не хватает - начинает использовать его (типа файла подкачки). Эффект от его использования как раз и наблюдается под XM монитором (когда памяти существенно меньше). И в обеих случая (SB и XM) диск один и тот же. И поскольку /V - это дополнительные и существенные потери памяти, если специально не оптимизировать и код и его размещение под размер оверлеев, кратный 8 кб, то потери памяти могу быть очень существенными. Кроме того, я подозреваю, что DEC оптимизировала работу с оверлеями, что бы они читались по одному разу - по мере продвижения процесса, а тогда выигрыша от /V (в плане чтения с дисков оверлеев) не будет вообще. Потому что, в стандартных модулях, чтение ОВЕРЛЕЕВ в память (при любом их варианте) - это задача самой программы. И ЕСЛИ оверлей читается только один раз - то фиолетово, /O или /V
Я о таком не знаю
Так что ещё раз подводя итоги
1. Есть хороший шанс, что при решении в лоб - просто замена /O на /V - MACRO вообще не взлетит
2. Даже если взлетит - я ставлю на то, что за счёт уменьшения объёма динамической памяти, скорость не улучшится, а останется на уровне прежней и есть хороший шанс, что она станет хуже.
- - - Добавлено - - -
Посмотрел дистры 5.4 и 5.7 - нет ни исходников, ни obj файлов MACRO
- - - Добавлено - - -
В 5.5 и 5.6 тоже нету
- - - Добавлено - - -
Так что пока всё это - теоретические размышления, подкреплённые практическим опытом
Ну 64 Кб MACRO подсунуть вполне реально
Надо трогать MACRO, мне это не сильно нравится.
Прогнозирую сокращение времени генерации ещё где то на минуту - минуту 15 секунд
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Вообще у меня в те времена, возникла идея драйвера кэша, к коему идут обращения, а он подсовывает данные из буферов в расширенной памяти. Прикидывал на базе драйвера LD:
Правда тогда думал исключительно о кэшировании каталогов. Тогда многого не знал ...
Но это были чисто прикидки .
Не, этот подвиг не для меня, особенно учитывая, что быстродействие накопителя на флеш памяти практически догоняет быстродействие VM на старых системах...
Сейчас смысла в такой конструкции мало...
Интересно только для тех, у кого старое железо.
На флеше - головку позиционировать не надо
И время генерации системы в разных сценариях показаны именно в варианте - RK на флеше
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием