Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Nov 28, 2020 3:15 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 259 posts ]  Go to page Previous 1 2 3 4 518 Next
Author Message
 Post subject:
PostPosted: Fri May 26, 2006 11:51 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Я вот тут подумал, может быть, наряду с существующей структурой
Code:
dd номер функции
4*dd параметры
n*db ASCIIZ-имя

ввести структуру типа
Code:
dd номер функции
4*dd параметры
db 0 ; чтобы не путалось со старым форматом
dd указатель на ASCIIZ-имя

? В некоторых случаях это явно удобнее...

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 1:45 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Code:
dd номер функции
4*dd параметры
db 0 ; чтобы не путалось со старым форматом
dd указатель на ASCIIZ-имя
Тогда указатель будет невыравнен. Лучше dd 0


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 2:01 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Потеря лишних трёх байт в обмен на выровненность? Здесь выравнивание не так уж и важно (кто-нибудь читает файлы в цикле 100000000 раз?) и всё равно скорость определяется не этой частью кода.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 4:25 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Потеря лишних трёх байт в обмен на выровненность?
Да что такое эти три лишних байта? Достаточно посмотреть memmap.inc - там дыр больше, чем в швейцарском сыре. Предлагал обсудить как лучше уплотнить данные и сэкономить сотни килобайт, никто ничего. Ладно, ставлю в BOCHS 128Мб
открываю картинку в Xpaint, запускаю Xtree, Tetris, Cmd, Mine, Mfar, Dockpack, открываю все доки, остается свободных 28490 страниц - это 111 Мб свободных. А тут три байта.


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 5:24 pm 
diamond
А можешь подробней описать пару случаев? И если внедрять то можно и не наряду, а просто поменять, так как 70 функция еще только формируется.


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


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 6:28 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario79
Quote:
Вот потому и свободных 111 Мб, потому что мы цепляемся за каждый байт.
Да не надо цепляться за каждый байт. Все равно память выделяется страницами . Я раньше тоже думал, что писать на ассемблере значит экономить каждый байт. Потом дошло что пока напишу свой супер-пупер-оптимальный код объем памяти в среднем компе вырастет в два раза. Вот ещё пример: переменные по адресам 0х9000
Code:
  0:9000     byte   bits per pixel
   0:9001     word   scanline length
   0:9008     word   vesa video mode
   0:900A     word   X res
   0:900C     word   Y res
   ...
   ...
все это дело вместе с 16-битной таблицей прерываний и областью данных БИОС (вместе килобайта 2) копируется по адресу 0x2F0000 и занимает 64 кБ. И какой прок в однобайтной
Code:
0:9000     byte   bits per pixel
. Вот такая крутая экономия.


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 7:13 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
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,да и ещё новую операционную систему,которая обновляется каждые несколько месяцев,и под которую есть много программ,требующих мало ресурсов,под которую можнео писать интересные программы - это БОЛЬШОЕ счастье.

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


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 8:29 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 8:50 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Serge,на pentium100 XTREE показывает содержимое каталога через 1-2 секунды.Я со временем понял,что ни один эмулятор не покажет скорости реальной машины.Поэтому все программы стараюсь тестировать на реальной машине.

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


Top
   
 Post subject:
PostPosted: Fri May 26, 2006 9:17 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Sat May 27, 2006 8:01 am 
К сожалению, большу'ю часть памяти потребляет возможность на прямую писать в порты ввода-вывода. И с этим ничего нельзя поделать, не уменьшая число приложений, которые можно запустить одновременно. Кроме того, драйверам часто нужен непрерывный участок памяти. Что бы его обеспечить его приходится резервировать. Это также требует много памяти.


Top
   
 Post subject:
PostPosted: Sat May 27, 2006 6:29 pm 
andrew_programmer
Serge
SYSXTREE тормозит ввиду не самого оптимального алгоритма сортировки. Стоит учесть и то, что для 58 функции нету непосредственных функций работы с содержимым директории, поэтому каждый автор сам реализовал код, и как уж он получился так он и получился.


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 2:34 am 
Offline

Joined: Mon Mar 27, 2006 6:33 am
Posts: 704
Возможн это предложение не для этого топиеа,
но почему не предусмотреть консоль загрузки как y SUN
стандарт OPEN BOOT PROM?

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


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 2:09 pm 
Kopa
Да ты прав - предложение не для этого топика.
Создай отдельную тему, иначе всегда возникает путаница.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 259 posts ]  Go to page Previous 1 2 3 4 518 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited