HiAsm
HiAsm
Вверх ↑
Форумы"Игра в слова"Правильность построения схем. ? №001 ← Ctrl12345...101112131415161718Ctrl →
Этот топик читают: Гость
Ответов: 5446
Рейтинг: 323
#196: 2012-03-30 23:51:25 ЛС | профиль | цитата
nesco, янифиганепонял:
nesco писал(а):
Таблица не нужна совсем, достаточно иметь в начале кластера структуру с содержанием всех нужных параметров -- принцип цепи, как у наших MT-потоков

Смотри: либо ты делаешь цепь (кластер есть указатель на первый блок, в каждом блоке есть указатель на следующий), и тогда для получения N-го блока тебе придётся перебрать все предыдущие (ибо никто тебе не гарантирует, что блоки будут последовательно в памяти лежать); либо кластер есть указатель на таблицу соответствия блок-адрес, и тогда цепь тебе нафиг не нужна. Третьего тут вроде не дано. Или ты имеешь в виду, что "заголовок" кластера - это не таблица, а цепь? Но это вообще какая-то ерунда выходит - ничем оно от обычной цепи не отличается (системе глубоко фиолетово, на сколько сдвигать указатель).
карма: 1

0
Разработчик
Ответов: 26158
Рейтинг: 2127
#197: 2012-03-30 23:53:17 ЛС | профиль | цитата
1nd1g0 писал(а):
перевыделение из-за "хвостиков", заступающих на соседнии страницы

Размер грануляции памяти (кластера памяти) находится очень просто, достаточно не выходить за его пределы, а то оформится новый кластер памяти
карма: 22

0
Ответов: 1731
Рейтинг: 68
#198: 2012-03-30 23:55:28 ЛС | профиль | цитата
[flood]nesco,
не выходить
оформиться [/flood]
карма: 1

0
Разработчик
Ответов: 26158
Рейтинг: 2127
#199: 2012-03-31 00:00:31 ЛС | профиль | цитата
iarspider писал(а):
ибо никто тебе не гарантирует, что блоки будут последовательно в памяти лежать

Абсолютно до фени, как они там лежат. У нас работа со StrList-ом происходит как со строками текста , так и с текстом, и никого не колышит, как эти строки в памяти раскиданы, и они точно не последовательны

Ты видимо меня не до конца понял -- цепь нужна для перемещения между кластерами, пока мы работаем внутри кластера, мы никуда не перемещаемся, как только мы выходим за диапазон адресации кластера, мы перескакиваем туда, где находится следующий элемент
------------ Дoбавленo в 00.00:
[flood]
Cosinus писал(а):
оформиться

Ты че, вопрос стоит "что сделает", а не "что сделать". Садись, два. А в первом у меня опечатка[/flood]
карма: 22

0
Ответов: 5446
Рейтинг: 323
#200: 2012-03-31 00:40:34 ЛС | профиль | цитата
nesco, я и говорил про перемещение между кластерами. Внутри кластера у тебя линейная адресация: начало_блока+индекс*размер_элемента. Размер блока у тебя фиксированный, так что понять, в каком блоке лежит нужный элемент легко. Я-то речь веду о том, как найти начало нужного блока. В твоём методе нельзя сразу узнать адрес k-го блока, надо сначала все предыдущие пройти (цепочка же). Ну вот псевдокод :

#cpp
// TElement - это один элемент, единица хранения так сказать

struct TBlock
{
  TBlock* pNextBlock;
  TElement* pData;
}

class TCluster
{
  size_t block_size; // кол-во TElement-ов на блок; size_t - это подходящий целочисленный тип, достаточно большой для индексации всех блоков и всех элементов в блоке
  TBlock* pFirstBlock;

  TElement * get(size_t index)
  {
    size_t iBlockIndex = index / block_size; 
    size_t iElementIndex = index % block_size; // остаток от деления
    TBlock* pBlock = pFirstBlock;
    while (iBlockIndex > 0)
    {
      pBlock = pBlock->pNextBlock
    }
    return pBlock[iElementIndex]->pData;
  }
}
карма: 1

0
Разработчик
Ответов: 26158
Рейтинг: 2127
#201: 2012-03-31 01:05:03 ЛС | профиль | цитата
iarspider писал(а):
Я-то речь веду о том, как найти начало нужного блока. В твоём методе нельзя сразу узнать адрес k-го блока, надо сначала все предыдущие пройти (цепочка же)

Ну, да, надо: либо прочитать все заголовки до нахождения адреса нужного, либо составить список указателей кластеров. Тут можно любой использовать, первый будет немного медленнее
карма: 22

0
Ответов: 5446
Рейтинг: 323
#202: 2012-03-31 01:19:31 ЛС | профиль | цитата
nesco, я об этом уже несколько постов подряд талдычу Первый (цепочка): медленный поиск, быстрое добавление. Второй (таблица) - быстрый поиск, медленное добавление (опять же, выделение блоками несколько сгладит эффект). Есть подозрение, что можно с помощью дерева сделать достаточно быстрым и поиск, и добавление (двоичное дерево, движение от старшего разряда индекса к младшему, "листья" - адреса блоков), и вроде плата (память/быстродействие) не очень большая будет.
карма: 1

0
Разработчик
Ответов: 26158
Рейтинг: 2127
#203: 2012-03-31 01:42:43 ЛС | профиль | цитата
iarspider, ты лучше мне скажи -- а какого черта мы тут зад рвем по этому вопросу, че это нам дает, оно нам надо, или ты хочешь это безобразие на С реализовать
------------ Дoбавленo в 01.42:
iarspider писал(а):
Первый (цепочка): медленный поиск, быстрое добавление. Второй (таблица) - быстрый поиск, медленное добавление (опять же, выделение блоками несколько сгладит эффект)

Гы, гы, гы. Первый метод -- FAT, второй метод -- NTFS
карма: 22

0
Ответов: 5446
Рейтинг: 323
#204: 2012-03-31 06:39:09 ЛС | профиль | цитата
Про NTFS не знаю, а FAT - да, именно так и сделан. А по поводу рванья зада - дык скучно же
карма: 1

0
Ответов: 1429
Рейтинг: 50
#205: 2012-03-31 08:49:43 ЛС | профиль | цитата
iarspider, спасибо, что обсудили это тут, я увидел детали этого вопроса, по книжкам гораздо сложнее получить представление о таком.

карма: 0

0
Ответов: 1528
Рейтинг: 57
#206: 2012-04-09 09:54:31 ЛС | профиль | цитата
хочу реализовать, метод кластерного массива, только не понятно с хранением ссылок
можно далее развить идею?
карма: 0

0
Разработчик
Ответов: 26158
Рейтинг: 2127
#207: 2012-04-09 11:01:40 ЛС | профиль | цитата
hitman249 писал(а):
только не понятно с хранением ссылок

Я так предполагаю, что первым идет некоторая непрерывная структура заголовка кластера фиксированной размерности. Вот что там конкретно хранить, надо бы уточнить. То, что там должно быть поле указателя адреса заголовка следующего кластера, то это -- обязательно. Скорее всего нужен еще и индекс кластера, для быстрого поиска нужного индекса элемента
карма: 22

0
Ответов: 1528
Рейтинг: 57
#208: 2012-04-09 11:22:09 ЛС | профиль | цитата
nesco писал(а):
фиксированной размерности

если размерность фиксированная то где хранить ссылки на массивы?
------------ Дoбавленo в 11.22:
в начале я так понял, что ссылки идут либо в последнейпервой ячейке всех массивов, либо в таблице размерность которой также не понятна
карма: 0

0
Разработчик
Ответов: 26158
Рейтинг: 2127
#209: 2012-04-09 11:50:27 ЛС | профиль | цитата
hitman249 писал(а):
если размерность фиксированная то где хранить ссылки на массивы?

Здрасте, в том и прикол кластерного массива -- неизменность размера кластера, включая и его заголовок. В случае привязанного заголовка, кластер всегда должен быть размером -- FixedSizeHider + FixedSizeData. Если предполагается делать таблицу заголовков, то размер таблицы изначально должен быть расчитан на N кластеров (табличный кластер), тогда размер таблицы будет -- N * FixedSizeHider, а размер одного кластера массива будет -- FixedSizeData.
карма: 22

0
Ответов: 1528
Рейтинг: 57
#210: 2012-04-09 12:19:59 ЛС | профиль | цитата
nesco,
nesco писал(а):
неизменность размера кластера, включая и его заголовок

под заголовком что имеется ввиду ?


nesco писал(а):
размер таблицы изначально должен быть расчитан на N кластеров

зачем он тогда вообще нужен такой размер таблицы? исходя из этого получается от чего бежали к тому и вернулись.

требуется неограниченное количество массивов, зачем изобретать снова "стену"
------------ Дoбавленo в 12.17:
hitman249 писал(а):
где хранить ссылки на массивы?

nesco писал(а):
А лучшее, все же -- враг хорошего!
nesco писал(а):
-- FixedSizeHider

чтото я с этими "--" начинаю не понимать их смысла
------------ Дoбавленo в 12.19:
[flood]-
--
---
----[/flood]
карма: 0

0
Форумы"Игра в слова"Правильность построения схем. ? №001 ← Ctrl12345...101112131415161718Ctrl →
Сообщение
...
Прикрепленные файлы
(файлы не залиты)
HiAsm Studio 2003 - 2024
Пользовательское соглашение | support@hiasm.com
Яндекс.Метрика