Потеря лишних трёх байт в обмен на выровненность? Здесь выравнивание не так уж и важно (кто-нибудь читает файлы в цикле 100000000 раз?) и всё равно скорость определяется не этой частью кода.

Потеря лишних трёх байт в обмен на выровненность?

Да что такое эти три лишних байта? Достаточно посмотреть memmap.inc - там дыр больше, чем в швейцарском сыре. Предлагал обсудить как лучше уплотнить данные и сэкономить сотни килобайт, никто ничего. Ладно, ставлю в BOCHS 128Мб
открываю картинку в Xpaint, запускаю Xtree, Tetris, Cmd, Mine, Mfar, Dockpack, открываю все доки, остается свободных 28490 страниц - это 111 Мб свободных. А тут три байта.

diamond
А можешь подробней описать пару случаев? И если внедрять то можно и не наряду, а просто поменять, так как 70 функция еще только формируется.

Serge
Вот потому и свободных 111 Мб, потому что мы цепляемся за каждый байт.
А вообще еще в Колибри 0300 я переписал большинство приложений, оптимизировав их по размеру памяти. Правда вся оптимизация состояла в подборе минимально необходимого количества рабочей памяти, но зато приложений было много (более 100). Раньше (благодаря опять таки стараниями Велика, написавшему такую «продвинутую» документацию) начинающий программер щедро отводил под приложение типа "Привет мир" всего лишь 4 мегабайта памяти. Дальше было веселей - указатель стека устанавливался на середину памяти, и верхние 2 мегабайта не использовались даже теоретически. Пока Trans (был среди нас умный человек раньше) популярно не объяснил, что стек всегда растет в сторону меньших адресов и для большинства приложений текущего уровня 4 Кб (то есть один сегмент) за глаза хватит – я, и сам не мог понять такого положения вещей.
Не оптимизированными остались только сетевые приложения, так как я не мог проверить последствия своих действий для этого класса приложений.

Mario79

Вот потому и свободных 111 Мб, потому что мы цепляемся за каждый байт.

Да не надо цепляться за каждый байт. Все равно память выделяется страницами . Я раньше тоже думал, что писать на ассемблере значит экономить каждый байт. Потом дошло что пока напишу свой супер-пупер-оптимальный код объем памяти в среднем компе вырастет в два раза. Вот ещё пример: переменные по адресам 0х9000все это дело вместе с 16-битной таблицей прерываний и областью данных БИОС (вместе килобайта 2) копируется по адресу 0x2F0000 и занимает 64 кБ. И какой прок в однобайтной . Вот такая крутая экономия.

Serge,экономить память НУЖНО!Но там,где эта экономия действительно нужна.
bits_per_pixel всетаки лучше сделать типа dword.В однотипных операциях типа (x*screen_size_x+y)*bytes_per_pixel необходимо всё делать типа dword.А в редко используемых операциях byte(если умещается).А ещё есть такие хитрости.Например,
mov [value],0
заменяем на and [value],0
это и быстрее и на 3 байта короче.Такого рода оптимизацию я провожу на окончательном этапе написания программы(перед презентацией публике).

А вообще,даже сегодня,вовремена 2-3 гигабайтовых процессоров,есть люди которые до сих пор пользуются:pentium100,pentium166 или в лучшем случае pentium2(с 24 или 32 мегабайтами памяти).И не от того,что им хочется экзотики,а от элементарной нехватки денег на более продвинутый компьютер(а может не быть денег и на такой комп).И к тому же некоторым для покупки компьютера нужно ехать в город,который за сотни километров от сельской местности.А ехать в город - это тоже не малые деньги.
Для такого человека иметь Pentium100,да и ещё новую операционную систему,которая обновляется каждые несколько месяцев,и под которую есть много программ,требующих мало ресурсов,под которую можнео писать интересные программы - это БОЛЬШОЕ счастье.

Я за РАЗУМНУЮ оптимизацию !

andrew_programmer
Я тоже за разумную оптимизацию. Только оптимизация часто сводится к тому, что здесь сэкономили два байта, а рядом буфер на 16 байт занимает несколько килобайт. К сожалению вся система этим страдает. И оптимизация по скорости тоже важна, тем более что на 100 мегагерцевых процессорах падение быстродействия заметней, чем на 2-х гигагерцевых. Например в том же Bochs MFAR показывает содержимое рамдиска сразу, а XTREE замирает секунд на десять. Думаю что на Р-100 это заметно и без эмулятора. 24 Мб памяти вполне хватает для нормальной работы минимум одной программы.
Я проводил похожий тест с 32Мб памяти и результат был такой же, только свободной памяти было на 96 Мб меньше. Не знаю других 32-битных ОС на которых можно было бы запустить сразу столько программ в 32 мегабайтах. Kernel на дискете занимает 84 Кб, а ядро после загрузки 12 Мб, но никого это особенно не смущает. Если так пойдет дальше, то ядро перестанет влезать и в 32 Мб. Стоит об этом подумать. Если уплотнить ядро, то можно будет нормально работать и с 16 Мб ОЗУ. Думаю что такая оптимизация важнее, чем использование db вместо dd.

Serge,на pentium100 XTREE показывает содержимое каталога через 1-2 секунды.Я со временем понял,что ни один эмулятор не покажет скорости реальной машины.Поэтому все программы стараюсь тестировать на реальной машине.

А вот то,что после загрузки ядро занимает 12(наверное всетаки 14) мегабайт меня очень смущало.Но так как сильно в устройствах операционных систем я не разбераюсь,то я считал,что наверное так и должно быть.А раз там обнаружилось такая большая неорганизованность в плане занимаемой памяти,то ОБЯЗАТЕЛЬНО НЕОБХОДИМО ПЕРЕПИСАТЬ КОД С ПРАВИЛЬНЫМ РАСПРЕДЕЛЕНИЕ ПАМЯТИ ПОД НЕОБХОДИМЫЕ БУФЕРЫ.

Если XTREE так тормозит на P-100 то стоит посмотреть почему MFAR нет. Я начинал программировать на 12-Мгц АТ-286 с 1 Мб ОЗУ. Так что 16 Мб это очень много памяти а Р-100 очень быстрый процессор. Без кавычек. Windows 3.1 хоть и со скрипом но работала. Будь памяти 2 Мб просто летала бы. Когда вышла Win95, IBM хвалилась тем, что их OS/2 хорошо работает в 4 Мб. Так что здесь надо оптимизировать.

К сожалению, большу'ю часть памяти потребляет возможность на прямую писать в порты ввода-вывода. И с этим ничего нельзя поделать, не уменьшая число приложений, которые можно запустить одновременно. Кроме того, драйверам часто нужен непрерывный участок памяти. Что бы его обеспечить его приходится резервировать. Это также требует много памяти.

andrew_programmer
Serge
SYSXTREE тормозит ввиду не самого оптимального алгоритма сортировки. Стоит учесть и то, что для 58 функции нету непосредственных функций работы с содержимым директории, поэтому каждый автор сам реализовал код, и как уж он получился так он и получился.

Возможн это предложение не для этого топиеа,
но почему не предусмотреть консоль загрузки как y SUN
стандарт OPEN BOOT PROM?

http://www.gentoo.org/doc/en/gentoo-spa ... erence.xml

Kopa
Да ты прав - предложение не для этого топика.
Создай отдельную тему, иначе всегда возникает путаница.

Mario79 wrote:Kopa
Да ты прав - предложение не для этого топика.
Создай отдельную тему, иначе всегда возникает путаница.

Создал топик по Boot Biosу
http://meos.sysbin.com/viewtopic.php?p=5772#5772