| 1.1, Аноним (-), 00:05, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Сборку мусора надо обязательно переложить на GPU. Аутсорс, так сказать. Процессор будет весь в белом на белом коне, а GPU будет за ним подметать.
| | |
| |
| 2.4, ВовкаОсиист (ok), 00:24, 20/08/2012 [^] [^^] [^^^] [ответить]
| –6 +/– |
 А ещё можно прикрутить руки себе на место и юзать new/delete. И тогда никаких белых коней ненужно.
| | |
| |
| 3.5, Аноним (-), 00:32, 20/08/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
В этом случае процессор будет сразу удалять ненужные объекты - а это затраты времени.
| | |
| |
| 4.9, ВовкаОсиист (ok), 01:14, 20/08/2012 [^] [^^] [^^^] [ответить]
| +16 +/– |
Да что ты говоришь. А если включить свой моск и подумать, когда обьект удалять так, чтобы это не сказалось на производительности? Хотя постой, о чём ты вообще? Освободить указатель в пуле - дело наносекунд. Это же в вашей жабе даже удаление обьекта из памяти занимает пол часа :-D Совсем уже одеревенели от своих жаб. Будто-бы сборщики мусора дают прирост производительности :-D Ох уж эти школьники) Кстате, минусаторы, бегите бегом, на святое позарились. Криворукие^W Жабисты в шоке!!
| | |
| |
| 5.13, Anonymouses (?), 01:35, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
А деструкторы для объектов выполняються в священном эфире и CPU не грузят?
Клево у вас, в параллельной вселенной!
| | |
| |
| 6.15, ВовкаОсиист (ok), 01:58, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Так говорите, будто бы на С/С++ я обьекты не могу освобождать паралельно в отдельном треде) Интересно, что-же вы в деструкторах такого наворотить придумали, чтобы оно тормозило о_О
| | |
| |
| |
| |
| 9.22, iZEN (ok), 08:34, 20/08/2012 [^] [^^] [^^^] [ответить] | +1 +/– |  Чем это отличается от GC Тем, что из программы на Java нельзя послать прямой си... текст свёрнут, показать | | |
| |
| |
| 11.45, iZEN (ok), 14:12, 21/08/2012 [^] [^^] [^^^] [ответить] | +/– | Это асинхронная нотификация непрямой сигнал Не факт, что GC после этого вызов... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 4.10, Mna (??), 01:14, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
вопрос что лучше открытые минимальные затраты на очистку, либо забыть почистить до 3го пришествия, когда памяти позарез надо а ее нет и вызывается сборщик и вся машина столл-ается
| | |
|
| 3.20, жабабыдлокодер (ok), 08:23, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Открою Вам 2 страшных тайны:
1) В яве нет delete. Вообще нет. Там есть сборщик мусора. Иногда это доставляет некоторые неудобства.
2) Сборщик мусора запускается в отдельном потоке, причем можно оставить его на усмотрение jvm, а можно запускать в нужное время и в нужном месте.
| | |
| |
| 4.36, ВовкаОсиист (ok), 16:34, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ой спасибо, я даже не знал что в жабе нет делит. А если бы вы ещё прочитали повнимательней, то вообще бы поняли что я с сарказмом намекал на ненужность жабы.
| | |
|
|
| 2.7, Nuzhny (?), 01:00, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Сборку мусора видеопамяти, а не системной. И осуществляться эта сборка будет (сюрприз-сюрприз!) на CPU. Потому что внутри GPU кода выделение видеопамяти (а системной тем более) невозможно (кроме регистровой и маленькой кеш-памяти).
Но это всё мелочи по сравнению с тем, что можно получить на выигрыше с ускоренными вычислениями. Глядишь, скоро можно будет и тяжёлую математику на Яве писать, всякую обработку изображений, видео и звука. А для функциональных языков типа Скалы это будет тем более плюсом: кратко, выразительно и быстро писать программы.
| | |
| |
| 3.52, Аноним (-), 06:35, 25/09/2012 [^] [^^] [^^^] [ответить] | +/– | Забавно но на последних тестах Scala не только идет вровень с джавой но и местам... большой текст свёрнут, показать | | |
|
|
| 1.6, lucentcode (ok), 00:58, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Ну и изобретатели. Для некоторых задач и типов вычислений использование GPU более чем оправданно. Но на многих задачах GPU будет тормозить почище чем CPU. Как их JVM будет определять какой код на чем выполнить, что-бы получить прирост производительности?
| | |
| |
| 2.8, Nuzhny (?), 01:12, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Так в новости же сказано, что грядёт расширение API для управления. Это наверняка будет перечисление доступных устройств, их выбор и определение функций, которые будут выполняться на GPU. Иначе и смысла нет.
Вообще говоря, всё это идёт в продолжении тренда:
1. шейдеры только для видеокарт;
2. CUDA от Нвидии для своих видеокарт и сопроцессоров;
3. OpenCL уже для гетерогенных устройств (и дискретных видеокарт, и встроенных, для обычных х86 CPU, уже и на ARM);
4. появление HSA как упрощение внедрения низкоуровневого OpenCL.
Последнее делается в основном той же AMD, которая хочет снизить влияние Нвидиевской CUDA, а теперь помогает явистам. Думаю, многие языки и фреймворки скоро получат высокоуровневые средства генерации кода для высокопараллельных систем, а не на кластеры, что сейчас довольно развито уже. Возможно даже, что такой мелко и крупнозернистый параллелелизм удастся объединить под каким-нибудь одним стандартом. Что было бы хорошо, но я пока не представляю как.
| | |
| |
| 3.11, lucentcode (ok), 01:28, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Будет хорошо, если общий стандарт создадут Intel и AMD. А то NVidia любит vendor lock-in решения. Он в этом на Microsoft похожи.
| | |
|
| 2.12, Anonymouses (?), 01:33, 20/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Учитывая, что код для GPU должен обладать одним основным свойством: куча одинаковых действий над различными данными (SIMD), выделить его не сложно. Тем более имея в наличии байткод и комментарии выставленные явовским компилятором.
| | |
|
| 1.21, жабабыдлокодер (ok), 08:25, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
То есть, теперь будут новости типа: "Для обеспечения роста производительности критические участки кода были переписаны на Java"? :)
| | |
| 1.23, Аноним (-), 09:03, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Предлагаю переложить сборку мусора на облачные сервисы на серверах Оракол.
| | |
| 1.24, o (?), 09:07, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Теперь в серваки придется игровые видеокарты втыкать?
Дешевле таки просто не юзать яву.
| | |
| |
| 2.25, жабабыдлокодер (ok), 09:13, 20/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вас не возмущает необходимость втыкать в серваки специализированные процессоры? Или Вы таки держите серверы с процессорами Целерон?
| | |
|
| 1.26, Аноним (-), 10:27, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я до сих пор помню, как Oracle Corp. уничтожили кучу отличных открытых проектов и разогнали сообщества пользователей и разработчиков :(((
Вечная Память.
| | |
| 1.30, Аноним (-), 11:44, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ну вот докатились: теперь новые видеокарты будут покупать не для игр, а чтобы джава не тормозила.
| | |
| 1.32, АнониМ (?), 11:47, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Попытка залезть на проигранный десктоп?
Лучше бы делом как-нить занялись ...
| | |
| |
| 2.39, Crazy Alex (ok), 19:54, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Попытка усидеть на сервере. Довольно удачная, между прочим. В принципе, это чуть ли не первый вменяемый плюс байткодовых платформ - до этого все их "оптимизации" в лучшем случае позволяли получать скорость натива. А вот здесь есть шанс многократно ускорить даже то, к чему исходники сто лет назад как потеряли, просто за счёт установки нового рантайма.
| | |
| |
| 3.48, Аноним (-), 18:27, 21/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Это сильно вряд ли, потому что из серии "а давайте все автоматически распараллелим" (что было модно лет эдак 25 назад, на этой волне появилось множество функциональных языков с упором на чистоту).
Чтобы получить какой-либо прирост, работать с GPU надо вручную.
| | |
| |
| 4.50, JL2001 (ok), 10:43, 27/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Это сильно вряд ли, потому что из серии "а давайте все автоматически
> распараллелим" (что было модно лет эдак 25 назад, на этой волне
> появилось множество функциональных языков с упором на чистоту).
> Чтобы получить какой-либо прирост, работать с GPU надо вручную.
вас не удручает что в семействе современных х86 инструкции паралелятся автоматически по блокам исполнения а не ручками ?
| | |
|
|
|
| 1.34, ram_scan (?), 16:23, 20/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Феерично. Сначала придумали жабу, с лозунгом "подгузник - здесь ж0пу себе вытирать не надо", потом выяснили что ан все-таки памперсы менять накладно, да и ж0па в памперсе все одно остается грязная, теперь наняли GPU, который раз в 15 минут обходит весь детский сад и всем ж0пу вытирает, вне зависимости от того погадил киндер или нет. Что завтра придумают чтобы ж0пу не вытирать когда это нужно и не вытирать когда не нужно ?
Я вот все думаю, неужто вся эта автоматика проще и гигиеничнее чем самому бумагой туалетной пользоваться ?
| | |
| |
| 2.37, ВовкаОсиист (ok), 16:37, 20/08/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Абсолютная правда. Только вот те гики которые считают себя программистами, не слышали про делит вообще. Типа "Освобождать память? Не, не пробовал"
| | |
| |
| 3.38, Аноним (-), 19:05, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
delete хорош и крайне полезен, когда речь идёт про C++(аналогично retaiin/release в Objective C и free в plain C).
Если поделитесь, как использовать delete в Java — буду очень признателен
| | |
|
| 2.40, Crazy Alex (ok), 19:56, 20/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Это к чему вообще? Очевидно же, что к сборке памяти GPU вообще никакого отношения иметь не будет.
| | |
| |
| 3.41, ram_scan (?), 22:51, 20/08/2012 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Вы новость читали вообще ? Цитирую: "В JVM планируется добавить поддержу генерации кода для GPU, обеспечить сборку мусора для этого кода".
Сборщик мусора, "теперь и банановый" (ц).
| | |
| |
| 4.44, Nuzhny (?), 11:29, 21/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что память выделяется на видеокарте. Кто по твоему должен её освобождать? Стандартный сборщик мусора это не умеет, разумеется, надо добавлять поддержку. Что в этом такого страшного?
Кроме того, видеопамять не будет выделяться часто и мелкими блоками. Как правило, это происходит крайне редко: при начале и окончании потока вычислений. И выделяются сразу большие буферы для матриц, изображений, буферов обработки звука и т.д. и т.п. Сборка мусора для таких вещей будет оказывать практически нулевой эффект на производительность.
| | |
|
|
|
| 1.47, sneer (??), 15:17, 21/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
господи какой деский сад. И про задержки в т.ч. погуглите azul JVM. Никаких там мега пауз нет. Кто вам сказал что GPU будет мусор собирать?
| | |
|
