Собственно, требуется возможность быстрой работы с матрицами на java по
Кроме реализации ресурсожрущего кода на С++ и подключение его через JNI ничего в голову не приходит.
2. Или вы делаете сложные вычисления на базе этих матриц? И садите процессор? На графическом процессоре работа с матрицами может давать ощутимые преимущества.
Сложные вичисления. Проблема в проверке выхода за границы массива при каждом обращении к элементу массива. Unsafe код на C# работает гораздо быстрее, на С++ еще быстрее.
В общем понял — оптимизация группы алгоритмов или перевод части кода на C++.
PSНа смартфонах вроде нет прямого доступа к вычислениям на GPU?.
Смотри, если у тебя один из последних андроидосмартов с тегрой, то там есть renderscript.На него можно переложить часть задач, он работает непосредственно с GPU, но боюсь там потеряешь при переводе матриц в нужную структуру для вычислений.
Я обсчитывал flow dynamics пару лет назад на CUDA и эта конвертация сильно била по скорости, так что может оказаться сомнительной эта фича..
Альтернатива — memory mapped files, джава их поддерживает через NIO
Я знаю как работает механизм файловой системы Windows, это решение тормознет работу с массивами еще в 10 раз, если для доступа к каждому элементу делать файловый вызов.
Для memory mapped files не нужно делать каждый раз файловый вызов
or sun.misc.Unsafe robaustin.wikidot.com/...cations-in-java
or sun.misc.UnsafeУж простите, что я на русском.
Use ByteBuffer.allocateDirectА это будет быстрее чем работа с массивом? Если есть ссылки, интересно будет почитать. У ТСа, по его словам, тормозят даже они.
Stosovno performance, napevne topic startery potribno pokazatu kod. Ja dymajy jogo mozhna optumizyvatu bez JNI
Пишите на английском. Здесь поймут
Автор как бы писал, но здесь признали за моветон или автор сам смутился :)
Vazhko pusatu kurulecejy.
Или Google Russian Input. Или Grammatica IME (на правах рекламы)
На практике мерить не приходилось при работе с большими объемами данных, но наверное мы немного можем экономить на том что GC не будет заниматься обработкой этой памяти. Собственно мне нравится набор средств описанный на блоге: www.javaspecialist.ru/...heap-cache.html.
Класс этот есть в JVM много-много лет, он есть также и в JRockit и в IBM JVM. Так что особенных причин бояться его использовать нет. Его уже никто не будет удалять из api, т.к. слишком много кода написано серьезными ребятами с большими залежами легаси-приложений по всему миру с его использованием.
ByteBuffer.allocateDirect не дает выделять память больше чем MAX_INT, что для обычных случаев просто не хватает (матрица 500 на 500 тысяч в обычный массив не влезает).
Вообще, топик-стартеру советую посмотреть, как занимаются вычислениями на Java нормальные люди. Наверняка от Java там только Hadoop, а все джобы для него поставляются в виде тонких врапперов вокруг библиотек на Fortran. Хотя, мб библиотеки там тоже на чистой Java. В общем, гуглите и не велосипедничайте понапрасну.
Ну работу с большими матрицами, научные вычисления и прочее чаще всего пишут либо на FORTRAN, как было уже правильно замечено, либо на с++ с использованием GPU (CUDA, opencl), SIMD etc.
Ну работу с большими матрицами, ... пишут либо на FORTRAN ... либо на с++ с использованием GPU (CUDA, opencl), SIMD etc.
А может вместо того чтобы начать изучать Хаскалл, надо подумать и не грузить все в память если пердполагаетсо что размер данных неограничен.
быстрой работы с матрицами на java по
20-100 млн элементов.
что обрабатывающий код исполняется до 40 секунд.
Предсказание: проблема или в коде или в настройкам ДжВМ (мало памяти).
Но safe реализация кода приводит к тому,
Код вы вряд ли покажете. Трассы профайлера хоть. Что там светится?
Предсказание: проблема или в коде или в настройкам ДжВМ (мало памяти).
В коде проблем нет, просто там идет работа с большими окнами по 11^2 элементов на пиксел (элемент). В общем адаптивная бинаризация 600dpi-ных изображений.
В коде проблем нетНу на это я могу Вам сказать, что в джвм проблем с вычислениями в памяти тоже нет проблем...
Можно, вопрос в том — поможет ли это? Было бы не плохо видеть код, очень вероятно проблема только в самом коде.
В любом случае для джавы есть вроде байндинг к LAPAC, так что в худшем случае можно его заюзать.
Возможно проблема таки не в коде.Не знаю, не знаю... Я еще не встречался с проблемой, когда узкое место в джвме или компиляторе.
1) Числодробилки: именно много операций с плавающей точкой. Тут ЦПП довольно часто выносит Джаву (по моему субъективному опыту)Я еще не встречался с проблемой, когда узкое место в джвме или компиляторе.
2) Операции с многомерными массивами. Но тут ближе таки к коду: их надо правильно переворачивать.
Как я уже написал проблема в векторизации. Типа если у тебя есть цикл for(...) a[i] += b[i]; компиллер может умещать несколько сложений в одну векторизированную команду. Это если компиллер умный и знает что масивы a и b не пересекаются. Практика показывает что джава компилеры недостаточно умны в этом направлении по сравнению с c++/fortran компилерами. Второй момент что джава может делать index out of bound чек на каждой итерации и это тоже сильно тормозит цикл.
Index out of bound также может отсутствовать, но это зависит...
Но матричные либы на джаве почемы то в разы стабильно проигрывают ц+±ным
Ммм, попытался нагуглить — не нашел. Было бы интересно взглянуть на пруфы.
Вот тут например есть пруфы: stackoverflow.com/...-math-libraries
Ни и где же там пруфы? Вы читали? Там как раз говорится, что скорость зависит от конкретных либ и от конкретной задачи.
Там говорится что на всех приведенных задачах все конкретные джава либы сливают всем конкретным ц++/fortran либам. Других случаев я там не заметил.
Фортрана там точно не будет.
Возможно проблема таки не в коде.ИМХО, таки в коде, ибо даже если:
Есть языки и компилеры которые легко векторизируют матричные операции(фортран,цпп), а есть которые похуже.то фраза:
понаводит на мысль что надо думать перед тем как грузить всякую хну в память.20-100 млн элементов
Но важно другое:
Судя по всему человек даже не запускал профайлер, так шо наши гадания бессмысленны.
А теперь самое важное:
В любом случае для джавы есть вроде байндинг к LAPACЧто такое LAPAC? Для чего оно надо? И ссылочки «на почитать».
по20-100 млн элементовнаводит на мысль что надо думать перед тем как грузить всякую хну в память.
100 млн чисел это 1 гб, в чем проблема с грузить в память?
Что такое LAPAC? Для чего оно надо? И ссылочки «на почитать».
100 млн чисел это 1 гб, в чем проблема с грузить в память?
Дело не столько в объеме, сколько в количестве и в том что оно очень просто растет. Да и 1Гб — это не так уж и мало.
В данном случае это скорее всего не фактор.
Судя по вопросу, Вам нужна возможность выделять/очищать память вручную (без GC).
Он в пакете sun, то есть не публичное и может пропасть в любой момент.
Про это знаю, но это больше похоже на хак.
Есть куча джавовских либ по работе с матрицами, можно попробовать заюзать их или поискать в них вдохновения на тему оптимизации
Alex Nitavsky
Максим Дарбак
Ostap Vyshnya
reality_hacker
Volodymyr Zhabiuk
Bogdan Shyiak
Ievgen Gusher
Andriy Dobrov
Ivan M
Alex Nitavskyi
Андрей
Maksym Stepanenko
Bogdan Shyiak
Дмитро Думанський
Дмитро Думанський
reality_hacker
40 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів