?

Log in

No account? Create an account

Previous Entry Share Next Entry
msl-five. Это пять.
mikelsv
Почему бы не вспомнить про msl и не написать очередную, пятую версию? Признаться, есть версия 4.5, которая врое как и должна быть пятой, но цифры не те. Поэтому пятая версия будет писаться с нуля и с новыми идеями.

Собственно об идеях и хотелось поговорить. Прояснить моменты. По другому взглянуть на проект и ожидаемый результат. Если раньше требовалось написать работающую версию, то сейчас понятно, что даже на ней далеко не уедешь. Нужна оптимизация, причем настолько, что с нее нужно и начинать.

Я хочу:
- Быстую работу с переменными.
- Поддержку многопоточности.

Вот на этих идеях и следует строить логику.

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

На тему памяти у меня готова идея выделять большие блоки памяти и взять недавно созданный класс FString. Все данные размещаются в выделенной памяти. По порядку. А чтобы не было фрагментации в памяти будет указатель на переменную класса, что позволит перемещать данные. Тут правда возникает вопрос, как эти данные безопасно перемещать, однако полагаю, что перемещение будет размыто по времени, а установка идти через блокировки.

Другой вопрос, что делать с многопоточностью. Сейчас мне начинает казаться, что логика та же. Хотя, возможна ситуация, когда один поток пишет, а второй читает. С одной стороны блокировка на чтение нужна, а с другой хочется обойтись без нее, иначе придуется добавить кучу блокировок. С третьей, полагаю, стоит использовать безопасную установку, так, чтобы в любой момент времени максимальной ошибкой при чтении были кривые данные. Сваливаем проблему на пользователя. Пусть пользуется блокировками или получает проблемы. Хотя, какие проблемы, когда даже многопоточный код на php чуть ли не шутка.

Итого.
Задача создать класс FString{ unsigned char *data; unsigned int sz; }, хранящий строки в блоках памяти. Базовая структура в блоке памяти: FString* val; unsigned char data[]; В функцию FString::Set(VString line) вызывает функцию установки с использованием блокировки. При удалении или изменении размера данных доступ к осбовожденной памяти должна блокироваться, на случай, если ее читают. Тут видится два решения. Добавить unsigned int time; в блок памяти к каждой переменной, что очевидно потребует кучу памяти, а пользы приносить в принципе не будет. Поэтому мне кажется наиболее правильным второе решение, добавить маркер запрета на изменения всему блоку памяти...Хмм, что можно сказать о проблемах? Они будут.
Очевидная пробема VString a = FString b; Только представил себе бесконечную миграцию данных. Как понял, что домигрируют они до первого глюка. А в идеале хотелось бы заменить MString на FString, В первом данные всегда на месте. Решение? Флаги запрета перемещения? VFString с указателем на FString? ... А если сделать привязку переменных к блоку памяти? С запретом на изменение. Да, придется написать что-то вроде FStringLock(); И безопасно использовать переменные, зная, что они не убегут. Вопрос в правильной реализации, без заметных тормозов.

Вот как-то так, это базовый каркас для быстрых переменных и базовые размышления.

К слову, есть почти законченный msl-ce 4.5 с псевдокодом и кодогенерацией, но мы же не ищем легких путей и пишем все заново.