> man operating_systems
Центр информации по операционным системам :: Форумы :: Операционные системы :: Другие ОС
 
<< Предыдущая тема | Следующая тема >>
Constructor OS - обсуждаем здесь
Переход на страницу  1 2 3 [4] 5
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
Wanderer
Среда 15.06.2005 19:20

ID пользователя #2
Зарегистрирован: Вторник 29.06.2004 20:13
Местонахождение: Беларусь, Гомель
Сообщений: 76
Я одного не понимаю, как одно мешает другому? Как объекты относятся к повышению фрагментации?
[ Редактирование среда 15.06.2005 19:27 ]

Доказывая идиоту, что он идиот, ты сам становишься идиотом.
Наверх
Сайт
Dron
Среда 15.06.2005 20:14


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Объекты не отменяют фрагментации... это точно...

Но давно доказано, что в многозадачных системах с кешированием и тд... влияние фрагментации на скорость ничтожно мало.

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев
Наверх
Сайт
mzprog
Четверг 16.06.2005 07:01
ID пользователя #306
Зарегистрирован: Четверг 05.05.2005 10:16
Сообщений: 23
Manifesto писал:
<div class='codec'>Вот я офигеваю, что от 3OS, что от Вас. Не будет поддержка файловых систем, каталог - объект, файл объект - ежу понятно, все это только логическое представление, к сожалению такой логикой не объяснить физическое резмещение файлов/каталогов на диске. Все эти объекты - абстракция, их нет, на диске все хранится в plain - сектор за сектором, дорожка за дорожкой, сторона за стороной. Тут уже начинают возникать такие проблемы, как, например, дефрагментация, как вы будете ее решать имея на руках объяснение, типа, все кругом объекты? ИМХО, я вот что реально хотел бы услышать, от 3OS'овцев я этого так и не добился. </div>Предполагается, что в будующем (через полгода) COS будет представлять собой тоже, что и Mz C++ Constructor сейчас. На данный момент, в Конструкторе можно загружать один файл, содержащий все проекты - это набор объектов разного типа. При этом они храняться байт за байтом. Загружаясь, объекты полностью переносятся в ОЗУ. В ОЗУ совершаются и все манипуляции. Сохраняясь в файле, объекты храняться также байт за байтом (этот файл можно представить в виде диска). Таким образом никакой фрагментации!

Но этот подход применим в том случае, если в сумме объекты занимают на порядок меньше размера ОЗУ.

В принципе, предполагается реализовать объектную файловую систему.

Пусть у нас есть два объекта. У одно в заголовке прописано, что он хранится в в секторах 101, 102, 104, а у второго - 103, 105. Вашу мать: фрагментация! Предлагаю Manifesto самому написать простейший дефрагментатор для данной ситуации (естественно на словах). Слабо?!!
Наверх
Сайт
Manifesto
Четверг 16.06.2005 10:36
ID пользователя #43
Зарегистрирован: Четверг 12.08.2004 10:01
Сообщений: 6
Ну раз уж так просишь. Меняешь местами 104 и 103 и переписываешь заголовки. Епт, вашу мать, чего вы так к фрагментации прицепились, речь не о ней. Речь о ФАЙЛОВОЙ СИСТЕМЕ КАК ТАКОВОЙ.

>> Но этот подход применим в том случае, если в
>> сумме объекты занимают на порядок меньше
>> размера ОЗУ.

Да даже и если меньше, сидеть и ждать когда 200 метров загрузятся в память нет желания. Да и вообще это полная бойда, грузить все в память, а гдеж будут программы работать? Или все программы тоже будут в памяти висеть? Маразм.

>> В принципе, предполагается реализовать
>> объектную файловую систему.

Логически она будет объектной, физически ничего подобного.
Наверх
Manifesto
Четверг 16.06.2005 10:45
ID пользователя #43
Зарегистрирован: Четверг 12.08.2004 10:01
Сообщений: 6
Dron написал(а) ...
Объекты не отменяют фрагментации... это точно...

Но давно доказано, что в многозадачных системах с кешированием и тд... влияние фрагментации на скорость ничтожно мало.


Кем доказано? Ты давно дефрагментил свою винду? Попробуй, заметишь разницу (хоть винда и многозадачная и с кэшем).

А на самом деле, фрагментация будет всегда и всегда она будет влиять на производительность, ни кэш, ни многозадачность не поможет (хотя я первый раз слышу, чтобы многозадачность и кэш уменьшали влияние фрагментации, ведь кэширование - это либо сохранение считанных данных, либо загрузка на опережение, один хрен, чтобы считать и закэшировать данные нужно процессорное время и время чтобы занять диск на время считывания кэшируемых данных).
<span class='smallblacktext'>[ Редактирование четверг 16.06.2005 10:54 ]</span>
Наверх
mzprog
Четверг 16.06.2005 10:55
ID пользователя #306
Зарегистрирован: Четверг 05.05.2005 10:16
Сообщений: 23
>> Но этот подход применим в том случае, если в
>> сумме объекты занимают на порядок меньше
>> размера ОЗУ.

>Да даже и если меньше, сидеть и ждать
>когда 200 метров загрузятся в память нет желания.
>Да и вообще это полная бойда, грузить все в память,
>а гдеж будут программы работать?
>Или все программы тоже будут в памяти висеть? Маразм.

Допустим, у меня на компе 512 метров ОЗУ, ну и пусть в ОЗУ запишется при загрузки 50 метров программ. И что? У меня сейчас под виндой намного больше занято... Тем более это временный вариант!

>Логически она будет объектной,
>физически ничего подобного.

Любая файловая система - логически файловая система, физически - набор байтов, секторов или точнее набор намагнитностей




Наверх
Сайт
mzprog
Четверг 16.06.2005 11:19
ID пользователя #306
Зарегистрирован: Четверг 05.05.2005 10:16
Сообщений: 23
Manifesto написал(а) ...
Dron написал(а) ...
Объекты не отменяют фрагментации... это точно...

Но давно доказано, что в многозадачных системах с кешированием и тд... влияние фрагментации на скорость ничтожно мало.


Кем доказано? Ты давно дефрагментил свою винду? Попробуй, заметишь разницу (хоть винда и многозадачная и с кэшем).

А на самом деле, фрагментация будет всегда и всегда она будет влиять на производительность, ни кэш, ни многозадачность не поможет (хотя я первый раз слышу, чтобы многозадачность и кэш уменьшали влияние фрагментации, ведь кэширование - это либо сохранение считанных данных, либо загрузка на опережение, один хрен, чтобы считать и закэшировать данные нужно процессорное время и время чтобы занять диск на время считывания кэшируемых данных).


Пусть дефрагментированный файл считывается за 5 сек, а фрагментированный за 10. Пусть 2-ая половина файла находиться в кэше (скорость чтения 0,001 сек). Тогда, в 1-ом случае файл считается за 2,501 сек, а во втором за 5,001. То есть, ждать будем не на 5 сек больше, а на 2,5 , что уже не так заметно...

Да и вообще о чём спор? Конечно, фрагментация, похоже, будет всегда и бороться с ней, то есть дефрагментировать, тоже будут всегда... Хотя, я сам лично уж и не помню когда этим занимался А что, интересное занятие! - надо будет на досуге заняться
Наверх
Сайт
Manifesto
Четверг 16.06.2005 11:25
ID пользователя #43
Зарегистрирован: Четверг 12.08.2004 10:01
Сообщений: 6
>> Допустим, у меня на компе 512 метров ОЗУ, ну
>> и пусть в ОЗУ запишется при загрузки 50
>> метров программ. И что? У меня сейчас под
>> виндой намного больше занято... Тем более это
>> временный вариант!

50 метров? Это типа несколько копий notepad'ов? Ты загрузи попробуй все свои программы, которые у тебя установлены и посмотрим что из этого выйдет.

Временных вариантов быть не должно, либо делать сразу, либо не делать вообще.
Наверх
mzprog
Четверг 16.06.2005 11:44
ID пользователя #306
Зарегистрирован: Четверг 05.05.2005 10:16
Сообщений: 23
Manifesto написал(а) ...
>> Допустим, у меня на компе 512 метров ОЗУ, ну
>> и пусть в ОЗУ запишется при загрузки 50
>> метров программ. И что? У меня сейчас под
>> виндой намного больше занято... Тем более это
>> временный вариант!

50 метров? Это типа несколько копий notepad'ов? Ты загрузи попробуй все свои программы, которые у тебя установлены и посмотрим что из этого выйдет.

Временных вариантов быть не должно, либо делать сразу, либо не делать вообще.


Зачем мне грузить несколько копий notepadoff?
Я занимаюсь написанием оси, которая будет размещаться пока на дискете. Да и потом, в ближайщем будующем вряд ли осилит 10 метров, а о 50-ти речь вообще не идёт.
К этому времени ОЗУ у меня будет не 512, а 5 гигов, хотя нормальная файловая система всё-таки предполагается...

Да и потом, почему такая категоричность - "временных вариантов не должно быть"? Почему? Пока первый вариант, а время второго варианта пока не пришло...
Наверх
Сайт
Dron
Четверг 16.06.2005 12:59


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Вы все еще дефрагментируете??? тогда мы идем к вам!!!
попробуйте ext2 или reiserfs... или да любую fs из юникса... Что, фрагментируется - да!
Но файлы располагать надо с умом, дабы фрагментация не превышала некоего разумного предела...

В досе всегда все писалось по порядку... первый свободный, второй свободный... и тд...
Не знаю как в современных системах от МС... вероятно не так... но на сколько не так - судить не берусь...

В юниксе и слова такого нету - дефрагментатор.

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев
Наверх
Сайт
Переход на страницу  1 2 3 [4] 5  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.