Есть такая прекрасная библиотека OMPTL
Суть в том что она предоставляет параллельные версии алгоритмов STL, c той же сигнатурой
Т.е. вообще ничего переписывать не надо, заменяем, например, std::sort(...) или std::find_if(...) на omptl::sort(...), omptl::find_if(...)
Здравствуйте, rm822, Вы писали:
R>Есть такая прекрасная библиотека OMPTL R>Суть в том что она предоставляет параллельные версии алгоритмов STL, c той же сигнатурой
... R>Пользуемся лет 5, багов за время эксплуатации найдено небыло, рекомендую всем кто хочет получить параллелизм с минимумом вложений
А есть какой-то бенчмарк?
Начиная с какой размерности проявляется выигрыш от параллельности?
Может расскажешь свою success story? Какие алгоритмы использовали, на каких данных, сколько данных и т.д.?
Использование в реальном проекте гораздо интереснее синтетического теста.
_____________________
С уважением,
Stanislav V. Zudin
SVZ>Может расскажешь свою success story? Какие алгоритмы использовали, на каких данных, сколько данных и т.д.?
У нас энтерпрайз и все большие объемы — они в БД. Была отдельная эпопея со скейлингом на 100ядерные машины, но к С++ она никакого отношения не имеет
Интересующимся параллелизмом в БД рекомендую посмотреть
А в плюсах — обычно неожиданно выясняется что данных стало 10-50-100 раз больше чем планировалось 3 года назад, и все как-то ме-е-е-е-дленно
Если скейлится линейно — прикручиваем параллелизм, если код написан в парадигме STL — то это будет просто.
Иногда не скейлится и дальше it depends...
Кучу ресурсов жрет UI, у нас упор на юзабилити, работу с текстом и все такое...
Несколько примеров
— году эдак в 2002 Microsoft в SP к XP сделал прекрасную вещь. Он использовал в проводнике сортировку строк, которая различала числа внутри.
IMG8
IMG9
IMG10
IMG11
стали сортироваться именно в таком порядке
однако до сих про 99% софта сортирует строки как
IMG10
IMG11
IMG8
IMG9
оно и понятно почему, алгоритм который различает числа работает раз в 5 медленне
— была такая програмка punto switcher, переключала текст набранный не в той раскладке, потом поисковики начали фиксить неправильные запросы, но весь остальной софт это почему-то не коснулось
99% продолжают при поиске требовать от пользователей вводить все as is.
Fuzzy matching, он тоже достаточно ёмкий и малоизвестный https://en.wikipedia.org/wiki/Bitap_algorithm
— большинство search as you type работает довольно мерзко, ищет в основном по совпадению начальных символов, некоторые по подстроке, но найти
в комбо-боксе по вводу "п и с" "Пушкин Иван Сергеевич" — практически никто не может
— 90% софта испытвает проблемы если вместо 12.3 ввести 12,3 или 12 300 вместо 12300
— поиск во всех гридах сделан откровенно фигово
Если добавить еще фишек и данных, то окажется что на 1м ядре не взлетает.
Права жрут кучу ресурсов
Декомпрессия данных, когда их много
Формулки всякие
Здравствуйте, rm822, Вы писали:
SVZ>>Может расскажешь свою success story? Какие алгоритмы использовали, на каких данных, сколько данных и т.д.? R>У нас энтерпрайз и все большие объемы — они в БД. Была отдельная эпопея со скейлингом на 100ядерные машины, но к С++ она никакого отношения не имеет
Меня как раз интересовало, почему вы перелезли с stl на OMPTL и что с этого поимели. В цифрах. Ну не ради же модных веяний, видимо, стандартный stl на ваших данных тормозил.
R>А в плюсах — обычно неожиданно выясняется что данных стало 10-50-100 раз больше чем планировалось 3 года назад, и все как-то ме-е-е-е-дленно
Вот сколько именно надо данных, чтобы стандартная библиотека начала тормозить?
На моих задачах число объектов от 100К до нескольких млн. Поиск и сортировка занимают пренебрежимо мало времени на фоне операций с полигонами
Но эту проблему надо решать нетрадиционными алгоритмами, тут параллелизация не поможет
R>Кучу ресурсов жрет UI, у нас упор на юзабилити, работу с текстом и все такое... R>Несколько примеров R> — году эдак в 2002 Microsoft в SP к XP сделал прекрасную вещь. Он использовал в проводнике сортировку строк, которая различала числа внутри. R>оно и понятно почему, алгоритм который различает числа работает раз в 5 медленне
Делал такое. До 10тыс. элементов тормоза незаметны, а больше пока не попадалось.
R> — большинство search as you type работает довольно мерзко, ищет в основном по совпадению начальных символов, некоторые по подстроке, но найти R>в комбо-боксе по вводу "п и с" "Пушкин Иван Сергеевич" — практически никто не может
У нас строки используются мало.
Выглядят часто вот так:
Поэтому оказалось достаточно поиска по подстроке.
R> — 90% софта испытвает проблемы если вместо 12.3 ввести 12,3 или 12 300 вместо 12300
Хе
По моим наблюдениям 90% программ ожидают ввод в дефолтной сишной локали. И пишут/читают текстовые файлы с той же локалью. И большинство пользователей к этому привыкли.
Но некоторые программы начинают учитывать локализацию при чтении/записи текстовых файлов, и вот тут такие интересные эффекты возникают...
Пока сталкивался с этим только в Altium Designer'е и в какой-то версии Visual Studio.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, rm822, Вы писали:
R>Есть такая прекрасная библиотека OMPTL R>Суть в том что она предоставляет параллельные версии алгоритмов STL, c той же сигнатурой R>Т.е. вообще ничего переписывать не надо, заменяем, например, std::sort(...) или std::find_if(...) на omptl::sort(...), omptl::find_if(...)
SVZ>Меня как раз интересовало, почему вы перелезли с stl на OMPTL и что с этого поимели. В цифрах. Ну не ради же модных веяний, видимо, стандартный stl на ваших данных тормозил.
Потому что закон мура перешел на ядра. Кол-во данных растет а скорость 1го ядра — уже нет.
SVZ>Вот сколько именно надо данных, чтобы стандартная библиотека начала тормозить?
на тех задачах что я описывал от 100к, до 30м
пользовательский ввод оч чувствителен к времени
50мс воспринимается как мгонвенно, а 250мс — как невыносимые тормоза
разница всего в 5 раз, но воспринимается она как пара порядков
