Разместите свой проект бесплатно и начните получать предложения от фрилансеров-исполнителей уже спустя минуты после публикации!
50 000 ₽

Оптимизация java-модуля

истекло время актуальности


Есть Java-сервис, который взаимодействует с PHP с помощью Apache Thrift.


Ядро сервиса - операции сложения битовых векторов. Сама логика сервиса проста (не требует особых или математических знаний, просто сложение больших массивов данных). Объем данных в памяти - несколько гигабайт. 


Нужно переписать модуль, чтобы повысить производительность:

  • использовать последнюю Java - использовать современные наработки;
  • заменить Apache Thrift на что-то более производительное: скорее всего, на FlatBuffers (нужно тестировать);
  • подобрать более эффективные алгоритмы вычислений (есть их описания) - как вариант, добавить индексные массивы координат, в которых хранятся 1.

Сейчас запрос выполняется за 50-400 мс. Нужно, чтобы он укладывался в 10-100 мс.


Вариант - переписать модуль на С/Rust с использованием библиотеки Roaring Bitmaps (или подобной альтернативы). 


Просьба рассказать о своем опыте.


Дополнительная информация по теме - в похожей разработке:

https://habr.com/ru/company/badoo/blog/451938/



  1. 30 дней50 000 ₽
    Андрей Андреев
     186 

    Предлагаю ваши вычисления распараллелить, для этого мне понадобится очень хороший компьютер с как минимум с восемью ядрами на борту. И давайте заложимся на то, что в науке отрицательный результат, это тоже очень хороший результат. :-) Заплатите мне к примеру 30 % стоимости за научные изыскания, если ничего не получится. А если всё получится то 100 %. Я в вашей схеме вызовов менять ничего не буду, потому что даже замена Java на С++ даст от силы 5 % скорости, а замена Apache Thrift на FlatBuffers вообще ничего не даст. А новая версия JDK может разве что замедлить вычисления.

    Короче я предлагаю ускорить процесс вычислений за счет дополнительных ядер на борту, то есть за счет увеличения суммарной мощности компьютера. А еще лучше чтобы самих процессоров было 2, а еще лучше четыре, тогда у меня в распоряжении будет 32 ядра. Да там ваши битовые векторы, как пулей будут летать.

    Использовать графический процессор вряд ли получится, так как на сервера редко кто-то ставит
    GeForce RTX 2080 Ti поэтому лучше использовать штатные ядра процессора.

    Программу вашу придется сначала оформить как десктопную и переписать вообще весь алгоритм вычислений.

    Казахстан Алматы (Алма-Ата) | 17 сентября в 16:59 |
  2. 15 дней70 000 ₽
    Alex Maslakov
     294 

    Забабахаю.

    !===авыфавыфавы!===авыфавыфавы!===авыфавыфавы!===авыфавыфавы!===авыфавыфавы

    Грузия Тбилиси | 17 сентября в 21:55 |
  3. 20 дней50 000 ₽
    Вася Иванов
     155 

    -- пишите в skype [email protected] для обсудить условия и задание
    -- Личку и почту не читаю- пишите В SKYPE

    Украина Одесса | 18 сентября в 08:59 |
  4. ставка скрыта фрилансером
  5. 10 дней50 000 ₽
    Андрей Северин
     1104  проверен   7  1

    Здравствуйте.

    Задача интересная. Готов переписать сервис на языке C (в профиле есть заказы с этим языком) и попытаться убрать промежуточные слои. Также, есть желание поэкспериментировать с другими алгоритмами.

    Россия Санкт-Петербург | 18 сентября в 23:39 |
  6. 37 дней49 000 ₽
    Екатерина Иванова
     253 

    Возьмусь за эту работу по готовым описаниям алгоритмов. Предлагаю использовать индексные массивы координат, в которых хранятся 1

    Россия Москва | 29 сентября в 18:24 |
  • Anton Kravtsov
    17 сентября в 13:59 |

    В предыдущем вашем проекте было несколько дополнительных вариантов для оптимизации... Опробовали некоторые? Не помогло?

    Кстати, для PHP ещё можно ваять расширения (напр., на C++) - возможно, это направление тоже пригодится. Хотя если узкое место - в Java-сервисе, то PHP-оптимизация не особо поможет.

  • Владимир Андреев — заказчик проекта
    17 сентября в 14:04 |

    Решили отказаться от CUDA, и сосредоточиться на Java / С. 

  • Андрей Андреев
    18 сентября в 12:49 |

    В принципе если компьютер стоит в офисе, то можно рассмотреть и CUDA. Факт в том, что у вас нет никакого другого выхода, кроме как дробить задачу на процессоры и нет никакого другого пути ускорить процесс вычисления битовых векторов. Программы на Java и Cи в среднем работают одинаково быстро, так как Си чистый компилятор, а Java JIT компилятор.  Именно поэтому Java почти полностью вытеснила Си из области серверных приложений.  Скорее всего интересующие вас функции, на Java и Си будут выполнятся одинаково быстро.  Но если хотите, то за ваши деньги можно попробовать переписать вашу программу на Си, быть может и увеличим скорость работы вашей программы на 5 %, но не в 4 раза как вы хотите это точно.

  • Александр Шальнев
    18 сентября в 12:57 |

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

    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-gpp.html


    Вам сейчас тут мамкины аналитики расскажу, что Java и C++ - одинаковы по производительности, максимум 5% разницы.... Бред и абсолютная некомпетентность

  • Андрей Андреев
    18 сентября в 13:19 |

    Когда не очень грамотные люди начинают делать всякие тесты, сравнивая скорость работы интерпретатора Java на первом запуске программы с заранее откомпилированной программой на Си. То оно всегда так и получается, можете мне поверить на слово, второй и все последующие запуски одной и той же программы на Java и С++ будут абсолютно одинаковыми по времени. А если процессор не тот, под который компилировалась программа на Си, то JIT программа на Java будет оптимальнее и быстрее. Это я сто раз проверял, для серверных программ JIT компилятор от Java работает быстрее Си. Поэтому я и не использую сейчас нигде Си, устарел он малость и никакого прироста скорости программ компилятор Си не дает. 

  • Anton Kravtsov
    18 сентября в 14:49 |

    второй и все последующие запуски одной и той же программы на Java и С++ будут абсолютно одинаковыми по времени 

    Ваше замечание в контексте тестов весьма уместно - судя по "протоколу", там измерялось "брутто" (включающее затраты JIT-компилятора, загрузку программы в память и проч.). Имело бы смысл сравнить чистое время, потраченное на прикладную задачу.

    Впрочем, предположу, что и в этом случае откомпилированная программа на C++ окажется быстрее, чем откомпилированная программа на Java.

    В целом, каждый может повторить тесты (т.к. исходные коды программ приведены) и провести замеры по своим стандартам 🙂

    PS: сорри за оффтопик 🙂

  • Андрей Андреев
    18 сентября в 17:19 |

    Нет JIT программа на Java, будет либо такой же быстрой как и на Си, либо Java программа будет быстрее. Так как Java машина точно знает, что за процессор используется, сколько и какой памяти на борту. Поэтому JIT код Java практически  всегда более эффективен, чем статическая компиляция Cи.  У Java только некоторые функции работают медленнее, чем на C и то максимум на 5 %. Вот если специально вставить в цикл более медленные функции Java, то только тогда можно получить проигрыш в 5 % скорости. А так в среднем JIT компилятор Java создает более быстрые и более эффективные программы чем статический компилятор Си.  Java и Си по скорости выполнения, особенно серверных программ практически никак не отличаются. У Java только первый запуск программы намного медленнее, чем на Си, а дальше JIT компилятор создает либо точно такой же как и Си, либо более эффективный машинный код в машинных командах процессора. 

  • Александр Шальнев
    18 сентября в 17:46 |

    Ну, если Вы утверждаете, что использование дополнительного уровня абстракции в виде виртуальной машины может действительно добавить производительности… и при этом ещё и утверждаете, что прога на Java будет ещё и быстрее - то продолжать какой-либо диалог смысла нет.

    Те, кто что-то понимают сделают соответствующие выводы, а кто не понимает, надеюсь, обратятся к правильному специалисту.

    Спасибо за потраченное время 🙂

  • Андрей Андреев
    18 сентября в 17:59 |

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

  • Александр Шальнев
    18 сентября в 18:02 |

    Как скажете. Я обязательно воспользуюсь Вашими рекомендациями 🙂

  • Андрей Андреев
    18 сентября в 18:06 |

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

  • Евгений Фрис
    17 сентября в 14:02 |

    уж лучге было бы переидти на node

  • Владимир Андреев — заказчик проекта
    17 сентября в 14:03 |

    Можно и node рассмотреть, а как он поможет?

  • Евгений Фрис
    17 сентября в 14:04 |

    а вы хоть знаете принцип работы node, и почему большенство крупных сайтов перешли на него? все очень просто, оптимизация потока

  • Владимир Андреев — заказчик проекта
    17 сентября в 14:06 |

    в данной конкретной задаче как он бы помог? где большие данные будут храниться? кто будет делать необходимые вычисления над ними?

  • Евгений Фрис
    17 сентября в 14:09 |

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

  • Владимир Андреев — заказчик проекта
    17 сентября в 14:13 |

    PHP получать лишь результаты выборки, они очень маленькие. Сами данные и функционал - в Java

  • Андрей Андреев
    17 сентября в 15:38 |
    удалено модератором
  • Александр Шальнев
    17 сентября в 18:36 |
    удалено модератором
  • Вася Иванов
    18 сентября в 09:01 |
    удалено модератором
  • Giorgi Eremiani
    20 сентября в 23:40 |

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