Разработчики HotSpot Java VM из компании Oracle и участники сообщества OpenJDK из компании AMD анонсировали (http://mail.openjdk.java.net/pipermail/discuss/2012-August/0...) проект по интеграции в виртуальную машину Java (JVM) средств для ускорения работы за счёт переноса определённых вычислительных задач с CPU на плечи GPU. При этом прирост производительности скажется не только на Java, но на других языках, использующих для своего выполнения JVM, таких как Groovy, Scala и JRuby.
Возможности по задействованию GPU планируется добавить в Hotspot JVM, в котором уже имеются встроенные механизмы оценки производительности выполняемого кода. В JVM планируется добавить поддержу генерации кода для GPU, обеспечить сборку мусора для этого года и адаптировать runtime-компоненты для выполнения кода на стороне GPU. Дополнительно планируется подготовить серию расширений для Java API, позволяющих управлять выполнением функций с использованием GPU.
URL: http://www.theregister.co.uk/2012/08/16/java_gpu_hardware_ac.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=34613
Сборку мусора надо обязательно переложить на GPU. Аутсорс, так сказать. Процессор будет весь в белом на белом коне, а GPU будет за ним подметать.
А ещё можно прикрутить руки себе на место и юзать new/delete. И тогда никаких белых коней ненужно.
В этом случае процессор будет сразу удалять ненужные объекты - а это затраты времени.
Да что ты говоришь. А если включить свой моск и подумать, когда обьект удалять так, чтобы это не сказалось на производительности? Хотя постой, о чём ты вообще? Освободить указатель в пуле - дело наносекунд. Это же в вашей жабе даже удаление обьекта из памяти занимает пол часа :-D Совсем уже одеревенели от своих жаб. Будто-бы сборщики мусора дают прирост производительности :-D Ох уж эти школьники) Кстате, минусаторы, бегите бегом, на святое позарились. Криворукие^W Жабисты в шоке!!
А деструкторы для объектов выполняються в священном эфире и CPU не грузят?
Клево у вас, в параллельной вселенной!
Так говорите, будто бы на С/С++ я обьекты не могу освобождать паралельно в отдельном треде) Интересно, что-же вы в деструкторах такого наворотить придумали, чтобы оно тормозило о_О
А по поводу высвобождения памяти в другом потоке, это вы аккуратнее.
Аллокать во всей программе, а треду-уборщику скивыдваешь указатель и сигнал.
Сигналы ставятся в очередь, проц. освободится - сигнал c обработчиком отработают.
Только не проще ли сделать free()/delete[]
> Аллокать во всей программе, а треду-уборщику скивыдваешь указатель и сигнал.Чем это отличается от GC? Тем, что из программы на Java нельзя послать прямой сигнал GC, что пора бы прибраться, а из C++ можно?
А ваш тред-уборщик в параллельной вселенной работает и не занимает ресурсы CPU в этой совсем-совсем?
Таки можно послать и в жаве. Ежели надо.
> Таки можно послать и в жаве. Ежели надо.Таки нельзя.
>Чем это отличается от GC? Тем, что из программы на Java нельзя послать прямой сигнал GC, что пора бы прибраться, а из C++ можно?Runtime.getRuntime().gc();
>>Чем это отличается от GC? Тем, что из программы на Java нельзя послать прямой сигнал GC, что пора бы прибраться, а из C++ можно?
> Runtime.getRuntime().gc();Это асинхронная нотификация (непрямой сигнал). Не факт, что GC после этого вызова начнёт что-то там подчищать.
>> Runtime.getRuntime().gc();
> Это асинхронная нотификация (непрямой сигнал). Не факт, что GC после этого вызова
> начнёт что-то там подчищать.так и там "Сигналы ставятся в очередь, проц освободится - сигнал c обработчиком отработают." - синхронности не замечено
Там где человек может оптимизировать код статически, сборщики мусора тупо собирают тонны рамы, а потом освобождают с огромадными задержками. Плюс ко всему ещё и утечки имеются, от кривости рук программиста. Зачем тогда вообще нужен сборщик?
Однако в плюсах утечки памяти случаются куда как чаще чем в джаве.
А как вы с фрагментацией памяти боретесь например?
+100. Можно много невнятных ошибок хапнуть.Так-то удаление объектов занимает немалое время, если выделение было сделано штатными средствами, поэтому объекты выделять/удалять надо как можно реже. А вот если пошаманить с аллокаторами, то можно все существенно ускорить.
Ой, а как Ви таки боретесь с фрагментацией кучи за наносекунды?
Погуглите по ключевому слову slab .
вопрос что лучше открытые минимальные затраты на очистку, либо забыть почистить до 3го пришествия, когда памяти позарез надо а ее нет и вызывается сборщик и вся машина столл-ается
Открою Вам 2 страшных тайны:
1) В яве нет delete. Вообще нет. Там есть сборщик мусора. Иногда это доставляет некоторые неудобства.
2) Сборщик мусора запускается в отдельном потоке, причем можно оставить его на усмотрение jvm, а можно запускать в нужное время и в нужном месте.
Ой спасибо, я даже не знал что в жабе нет делит. А если бы вы ещё прочитали повнимательней, то вообще бы поняли что я с сарказмом намекал на ненужность жабы.
Сборку мусора видеопамяти, а не системной. И осуществляться эта сборка будет (сюрприз-сюрприз!) на CPU. Потому что внутри GPU кода выделение видеопамяти (а системной тем более) невозможно (кроме регистровой и маленькой кеш-памяти).
Но это всё мелочи по сравнению с тем, что можно получить на выигрыше с ускоренными вычислениями. Глядишь, скоро можно будет и тяжёлую математику на Яве писать, всякую обработку изображений, видео и звука. А для функциональных языков типа Скалы это будет тем более плюсом: кратко, выразительно и быстро писать программы.
> Сборку мусора видеопамяти, а не системной. И осуществляться эта сборка будет (сюрприз-сюрприз!)
> на CPU. Потому что внутри GPU кода выделение видеопамяти (а системной
> тем более) невозможно (кроме регистровой и маленькой кеш-памяти).
> Но это всё мелочи по сравнению с тем, что можно получить на
> выигрыше с ускоренными вычислениями. Глядишь, скоро можно будет и тяжёлую математику
> на Яве писать, всякую обработку изображений, видео и звука. А для
> функциональных языков типа Скалы это будет тем более плюсом: кратко, выразительно
> и быстро писать программы.Забавно но на последних тестах Scala не только идет вровень с джавой но и местами её обгоняет. Особенно это заметно на параллельном коде. Кроме того на скале *уже* можно писать под GPU (т.е. все итеративные места компилятором при помощи плагина будут пересены с CPU на GPU) http://code.google.com/p/scalacl/
для этого нужен отдельный сопроцессор
Им потихоньку становится ГПУ.
Ну и изобретатели. Для некоторых задач и типов вычислений использование GPU более чем оправданно. Но на многих задачах GPU будет тормозить почище чем CPU. Как их JVM будет определять какой код на чем выполнить, что-бы получить прирост производительности?
Так в новости же сказано, что грядёт расширение API для управления. Это наверняка будет перечисление доступных устройств, их выбор и определение функций, которые будут выполняться на GPU. Иначе и смысла нет.
Вообще говоря, всё это идёт в продолжении тренда:
1. шейдеры только для видеокарт;
2. CUDA от Нвидии для своих видеокарт и сопроцессоров;
3. OpenCL уже для гетерогенных устройств (и дискретных видеокарт, и встроенных, для обычных х86 CPU, уже и на ARM);
4. появление HSA как упрощение внедрения низкоуровневого OpenCL.Последнее делается в основном той же AMD, которая хочет снизить влияние Нвидиевской CUDA, а теперь помогает явистам. Думаю, многие языки и фреймворки скоро получат высокоуровневые средства генерации кода для высокопараллельных систем, а не на кластеры, что сейчас довольно развито уже. Возможно даже, что такой мелко и крупнозернистый параллелелизм удастся объединить под каким-нибудь одним стандартом. Что было бы хорошо, но я пока не представляю как.
Будет хорошо, если общий стандарт создадут Intel и AMD. А то NVidia любит vendor lock-in решения. Он в этом на Microsoft похожи.
ну так есть такой стандарт, OpenCL зовётся
Учитывая, что код для GPU должен обладать одним основным свойством: куча одинаковых действий над различными данными (SIMD), выделить его не сложно. Тем более имея в наличии байткод и комментарии выставленные явовским компилятором.
То есть, теперь будут новости типа: "Для обеспечения роста производительности критические участки кода были переписаны на Java"? :)
Предлагаю переложить сборку мусора на облачные сервисы на серверах Оракол.
Теперь в серваки придется игровые видеокарты втыкать?
Дешевле таки просто не юзать яву.
Вас не возмущает необходимость втыкать в серваки специализированные процессоры? Или Вы таки держите серверы с процессорами Целерон?
он одминит локалхосты, очевидно же
На амазоне например уже два года какhttp://aws.amazon.com/about-aws/whats-new/2010/11/15/announc.../
Я до сих пор помню, как Oracle Corp. уничтожили кучу отличных открытых проектов и разогнали сообщества пользователей и разработчиков :(((
Вечная Память.
Ну вот докатились: теперь новые видеокарты будут покупать не для игр, а чтобы джава не тормозила.
Попытка залезть на проигранный десктоп?
Лучше бы делом как-нить занялись ...
Попытка усидеть на сервере. Довольно удачная, между прочим. В принципе, это чуть ли не первый вменяемый плюс байткодовых платформ - до этого все их "оптимизации" в лучшем случае позволяли получать скорость натива. А вот здесь есть шанс многократно ускорить даже то, к чему исходники сто лет назад как потеряли, просто за счёт установки нового рантайма.
Это сильно вряд ли, потому что из серии "а давайте все автоматически распараллелим" (что было модно лет эдак 25 назад, на этой волне появилось множество функциональных языков с упором на чистоту).Чтобы получить какой-либо прирост, работать с GPU надо вручную.
> Это сильно вряд ли, потому что из серии "а давайте все автоматически
> распараллелим" (что было модно лет эдак 25 назад, на этой волне
> появилось множество функциональных языков с упором на чистоту).
> Чтобы получить какой-либо прирост, работать с GPU надо вручную.вас не удручает что в семействе современных х86 инструкции паралелятся автоматически по блокам исполнения а не ручками ?
Феерично. Сначала придумали жабу, с лозунгом "подгузник - здесь ж0пу себе вытирать не надо", потом выяснили что ан все-таки памперсы менять накладно, да и ж0па в памперсе все одно остается грязная, теперь наняли GPU, который раз в 15 минут обходит весь детский сад и всем ж0пу вытирает, вне зависимости от того погадил киндер или нет. Что завтра придумают чтобы ж0пу не вытирать когда это нужно и не вытирать когда не нужно ?Я вот все думаю, неужто вся эта автоматика проще и гигиеничнее чем самому бумагой туалетной пользоваться ?
Абсолютная правда. Только вот те гики которые считают себя программистами, не слышали про делит вообще. Типа "Освобождать память? Не, не пробовал"
delete хорош и крайне полезен, когда речь идёт про C++(аналогично retaiin/release в Objective C и free в plain C).Если поделитесь, как использовать delete в Java — буду очень признателен
Это к чему вообще? Очевидно же, что к сборке памяти GPU вообще никакого отношения иметь не будет.
Вы новость читали вообще ? Цитирую: "В JVM планируется добавить поддержу генерации кода для GPU, обеспечить сборку мусора для этого кода".Сборщик мусора, "теперь и банановый" (ц).
Потому что память выделяется на видеокарте. Кто по твоему должен её освобождать? Стандартный сборщик мусора это не умеет, разумеется, надо добавлять поддержку. Что в этом такого страшного?
Кроме того, видеопамять не будет выделяться часто и мелкими блоками. Как правило, это происходит крайне редко: при начале и окончании потока вычислений. И выделяются сразу большие буферы для матриц, изображений, буферов обработки звука и т.д. и т.п. Сборка мусора для таких вещей будет оказывать практически нулевой эффект на производительность.
господи какой деский сад. И про задержки в т.ч. погуглите azul JVM. Никаких там мега пауз нет. Кто вам сказал что GPU будет мусор собирать?