Oberon space

Мучает меня дурацкая идея...

Есть данные. В основном данные нужны в режиме только для чтения. Изменяются они редко. Данных может быть много - гигабайты.

Есть программа. Программа стартует, медленно всасывает в себя все данные, а потом очень быстро работает.

Программ может быть несколько (у меня их уже две). Запускаются они на одном большом сервере.

Вроде всё нормально, однако:
1) Жалко память (копий данных столько сколько программ).
2) Жалко при старте тратить время на всасывание данных (хочется иметь возможность очень быстрого рестарта).

Дурацкая идея:
Сделать "сервер" данных, который будет шарить свою память. Он (ре)стартует медленно.
Остальные программы при старте будут всего лишь маппить память. Выгоды: мгновенный рестарт, данные не копируются.

Сколько же тут подводных камней...

400 лет назад народ отвоевал Москву у поляков...

Последние несколько лет некоторыми товарищами продвигался мем: "народные ополченцы" -- это такие ламеры от программирования. Особо не задумываясь я и сам иногда ругался "народными ополченцами". До меня только недавно дошло на сколько же этот мем русофобский.

Народное ополчение - святое, ламеры от программирования - позор. Мысль связать одно с другим ужасна.

Однажды понадобилось иметь персистентную коллекцию неких записей. В процессе работы программы записи могут изменяться, удаляться, добавляться. Держать для неё отдельную СУБД - это как из пушки по воробъям, так что просто завёл файл. Встал вопрос как организовать с ним работу. Я выделил три условия:

1) С одной стороны размер этого файла не очень гигантский в том смысле, что при старте программа зачитывает его целиком в оперативку. Пусть программа стартует медленно, зато работает быстро.

2) С другой стороны его размер достаточно велик для того чтобы при изменении одной или нескольких записей перезаписывать файл целиком сбрасывая все записи из оперативки на диск. Жесткий диск может интенсивно использоваться другими программами работающими на этом же компьютере, поэтому полная перезапись файла может занять несколько секунд.

3) Если во время записи в файл произойдёт авария (выключение питания, падение программы), то данные не должны серьёзно испортиться. При рестарте программа перечитывая файл должна сама исправить ошибки в файле.

Хотелось бы узнать кто как поступил бы в этой ситуации.

Я организовал работу с этим файлом так.
Каждая запись снабжается уникальным идентификатором. Данные в файле представляют собой набор команд двух типов:
1) добавить или перезаписать запись с таким-то идентификатором такими-то значениями,
2) удалить запись с таким-то идентификатором.
Программа стартует, читает файл и выполняет команды; после выполнения всех команд в оперативной памяти получается итоговый набор записей. Когда в процессе работы программы какая-то запись удаляется, то в конец того файла дописывается команда "удалить запись с таким-то идентификатором". Когда какая-то запись добавляется или изменяется, то в конец файла дописывается команда "добавить или перезаписать запись с таким-то идентификатором такими-то значениями". То есть во время работы программы в файл дописываются только изменения -- это очень быстро (правда занимает больше места на диске). Важно что запись всегда идёт только в конец файла. Если во время записи данных в файл произойдёт авария, то при рестарте программа дочитав до этого места обнаружит ошибку в формате данных и перезапишет файл автоматически удалив эту ошибку. Ошибка может быть только в конце файла! Если при старте программа прочитав файл обнаруживает, что количество команд в нём более чем в два раза превышает итоговое количество записей, то она перезапишет файл (тем самым уменьшит его размер более чем в 2 раза). Перезапись осуществляется естественно сначала во временный файл, а затем выполняется (как бы атомарная) замена старого файла новым.

Добавила Микрософт в C# 2010 ключевое слово dynamic для поддержки программирования в стиле динамических языков а-ля Питон. Динамика реализуется через reflection. Дошли руки померить скорость работы.

Будем вызывать процедуру Foo класса MyObject:
public sealed class MyObject
{
   public static int sum;

   public void Foo (int x, int y, int z)
   {
      sum = sum + x + y + z;
   }
}

Обычный статический вызов:
public static void Test0 (MyObject x)
{
   x.Foo(1, 2, 3);
}

Обычный вызов с предварительным динамическим приведением типа:
public static void Test1 (object x)
{
   ((MyObject)x).Foo(1, 2, 3);
}

Чисто динамический вызов (а-ля Питон):
public static void Test2 (dynamic x)
{
   x.Foo(1, 2, 3);
}

Время затраченное на миллиард вызовов:
Test0   1.90 секунд
Test1   1.95 секунд
Test2  24.37 секунд

У GPU и CPU гибридного процессора AMD Kaveri будет общее адресное пространство памяти

http://www.ixbt.com/news/hard/index.shtml?15/91/61

Примерно одновременно с APU Kaveri выйдут процессоры Intel Haswell, у которых, при всех достоинствах, не будет единого адресного пространства для x86-совместимых ядер и интегрированной графики.

Речь о численном решении всяческих волновых уравнений с сильно локализованными волновыми пакетами. Хочется пространственную сетку сделать неравномерной, так чтобы в области нахождения волнового пакета количество точек было очень большим, а в остальной части (пустого) пространства -- малым. И ещё подвижной, чтобы по мере распространения волнового пакета плотность точек решётки под него подстраивалась.

Кто нибудь слышал про подобное?

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

Вчера ради спортивного интереса включил в асусовском биосе опцию OC Tuning (Overclock Tuning). Перезагрузившись пару раз компьютер сам настроился на множитель турбо буста 43 и частоту шины где-то в районе 103 МГц (Core i7 2600K, ASUS P6Z68 V LE, Kingston 4*4 Гб 1333 МГц).

Выглядит это так. Пока ничего вычислять не надо процессор работает на частоте 1600 МГц. Как только запускаешь процессороёмкую программу включается турбо буст и проц сам гонится примерно до 4.5 ГГц. Невооружённым глазом заметно, что компьютер становится более отзывчивым (летает).

Замерил производительность сортировкой:


Правда радость от того что компьютер "летает" была недолгой...

После баловства с сортировкой я запустил серьёзную программу (365/7/24) под большой нагрузкой надолго. Минут через пятнадцать она сдохла -- "не отвечает". Пришлось снизить множитель турбо буста до 42. Серьёзная программа проработала дольше, но всё равно сдохла. Снизил до 41. Проработала ещё дольше, но тоже сдохла. Снизил до 40. Работала гораздо дольше, но опять сдохла. Снижать множитель до 39 уже выгоды особой нет, а сдохнуть может.

Короче пользы от оверклокинга не оказалось совершенно никакой: программы которые выполняются за минуту ускорять особого смысла нет, а серьёзные программы которые должны под большой нагрузкой работать по формуле 365/7/24 ускорять не получается ибо они через некоторое время дохнут.

Это ещё не всё. Мало того что нет пользы, так есть ещё и вред. Когда процессор начинает совершать ошибки, то портятся все программы, а не только та которая много думает. В частности портится сама Виндос. В течение одного дня Виндовс у меня слетела два раза (после перезагрузки компьютера Виндовс не смогла сама загрузиться). На этом беды не кончились. Во время этих "турбо-бустов" у меня была запущена MS Visual Studio 2008, вот она тоже сама себя запорола и, видимо, придётся её переустанавливать (не открывает проекты зараза). Какие ещё разрушения были вчера причинены системе я пока не понял.