Здравствуйте, Alexander_fx, Вы писали:
A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных.
У тебя расход памяти по скромной оценке около 1гб по скромной оценке. К слову, физической памяти у твоего процесса никогда столько не будет. Т.е. данные будут постоянно перекачиваться между диском и физической памятью. Так работает виртуальная память. Дополнительно проблемы у GC, из за фрагментации и прочих вещей.
Независимо от стурктуры данных, у тебя уже тупик нарисовался. В твоем условии нет сведений, как можно выйти из этого тупика.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Some calculations, such as financial, require a large number of digits but cannot tolerate rounding errors. Ф>>Decimal is not a floating-point data type.
I>Я в курсе. А разве где то было указано, что есть вот такие особенные вычисления ?
Поле "цена" — это уже финансовые вычисления. Вычисления начинаются в момент приведения типа (Log10 -> Log2), т.е. когда ты сохраняешь эту цену как double. До и после этого скорее всего будут такие операции как суммирование, умножение (n*price, percents * AmountOfTransaction, ... etc), и я очень надеюсь, что они происходят не с даблами.
Даже если это покупка или продажа акций, то уже будет и сумма, и удержание процентов с операции (умножение), и вычитание: Account -= AmountOfTransaction.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Ikemefula, Вы писали:
I>Ты лучше расскажи, как именно в buffer pool будет храниться миллиард строк. Мне непонятно, что значит "выделяем сегменты", "наворачиваем коллекции", "заполняем структурами"
Вот именно за этим я и отослал к книжке Бена Ватсона. Смысл обсуждать сложные вещи, если надо сперва пересказать азбуку оптимизации по хардкору?
Ну, т.е. любая попытка объяснения сведётся к тому, что сначала надо будет объяснять более базовые вещи и так до Рихтера.
I>Вот с серилизацией все понятно, всё само. А как в buffer pool ?
Смысл такой: у тебя есть возможность динамически аллоцировать/освобождать сегменты (массивы определённой длины) без создания дополнительной нагрузки на GC — освобождённые инстансы забираются обратно в пул. Количество этих сегментов — пока не исчерпается адресное пространство процесса / VM.
Всё, как их использовать — целиком и полностью на тебе.
На практике надо _очень_ хорошо понимать задачу, типовые сценарии и критерии по производительности. В общем, как и везде, хочешь выжать больше — будь готов жертвовать чем-то другим, например, простотой кода или универсальностью структур данных.
Здравствуйте, netch80, Вы писали:
A_>>>может есть специализированные библиотеки сторонних производителей. A_>>>или может кто то видел библиотеки для работы с большими обьемами данных.
I>>У тебя расход памяти по скромной оценке около 1гб по скромной оценке. К слову, физической памяти у твоего процесса никогда столько не будет.
N>Вы меня уж простите за влезание в непрофильный форум в воскресенье, но почему не будет?
Это я погорячился. C учетом дополнения "В принципе, с учетом "в текущей машине 64 гига. текущая реализация в пике кушает 25 гигов.""
Память вроде как должна быть, на худой конец, винду можно принудить её использовать.
I>> Т.е. данные будут постоянно перекачиваться между диском и физической памятью. Так работает виртуальная память. Дополнительно проблемы у GC, из за фрагментации и прочих вещей. N>Это же всё измеряется?
Конечно.
I>>Независимо от стурктуры данных, у тебя уже тупик нарисовался. В твоем условии нет сведений, как можно выйти из этого тупика.
N>
В принципе, с учетом "в текущей машине 64 гига. текущая реализация в пике кушает 25 гигов.", можно выжимать биты.
Здравствуйте, Ikemefula, Вы писали:
I>Похоже, кого то вопрос задел за живое. Так и говори — никак.
Не угадал. Смысл повторять то, что уже отвечал, да ещё и без сарказма? Скучно же.
Я всё расписал в стартовом ответе, если потерял нить обсуждения:
А. Только managed code
* используем buffer pool, выделяем из него сегменты, наворачиваем поверх коллекцию или stream, заполняем структурами. Vladek выше давал ссылку на RecyclableMemoryStream, там в документашке всё есть как бы.
* других вариантов без unmanaged нет. Надо объяснять почему?
Б. Количество сегментов настолько большое, что они сами по себе создают gc pressure. Правда, для этого надо выделить гигов эдак 10-20 (считаем сегменты в 65к), активно насиловать gen2 и использовать client gc, т.е. быть полным злым буратиной.
Ну ок, лечится элементарно: перекидываем буферы в MMF/свой unmanaged pool.
В. Объекты не влезают в память. Тут как бы очевидно — любая in-process db/distributed cache (смотря по обстоятельствам)
Собственно вопрос на миллион долларов: куда тут приткнуть pile? И нафига дёргаться _до_ момента, когда мы действительно уткнёмся в GC?
I>Спасибо, но я не спрашивал у тебя советов, как разгрузить GC. Давать советы, когда тебя не просили — хамство.
Ну да, любой врач, который лечит болезнь, а не жалобы по определению хам. Так и живём
Ну и поскольку я сегодня добрый, я не буду напоминать про "К слову, физической памяти у твоего процесса никогда столько не будет". Хотя надо бы
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>Время по профайлеру не выходит за определеные рамки, 15-30mc. Это про Pile. Стало быть с нагрузкой все в порядке — она под контролем. S>Это неимоверно много. Сопоставимо с worst case для realtime gc или с обычными in-mem db (как пример — Redis или VelocityDB). Нынче в моде 10e6 rps, какие миллисекунды?
S>Тем более для классической CDN-задачи, по крайней мере текущее обсуждение всё больше в эту сторону сворачивает.
S>>>1. Люди не читали матчасть, пока не стало поздно. За такими постами имеет смысл следить только ради "смотри, как делать не надо". Потому что если читать — подобные приседания за очень редкими исключениями не нужны. У вас же получилось I>>Не пойму, чего именно у меня получилось, не смочь в гц, следить за постами или редкое приседание ? S>Не, в том смысле, что у тебя всё сработало без приседаний с unmanaged-пулом.
I>>И тут снова не ясно, каким чудом хранить строки без этой самой серилизации в managed варианте S>Ну так не надо стандартные строки пихать куда не лезут. Свой стек аля Text.Formatting и вперёд. Ну да, hiperf небесплатный и никогда им не был, какие ещё варианты могут быть-то?
Voobshe neponyatno chto vy sravnivaete. Kakoi Redis? Vam Redis dast original "Person" ili storku kotoruju nado parsit?
Pile legko daet 2+M cache hits/sec i pri etom CPU <25%. Eto uje objekti predmetnoi oblasti a ne string.
Stringi pile mojet dat 10,000,000/sec , no eto stroki. Unmanaged pool nichem ne pomojet ibo v nem nevozmojno xranit objekti predmetnoi oblasti prosto tak.
Mojno sdleat spezialnoe xranilishe na C++ i xranit naprimer Person v unmanaged pamyati, no eto ochen slojno i ne opravdano. A chto esli mne nado pomenyat polya v Person?
Pile kak raz nujen dlya togo chtobi xranit DOMAIN OBJECTS. Realno, nash HTTP MVC stack + filters+security+CSRF etc.. tyanet okolo 50,000 req/sec — eto soljnix business zaprosov, s traversingom
sozialix svazei druzei, inogda po 10 chelovek vglub'.
Здравствуйте, Ikemefula, Вы писали:
I>Поле цена это просто поле цена. Я например год работал на проекте, где лет пять до того цену хранили даблом. И никаких проблем с погрешностью не было. Не просто никаких, а абсолютно никаких. I>Так что не все вычисления можно и нужно относить к 'финансовым'.
Ты ведь зачем-то используешь double вместо float. То есть какая-то зависимость от погрешности есть.
Умные люди в больших проектах на таких вот ошибках вычисления с плавающей точкой делают хорошие деньги, выводя из оборота тысячные доли копеек.
Кроме того GetHashCode() вычисляет хэш по байтам double'а (приводя Double* к Int64*), а, значит, ошибка с плавающей точкой приведёт тебя к тому, что ты не сможешь найти значение в словаре по указанному значению (будет 9,99999999999998 вместо 10.0 и т.д.).
Если же ты ищешь по тем самым Double'ам, которые сохранены у тебя в твоих объектах — фактически, используешь их как индексы, то... я бы за такое бил по рукам, но в условиях дефицита памяти на что люди только не идут. Как я писал выше, для Dictionary не важно — индексируешься ты по Double или по Int64. Но у тебя чертовски толстая коллекция с вероятностью коллизии хэшей 1/143, что в общем-то дохрена. Поэтому я бы, на твоём месте, разбил словарь на кучку более мелких, по ценовым диапазонам — и будет тебе счастье.
Но я всё же рекомендую переосмыслить подход к индексации записей.
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, Sinix, Вы писали:
I>>Что хранить — понятно. Как сохранить в твой буфер миллиард строк ? S>кэп: ну а зачем тебе непрерывный буфер, если под капотом можно работать с сегментами?
Похоже, кого то вопрос задел за живое. Так и говори — никак.
S>Для по максимуму разгрузить GC — вэлкам в MappedMemoryFiles с его ReadArray<T>, или извращаемся с unmanaged heap по вкусу. S>Также см. главу два (Garbage Collection) в Writing High-Performance .NET Code, она практически вся про сабж.
Спасибо, но я не спрашивал у тебя советов, как разгрузить GC. Давать советы, когда тебя не просили — хамство.
I>Время по профайлеру не выходит за определеные рамки, 15-30mc. Это про Pile. Стало быть с нагрузкой все в порядке — она под контролем.
Это неимоверно много. Сопоставимо с worst case для realtime gc или с обычными in-mem db (как пример — Redis или VelocityDB). Нынче в моде 10e6 rps, какие миллисекунды?
Тем более для классической CDN-задачи, по крайней мере текущее обсуждение всё больше в эту сторону сворачивает.
S>>1. Люди не читали матчасть, пока не стало поздно. За такими постами имеет смысл следить только ради "смотри, как делать не надо". Потому что если читать — подобные приседания за очень редкими исключениями не нужны. У вас же получилось I>Не пойму, чего именно у меня получилось, не смочь в гц, следить за постами или редкое приседание ?
Не, в том смысле, что у тебя всё сработало без приседаний с unmanaged-пулом.
I>И тут снова не ясно, каким чудом хранить строки без этой самой серилизации в managed варианте
Ну так не надо стандартные строки пихать куда не лезут. Свой стек аля Text.Formatting и вперёд. Ну да, hiperf небесплатный и никогда им не был, какие ещё варианты могут быть-то?
Здравствуйте, Alexander_fx, Вы писали:
M>>Полюбопытствую: какое сейчас время запроса? И на сколько быстрее хочется?
A_>>> 30 000 000 экземпляров записей M>>На 32-х разрядных ДотНетах можно и OutOfMemory схватить, если такое количество держать в памяти. M>>Так. К слову.
A_>32 бита — забыл лет 5 назад. в текущей машине 64 гига. A_>текущая реализация в пике кушает 25 гигов.
Какие типичные операции ? Что показывает профайлер ? Где именно тормозит твое решение ?
Какие издержки на GC ?
Сколько физической памяти винда отдаёт твоему процессу ?
I>Если вычисления сделаны одинаковые, то и значения будут идентичные. А если ты в одном месте считашь логариф, а в другом делаешь ровно то же, но через сложение-умножение-деление, то результаты будут с погрешностью. I>Потому нет смысла говорить про децимал, пока нет ясности с операциями. I>Если все условия соблюдены, то дабл может дать внятную оптимизацию и по памяти и по быстродействию !
И зачем мне это курить, если ты сам подтверждаешь мои слова? Single даст ещё большую оптимизацию и по памяти и по быстродействию. И если ты разрабатываешь приложение, которое работает с живыми деньгами, то завязываться на то, что за всё время жизни алгоритмы получения этих циферок не поменяются — не очень хорошая мысль.
I>Откуда 1/143 ?
Весьма грубая прикидка сделанная на основе того, что в коллекции 30 000 000 записей и предположения, что на этот момент коллизий нет (что наверняка противоречит действительности). Понятно, что в итоге она стремится к 0,99999999976716935634613037109375, так как мы вычисляем 32-битный хэш от 64-битного целого. Так что корзины у автора уже наверняка формируются. Будет больше записей — будет ещё больше корзин, поиск по словарю замедлится ещё сильнее.
I>Спасибо, я передам топикстартеру.
Спасибо. (=
P.S. Ты так отстаивал текущую модель, что я не обратил внимания.
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, pagid, Вы писали:
P>Не могут деньги со счетов потечь по этой причине. Если конечно в банковской бд не хранить суммы с точность превышающей копейки, если всегда округлять по одним правилам. Но это уже несколько о другом.
Если софтина дает гарантии корректной работы, то совершенно не важно, как всё хранится — синглом или децималом.
Проблема возникает тогда, когда люди пытаются делать "как правильно". Тогда с равной вероятностью надо ожидать проблем и от дабла и от децимала.
Здравствуйте, pagid, Вы писали:
P>Не могут деньги со счетов потечь по этой причине. Если конечно в банковской бд не хранить суммы с точность превышающей копейки, если всегда округлять по одним правилам. Но это уже несколько о другом.
Какие округления, человек?
Речь как раз о них. В банковских системах не округляют суммы и хранятся они с максимальной точностью (для чего и используется Decimal). Как только ты начинаешь округлять что либо, остаток остаётся "бесхозным". С точки зрения программиста, он просто отбросил лишнее. Но это "лишнее" имеет вполне материальное представление в твёрдой валюте, лежащей в сейфах. И вот когда об этом прознает достаточно умный и талантливый специалист, он сумеет вывести эти повисшие в воздухе остатки себе в карман. И если речь идёт о десятых долях копейки (цента, евроцента, и т.д.), то помноженные на миллионы запросов, они превращаются в мощный финансовый поток.
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, Albeoris, Вы писали:
A>Какие округления, человек?
И с какой точностью ты видишь суммы в банковской выписке?
A>В банковских системах не округляют суммы
Это в какой стране так? господа, разработчики банковского софта, подскажите пожалуйста.
Если такое где-то есть, то там конечно возможны интересные эффекты.
A> и хранятся они с максимальной точностью (для чего и используется Decimal)
А памяти оперативной хватает, или как только разделишь $1 на 3 для обеспечения хранения одной суммы приходится приходится дисковые массивы использовать, их надеюсь хватает?
A> И вот когда об этом прознает достаточно умный и талантливый специалист, он сумеет вывести эти повисшие в воздухе остатки себе в карман. И если речь идёт о десятых долях копейки (цента, евроцента, и т.д.), то помноженные на миллионы запросов, они превращаются в мощный финансовый поток.
Детский сад.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
S>>>Вот именно за этим я и отослал к книжке Бена Ватсона. Смысл обсуждать сложные вещи, если надо сперва пересказать азбуку оптимизации по хардкору? I>>Ты сказал следующее "других вариантов без unmanaged нет". Вот я и думаю, как это относится к Pile ? Вот он умеет хранить миллиард строк. S>Дык неэффективно же, через сериализацию. Вдобавок, сами сегменты хранятся как managed byte[] и по-прежнему создают нагрузку на GC.
Люди пишут, что при 80+ГБ объектов в памяти, на GC уходит ~15ms. Вполне нормально, имхо.
Всегда есть менее универсальное решение, которое будет быстрее. Суть в том, что этот Pile как раз претендует на универсальность засчёт некоторого снижения производительности. Если верить их тестам, то не на самой мощной машине там вполне приемлимый перформанс (~500K/sec write, 700K/sec read при объекте размером 75 байт) . Зато не надо подгонять данные под хранилище, что бывает достаточно важным в некоторых задачах.
Здравствуйте, Sinix, Вы писали:
I>>Время по профайлеру не выходит за определеные рамки, 15-30mc. Это про Pile. Стало быть с нагрузкой все в порядке — она под контролем. S>Это неимоверно много. Сопоставимо с worst case для realtime gc или с обычными in-mem db (как пример — Redis или VelocityDB). Нынче в моде 10e6 rps, какие миллисекунды?
Миллиард строк здесь нигде не фигурирует. Вобщем, если других замеров нет, то можно и закончит
S>>SQLite может хранить всю свою базу только в памяти. S>>Единственный нюанс, если мне не изменяет склероз, писать в нее обязательно надо в транзакции (в противном случае, на каждую запись SQLite сама открывает/закрывает транзакцию).
S>Про транзакции не скажу, но соединение необходимо постоянно держать открытым. Вообще говоря, sqlite, даже в памяти, не самое лучшее решение для данной задачи, ибо оверхед на доступ к данным все же есть. Хотя надо мерить и смотреть, но навскидку кажется, что это не самый быстрый вариант.
Надо мерить. Навскидку, чем сложнее выборка тем предпочтительней sqlite. Да и кода писать сильно меньше.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sinix, Вы писали:
I>>>Ты лучше расскажи, как именно в buffer pool будет храниться миллиард строк. Мне непонятно, что значит "выделяем сегменты", "наворачиваем коллекции", "заполняем структурами"
S>>Вот именно за этим я и отослал к книжке Бена Ватсона. Смысл обсуждать сложные вещи, если надо сперва пересказать азбуку оптимизации по хардкору?
I>Ты сказал следующее "других вариантов без unmanaged нет". Вот я и думаю, как это относится к Pile ? Вот он умеет хранить миллиард строк.
S>>Ну, т.е. любая попытка объяснения сведётся к тому, что сначала надо будет объяснять более базовые вещи и так до Рихтера.
I>Если что, я с товарищами несколько лет кряду оптимизировал приложение, где было конское количество объектов, до 100КК разных виртуальных вычислимых объектов. И это работало очень достойно, при чем в 32х бит приложении. Я правда не дошел до серилизатора и ММФ, думал слишком медленно будет. Однако, все сильно. Но вот интересно, как люди ухитряются тотально сбороть GC в миллиардах объектов.
S>>Смысл такой: у тебя есть возможность динамически аллоцировать/освобождать сегменты (массивы определённой длины) без создания дополнительной нагрузки на GC — освобождённые инстансы забираются обратно в пул. Количество этих сегментов — пока не исчерпается адресное пространство процесса / VM.
I>Ок, наворачивать == аллоцировать/освобождать. Тогда строки хранить побайтно этих сегментах. В итоге получится тот же Pile, только менее универсальный, но более быстрый. I>Насколько buffer pool будет быстре Pile ? Есть какие сравнения ?
Vy mojete xranit v Pile byte[] — ine delat serializaiju. No eto marazm. Prakticheski Pile daet realno na nashem production servere 3,000,000/lookups v secundu is kotoryx 2M+ hits.
Pile idealene dlya sozialnix sitov i proscheta slojnix grafov, kogda nodes ne chasto menautysa
привет
Работаю с биржевыми данными
данных много — 30 000 000 экземпляров записей
в каждом экземпляре есть поле — цена — тип Double
необходимо иметь быстрый доступ к экземпляру по цене
dictionary of double на мой взгляд работает медленно
подскажите есть ли что то быстрее
может есть специализированные библиотеки сторонних производителей.
или может кто то видел библиотеки для работы с большими обьемами данных.
Спасибо.
Здравствуйте, Alexander_fx, Вы писали:
A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее
А зачем хранить double, храните int или long просто * 1000 или 10000 сколько будет достаточно чтобы копейки, центики и евроцентики перешли в целую часть
A_>может есть специализированные библиотеки сторонних производителей.
Помоему для быстрой навигации по большому объему используются всякие балансированные деревья , по крайней мере в СУБД их используют для индексов.
A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, Alexander_fx, Вы писали:
A_>подскажите есть ли что то быстрее
Полюбопытствую: какое сейчас время запроса? И на сколько быстрее хочется?
A_> 30 000 000 экземпляров записей
На 32-х разрядных ДотНетах можно и OutOfMemory схватить, если такое количество держать в памяти.
Так. К слову.
Здравствуйте, xednay89, Вы писали:
X>А этот взгляд чем обоснован? Как вы определили, что медленно?
Любая структура такого размера будет медленной. 240мб — не хухры мухры, а это одними только даблами.
Издержки на dictionary это еще столько же. +30млн самих объектов — это столько же, по самой скромной оценке.
Итого, все это постоянно кочует между виртуальной(свопом) и физической памятью.
Здравствуйте, Ikemefula, Вы писали:
A_>>в каждом экземпляре есть поле — цена — тип Double A_>>необходимо иметь быстрый доступ к экземпляру по цене A_>>dictionary of double на мой взгляд работает медленно A_>>подскажите есть ли что то быстрее A_>>может есть специализированные библиотеки сторонних производителей. A_>>или может кто то видел библиотеки для работы с большими обьемами данных.
I>У тебя расход памяти по скромной оценке около 1гб по скромной оценке. К слову, физической памяти у твоего процесса никогда столько не будет.
Вы меня уж простите за влезание в непрофильный форум в воскресенье, но почему не будет?
Вот люди терабайт в одну машину складывают, а не "несчастный" гигабайт.
I> Т.е. данные будут постоянно перекачиваться между диском и физической памятью. Так работает виртуальная память. Дополнительно проблемы у GC, из за фрагментации и прочих вещей.
Это же всё измеряется?
I>Независимо от стурктуры данных, у тебя уже тупик нарисовался. В твоем условии нет сведений, как можно выйти из этого тупика.
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, Alexander_fx, Вы писали:
A_>>подскажите есть ли что то быстрее M>Полюбопытствую: какое сейчас время запроса? И на сколько быстрее хочется?
A_>> 30 000 000 экземпляров записей M>На 32-х разрядных ДотНетах можно и OutOfMemory схватить, если такое количество держать в памяти. M>Так. К слову.
32 бита — забыл лет 5 назад. в текущей машине 64 гига.
текущая реализация в пике кушает 25 гигов.
Здравствуйте, Alexander_fx, Вы писали:
A_>привет A_>Работаю с биржевыми данными A_>данных много — 30 000 000 экземпляров записей A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
Как инициализируешь Dictionary ? Размер указываешь ?
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Alexander_fx, Вы писали:
A_>>в каждом экземпляре есть поле — цена — тип Double
Ф>
В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Здравствуйте, Alexander_fx, Вы писали:
A_>>>в каждом экземпляре есть поле — цена — тип Double
Ф>>
I>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Я не про скорость в данном случае.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Ikemefula, Вы писали:
Ф>>
I>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Для цен и денег советуют decimal использовать. Аккуратнее будет.
Здравствуйте, xednay89, Вы писали:
I>>Итого, все это постоянно кочует между виртуальной(свопом) и физической памятью.
X>Я не понял, из чего следует, что данные куда-то кочуют. Вроде по размерности данных — все вполне помещается в память
После того как ТС сказал, что у него 64гб и из них 25 занято в пике — да, очевидно, что все может вместиться в память.
Здравствуйте, Sharov, Вы писали:
I>>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
S>Для цен и денег советуют decimal использовать. Аккуратнее будет.
Здравствуйте, Философ, Вы писали:
Ф>>>
I>>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Ф>Я не про скорость в данном случае.
Тот же децимал вдвое больше дабла. Это скользкий момент. Без учета основных операций над числом нет оснований просто так распылять память.
Здравствуйте, Alexander_fx, Вы писали:
A_>привет A_>Работаю с биржевыми данными A_>данных много — 30 000 000 экземпляров записей A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
А смысл это все иметь в памяти?
Почему бы не использовать, например,SQLite ?
Здравствуйте, Don Reba, Вы писали:
W>>А смысл это все иметь в памяти? W>>Почему бы не использовать, например,SQLite ?
DR>Вопрос был о самых быстрых коллекциях, а не о самых медленных.
так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.
Здравствуйте, Win32nipuh, Вы писали:
W>так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.
Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ?
SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ? O>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов.
Подробности не описаны в вопросе ТС.
Вы слово "СУБД" использовали в кавычках, не знаю, можно ли назвать SQLite СУБд или встраиваемой, это уже игра слов.
Здравствуйте, Win32nipuh, Вы писали:
W>Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов. W>Подробности не описаны в вопросе ТС.
А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
С одной стороны — да, но с другой — для того, чтобы "любой алгоритм применить" в своей программе надо его реализовать,а если есть желание и время, то можно и велосипед придумать.
Кстати, по поводу выборок, а также индексов и тормозов на обновлении:
Я на нашел у ТС данных откуда он берет данные, обновляет ли или только читает, возможно был невнимателен, зато нашел такое
"необходимо иметь быстрый доступ к экземпляру"
То есть все-таки чтение.
И да, можно еще добавить Redis, все от задачи зависит.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>>>
I>>>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Ф>>Я не про скорость в данном случае.
I>Тот же децимал вдвое больше дабла. Это скользкий момент. Без учета основных операций над числом нет оснований просто так распылять память.
Some calculations, such as financial, require a large number of digits but cannot tolerate rounding errors.
Decimal is not a floating-point data type.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Some calculations, such as financial, require a large number of digits but cannot tolerate rounding errors. Ф>Decimal is not a floating-point data type.
Я в курсе. А разве где то было указано, что есть вот такие особенные вычисления ?
Здравствуйте, Философ, Вы писали:
Ф>Поле "цена" — это уже финансовые вычисления.
Поле цена это просто поле цена. Я например год работал на проекте, где лет пять до того цену хранили даблом. И никаких проблем с погрешностью не было. Не просто никаких, а абсолютно никаких.
Так что не все вычисления можно и нужно относить к 'финансовым'.
Здравствуйте, okon, Вы писали:
O>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ? O>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
На счет сортировки — SQL бд точно умеет быстро сортировать. Вот искать — далеко не факт.
Здравствуйте, Albeoris, Вы писали:
A>Кроме того GetHashCode() вычисляет хэш по байтам double'а (приводя Double* к Int64*), а, значит, ошибка с плавающей точкой приведёт тебя к тому, что ты не сможешь найти значение в словаре по указанному значению (будет 9,99999999999998 вместо 10.0 и т.д.).
Если вычисления сделаны одинаковые, то и значения будут идентичные. А если ты в одном месте считашь логариф, а в другом делаешь ровно то же, но через сложение-умножение-деление, то результаты будут с погрешностью.
Потому нет смысла говорить про децимал, пока нет ясности с операциями.
Если все условия соблюдены, то дабл может дать внятную оптимизацию и по памяти и по быстродействию !
A>Если же ты ищешь по тем самым Double'ам, которые сохранены у тебя в твоих объектах — фактически, используешь их как индексы, то... я бы за такое бил по рукам,
Одни хотят бить за даблы, другие — за их отсутствие. Нужно внятно говорить, какую проблему хочется решить на основании каких именно догадок
> но в условиях дефицита памяти на что люди только не идут. Как я писал выше, для Dictionary не важно — индексируешься ты по Double или по Int64. Но у тебя чертовски толстая коллекция с вероятностью коллизии хэшей 1/143, что в общем-то дохрена.
Откуда 1/143 ?
>Поэтому я бы, на твоём месте, разбил словарь на кучку более мелких, по ценовым диапазонам — и будет тебе счастье.
I>>Если вычисления сделаны одинаковые, то и значения будут идентичные. А если ты в одном месте считашь логариф, а в другом делаешь ровно то же, но через сложение-умножение-деление, то результаты будут с погрешностью. I>>Потому нет смысла говорить про децимал, пока нет ясности с операциями. I>>Если все условия соблюдены, то дабл может дать внятную оптимизацию и по памяти и по быстродействию ! A>И зачем мне это курить, если ты сам подтверждаешь мои слова? Single даст ещё большую оптимизацию и по памяти и по быстродействию. И если ты разрабатываешь приложение, которое работает с живыми деньгами, то завязываться на то, что за всё время жизни алгоритмы получения этих циферок не поменяются — не очень хорошая мысль.
Ну вот я работал с таким приложением и все было на даблах еще за пять лет до меня. Никаких проблем, объяснения магии — в ссылке
I>>Спасибо, я передам топикстартеру. A>Спасибо. (= A>P.S. Ты так отстаивал текущую модель, что я не обратил внимания.
Я отстаиваю простую вещь — дабл vs децимал есть оффтопик.
A_>привет A_>Работаю с биржевыми данными A_>данных много — 30 000 000 экземпляров записей A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
Это серверное приложение, я надеюсь, не толстый клиент?
Если серверное приложение, то зачем ему всё грузить сразу в память?
Почему не провести подсчёты в СУБД? На худой конец в NoSQL какой-нить, которая всё в памяти держит *под это нужна машина, конечно или лучше кластер*
Здравствуйте, Ikemefula, Вы писали:
I>Я отстаиваю простую вещь — дабл vs децимал есть оффтопик.
Да я солидарен с тобой, поэтому предложил конкретное решение конкретной проблемы. Но когда деньги (потенциально, мои) начинают хранить в Doubla'ах, во мне просыпается кровожадное чудовище. Я понимаю, что всё это из области наколенных программ для домашнего использования, но однажды такие программисты придут в какой-нибудь "Сбербанк", и деньги со счетов тонкой струйкой потекут в тёплые страны. Не благодаря стечению обстоятельств, а по конкретному злому умыслу, эксплуатирующему уязвимость.
P.S. Мысль! Ну мысль же! Ааа... чёртовы thing'и! X"D
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, Albeoris, Вы писали:
I>>Я отстаиваю простую вещь — дабл vs децимал есть оффтопик. A>Да я солидарен с тобой, поэтому предложил конкретное решение конкретной проблемы. Но когда деньги (потенциально, мои) начинают хранить в Doubla'ах, во мне просыпается кровожадное чудовище. Я понимаю, что всё это из области наколенных программ для домашнего использования,
Ты предложил 'как делать правильно во всех случаях где есть цена потому что иначе неправильно даже если работает правильно'
Здравствуйте, Ikemefula, Вы писали:
I>А за счет чего gc исключается ? Вот надо хранить миллиард строк. Как это будет храниться в пуле ?
1. Храним структуры.
2. Структуры храним в массиве из пула. Нужен динамический размер — собираем список из сегментов из пула.
Ну да, оно очень ограничено по сценариям использования, да и произвольные структуры данных поверх так просто не построишь, но у NFX Pile ровно те же проблемы.
Здравствуйте, Sinix, Вы писали:
S>1. Храним структуры. S>2. Структуры храним в массиве из пула. Нужен динамический размер — собираем список из сегментов из пула.
Что хранить — понятно. Как сохранить в твой буфер миллиард строк ?
S>Ну да, оно очень ограничено по сценариям использования, да и произвольные структуры данных поверх так просто не построишь, но у NFX Pile ровно те же проблемы.
NFX Pile для GC торчит как ровно один большой объект. Миллиард строк будет все равно одним объектом.
NFX из за серилизации может хранить вообще всё что угодно.
Здравствуйте, Ikemefula, Вы писали:
I>Что хранить — понятно. Как сохранить в твой буфер миллиард строк ?
кэп: ну а зачем тебе непрерывный буфер, если под капотом можно работать с сегментами?
Для по максимуму разгрузить GC — вэлкам в MappedMemoryFiles с его ReadArray<T>, или извращаемся с unmanaged heap по вкусу.
Также см. главу два (Garbage Collection) в Writing High-Performance .NET Code, она практически вся про сабж.
Здравствуйте, Sinix, Вы писали:
I>>Похоже, кого то вопрос задел за живое. Так и говори — никак. S>Не угадал. Смысл повторять то, что уже отвечал, да ещё и без сарказма? Скучно же.
S>* используем buffer pool, выделяем из него сегменты, наворачиваем поверх коллекцию или stream, заполняем структурами. Vladek выше давал ссылку на RecyclableMemoryStream, там в документашке всё есть как бы. S>* других вариантов без unmanaged нет. Надо объяснять почему?
Ты лучше расскажи, как именно в buffer pool будет храниться миллиард строк. Мне непонятно, что значит "выделяем сегменты", "наворачиваем коллекции", "заполняем структурами"
Вот с серилизацией все понятно, всё само. А как в buffer pool ?
Здравствуйте, Albeoris, Вы писали:
A>Да я солидарен с тобой, поэтому предложил конкретное решение конкретной проблемы. Но когда деньги (потенциально, мои) начинают хранить в Doubla'ах, во мне просыпается кровожадное чудовище.
Оставайся человеком. A> Я понимаю, что всё это из области наколенных программ для домашнего использования, но однажды такие программисты придут в какой-нибудь "Сбербанк", и деньги со счетов тонкой струйкой потекут в тёплые страны. Не благодаря стечению обстоятельств, а по конкретному злому умыслу, эксплуатирующему уязвимость.
Не могут деньги со счетов потечь по этой причине. Если конечно в банковской бд не хранить суммы с точность превышающей копейки, если всегда округлять по одним правилам. Но это уже несколько о другом.
Здравствуйте, Sinix, Вы писали:
I>>Ты лучше расскажи, как именно в buffer pool будет храниться миллиард строк. Мне непонятно, что значит "выделяем сегменты", "наворачиваем коллекции", "заполняем структурами"
S>Вот именно за этим я и отослал к книжке Бена Ватсона. Смысл обсуждать сложные вещи, если надо сперва пересказать азбуку оптимизации по хардкору?
Ты сказал следующее "других вариантов без unmanaged нет". Вот я и думаю, как это относится к Pile ? Вот он умеет хранить миллиард строк.
S>Ну, т.е. любая попытка объяснения сведётся к тому, что сначала надо будет объяснять более базовые вещи и так до Рихтера.
Если что, я с товарищами несколько лет кряду оптимизировал приложение, где было конское количество объектов, до 100КК разных виртуальных вычислимых объектов. И это работало очень достойно, при чем в 32х бит приложении. Я правда не дошел до серилизатора и ММФ, думал слишком медленно будет. Однако, все сильно. Но вот интересно, как люди ухитряются тотально сбороть GC в миллиардах объектов.
S>Смысл такой: у тебя есть возможность динамически аллоцировать/освобождать сегменты (массивы определённой длины) без создания дополнительной нагрузки на GC — освобождённые инстансы забираются обратно в пул. Количество этих сегментов — пока не исчерпается адресное пространство процесса / VM.
Ок, наворачивать == аллоцировать/освобождать. Тогда строки хранить побайтно этих сегментах. В итоге получится тот же Pile, только менее универсальный, но более быстрый.
Насколько buffer pool будет быстре Pile ? Есть какие сравнения ?
Здравствуйте, Ikemefula, Вы писали:
S>>Вот именно за этим я и отослал к книжке Бена Ватсона. Смысл обсуждать сложные вещи, если надо сперва пересказать азбуку оптимизации по хардкору? I>Ты сказал следующее "других вариантов без unmanaged нет". Вот я и думаю, как это относится к Pile ? Вот он умеет хранить миллиард строк.
Дык неэффективно же, через сериализацию. Вдобавок, сами сегменты хранятся как managed byte[] и по-прежнему создают нагрузку на GC.
Если уж и упарываться с "мы пойдём своим путём", то как-то так.
I>Если что, я с товарищами несколько лет кряду оптимизировал приложение, где было конское количество объектов, до 100КК разных виртуальных вычислимых объектов. И это работало очень достойно, при чем в 32х бит приложении. Я правда не дошел до серилизатора и ММФ, думал слишком медленно будет. Однако, все сильно. Но вот интересно, как люди ухитряются тотально сбороть GC в миллиардах объектов.
Нутуткак... с "мы не смогли в GC" возможны ровно два варианта:
1. Люди не читали матчасть, пока не стало поздно. За такими постами имеет смысл следить только ради "смотри, как делать не надо". Потому что если читать — подобные приседания за очень редкими исключениями не нужны. У вас же получилось
2. У людей реальный large scale и они на нём съели собаку. Как правило, таких постов не бывает, ибо NDA и не дураки дарить такой подарок конкурентам. Исключений очень мало, ссылки поприводил постом выше.
I>Ок, наворачивать == аллоцировать/освобождать. Тогда строки хранить побайтно этих сегментах. В итоге получится тот же Pile, только менее универсальный, но более быстрый. I>Насколько buffer pool будет быстре Pile ? Есть какие сравнения?
Сам по себе — одинаково. Выигрыш будет за счёт отсутствия сериализации (в обмен на заметное усложнение работы с произвольными структурами, да). Чтоб кто-то сравнивал — сомневаюсь, не настолько популярная тема, чтоб имело смысл бенчмарки лепить.
Здравствуйте, DarthSidius, Вы писали:
DS>Выполни код:
Console.WriteLine("{0:C} {1:C}", 2.225m, 2.235m);
DS>
По практическим соображениям еще интереснее как механизмы System.Data.OleDb работают при записи в sql'ные поля decimal(n,2). Как-нибудь при случае проверю
Здравствуйте, Sinix, Вы писали:
I>>Ты сказал следующее "других вариантов без unmanaged нет". Вот я и думаю, как это относится к Pile ? Вот он умеет хранить миллиард строк. S>Дык неэффективно же, через сериализацию. Вдобавок, сами сегменты хранятся как managed byte[] и по-прежнему создают нагрузку на GC.
Время по профайлеру не выходит за определеные рамки, 15-30mc. Это про Pile. Стало быть с нагрузкой все в порядке — она под контролем.
S>Нутуткак... с "мы не смогли в GC" возможны ровно два варианта: S>1. Люди не читали матчасть, пока не стало поздно. За такими постами имеет смысл следить только ради "смотри, как делать не надо". Потому что если читать — подобные приседания за очень редкими исключениями не нужны. У вас же получилось
Не пойму, чего именно у меня получилось, не смочь в гц, следить за постами или редкое приседание ?
S>2. У людей реальный large scale и они на нём съели собаку. Как правило, таких постов не бывает, ибо NDA и не дураки дарить такой подарок конкурентам. Исключений очень мало, ссылки поприводил постом выше.
Опенсорс никто пока не отменял. Если замеров нет, то согласно книге, на которую ты ссылался, нет оснований утверждать что одно другого быстрее. Или не так ?
I>>Насколько buffer pool будет быстре Pile ? Есть какие сравнения? S>Сам по себе — одинаково. Выигрыш будет за счёт отсутствия сериализации
И тут снова не ясно, каким чудом хранить строки без этой самой серилизации в managed варианте
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Win32nipuh, Вы писали:
W>>А смысл это все иметь в памяти? W>>Почему бы не использовать, например,SQLite ?
DR>Вопрос был о самых быстрых коллекциях, а не о самых медленных.
SQLite может хранить всю свою базу только в памяти.
Единственный нюанс, если мне не изменяет склероз, писать в нее обязательно надо в транзакции (в противном случае, на каждую запись SQLite сама открывает/закрывает транзакцию).
Здравствуйте, sn175, Вы писали:
S>Здравствуйте, Don Reba, Вы писали:
DR>>Здравствуйте, Win32nipuh, Вы писали:
W>>>А смысл это все иметь в памяти? W>>>Почему бы не использовать, например,SQLite ?
DR>>Вопрос был о самых быстрых коллекциях, а не о самых медленных.
S>SQLite может хранить всю свою базу только в памяти. S>Единственный нюанс, если мне не изменяет склероз, писать в нее обязательно надо в транзакции (в противном случае, на каждую запись SQLite сама открывает/закрывает транзакцию).
Про транзакции не скажу, но соединение необходимо постоянно держать открытым. Вообще говоря, sqlite, даже в памяти, не самое лучшее решение для данной задачи, ибо оверхед на доступ к данным все же есть. Хотя надо мерить и смотреть, но навскидку кажется, что это не самый быстрый вариант.
Здравствуйте, sn175, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>>SQLite может хранить всю свою базу только в памяти. S>>>Единственный нюанс, если мне не изменяет склероз, писать в нее обязательно надо в транзакции (в противном случае, на каждую запись SQLite сама открывает/закрывает транзакцию).
S>>Про транзакции не скажу, но соединение необходимо постоянно держать открытым. Вообще говоря, sqlite, даже в памяти, не самое лучшее решение для данной задачи, ибо оверхед на доступ к данным все же есть. Хотя надо мерить и смотреть, но навскидку кажется, что это не самый быстрый вариант.
S>Надо мерить. Навскидку, чем сложнее выборка тем предпочтительней sqlite. Да и кода писать сильно меньше.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>А за счет чего gc исключается ? Вот надо хранить миллиард строк. Как это будет храниться в пуле ?
S>1. Храним структуры. S>2. Структуры храним в массиве из пула. Нужен динамический размер — собираем список из сегментов из пула.
S>Ну да, оно очень ограничено по сценариям использования, да и произвольные структуры данных поверх так просто не построишь, но у NFX Pile ровно те же проблемы.
У Pile нет таких проблем. Вы можете хранить objects предметнои области (еслу толко в них нет unmanaged handles) без модификации
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>Похоже, кого то вопрос задел за живое. Так и говори — никак.
S>Не угадал. Смысл повторять то, что уже отвечал, да ещё и без сарказма? Скучно же.
S>Я всё расписал в стартовом ответе, если потерял нить обсуждения:
S>А. Только managed code S>* используем buffer pool, выделяем из него сегменты, наворачиваем поверх коллекцию или stream, заполняем структурами. Vladek выше давал ссылку на RecyclableMemoryStream, там в документашке всё есть как бы. S>* других вариантов без unmanaged нет. Надо объяснять почему?
S>Б. Количество сегментов настолько большое, что они сами по себе создают gc pressure. Правда, для этого надо выделить гигов эдак 10-20 (считаем сегменты в 65к), активно насиловать gen2 и использовать client gc, т.е. быть полным злым буратиной.
S>Ну ок, лечится элементарно: перекидываем буферы в MMF/свой unmanaged pool.
S>В. Объекты не влезают в память. Тут как бы очевидно — любая in-process db/distributed cache (смотря по обстоятельствам)
S>Собственно вопрос на миллион долларов: куда тут приткнуть pile? И нафига дёргаться _до_ момента, когда мы действительно уткнёмся в GC?
I>>Спасибо, но я не спрашивал у тебя советов, как разгрузить GC. Давать советы, когда тебя не просили — хамство. S>Ну да, любой врач, который лечит болезнь, а не жалобы по определению хам. Так и живём
S>Ну и поскольку я сегодня добрый, я не буду напоминать про "К слову, физической памяти у твоего процесса никогда столько не будет". Хотя надо бы
Pile pritknut suda, kogda nado xranit sotni millionov social connections i so skorostijy 5,000,000 /sec delat' lookup. Pri etom mojno xranit' predmetnie objects: Person, Friend, List<Friend> a ne special kakie to structures
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
S>>>Вот именно за этим я и отослал к книжке Бена Ватсона. Смысл обсуждать сложные вещи, если надо сперва пересказать азбуку оптимизации по хардкору? I>>Ты сказал следующее "других вариантов без unmanaged нет". Вот я и думаю, как это относится к Pile ? Вот он умеет хранить миллиард строк. S>Дык неэффективно же, через сериализацию. Вдобавок, сами сегменты хранятся как managed byte[] и по-прежнему создают нагрузку на GC.
S>Если уж и упарываться с "мы пойдём своим путём", то как-то так.
I>>Если что, я с товарищами несколько лет кряду оптимизировал приложение, где было конское количество объектов, до 100КК разных виртуальных вычислимых объектов. И это работало очень достойно, при чем в 32х бит приложении. Я правда не дошел до серилизатора и ММФ, думал слишком медленно будет. Однако, все сильно. Но вот интересно, как люди ухитряются тотально сбороть GC в миллиардах объектов.
S>Нутуткак... с "мы не смогли в GC" возможны ровно два варианта: S>1. Люди не читали матчасть, пока не стало поздно. За такими постами имеет смысл следить только ради "смотри, как делать не надо". Потому что если читать — подобные приседания за очень редкими исключениями не нужны. У вас же получилось
S>2. У людей реальный large scale и они на нём съели собаку. Как правило, таких постов не бывает, ибо NDA и не дураки дарить такой подарок конкурентам. Исключений очень мало, ссылки поприводил постом выше.
I>>Ок, наворачивать == аллоцировать/освобождать. Тогда строки хранить побайтно этих сегментах. В итоге получится тот же Pile, только менее универсальный, но более быстрый. I>>Насколько buffer pool будет быстре Pile ? Есть какие сравнения? S>Сам по себе — одинаково. Выигрыш будет за счёт отсутствия сериализации (в обмен на заметное усложнение работы с произвольными структурами, да). Чтоб кто-то сравнивал — сомневаюсь, не настолько популярная тема, чтоб имело смысл бенчмарки лепить.
Pile is open source. What NDA are you talking about? We keep hundreds of millions of social connections in ram in production cheers
Здравствуйте, itadapter, Вы писали:
S>>Ну да, оно очень ограничено по сценариям использования, да и произвольные структуры данных поверх так просто не построишь, но у NFX Pile ровно те же проблемы.
I>У Pile нет таких проблем. Вы можете хранить objects предметнои области (еслу толко в них нет unmanaged handles) без модификации
Привет!
Судя по количеству ответов, не только Ikemefula не читал стартовый пост
привет
Работаю с биржевыми данными
данных много — 30 000 000 экземпляров записей
в каждом экземпляре есть поле — цена — тип Double
необходимо иметь быстрый доступ к экземпляру по цене
Ну т.е. у человека проблема непонятно в чём, но скорее всего не в GC (вот тут пошло отступление в сторону раз) и уж точно не в
Итого, все это постоянно кочует между виртуальной(свопом) и физической памятью.
С учётом комментария топикстартера про "25 гб в пике" — проблема в первую очередь в "никто perf metrics не заморачивался".
Но это я уже к остальным комментаторам присоединяюсь, диагностика по фото такая диагностика
Я в этот праздник жизни старался не вмешиваться, единственно, постарался ответить, почему _в данном конкретном случае_ Pile не лучший выбор и лучше подобрать альтернативу.
Разобрались?
Здравствуйте, Sinix, Вы писали:
I>>У Pile нет таких проблем. Вы можете хранить objects предметнои области (еслу толко в них нет unmanaged handles) без модификации
S>
S>привет
S> Работаю с биржевыми данными
S> данных много — 30 000 000 экземпляров записей
S> в каждом экземпляре есть поле — цена — тип Double
S> необходимо иметь быстрый доступ к экземпляру по цене
S>Ну т.е. у человека проблема непонятно в чём, но скорее всего не в GC
Вообще то замеры показывают, что 30КК в Gen2 дают жесточайшие лаги GC. У ТС реально намного больше объектов в рантайме, ибо речь про записи, а сколько всего объектов можно только предположить основываясь на тех самых 25гб в пике.
S>С учётом комментария топикстартера про "25 гб в пике" — проблема в первую очередь в "никто perf metrics не заморачивался".
25гб в пике уже наводит на мысль, что с ГЦ нужно замерить в первую очередь. Не то записи конского размера, не то на каждую запись по десятку вспомогательных объектов. Ну не умеет ГЦ такие объемы обрабатывать. Он на 10млн уже начинает тупить.
S>Я в этот праздник жизни старался не вмешиваться, единственно, постарался ответить, почему _в данном конкретном случае_ Pile не лучший выбор и лучше подобрать альтернативу. S>Разобрались?
Если замеров внятных не было, счетчиками никто не заморачивался, то совершенно не ясно, откуда проблемы. Может дело вообще не в ГЦ, а может и в ГЦ — замеров то нет. Без них что либо утверждать, лучший выбор или не лучший — чисто шаманский подход и танцы с бубном.
Здравствуйте, Ikemefula, Вы писали:
I>Вообще то замеры показывают, что 30КК в Gen2 дают жесточайшие лаги GC. У ТС реально намного больше объектов в рантайме, ибо речь про записи, а сколько всего объектов можно только предположить основываясь на тех самых 25гб в пике.
Это всё диагностика по фотографии. В корректно написанном софте GC2 может не происходить днями, а если и срабатывать, то практически не оказывать эффекта из-за <gcConcurrent/> (в 4.5+). На крайний случай, нагрузка может скидываться на другие машины в ответ на GC.RegisterForFullGCNotification(). В общем, смотреть надо.
I>Если замеров внятных не было, счетчиками никто не заморачивался, то совершенно не ясно, откуда проблемы. Может дело вообще не в ГЦ, а может и в ГЦ — замеров то нет. Без них что либо утверждать, лучший выбор или не лучший — чисто шаманский подход и танцы с бубном.
Бинго!
Сначала диагностика, потом лечение. Порядок важен.
Здравствуйте, Albeoris, Вы писали:
I>>Поле цена это просто поле цена. Я например год работал на проекте, где лет пять до того цену хранили даблом. И никаких проблем с погрешностью не было. Не просто никаких, а абсолютно никаких. I>>Так что не все вычисления можно и нужно относить к 'финансовым'. A>Ты ведь зачем-то используешь double вместо float. То есть какая-то зависимость от погрешности есть.
7 точных цифр недостаточно даже для записи суммы вроде $987654.32 — которые реально бегают по миру.
16 цифр всё-таки (пока) достаточно для происходящего в современных финансах, даже с учётом необходимости запаса в как минимум одну цифру на округление.
Проблема double и вообще двоичных представлений в другом — обсуждалось, например, совсем недавно
.
A>Умные люди в больших проектах на таких вот ошибках вычисления с плавающей точкой делают хорошие деньги, выводя из оборота тысячные доли копеек.
Это только при отсутствии минимального контроля кода, даже коллегами по разработке, а тем более сторонней организацией (которую к таким серьёзным задачам таки надо привлекать), и на специфических задачах (ну где сейчас делят сумму, например, на 3 равные части? в основном идёт сама сумма и оплата за перевод).
Скорее всего эта история из 70-х больше не воспроизводилась, и все более поздние упоминания её как реальной — просто байки. (Готов сделать поправку на экзотические места вроде Индии, где повторяют проблемы IT со сдвигом на 20-30 лет.)
A>Кроме того GetHashCode() вычисляет хэш по байтам double'а (приводя Double* к Int64*), а, значит, ошибка с плавающей точкой приведёт тебя к тому, что ты не сможешь найти значение в словаре по указанному значению (будет 9,99999999999998 вместо 10.0 и т.д.).
Даже с учётом экзотичности подхода ТС (ну какой словарь по цене? а если она совпадает у акций десятков тысяч разных фирм?), цена, если она взята из нормального источника, представляет собой значение, максимально точно представляющее десятичную реальную цену.
Вот качество подобного приведения — вопрос более интересный — вдруг в разных библиотеках это сделано по-разному.
Но у Вас тут допущение, которому я не вижу нигде в треде обоснования — почему вдруг _хэш_??? Тут полезен только поиск от точной цены на некоторый диапазон вбок. Следовательно, задача нормально ложится только на std::multimap (в терминах C++); не вижу аналога для дотнета — наверно, надо брать сторонние решения. SortedDictionary с массивом значений не годится из-за отсутствия перехода к соседним значениям (как higherEntry, lowerEntry у NavigableMap в Java), если это не достигается хитрой оптимизацией Min/Max с ограничениями.
A>Но я всё же рекомендую переосмыслить подход к индексации записей.
