Microsoft будет на конференции JavaOne

JAVA - R.I.P.

бесталковая межкорпаративная оргия над помирающей фигней

>rusty_dm бест_о_лковая, а не "бесталковая"

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

--седайко стюмчик

>помирающей фигней

Жаль, что основные игроки индустрии не знают про это

а баломёр танцевать будет?

JAVA рулит ...

Как любят все-таки уважаемые ЛОР'овцы повесить на тот или иной продукт(событие) ярлычок позаметнее.. "помирающая фигня", "бестолковщина", "рулит", "ацтой".. как дети малые.. каждая технология имеет свои плюсы и свои минусы. Ярлыки вешают либо люди, не разбирающиеся с предмете разговора, но желающие выглядеть "покруче" в глазах общественности, либо те, кому технология/продукт просто субъективно не нравится, а аргументировать свои тезисы - автору лень (неплохо было бы услышать аргументацию, а?).

> Как любят все-таки уважаемые ЛОР'овцы повесить на тот или иной продукт(событие) ярлычок позаметнее.. "помирающая фигня", "бестолковщина", "рулит", "ацтой".. как дети малые.. каждая технология имеет свои плюсы и свои минусы. Ярлыки вешают либо люди, не разбирающиеся с предмете разговора, но желающие выглядеть "покруче" в глазах общественности, либо те, кому технология/продукт просто субъективно не нравится, а аргументировать свои тезисы - автору лень (неплохо было бы услышать аргументацию, а?).

Ну, ты высказался. Только зазря это всё... Максимум, чего ты добьёшься от местных анонимусов, это: "папа, а с кем это ты сейчас разговаривал,а?"

не лень просто не торчу тут постоянно =)
а может и лень объяснять что мир прекрасно обходится без Java
а если где она и используется так только потомучто авторы извращенцы и не хотят/не умеют делать вещи по нармальному
все это имхо...

зы
оно жрет дофига проца и памяти - факт

Нет, он будет петь. Только не "developers, developers, ...", а "жабобыдлокодеры, жабобыдлокодеры!". Рэпак такой, типа.

> оно жрет дофига проца и памяти - факт

Ну и что? По соотношению "сколько оно хорошего делает"/"скольно оно жрет" одна из самых сбаоансированных технологий для реализации слоя бизнеслогики, не зря даже геймплей многих 3d-игр на Java пишут (см., например, Chrome).

P.S. Продолжать _здесь_ на эту тему дискутировать не буду, смешно :)

> а может и лень объяснять что мир прекрасно обходится без Java
а ярлыки вешать не лень ?

>зы оно жрет дофига проца и памяти - факт

И это все? Купи еще памяти, или для тебя это сейчас проблема?

Так оно жрет все, скока ни дай ))) и тормозит.. тормозит... ))))

> Так оно жрет все, скока ни дай ))) и тормозит.. тормозит... ))))

Такой значит из тебя программер.

>Так оно жрет все, скока ни дай ))) и тормозит.. тормозит... ))))

Интересно, а на чем написан ДУМ-3? Не на Яве?

Скорее всего. Уж очень натурально тормозит.

Ты лги, но не слишком завирайся. Вот если бы сказал про соотношение "насколько его разрекламировали, и как много знающих его дворников на рынке труда" к "какое оно кривое технологически" - была бы правда. А так - стандартные бредни безграмотных жабофилов.

Можно линки на высказывания более авторитетного эксперта по языкам программированиям чем жалкий анонимус, который пишет максимум два + два. :)

Можно линки на высказывания более авторитетного эксперта по языкам программированиям чем жалкий анонимус, который пишет максимум два + два. :)

Читай, что Луговский про Java пишет.

А что он пишет? Много кто что пишет....

Я не программер я юзер )))))

>>бесталковая межкорпаративная оргия над помирающей фигней

Она и изначально не сильно дышала -но мощные инъекции SUN ,да и всего мира IT ...IT индустрия пока специально тянет к себе мир сложных и глючных продуктов,потому что на них можно больше денег заработать -С,С++,JAVA,C# -эти четыре уродца IT мира да и ещё куча написаного этими языками софта и софта написанного для программирования на этих языках.Сговор крупных корпораций -им бесполезно объяснять, что правильно или нет.Всё равно что попу в церкви объяснять что кремировать труп удобнее.Он не откажется от взимания денег за панихиду ,кучу свечей продваемых втридорога ,всякий там 9 -40 день итд,потому что он лишиться заработка , а точнее жирного куска. Где то на cnews.ru сегодня была статья что количество ит служащих будет сокращаться.думаю это правда-сколько можно тянуть на себя одеяло-то :) называется профессиональная этика эта вешь - у продавцов своя ,у врачей своя у IT своя.Правило такое, если зарабатываешь деньги нечестно(точнее не выполняя свои обязаности)-никому не рассказывай.И даже если сосед знаешь что он делает так -тоже молчи -станет сосед меньше зарабатывать и тебе меньше достанется

Я надеюсь, остальные учясники запасутся пищевыми протухтами третево сорта заранее?

> С,С++,JAVA,C# -эти четыре уродца

Ладно, а первые два тебе чем не угодили?

Жаба, быдло, кодеры, жаба, быдло, кодеры - подключааайся к самым-самым! Йоу!

>Так оно жрет все, скока ни дай ))) и тормозит.. тормозит... ))))

Лох - это судьба. У меня не тормозит, а летает

> оно жрет дофига проца и памяти - факт

Про ключи -mx и -ms автор точно не слышал.
Ява жрет ровно столько, сколько ей _жестко_ задали.
Чем больше объем ОЗУ, тем реже запускается сборщик мусора - меньше суммарные overhead.

Про "жрет много проца" - это для программ по умолчанию.
Ява позволяет писать программы с заданным
и _заранее гарантированным_ уровнем производительности.
Т.е., если устраивает скорость - не трогаем.
Если не устраивает, и это критично - только тогда
начинаем оптимизировать.

Один тот факт, что GC в жабке хочет иногда до 50% машинного времени - уже клеймит её позором, нормальные GC далее 5% не высовываются.

Джава нужна - всё-таки нужны программы, которые запускаются и на РС и на телефонах и везде где только можно. Главное, чтобы народ не свёхивался на джаве, а то вон и квак2 переписали - зачем? Может и ось на джаве напишем? Тем более, что язык по-сути выгоден производителям железа... Ниша, у джавы есть своя ниша, главное, чтобы она от туда не вылезала. А то этот бред (мощное железо - делаем тупниковое ПО), никуда кроме как в тупик не приведёт, т.к. тупниковое ПО - это убогие алгоритмы и как слетствие - гора нечитаемого кода -> долгая, но смерть проекта.

>Про "жрет много проца" - это для программ по умолчанию. >Ява позволяет писать программы с заданным >и _заранее гарантированным_ уровнем производительности. >Т.е., если устраивает скорость - не трогаем. >Если не устраивает, и это критично - только тогда >начинаем оптимизировать.

Стоп. Так ведь тормоза когда GC запускается. Сама по себе прога не тормозит. А от GC не избавиться.

>Чем больше объем ОЗУ, тем реже запускается сборщик мусора - меньше суммарные overhead. Плохо, что прога может сожрать для какой-то операции 100Мб памяти, потом ей столько не нужно, скажем 50Мб хватит за глаза, а 50Мб она так и не отдаст системе, пока ее не перезапустишь

>тупниковое ПО - это убогие алгоритмы и как слетствие - гора нечитаемого кода -> долгая, но смерть проекта.

Как раз убогие алгоритмы на Lisp - гора нечитаемого кода, а алгоритмы на Java как раз читаемые легко даже студентами в силу сквозного ООП.

Почему тогда в Лиспе GC не более 5 процентов жрёт, а в Жабе постоянно вылезает до 50%?

Ни хрена ты просто в Лиспе не понимаешь, быдлёнок гнойный. Сдохни на хрен, вонючий выродок.

> Ни хрена ты просто в Лиспе не понимаешь, быдлёнок гнойный. Сдохни на хрен, вонючий выродок.

Что, опять Луговского на выходные из психушки выпустили? Ох, не доведёт это до добра, покусает он кого-нибудь, придётся потом уколы от бешенства делать...

> Джава нужна - всё-таки нужны программы, которые запускаются и на РС и на телефонах и везде где только можно.

открою, блин, глаза: уже давно есть питон, у которого одна виртуальная машина со следующей версией перла!
на эту виртуальную машину (пэррот) можно прикрутить сколько угодно языков!
и только так правильно: кроссплатформенность НЕ ДОЛЖНА ограничивать выбор языка программирования.

Читаю я и охреневаю - это ж надо, до 50%, ужоснах %)
А теперь по делу: всем тем, у кого java отжирает по 50% времени работы нужно срочно прочитать о настройке GC. Ибо есть настройки по умолчанию, которые далеко не всегда оптимальны для ВАШЕЙ программы. Есть не менее 5 разных сборщиков мусора, работающих в разных комбинациях, их применение полностью документированно. Есть средства диагностики, которе точно покажут, какая часть heap'a и какого типа сборки GC являются узким местом. Например ваша программа активно распределяет память под короткоживущие объекты. По умолчанию размера eden может не хватать, из-за чего будет происходить слишком частый вызов minor сборщикa.
Пример из личного опыта: под нагрузкой приложение тормозило, причем работа GC занимала до 50% всего времени. Путем выбора правильной комбинации для minor и major сборщиков и веоичины footprint удалось свести потери на GC с 50 до 0,2%.
На сайте sun есть пара замечательных статей, которые дают достаточно информации по этому поводу. например "Turbo-charging Java HotSpot Virtual Machine, v1.4.x to Improve the Performance and Scalability of Application Servers", "Tuning Garbage Collection with the 5.0 Java Virtual Machine"
Google вам в руки. Sapienti sat.

>а если где она и используется так только потомучто авторы извращенцы и не хотят/не умеют делать вещи по нармальному

Читать сначала научись, юноша. Потом ремарки будешь писать. Такое ощущение, что за написание тупорылых сообщений на лоре Вам денег доплачивают. Так все стараются свою тупость показать.

> оно жрет дофига проца и памяти - факт

А еще кроме J2EE нет альтернативных технологий с таким охватом корпоративных задач, и подобно J2SE технологий, которые работают практически на любой платформе и подобно J2ME почти во всех телефонах в мире. Да, жрет немного памяти, но работает автоматический сборщик мусора и нет, или практически утечек памяти. Да жрет процессор, немного, но если писать программы правильно (чему надо учиться, это тебе не на баш сгавнякать чего-нить), то работает очень быстро. Быстрее, чем скажем на С. Значительно быстрее. А сейчас еще есть возможность прозрачного использования в отрисовке OpenGL, надо только при запуске указать определенную переменную окружения. И список этот можно продолжать до бесконечности... Покажите мне такую технологию еще одну. А нету больше такой.

это все слова. вроде бреда фанатиков D3. сколько я не перепробовал софта на жабе - он жутко тормозит. а мужики то не знают (с)

> сколько я не перепробовал софта на жабе - он жутко тормозит.
это сайт у тебя тоже тормозит ?

2 stasL:

>Да жрет процессор, немного, но если писать программы правильно (чему надо учиться, это тебе не на баш сгавнякать чего-нить), то работает очень быстро. Быстрее, чем скажем на С. Значительно быстрее.

Сколько тебе лет, мальчик? Прекрати нести всякую ересь, а то получишь от взрослых дядей по губам :-)

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

Итак, я даю тебе задачу, типичную и для Си, и для Java. Если ты сможешь при всей своей опупевшей наглости получить на Java производительность выше, чем у моего решения на Си - то это войдёт в историю ЛОРа, а я публично покаюсь за все наезды на Java, какие только были.

--

В.С. Луговский, mauhuur -at- gmail -dot- com

1) Нормальный GC динамически подстраивается под нагрузку. Во многих ситуациях характер нагрузки заранее предсказать нельзя.

2) До 50% в среднем - это при оптимальной настройке убогонького жабского GC, по умолчанию на многих задачах оказывается под 95%

>>1) Нормальный GC динамически подстраивается под нагрузку. Во многих
>>ситуациях характер нагрузки заранее предсказать нельзя.
Да, нельзя. Но всегда есть рабочий режим. Вот обслуживает моя система 1000 человек в пике согласно требованиям заказчика с требуемым временем отклика. Для меня это верхняя граница(+запас по прочности). Я дал такую нагрузку, получил GC 85%. Оттюнил, получил 0,5%. Все, при меньшей загрузке затраты на GC будут меньше, латентность системы в пределах требований. Этого достаточно, нагрузка при 10000 пользователей меня не интересует. А если нужно 10000, то это другая система, возможно даже с другой архитектурой.
>>2) До 50% в среднем - это при оптимальной настройке убогонького жабского GC, по умолчанию на многих задачах оказывается под 95%
Слишком смело сказано. GC в одной только реализации SUN около пяти, в том числе и адаптирующиеся динамически под загрузку. У BEA есть свои реализации GC(там адаптивный GC вообще по умолчанию запускается)+у IBM свои.
Что касается 50% в среднем, то мой личный опыт, на моих серверных задачах, говорит мне, что это не так. Вы можете оставаться при своем мнении, но вот собственным логам GC я верю больше :)

Да, а где, по вашему мнению, не убогий GC ?
Lisp, python, haskell, .NET ? Какая-гибудь академическая разработка ?
Тут встает 2 коварных вопроса
1) написана ли на этом языке с неубогим GC пара-тройка серьезных систем, которые оную неубогость могут подтвердить?
2) если они (языки с неубогими GC) такие продвинутые, отчего та-же SUN не имплементирует что-то подобное? или вы заведомо считаете тамошних программистов тупыми ограниченными кодерами ?

Я говорю про свои задачи - огромное количество короткоживущих очень маленьких объектиков. Ни в одной JVM нет хорошо затачиваемого под такой тип нагрузки GC. И про 50% я насвистел, кстати - меньше 60 не получается в принципе.

Сравни с GC, используемым в OCaml-е - он туп, как пробка, но при этом на порядки быстрее любого GC в любой JVM. Главное - там очень быстрая операция выделения памяти, никакая JVM из врождённых ограничений никогда так не сможет.

В OCaml-е - не убогий.

Серьёзных систем - полно, но это не подтверждение. Приемлимое подтверждение - бенчмарки.

2) Sun по барабану на такие типы нагрузки. Кодеры у них может и не тупые, а вот дизайнеры - такие, как Гослинг - упёртые бараны. Хотя - нет, кодеры тоже тупые. Посмотри на сырцы HotSpot. Если не стравишь - героем будешь!

в линксе? нет =) пробовал limeware, azureus, читалку книг - это недавно. до этого давно пробовал уже не помню что за софтины. у меня тогда стойкое отвращение к жабе выработалось - большое, тормозное. вот недавно решил проверить как дела - воз и там же

Вот видишь - ты тоже говоришь о своих задачах :). Потому нельзя быть таким категоричным - задач много. Работает старое правило 80\20
Что касается твоей задачи.
Cтранно, что такая большая разница получается. Маленькие, это сколько ?
Дело в том, что для минорных сборок принципиально алгоритм ведь не сложный, там не нужно дерево объектов обходить даже - простое тупое копирование идет из области А в область Б - чего уж проще-то ?

Да, действительно самый больщой вклад будет вносить операция распределение памяти.
Но можно выкрутится другим способом - увеличить размер minor поколения, тогда сборки будут реже за счет расхода памяти.
Что касается серьезных систем, то окамл я все таки с J2EE равнять не буду. Интересный язык, но я думаю, что для большинства коммерческих проектов он непригоден в силу малой распространенности, а следовательно, большей стоимости программистов и сопровождения. Хорошая академическая разработка для хороших академических проектов :)

Да не надо сравнивать количество библиотек и обученных обезьянок. Надо задаться вопросом, почему барашки из Sun не смогли сделать так же?