std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 06.05.12 09:37
Оценка:
Всем привет,
Конструирую Key-Value структуру данных.
Поиск Log(1), Вставки Log(1)
Особенностью этой структуры есть черезвычайно высокая скорость поиска
(от 3,1 наносекунд до 50 нс занимает один поиск), высокая скорость вставок (от 5нс до 50 нс),
экономия памяти вплоть до компрессии данных,
возможность выборок по диапазону ключей (данные в структуре отсортированы).

Вопрос такой.
Что еще можно потестить из асоциативных массивов, может какая структура данных с со схожими параметрами
ускользнула из вида ?

Бенчмарки можно глянуть здесь
http://www.sql.ru/blogs/stebelek/1269

И здесь
http://www.sql.ru/blogs/stebelek/1267

Спасибо!
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HA
От: the_daily_ragnarok Россия  
Дата: 06.05.12 11:20
Оценка: +1 :)
Здравствуйте, PC_2, Вы писали:

PC_>Поиск Log(1), Вставки Log(1)


O'RLY?
Log(1) = 0

Мнгновенный поиск-вставка?
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ego Liberare Art Ultimus Injuria
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 06.05.12 11:22
Оценка:
Здравствуйте, the_daily_ragnarok, Вы писали:

__>Здравствуйте, PC_2, Вы писали:


PC_>>Поиск Log(1), Вставки Log(1)


__>O'RLY?

__>Log(1) = 0

__>Мнгновенный поиск-вставка?


Пардон, О(1)
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HA
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 06.05.12 13:31
Оценка:
ап
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: WolfHound  
Дата: 06.05.12 14:08
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>ап

Код где?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 06.05.12 14:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, PC_2, Вы писали:


PC_>>ап

WH>Код где?

Код не опен сорц.
Опенсорснул я только одну из тестовых версий.
http://www.sql.ru/forum/actualfile.aspx?id=12509735
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HA
От: Wolverrum Ниоткуда  
Дата: 06.05.12 19:14
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Поиск Log(1), Вставки Log(1)


Это, простихоспаде как?
Это за 0 операций вставляется и ищется? Срочно премию получать!
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 07.05.12 08:32
Оценка: :)
Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, PC_2, Вы писали:


PC_>>Поиск Log(1), Вставки Log(1)


W>Это, простихоспаде как?

W>Это за 0 операций вставляется и ищется? Срочно премию получать!

Приятно, что в Эстонии тоже читают рсдн.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HA
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.05.12 10:27
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Конструирую Key-Value структуру данных.

PC_>Поиск Log(1), Вставки Log(1)
PC_>Особенностью этой структуры есть черезвычайно высокая скорость поиска
PC_>(от 3,1 наносекунд до 50 нс занимает один поиск), высокая скорость вставок (от 5нс до 50 нс),
PC_>экономия памяти вплоть до компрессии данных,
PC_>возможность выборок по диапазону ключей (данные в структуре отсортированы).

Протести
1. удаление
2. добавление 1 млн элементов
3. итерации по всему списку

Например hashset выдыхается на удалении, здесь у него O(N^^2) и все становится грустно.

PC_>Вопрос такой.

PC_>Что еще можно потестить из асоциативных массивов, может какая структура данных с со схожими параметрами
PC_>ускользнула из вида ?

Для твоих тестов это без толку. Нужно тестировать весь набор операций, что бы знать, в каких случаяхможно использовать твой контейнер

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

PC_>Бенчмарки можно глянуть здесь

PC_>http://www.sql.ru/blogs/stebelek/1269

главное что бы расход памяти не был O(N^^2) Где, кстати расход памяти ?
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 07.05.12 11:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Протести

I>1. удаление
I>2. добавление 1 млн элементов
I>3. итерации по всему списку

Удаление я пока что не рассматривал,
поскольку большинство задач это Вставка и Поиск в хештаблице.
Удаление обычно ограничивается Clear.

I>Например hashset выдыхается на удалении, здесь у него O(N^^2) и все становится грустно.


Попробуй протестировать hashset на вставки.

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


Нельзя, по памяти будет не оптимально для рандом значений.

PC_>>Бенчмарки можно глянуть здесь

PC_>>http://www.sql.ru/blogs/stebelek/1269
I>главное что бы расход памяти не был O(N^^2) Где, кстати расход памяти ?

В колонке вроде есть расход памяти, тоже экономней расходует ...
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[3]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 07.05.12 13:02
Оценка:
Кстате, а о каком ХешСет речь ?
Этот хеш сет вроде не моделирует пары Ключ/Значение.

HashSet<int> d = new HashSet<int>();
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[3]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: roro  
Дата: 07.05.12 14:26
Оценка:
Здравствуйте, PC_2

Сравните с Judy и Ternary Search Tree для поиска по строкам
Re[4]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 07.05.12 14:38
Оценка:
Здравствуйте, roro, Вы писали:

R>Здравствуйте, PC_2


R>Сравните с Judy и Ternary Search Tree для поиска по строкам


Спасибо, только боюсь время займет скачать, настроить это все под виндовз, запустить.
Ни у кого случайно нет настроеной среды сделать простенький тест ?
Вставка/Поиск нескольких миллионов ключей.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[5]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 07.05.12 17:10
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, roro, Вы писали:


R>>Здравствуйте, PC_2


R>>Сравните с Judy и Ternary Search Tree для поиска по строкам


PC_>Спасибо, только боюсь время займет скачать, настроить это все под виндовз, запустить.

PC_>Ни у кого случайно нет настроеной среды сделать простенький тест ?
PC_>Вставка/Поиск нескольких миллионов ключей.

Нашел врапер этой либы под дот нет https://github.com/dump247/JudyArray
После нескольких затяжных танцев с бубнами удалось завести сию либу.
Но результаты удручающи. В разы отстала от стандартного Dictionary.NET.
Конечно там еще обертка какойто перформенц отбирает, но не в разы же ...
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[6]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 07.05.12 17:18
Оценка:
Здравствуйте, PC_2, Вы писали:

Для сравнения, 1 млн рандом ключей.
Икор7
Вставка Джуди 1,1 секунда
Стандартный Диктионари 0,151 сек

Вставка Джуди 0,8 секунда
Стандартный Диктионари 0,142 сек

У меня для строк пока не запилина версия но для интов,
будет гдето 0,051 сек вставки
и 0,041 поиск

Код примерно такой
//fill
            List<string> keys = new List<string>();
            FileStream fs = new FileStream(@"c:\rand.bin", FileMode.Open);

            //JudyArray.JudyStringDictionary<int> judy = new JudyStringDictionary<int>();

            Dictionary<string, int> d = new Dictionary<string, int>(1000000);
            BinaryReader br = new BinaryReader(fs);
            for (int i = 0; i < 1000000; i++)
            {
                //keys.Add(br.ReadInt32());
                int num = br.ReadInt32();
                keys.Add(num.ToString());
            }

            br.Close();
            fs.Close();

            Stopwatch sw = new Stopwatch();
            sw.Start();

            //keys.Sort();

            for (int i = 0; i < keys.Count; i++)
            {
                //judy[keys[i]] = i;

                if (!d.ContainsKey(keys[i]))
                {
                    d.Add(keys[i], i);
                }
            }

            sw.Stop();

            MessageBox.Show(sw.ElapsedMilliseconds.ToString());

            sw = new Stopwatch();
            sw.Start();

            //keys.Sort();

            for (int i = 0; i < keys.Count; i++)
            {
                //judy.TryGetValue(keys[i], out value);
                if (d[keys[i]] != i)
                {
                    //MessageBox.Show("Error");
                }
                //if (!d.ContainsKey(keys[i]))
                //    d.Add(keys[i], keys[i]);
            }

            sw.Stop();

            MessageBox.Show(sw.ElapsedMilliseconds.ToString());
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HA
От: Mamut Швеция http://dmitriid.com
Дата: 07.05.12 19:12
Оценка:
PC_>Всем привет,
PC_>Конструирую Key-Value структуру данных.
PC_>Поиск Log(1), Вставки Log(1)
PC_>Особенностью этой структуры есть черезвычайно высокая скорость поиска
PC_>(от 3,1 наносекунд до 50 нс занимает один поиск), высокая скорость вставок (от 5нс до 50 нс),
PC_>экономия памяти вплоть до компрессии данных,
PC_>возможность выборок по диапазону ключей (данные в структуре отсортированы).

Выделенное ставит под вопрос O(1) для вставки. Возможно, O(1) «амортизированный»?

Удаление из структуры все же очень интересует.


dmitriid.comGitHubLinkedIn
Re[2]: и да
От: Mamut Швеция http://dmitriid.com
Дата: 07.05.12 19:33
Оценка:
PC_>>Всем привет,
PC_>>Конструирую Key-Value структуру данных.

Прделагаю тему превентивно удалить. Предыстория тут: http://www.sql.ru/forum/actualthread.aspx?tid=863510


dmitriid.comGitHubLinkedIn
Re[3]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.05.12 08:14
Оценка:
Здравствуйте, PC_2, Вы писали:

I>>Протести

I>>1. удаление
I>>2. добавление 1 млн элементов
I>>3. итерации по всему списку

PC_>Удаление я пока что не рассматривал,

PC_>поскольку большинство задач это Вставка и Поиск в хештаблице.
PC_>Удаление обычно ограничивается Clear.

Это и половины случаев не покроет.

I>>Например hashset выдыхается на удалении, здесь у него O(N^^2) и все становится грустно.


PC_>Попробуй протестировать hashset на вставки.


Так себе.

PC_>В колонке вроде есть расход памяти, тоже экономней расходует ...


Ну значит удаление умрёт наверняка
Re[4]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 08:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, PC_2, Вы писали:


I>>>Протести

I>>>1. удаление
I>>>2. добавление 1 млн элементов
I>>>3. итерации по всему списку

PC_>>Удаление я пока что не рассматривал,

PC_>>поскольку большинство задач это Вставка и Поиск в хештаблице.
PC_>>Удаление обычно ограничивается Clear.

I>Это и половины случаев не покроет.


Ну а каких случаев ? Почему так важно удаление ?
В нашей рабочей СУБД данные удаляются очень редко, они просто архивируются и база живет дальше.
Также чтобы построить движок фул текст энжин, тоже удаление не нужно.
Чтобы посчитать количество уникальных значений, отсортировать чтото — удаление не нужно.
И так далее. Из операций Вставка/Поиск/Память/Удаление, само по себе Удаление менее всего интересно
как операция.

Но если интересно удаление, то пока происходит обычное разрежение структуры данных за О(1) время.
При разрежении может оказаться, что некоторые страницы памяти пусты. Они удаляются и тогда уже высвобождается память.
Структуру данных можно перестроить, чтото вроде шринка в обычных СУБД.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[5]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.05.12 08:49
Оценка:
Здравствуйте, PC_2, Вы писали:

I>>Это и половины случаев не покроет.


PC_>Ну а каких случаев ? Почему так важно удаление ?


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

PC_>Но если интересно удаление, то пока происходит обычное разрежение структуры данных за О(1) время.

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

У тебя шота все за O(1), чтото не так с тестами. Код тестов ты не выкладывал ?
Re[6]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 08:53
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


Так это нормально. А как ты хотел ? Удалить одно значение и освободить десять байт моментально ?

I>У тебя шота все за O(1), чтото не так с тестами. Код тестов ты не выкладывал ?


Такого плана тест. rand.bin это заархивированый фильм, источник случайной последовательности для ключей.
Тест такого плана.

int _tmain(int argc, _TCHAR* argv[])
{
    //20/21/22/23/24 /25 /26 /
    //19/14/9 /6 /3.7/2.7/2.4/
    clock_t start, finish;

    FILE* file = fopen("c:\\rand.bin", "rb");

    uint maxOffset = 0;

    keys = new uint[COUNT_KEYS];

    for(uint i=1; i<COUNT_KEYS; i++)
    {
        fread(&keys[i], 4, 1, file);
    }
    
    fclose(file);

    init(27);

    start = clock();

    for(uint i=0; i<COUNT_KEYS; i++)
    {
        insert(keys[i], keys[i]);
    }

    finish = clock();

    printf( "Filled: %2.1d msec\n", (finish - start) );

    start = clock();

    for(uint i=0; i<COUNT_KEYS; i++)
    {
        if( getValueByKey(keys[i]) != keys[i])
        {
            printf( "Error: %2.1d %2.1d\n", getValueByKey(keys[i]), keys[i]);
        }
    }
    
    finish = clock();

    delete[] keys;
    
    printf( "Searches: %2.1d msec\n", (finish - start) );
    
    uint* buff = new uint[COUNT_KEYS];

    start = clock();

    uint count = getValuesByRange(buff, COUNT_KEYS, 1, 0xFFFFFFFF);
    
    finish = clock();

    printf( "Range: %2.1d msec\n", (finish - start) );

    delete[] buff;
    
    system("pause");

    return 0;
};
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[7]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.05.12 09:03
Оценка:
Здравствуйте, PC_2, Вы писали:

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


PC_>Так это нормально. А как ты хотел ? Удалить одно значение и освободить десять байт моментально ?


Примерно так. Есть мега-деревья, которые так и работают.

I>>У тебя шота все за O(1), чтото не так с тестами. Код тестов ты не выкладывал ?


PC_>Такого плана тест. rand.bin это заархивированый фильм, источник случайной последовательности для ключей.

PC_>Тест такого плана.

Я не понял, key это uint ? Контейнер для таких ключей я накидаю за полчаса с перерывом на обед
Re[8]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 09:08
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PC_>>Так это нормально. А как ты хотел ? Удалить одно значение и освободить десять байт моментально ?

I>Примерно так. Есть мега-деревья, которые так и работают.

Не, они так не работают. Читать для чего делается Shrink в СУБД.

I>Я не понял, key это uint ? Контейнер для таких ключей я накидаю за полчаса с перерывом на обед


Накидай, пока стандартные структуры сливают в разы, некоторые особо неприлично в 50+ раз.
Твоя задача сохранить 20 млн пар Int32/Int32 в структуре данных в 200 мегабайт
и обеспечить быстрый поиск по такой структуре.
Структура моделирует например телефонный справочник, где ключ номер телефона, значение указатель на имя абонента.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[9]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 09:36
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Твоя задача сохранить 20 млн пар Int32/Int32 в структуре данных в 200 мегабайт


Пардон, с 200 это я загнул, 400 мегабайт.
Хотя можно и в 200, только компрессионный алгоритм сьест все профиты на быстрых вставках.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[4]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: Eugeny__ Украина  
Дата: 08.05.12 09:40
Оценка:
Здравствуйте, PC_2, Вы писали:


PC_>>>ап

WH>>Код где?

PC_>Код не опен сорц.

PC_>Опенсорснул я только одну из тестовых версий.
PC_>http://www.sql.ru/forum/actualfile.aspx?id=12509735

Я так понял, что ключи — всегда инты? Ну, так не интересно.
И уж тем более сравнение по скорости с универсальным Dictionary не совсем корректное.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[5]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 09:47
Оценка:
Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, PC_2, Вы писали:



PC_>>>>ап

WH>>>Код где?

PC_>>Код не опен сорц.

PC_>>Опенсорснул я только одну из тестовых версий.
PC_>>http://www.sql.ru/forum/actualfile.aspx?id=12509735

E__>Я так понял, что ключи — всегда инты? Ну, так не интересно.

E__>И уж тем более сравнение по скорости с универсальным Dictionary не совсем корректное.

Согласен маловато инта.
Но с другой стороны это краеугольный камень. Например чтобы хранить Гуиды 16 байт, можно брать первые четыре байта
а все остальное хранить списками колизий. Ну как самый простой вариант.
И получать теже 40-50 наносекунд на вставку, и 40-50 наносекунд на поиск...
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[9]: std::map VS Dictionary.NET VS SortedDictionary.NET VS
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.05.12 10:24
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Ikemefula, Вы писали:


PC_>>>Так это нормально. А как ты хотел ? Удалить одно значение и освободить десять байт моментально ?

I>>Примерно так. Есть мега-деревья, которые так и работают.

PC_>Не, они так не работают.


Работают. Как, кстати говоря, будет работать твой контейнер если ключи будут неуникальными ?

I>>Я не понял, key это uint ? Контейнер для таких ключей я накидаю за полчаса с перерывом на обед


PC_>Накидай, пока стандартные структуры сливают в разы, некоторые особо неприлично в 50+ раз.


Стандартные затачиваются под стандартные сценарии. Подо что ты заточил своё дерево — не ясно. По тем тестам и результатам ничего не ясно, где это можно использовать и какие у него свойства.

PC_>Твоя задача сохранить 20 млн пар Int32/Int32 в структуре данных в 200 мегабайт


То есть, ты предлагаешь задачу, которая сэкономит 100-200мб относительно твоей реализации ?

Покажи тест на .net, будем искать ошибку
Re[10]: std::map VS Dictionary.NET VS SortedDictionary.NET V
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 10:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Покажи тест на .net, будем искать ошибку


На преведущей странице есть с# код.
Кстате Джуди ареям я по предварительным данным, слил 50% по поиску.
Но выиграл в два раза по скорости вставок.
Таки дела.

20 тыс строк кода на Си и пацаны с Хевлет Паккарда всеже сделали свое дело
Чтож, будем думать.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[11]: std::map VS Dictionary.NET VS SortedDictionary.NET V
От: roro  
Дата: 08.05.12 11:51
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Ikemefula, Вы писали:


I>>Покажи тест на .net, будем искать ошибку


PC_>На преведущей странице есть с# код.

PC_>Кстате Джуди ареям я по предварительным данным, слил 50% по поиску.
PC_>Но выиграл в два раза по скорости вставок.
PC_>Таки дела.

PC_>20 тыс строк кода на Си и пацаны с Хевлет Паккарда всеже сделали свое дело

PC_>Чтож, будем думать.

Вот тест на i5, размеро слова 64 бита, i686-apple-darwin11-llvm-gcc-4.2

word size = 8 numkeys = 1000000
generate keys
insert keys first = 1799781661ll last = 1932781528ll
insert time = 0.137306005 avg = 0.000000137 memory = 18.97 mb
read time = 0.011178000 avg = 0.000000011
range time = 0.041843001 avg = 0.000000042 items = 1000000



#include "Judy.h"

#include <stdlib.h>
#include <time.h>

#define NUMKEYS 1000000

int main(int argc,char* argv[])
{
    Pvoid_t array = NULL;
    PJError_t err = 0;

    printf("word size = %lu numkeys = %d\n",sizeof(Word_t),NUMKEYS);

    Word_t* keys = malloc(NUMKEYS*sizeof(Word_t));
    Word_t* range = malloc(NUMKEYS*sizeof(Word_t));
    
    srand(clock());
    
    printf("generate keys\n");
 
    Word_t startvalue = 6094748957;
    int i = 0;
    for (i = 0; i < NUMKEYS; ++i)
    {
        keys[i] = startvalue + (i * 133);
    }
    
    printf("insert keys first = %ull last = %ull\n",keys[0],keys[NUMKEYS-1]);
    
    clock_t start,stop;

    start = clock();
    for (i = 0; i < NUMKEYS; ++i)
    {
        JudyLIns(&array,keys[i],&err);
    }
    
    stop = clock();

    Word_t memused = JudyLMemUsed(array);
    printf("insert time = %0.9f avg = %0.9f memory = %0.2f mb\n",
        (float)(stop-start)/CLOCKS_PER_SEC,
        ((float)(stop-start)/CLOCKS_PER_SEC)/NUMKEYS,
        (float)memused / 1024 / 1024
    );
    
    start = clock();
    
    for(i = 0; i < NUMKEYS; ++i)
    {
        JudyLGet(&array,keys[i],&err);
    }
    
    stop = clock();
    printf("read time = %0.9f avg = %0.9f\n",
           (float)(stop-start)/CLOCKS_PER_SEC,
           ((float)(stop-start)/CLOCKS_PER_SEC)/NUMKEYS
           );
    
    start = clock();
    
    int j = 0;
    Word_t Index = 0;
    Word_t* PValue = NULL;
    JLF(PValue,array,Index);
    while (PValue != NULL)
    {
        range[j++] = Index;
        JLN(PValue,array,Index);
    }
    
    stop = clock();
    
    printf("range time = %0.9f avg = %0.9f items = %d\n",
           (float)(stop-start)/CLOCKS_PER_SEC,
           ((float)(stop-start)/CLOCKS_PER_SEC)/NUMKEYS,
           j
    );
    
    return 0;
}
Re[12]: std::map VS Dictionary.NET VS SortedDictionary.NET V
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 12:44
Оценка:
Здравствуйте, roro, Вы писали:

Спасибо за тест!
Такой вопрос, Джуди проверяет ключи на выход за диапазон ?
Ато вроде как на .NET обертке добавление двух одинаковых ключей убило всю структуру.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[12]: std::map VS Dictionary.NET VS SortedDictionary.NET V
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 13:15
Оценка:
Здравствуйте, roro, Вы писали:

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

Word_t startvalue = 6094748957;
R> int i = 0;
R> for (i = 0; i < NUMKEYS; ++i)
R> {
R> keys[i] = startvalue + (i * 133);
R> }

R>
R>word size = 8 numkeys = 1000000
R>generate keys
R>insert keys first = 1799781661ll last = 1932781528ll
R>insert time = 0.137306005 avg = 0.000000137 memory = 18.97 mb
R>read time = 0.011178000 avg = 0.000000011
R>range time = 0.041843001 avg = 0.000000042 items = 1000000
R>


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

int _tmain(int argc, _TCHAR* argv[])
{
    //20/21/22/23/24 /25 /26 /
    //19/14/9 /6 /3.7/2.7/2.4/
    clock_t start, finish;

    keys = new uint[COUNT_KEYS];

    /*FILE* file = fopen("c:\\rand.bin", "rb");

    uint maxOffset = 0;
    
    for(uint i=1; i<COUNT_KEYS; i++)
    {
        fread(&keys[i], 4, 1, file);
    }
    
    fclose(file);*/

    uint startvalue = 6094748957;
    int i = 0;
    for (i = 0; i < COUNT_KEYS; ++i)
    {
        keys[i] = startvalue + (i * 133);
    }

    init(27);

    /*
    uint* keys = new uint[COUNT_KEYS];
    uint* values = new uint[COUNT_KEYS];
    
    for(uint i=0; i<COUNT_KEYS; i++)
    {
        keys[i] = i;
        values[i] = i;
        count1 += i;
    }
    */

    start = clock();

    //368 mb //average for 15
    //372 mb //average for 10
    //383 mb //average for 5
    //423 mb //average for 1

    //( array(4 bytes value + 2 bytes key) + block(4bytes value + 2 bytes key)
    //12 bytes

    //init(keys, values, COUNT_KEYS);

    for(uint i=0; i<COUNT_KEYS; i++)
    {
        //if(i==4688209)
        //    printf( "%2.1d\n", i);
        
        insert(keys[i], keys[i]);
        //insert(i, i);
        //m[keys[i]] = keys[i];
        
        //4688210
        
        /*        
        if(i>9918351)
        for(uint j=0; j<=i; j++)
        {
            if(getValueByKey(keys[j]) != keys[j])
            {
                printf( "Error: %2.1d %2.1d\n", getValueByKey(j), j);
                return 0;
            }
        }
        */
    }

    finish = clock();

    //delete[] values;

    printf( "Filled: %2.1d msec\n", (finish - start) );

    start = clock();

    for(uint i=0; i<COUNT_KEYS; i++)
    {
        if( getValueByKey(keys[i]) != keys[i])
        {
            printf( "Error: %2.1d %2.1d\n", getValueByKey(keys[i]), keys[i]);
        }
    }
    
    finish = clock();

    delete[] keys;
    
    printf( "Searches: %2.1d msec\n", (finish - start) );
    printf( "CountDoublePage: %2.1d\n", CountDoublePage );
    printf( "CountMultiplyPage: %2.1d\n", CountMultiplyPage );
    printf( "Double size pages: %2.1d\n", CountDoublePage * sizeof(DoublePage));
    printf( "Multiply size pages: %2.1d\n", CountMultiplyPage * sizeof(MultiplyPage));
    printf( "Size pages: %2.1d\n", CountDoublePage * sizeof(DoublePage) + CountMultiplyPage * sizeof(MultiplyPage));
    
    uint* buff = new uint[COUNT_KEYS];

    start = clock();

    uint count = getValuesByRange(buff, COUNT_KEYS, 1, 0xFFFFFFFF);
    
    finish = clock();

    printf( "Range: %2.1d msec\n", (finish - start) );

    delete[] buff;
    
    printf( "Type1: %2.1d\n", type1 );
    printf( "Type2: %2.1d\n", type2 );
    printf( "Type3: %2.1d\n", type3 );
    printf( "TypeX: %2.1d\n", typeX );
    
    //2.8 1.3

    /*
    start = clock();

    uint* buffer = new uint[COUNT_KEYS];

    int idx = getValuesByRange(buffer, COUNT_KEYS, 0, COUNT_KEYS - 1);
    
    delete[] buffer;

    finish = clock();

    printf( "Search by range: %2.1d msec\n", (finish - start) );

    destroy();

    printf( "List: %2.1d bytes\n", COUNT_KEYS*4*2);

    */

    system("pause");

    return 0;
};



64 битных ключей у меня нет, есть пока 32х битные.
Поэтому просто, для начала, взял в два раза больше ключей (2 млн вместо 1 млн).
Результаты такие:

word size = 4 numkeys = 2000000
generate keys
insert keys first = 1799781661ll last = 1932781528ll
insert time = 0.041 avg = 0.000000041 memory ~30 mb
read time = 0.003 avg = 0.000000003
range time = 0.550 avg = 0.000000550 items = 2000000

У меня для этой последовательности тоже ключи феншуйно работают
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[13]: std::map VS Dictionary.NET VS SortedDictionary.NET V
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 08.05.12 13:17
Оценка:
Процессор iCore 7,
тут добрые люди еще для семпрона Джуди протестили

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&amp;tid=708039&amp;msg=12523337
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[14]: std::map VS Dictionary.NET VS SortedDictionary.NET V
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 11.05.12 10:36
Оценка:
Здравствуйте, PC_2, Вы писали:

Попробую в ближайшие пару недель собрать поисковый движок
на базе алгоритма.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.05.12 12:52
Оценка:
Здравствуйте, PC_2, Вы писали:
Посмотри Б деревья http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.
и солнце б утром не вставало, когда бы не было меня
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 11.05.12 14:59
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, PC_2, Вы писали:

S>Посмотри Б деревья http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.


Разные Б деревья в плане скорости поиска/вставки не интересны.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: minorlogic Украина  
Дата: 11.05.12 15:35
Оценка: 1 (1)
Если поиск и вставка константные и данные отсортированны (с возможностью быстрого обхода), то это революция в CS
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 11.05.12 15:53
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Если поиск и вставка константные и данные отсортированны (с возможностью быстрого обхода), то это революция в CS


Ну да, немного занятно получилось.

Quick sort = Inserts + Full scan по сортированым данным.

Тоесть чтобы отсортировать допустим большой обьем данных,
можно вставить в структуру и сделать фуллскан и по времени даже может быть
какойто минимальный выиграш Эдакий побочный эффект алгоритма.
Правда следует отметить справедливости ради, что второй алгоритм с структурой данных,
будет требовать дополнительную память. Квик сорт же не ест доп память.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[3]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.05.12 06:47
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Serginio1, Вы писали:


S>>Здравствуйте, PC_2, Вы писали:

S>>Посмотри Б деревья http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.


PC_>Разные Б деревья в плане скорости поиска/вставки не интересны.

Ну почему же. Б+ деревья на больших данных немного уступают Хэш таблицам. При примененийй данных типа курсора
и вставок типа NavigateOrInsertDefault можно это время сократить в 2 раза. При больших данных и поиск происходит быстрее, т.к. верхние уровни находятся в кэше процессора. Так как на практике в основном происходит поиск а не вставки, то возможно дополнительно в поиску подключать и хэш таблицу уоторая бы хранила Ключ и Страницу на которой находится элемент. Это значительно сократит поиск.
и солнце б утром не вставало, когда бы не было меня
Re[4]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 09:50
Оценка:
Здравствуйте, Serginio1, Вы писали:

PC_>>Разные Б деревья в плане скорости поиска/вставки не интересны.

S> Ну почему же. Б+ деревья на больших данных немного уступают Хэш таблицам. При примененийй данных типа курсора

На больших обьемах данных у хештаблиц коллизии ростут в экспоненциальном порядке.
Это первый недостаток. Второй, они не сортируют ключи и не позволяют делать выборки по диапазону.
Но по скорости вставки/выборки разные подвиды бинарных деревьев далеко или очень далеко.
К слову сказать у меня одна из модификаций префиксных деревьев и здесь тоже можно верхние уровни
размещать в ОЗУ.

S>и вставок типа NavigateOrInsertDefault можно это время сократить в 2 раза. При больших данных и поиск происходит быстрее, т.к. верхние уровни находятся в кэше процессора. Так как на практике в основном происходит поиск а не вставки, то возможно дополнительно в поиску подключать и хэш таблицу уоторая бы хранила Ключ и Страницу на которой находится элемент. Это значительно сократит поиск.


Глянул Вашу реализацию.
Ну чисто визуально, сравните Вашу функцию поиска по ключу:

public bool NavigateKey(K key)
{
  // Устанавливаем индекс элемента в 0.
  _currentElementIndex = 0; 
  // Если есть второй уровень...
  if (_pageCount > 1)
  {
    // Перебираем грани
    int hi = _pageCount - 1;

    int lo = 0;

    while (lo <=  hi)
    {
      int i = (lo +  hi) >> 1;
      int result = _comparer.Compare(NodeArray[i].Key, key);

      if (result < 0)
        lo = i + 1;
      else
      {
        hi = i - 1;
        if (result == 0)
        {
          // Ключ найден на 2 уровне. Устанавливаем текущую 
          // страницу CurrentLeafPage.
          _currentPageIndex = i;
          CurrentLeafPage = NodeArray[_currentPageIndex].ChildPage;
          _selected = true;
          return true;
        }
      }
    }

    // Ключ не найден на 2 уровне.
    // Проверяем на возможность того, что искомый ключ – 
    // наименьший из имеющихся в объекте.
    if (hi < 0)
    {
      // Данный ключ меньше наименьшего хранимого ключа.
      // Встаем на самый первый элемент двухуровневого массива 
      _currentPageIndex = 0;
      CurrentLeafPage = NodeArray[_currentPageIndex].ChildPage;
      _selected = false;
      // Возвращаем информацию о том, что ключ не найден.
      return false;
    }
    else
    {
      // Данный ключ попадает в диапазон ключей нижележащей страницы.
      // Изменяем текущую страницу CurrentLeafPage на найденную дочернюю
      // страницу 
      CurrentLeafPage = NodeArray[_currentPageIndex].ChildPage;
      // Устанавливаем текущий индекс ключа на листовой странице в 1, 
      // т.к. 0 уже проверяли.
      _currentElementIndex = 1;
    }
  }

  // Пытаемся найти индекс искомого ключа или индекс, в котором он должен
  // был находиться.
  hi = CurrentLeafPage.Count - 1;
  lo = _currentElementIndex;

  while (lo <= hi)
  {
    int i = (lo + hi) >> 1;
    int result = _comparer.Compare(CurrentLeafPage.PageItems[i].Key, key);

    if (result < 0)
      lo = i + 1;
    else
    {
      hi = i - 1;
      if (result == 0)
      {
        // Нашли!
        _currentElementIndex = i;
        _selected = true;
        return true;
      }
    }
  }

  // Не нашли... 
  _selected = false;
  // Помещаем в _currentElementIndex позицию в которую 
  // можно добавить элемент с искомым ключом.
  _currentElementIndex = lo;
  return false;
}


И мою функцию извлечения по ключу для строк

inline uint getValueByKey(char* key, uint base)
{
    ushort* pKey = (ushort*)key;
    Info* pParentInfo = pInfoRoot;

    for(uint i=0; i<base; i++)
        pParentInfo = pParentInfo->pBlockInfos[pKey[i]];
    
    //last iteration
    return ((InfoValue*)pParentInfo)->Value;
}


Теперь чисто визуально, сколько нужно первой реализации выполнить процессорных комманд, сделать дополнительных вызовов функций, копирований и тд
и моей реализации которая извлекает значение по ключу за О(1), внезависимости там 100 ключей или 100 млрд ключей.
Количество итераций в цикле зависит от длины ключа, например для ключа в 8 символов будет всегда константно 4 итерации.

Есть еще вырожденный вариант для 32 битных ключей

inline uint getValueByKeyInt32(uint key)
{
    return (uint)pInfoRoot->pBlockInfos[key&0xFFFF]->pBlockInfos[key>>16];
}


Как видите, здесь уж совсем экономный вариант.
Поиск чуть тяжелее чем прямое взятие элемента из массива по индексу и в некоторых случаях разгоняется до абсолютно
фантастических 2 наносекунд на один поиск (500 млн поисков в секунду).
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[5]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 11:21
Оценка:
Здравствуйте, PC_2, Вы писали:



PC_>Теперь чисто визуально, сколько нужно первой реализации выполнить процессорных комманд, сделать дополнительных вызовов функций, копирований и тд

Ну я предлагал использовать Хэш таблицу для ключей в котором хранится ключ и страница Б+ дерева Что бы производить поиск не по дереву а на странице.
Но это не суть. Проблема при увеличении объемов данных не попадающих в Кэш процессора сильно уже зависит от медленной памяти. А соотношение времени вставки поиска Б+ деревья и Хэш таблицы остаются константными. Кстати если видел реализацию NavigateOrInsertDefault то там запоминаентся текущая позиция и при изменении значения вторичный поиск не производится. А по поводу выборки Б+ деревьев, то это прохождение по масииву. Обычно нужны выборки по диапозону, поиск на меньше или больше значения без равно итд. Все то, что используется в Базе. А также сравнение двух таблиц по индексам где сравнение идет не по поиску ключа а по сравнению текущих значений и продвижению по таблице с меньшим ключем, при равном двигаются оба курсора.
и солнце б утром не вставало, когда бы не было меня
Re[5]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 11:38
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Serginio1, Вы писали:


PC_>>>Разные Б деревья в плане скорости поиска/вставки не интересны.

S>> Ну почему же. Б+ деревья на больших данных немного уступают Хэш таблицам. При примененийй данных типа курсора

PC_>На больших обьемах данных у хештаблиц коллизии ростут в экспоненциальном порядке.

В этой же статье есть Хэш таблица массив данных которых поделен на две части во второй хранятся коллизии и при заполнении которой размер таблицы увеличиваются в 2 раза и перезаполняются. Соотношение при полном заполнении заполненных в первой части к количеству в кчасти хранения коллизий постоянно. Кстати в нетовской реализации существует две таблицы в первой храняться данные ссылающиеся на вторую таблицу. Коллиции соединяюся односвязным списком как и свободные места. И по сути индентичен моей таблице. Перестройка таблицы происходит при полном заполнении таблицы. Первый нетовский вариант был весьма неудачен.
и солнце б утром не вставало, когда бы не было меня
Re[6]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 11:39
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, PC_2, Вы писали:

PC_>>Теперь чисто визуально, сколько нужно первой реализации выполнить процессорных комманд, сделать дополнительных вызовов функций, копирований и тд
S> Ну я предлагал использовать Хэш таблицу для ключей в котором хранится ключ и страница Б+ дерева Что бы производить поиск не по дереву а на странице.

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

S>Но это не суть. Проблема при увеличении объемов данных не попадающих в Кэш процессора сильно уже зависит от медленной памяти. А соотношение времени вставки поиска Б+ деревья и Хэш таблицы остаются константными.


Константно медленными.

S>Кстати если видел реализацию NavigateOrInsertDefault то там запоминаентся текущая позиция и при изменении значения вторичный поиск не производится. А по поводу выборки Б+ деревьев, то это прохождение по масииву.


Обычная оптимизация, что называется первое что пришло в голову.
Догадываюсь что это работает только для последовательного доступа по ключам.
Random выборки ближе к реалиям и более интересны.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[6]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 11:44
Оценка:
Здравствуйте, Serginio1, Вы писали:

Было бы интересно потестировать Вашу реализацию, на двух простеньких бенчмарках.
Результаты бенчмарков здесь http://www.sql.ru/blogs/stebelek/1267, код бенчмарков можно найти в этой теме на
преведущих страницах.

Пока что майкрософтовские красно-черные деревья отстали в среднем в 20-30 раз по каждой позиции.
И на 20%-30% по памяти.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[7]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 11:47
Оценка:
Здравствуйте, PC_2, Вы писали:


PC_>Все эти алгоритмические симбиозы, добавляют процессорных комманд. Если Вы решили использовать хештаблицу,

PC_>то отработка хешфункции для строки будет вам стоить до 50 наносекунд и пару сотен процессорных комманд.
PC_>Еще добавите какихто ифов, какойто счетчик в цикле, лишний переход по указателю функции и снова десятки наносекунд,
PC_>десятки процессорных комманд. Потом все суммируете и получаете результат.
Да все это пшик по сравнению к доступу к медленной памяти.

PC_>Думаю эта реализация может себя оправдать, например при работе с диском, когда временем процессора можно

PC_>принебречь по сравнению с временем работы доступа к диску.
Обычно данные кэширутся даже на файловом уровне.
S>>Но это не суть. Проблема при увеличении объемов данных не попадающих в Кэш процессора сильно уже зависит от медленной памяти. А соотношение времени вставки поиска Б+ деревья и Хэш таблицы остаются константными.

PC_>Константно медленными.

Да нет где то в 4 раза Б+ деревья медленнее хэш таблиц.
S>>Кстати если видел реализацию NavigateOrInsertDefault то там запоминаентся текущая позиция и при изменении значения вторичный поиск не производится. А по поводу выборки Б+ деревьев, то это прохождение по масииву.

PC_>Обычная оптимизация, что называется первое что пришло в голову.

PC_>Догадываюсь что это работает только для последовательного доступа по ключам.
PC_>Random выборки ближе к реалиям и более интересны.
Нужно отталкиваться от реалий. Я уже давно занимаюсь БД а там есть и рандомные слияния с использованием ХЭШ таблиц, и джойны с использованием отсортированных данных. Но если Б+ деревья отстают от хэш таблиц в 4 раза то сокращение в 2 раза с использованием NavigateOrInsertDefault уже становится соизмеримыми. Но это иследования 8 летней давности. Сейчас и изменением сорости памяти может сильно поменяться. Пока 1С мое все.
и солнце б утром не вставало, когда бы не было меня
Re[7]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 11:52
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Serginio1, Вы писали:


PC_>Было бы интересно потестировать Вашу реализацию, на двух простеньких бенчмарках.

PC_>Результаты бенчмарков здесь http://www.sql.ru/blogs/stebelek/1267, код бенчмарков можно найти в этой теме на
PC_>преведущих страницах.

PC_>Пока что майкрософтовские красно-черные деревья отстали в среднем в 20-30 раз по каждой позиции.

PC_>И на 20%-30% по памяти.
Там есть реализация Б+ деревьев. Там переделывать вроде ничего не надо попробуй ее. Все таки красночерные деревья достаточно медленные я их сравнивал правда давно. Прежде всего из-за скорости поиска. Так оптимальны на тот момент для интов размер страницы был равен 64 элемента. А вот страницы верхнего уровня увеличены до 256 можно было и больше и связано именно с поиском. Чем больше страница тем быстрее поиск.
и солнце б утром не вставало, когда бы не было меня
Re[8]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 11:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Да все это пшик по сравнению к доступу к медленной памяти.


Я думаю ин-мемори бенчмарки должни все расставлять на свои места. Сложно анализировать алгоритмы
на квантовом уровне. У меня если рандом ключи, доступ 40 наносекунд, а если последовательно то 3-5 наносекунд.
Тоже творится и в деревьях, ток им еще по нолику минимум дописывать.
Процессор довольно сложная штука, с блоком предсказаний, разной по тяжести процессорных комманд,
разной работой кешей процессора, доступом к ОЗУ и тд.
Вообщем то что намерял — опубликовал.

S> Да нет где то в 4 раза Б+ деревья медленнее хэш таблиц.

А у меня алгоритм еще в 3-4 раза быстрее, Хештаблиц, итого Б деревья отстают как раз std::map овские 20-30 раз.

S> Нужно отталкиваться от реалий. Я уже давно занимаюсь БД а там есть и рандомные слияния с использованием ХЭШ таблиц, и джойны с использованием отсортированных данных. Но если Б+ деревья отстают от хэш таблиц в 4 раза то сокращение в 2 раза с использованием NavigateOrInsertDefault уже становится соизмеримыми. Но это иследования 8 летней давности. Сейчас и изменением сорости памяти может сильно поменяться. Пока 1С мое все.


1С не интересно
Возвращайтесь к фундаментальным алгоритмам, прогресс не стоит на месте
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[8]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 11:55
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Там есть реализация Б+ деревьев. Там переделывать вроде ничего не надо попробуй ее.


Мне не интересно мерять.
Нет никакой интриги, всеравно медленно.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[9]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 12:06
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Serginio1, Вы писали:


S>>Да все это пшик по сравнению к доступу к медленной памяти.


PC_>Я думаю ин-мемори бенчмарки должни все расставлять на свои места. Сложно анализировать алгоритмы

PC_>на квантовом уровне. У меня если рандом ключи, доступ 40 наносекунд, а если последовательно то 3-5 наносекунд.
PC_>Тоже творится и в деревьях, ток им еще по нолику минимум дописывать.
PC_>Процессор довольно сложная штука, с блоком предсказаний, разной по тяжести процессорных комманд,
PC_>разной работой кешей процессора, доступом к ОЗУ и тд.
PC_>Вообщем то что намерял — опубликовал.

Там немного другие параметы. Первое это доступ к данным которые находятся в Кэше процессора. Самый быстрый вариант.
Второе это когда данные не попадают в Кэш, но находятся рядом за счет использования чтения памяти DDR и ширины шины памяти.
Поэтому на больших данных быстрее может быть моя Хэш таблица а не нетовская. Там нужно делать как минимум два перехода в моей минимум один раз.
и солнце б утром не вставало, когда бы не было меня
Re[9]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 12:17
Оценка:
Здравствуйте, PC_2, Вы писали:


S>> Да нет где то в 4 раза Б+ деревья медленнее хэш таблиц.

PC_>А у меня алгоритм еще в 3-4 раза быстрее, Хештаблиц, итого Б деревья отстают как раз std::map овские 20-30 раз.

Кстати когда я написал статью и показал, что моя хэш таблица может быть в 4 раза быстрее стандартной это мало кого заинтересовало.
Опять же моя хэш таблица быстрее текущей в те же 2 раза за счет курсрности. Так что твоя хэш таблица быстрее ненамного моей. А люди будут пользоватся стандартными. Хотя если честно мне интересен принцип такого ускорения.
и солнце б утром не вставало, когда бы не было меня
Re[10]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 12:23
Оценка:
Здравствуйте, Serginio1, Вы писали:

Вам нужно перемерять свой алгоритм.
Дело в том, что если Вы тестировали его еще на первых версиях Фреймворка, то там
были малооптимизированые версии. Я вот гонял последнюю их хештаблицу в фреймворке 3.5,
то эта работает весьма прилично. Скажем так, последняя ихняя версия отстала от моей всего в 2-3 раза.
Ну и плюс у меня сортированные ключи, тоесть можно делать выборки по диапазону.
А в майкрософтовской — нет. Тоесть функционал неэквивалентен, но по скорости весьма прилично.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[10]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 12:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Кстати когда я написал статью и показал, что моя хэш таблица может быть в 4 раза быстрее стандартной это мало кого заинтересовало.

S>Опять же моя хэш таблица быстрее текущей в те же 2 раза за счет курсрности. Так что твоя хэш таблица быстрее ненамного моей. А люди будут пользоватся стандартными. Хотя если честно мне интересен принцип такого ускорения.

Ну и плюс С# vs C++. Такие низкоуровневые вещи не имеем смысла писать на управляемом языке.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[11]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 12:38
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Serginio1, Вы писали:


PC_>Вам нужно перемерять свой алгоритм.

PC_>Дело в том, что если Вы тестировали его еще на первых версиях Фреймворка, то там
PC_>были малооптимизированые версии. Я вот гонял последнюю их хештаблицу в фреймворке 3.5,
PC_>то эта работает весьма прилично. Скажем так, последняя ихняя версия отстала от моей всего в 2-3 раза.
PC_>Ну и плюс у меня сортированные ключи, тоесть можно делать выборки по диапазону.
PC_>А в майкрософтовской — нет. Тоесть функционал неэквивалентен, но по скорости весьма прилично.

Так я про 3.5 и говорю. Они по всем алгоритмам схожи с моей. Я даже сравнивал их. Моя быстрее там, где нет лишнего рехеша, т.к. моя перезаполняется при заполнении части таблицы с коллизиями, а нетовская при полном заполнении. Ну и моя была раньше.
Если использовать запоминание позиции при поиске, то при модификации время уменьшается в 2 раза.
На больших данных не попадающих в кэш моя таблица тоже начинает быстрее работать, т.к. данные находятся рядом.
По поводу сравнения интов и строк. Когда мы начинаем сравнивать строки( а это основная масса данных), то разница в скорости быстро сокращается, т.к. основное время уходит на сравнение строк и хэширование строки.
и солнце б утром не вставало, когда бы не было меня
Re[11]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 12:44
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Serginio1, Вы писали:


S>> Кстати когда я написал статью и показал, что моя хэш таблица может быть в 4 раза быстрее стандартной это мало кого заинтересовало.

S>>Опять же моя хэш таблица быстрее текущей в те же 2 раза за счет курсрности. Так что твоя хэш таблица быстрее ненамного моей. А люди будут пользоватся стандартными. Хотя если честно мне интересен принцип такого ускорения.

PC_>Ну и плюс С# vs C++. Такие низкоуровневые вещи не имеем смысла писать на управляемом языке.

А начем мне писать если я использую C#. Там кстати из за эффекта оптимизации для сборки мусора старших поколений, идет лишние действия по запоминанию этих объектов которые сильно тормозят процесс после сборки мусора. Во второй версии NET они подправили, но не сильно, а в 4 уже не тестил http://rsdn.ru/forum/dotnet/415352.1.aspx
Автор: Serginio1
Дата: 20.10.03

Поэтому в Net предпочтительней использовать массивы а не списки.
и солнце б утром не вставало, когда бы не было меня
Re[12]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 12:44
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Так я про 3.5 и говорю. Они по всем алгоритмам схожи с моей. Я даже сравнивал их. Моя быстрее там, где нет лишнего рехеша, т.к. моя перезаполняется при заполнении части таблицы с коллизиями, а нетовская при полном заполнении. Ну и моя была раньше.

S>Если использовать запоминание позиции при поиске, то при модификации время уменьшается в 2 раза.
S>На больших данных не попадающих в кэш моя таблица тоже начинает быстрее работать, т.к. данные находятся рядом.
S>По поводу сравнения интов и строк. Когда мы начинаем сравнивать строки( а это основная масса данных), то разница в скорости быстро сокращается, т.к. основное время уходит на сравнение строк и хэширование строки.

Попробуйте сделать вот такой бенчмарк.
http://www.sql.ru/blogs/stebelek/1269

Тест не должен быть рафинированным, под курсор.
Должни рассматриватся в комплексе несколько параметров поиск/вставка/память,
природа ключей — рандом, последовательные.

ЗЫ: Скачал Ваш проект, к сожалению он не открылся на двух машинах (студия экспресс и ультимейт).
Просит сконвертировать, потом какието ошибки и отказывается открывать. Нужен фикс наверное.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[12]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 12:47
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> А начем мне писать если я использую C#.


Пишите на Си. Я тоже по основному месту работы уж 10 лет пишу как под дот нет,
но этот проект просто обязан быть на чистом Си/Си++
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[13]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.05.12 12:54
Оценка:
Здравствуйте, PC_2, Вы писали:



PC_>ЗЫ: Скачал Ваш проект, к сожалению он не открылся на двух машинах (студия экспресс и ультимейт).

PC_>Просит сконвертировать, потом какието ошибки и отказывается открывать. Нужен фикс наверное.
А можно на ты. Устал я от "Вы" и не ощущаю себя. Этот проект писался под бету VS 2005. Которую они потом сильно поменяли к релизу.
Там надо скопировать исходники и на них потестить. Я то программирую на 1С, а C# это так развлечение.
и солнце б утром не вставало, когда бы не было меня
Re[14]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 14.05.12 13:08
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Там надо скопировать исходники и на них потестить. Я то программирую на 1С, а C# это так развлечение.


Реализация, не сомневаюсь, не плохая и работа была проделана не малая.
Но конечно смущает Шарп, это первое. А второе — заезженые Хештаблицы и Б деревья.
Не знаю чем они могут еще удивить.

Сейчас у меня стоит таже проблема, кому нужен высокоскоростной алгоритм — вообщемто никому.
Но задачка черезвычайно интересная с точки зрения мало набиваем код, много думаем, строим графики, проверяем гипотезы.

На счет применения. Думаю одним из простых, на базе кластера из хешареев можно было бы построить
фулл текст энжин, аля Сфинкс, только вот скорость индексирования у него была бы не 10-15 мегабайт
на поток, а скажем 50-100 мб и мощность поиска по словоформам около миллиона в секунду.
Както так, больше пока ничего не придумывается.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[13]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Eugeny__ Украина  
Дата: 14.05.12 23:22
Оценка: +1
Здравствуйте, PC_2, Вы писали:

PC_>Тест не должен быть рафинированным, под курсор.


А рафинирование под инт? Я вот хочу любой объект, любой структуры. Например — строка рандомной длины. От байта до мегабайта. Для реальных задач — пойдет. Или, может, кастомную структуру?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[14]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 15.05.12 08:12
Оценка:
Здравствуйте, Eugeny__, Вы писали:

E__>А рафинирование под инт? Я вот хочу любой объект, любой структуры. Например — строка рандомной длины. От байта до мегабайта. Для реальных задач — пойдет. Или, может, кастомную структуру?


Посмотрите внимательней реализацию Джуди да и любой Хештаблицы.
По сути Hastable<String,String> = Простая хешфункция + Hastable<Int,Int> + Списки коллизий

Я правда хочу придумать что-то поинтеллектуальней.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[5]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: roro  
Дата: 15.05.12 11:08
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Есть еще вырожденный вариант для 32 битных ключей


PC_>
PC_>inline uint getValueByKeyInt32(uint key)
PC_>{
PC_>    return (uint)pInfoRoot->pBlockInfos[key&0xFFFF]->pBlockInfos[key>>16];
PC_>}
PC_>



судя по коду нужно зарезервировать 16 gb памяти, чтобы адресовать все доступные ключи

65536 * 65535 * sizeof(uint)
Re[15]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.05.12 11:15
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, Eugeny__, Вы писали:


E__>>А рафинирование под инт? Я вот хочу любой объект, любой структуры. Например — строка рандомной длины. От байта до мегабайта. Для реальных задач — пойдет. Или, может, кастомную структуру?


PC_>Посмотрите внимательней реализацию Джуди да и любой Хештаблицы.

PC_>По сути Hastable<String,String> = Простая хешфункция + Hastable<Int,Int> + Списки коллизий

PC_>Я правда хочу придумать что-то поинтеллектуальней.

А сортировка строк при этом сохранится?
и солнце б утром не вставало, когда бы не было меня
Re[6]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 15.05.12 11:17
Оценка:
Здравствуйте, roro, Вы писали:

R>судя по коду нужно зарезервировать 16 gb памяти, чтобы адресовать все доступные ключи

R>65536 * 65535 * sizeof(uint)

Существуют разные техники компрессий для Trie деревьев.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[16]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 15.05.12 11:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

PC_>>Я правда хочу придумать что-то поинтеллектуальней.

S> А сортировка строк при этом сохранится?

Вот потому хочется придумать чтото получше
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[7]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: roro  
Дата: 15.05.12 11:25
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, roro, Вы писали:


R>>судя по коду нужно зарезервировать 16 gb памяти, чтобы адресовать все доступные ключи

R>>65536 * 65535 * sizeof(uint)

PC_>Существуют разные техники компрессий для Trie деревьев.


Ну тогда нипонятно, оператор [] перегружен и выбирает индексы с распаковкой или там сейчас реально 16 гб?
Re[8]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 15.05.12 11:41
Оценка:
Здравствуйте, roro, Вы писали:

R>Ну тогда нипонятно, оператор [] перегружен и выбирает индексы с распаковкой или там сейчас реально 16 гб?


Оператор [] не перегружен.
Разреженные массивы мержатся на одной области памяти, "упаковываются" специальным алгоритмом.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[9]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 15.05.12 11:48
Оценка:
Здравствуйте, PC_2, Вы писали:

Вот есть иллюстрация. Только я не знаю или до меня это придумали
Читал что существует около 20 разных техник компрессий в Джуди.



Это общая концепция, есть еще секреты.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[10]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 15.05.12 12:43
Оценка:
Но сразу скажу, кто захочет применить сей метод, что он в общем случае очень сырой и нежизнеспособен.
Как и выложеный исходник. Мне понадобилось полтора года, десятки графиков, тестовых проектов и новых идей и приемчиков,
чтобы взрастить с такой простой идеи полноценный алгоритм который обходит в разы
все классические алгоритмы

Так что кто заинтересован в коммерческом использовании сих идей,
то лучше сразу обратится к автору дабы мигом пролететь над всеми граблями
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[2]: std::map VS Dictionary.NET VS SortedDictionary.NET VS HArray
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.05.12 01:35
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Если поиск и вставка константные и данные отсортированны (с возможностью быстрого обхода), то это революция в CS


А если ник PC_2, то еще и крутой трешовый юмор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.