RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : ...и немного пpо acpi ;)


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Slavik Gnatenko, 2:467/99
To : Igor Vaskov
Subj : ...и немного пpо acpi ;)
> > > Там хуже - там циферки есть. Против этого не попрешь. К тому-же тест не на графических операциях, а на компиляции.
> > А тут ещё проще - двойное кэширование :))
> > Образ диска кэшируется как файл и его содержимое внутри гостевой системы кэшируется как файлЫ :)
> > Есть разница - 8Mb кэш винта или 200Mb системы (например ;))
> Да ты не упрощай. Кэшь JFS можно сделать и более 200 мегов. И я предполагаю, что Шмедли не на HPFS свои исходники компилировал.
Вот только настроек кэша я в циферках Шмедли не припомню. А настройки - это не только объём, но и всякие тайминги. В общем сравнение ни о чём. Могу рассказатьтакую смешную вещь. Когда-то я активно писал мелкие базы данных. Были они под Win16, чтобы запускать максимально где попало. Есессно, с диском работали дико интенсивно. По производительности картина получилась такая:
- Win 3.11. Непревзойдённая средняя скорость. Кэш сбрасывается на диск только тогда, когда переполняется. И регулярно данные в нём зависают на часы, так и не записавшись. Прилагающийся бонус: если рубанут электричество или система повиснет, то базе превращается в кашу, потому что из типа записаного туча фрагментов так только в памяти и висела;
- OS/2. Нормальная работа. Кэшируется, как и для осевых приложений. Винт грузится не сильно, но и запись надолго в кэше не подвисает;
- Win 95+, Win NT 4.x+ (дошли до XP). Полный амбец по производительности. Запись, похоже, не кэшируется вообще. Пришлось переписывать код, чтобы самые суровые отчёты формировались в памяти, а не во временной базе. Иначе время формирования отчёта по сравнению с полуосью отличалось на два порядка. Ну и винт немного жалко :)

Вот и делай выводы что отстаёт на поколения.

> Кстати, есть же способ адресоваться к 16-и гигам в 32 битном режиме. Что по этому поводу думают гуру? Можно что-нибудь сделать, чтобы это использовать? Хотя-бы для кешей и рамдисков?
Обсасывали же уже. Непосредственно в режиме, скажем так, 386 compatible, адресоваться нельзя. Нужно переключать формат таблицы страниц. Это в общем-то настолько же разрушительно, насколько и переключиться в 64 бита. Т.е. ничего системного, в том числе и обработчик прерываний в таком режиме работать не может. Но технически, если копировать мелкими блоками, то доступаться так можно. Для рамдиска пойдёт. Для кешей возникает добавочная проблема: кто использовать-то будет? Для этого клиент должен уметь работать с кэшем, из которого в любой данный момент времени доступна только некая небольшая часть, а переключение окна занимает некое дополнительное время. JFS к таким клиентам не относится и боюсь, что адаптировать под такую модель её будет весьма не тривиально.

Fri 06 Jan 2012 20:02 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/2



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.