[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[locale] Re: [locale] Re: [locale] Re: [locale] "Кpивые" руки()
On Tue, 17 Jul 2001, Victor Wagner wrote:
> On Tue, 17 Jul 2001, Vlad Harchev wrote:
>
> > > состояние - дело небесполезное. Его за флашить оно гораздо быстрее выйдет,
> > > чем сохранять все, если вдруг скажем администратор решит машину
> > > отребутить.
> >
> > Никто ему это не даст сделать (или его уволят). И машины могут быть
> > бездисковые..
>
> Да? Так сразу и уволят? А если бульдозером силовой кабель переехало
> и отребутить машину решил UPS, а не администратор? Его тоже уволят?
Бульдозерами кабеля рвут не каждый день.
> Грубо говоря при времени рассчета более часа выгоднее потерять двадцать
> процентах скорости но обеспечить надежность в любых обстоятельствах.
Неизвестно сколько именно времени будет теряться - ОС же будет
пытаться при *каждом* изменении отммапленного (при простой операции записи в
память) записать это на диск (конечно есть кэш, но..)
> Тогда можно будет купить 1.2 гигагерцовый атлон и не бояться что он от
> диффузии сдохнет. Ну сдохнет, ну поменяете и продолжите с того же места.
Многоголовых матерей для атлонов очень мало в природе - так что не катит :)
> > > если ты будешь использовать не указатели а смещения от начала файла,
> > > то ты теряешь один такт на обращении по указателю.
> > >
> > > Единственное что свой аллокатор писать придется.
> >
> > И весь код который разименовывает указатели переписывать (например список
> > перебирает).
>
> А что, там его много этого кода? Все это должно быть инкапсулировано в
> три-четыре метода.
Давно ты на С и С++ не писал. На С это невозможно (все операции разименования
указателя надо будет проверять и модицицировать), на С++ - теоретически
возможно если перегрузить унарный оператор * но все равно определения структур
придется перелопачивать и возможно многие методы..
> > И да, свой аллокатор тоже придется писать..
>
> Ну пятый и шестой.
Ну это не так уж тривиально - быстрый аллокатор.
Best regards,
-Vlad