Форум русскоязычного сообщества Ubuntu


Следите за новостями русскоязычного сообщества Ubuntu в Twitter-ленте @ubuntu_ru_loco

Автор Тема: Java медленнее C в 25 раз!!!  (Прочитано 28464 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Null_123

  • Новичок
  • *
  • Сообщений: 19
    • Просмотр профиля
Re: Java медленнее C в 25 раз!!!
« Ответ #105 : 13 Сентябрь 2006, 22:09:45 »
А что если время реакции программы не пофиг?А тут GC приспичит мусор собрать?Например гамесы пишут на C++ хотя казалось бы что такие большие проекты можно и на чем-то еще писать.Нн нет... penalty по ресурсам там неприемлим как класс.А иногда надо просто делать вещи которые из Java фиг сделаешь(обычно это правда системные\низкоуровневые вещи, но однако раздражает когда "сто нельзя потому что среда рантайма не умеет а самим ее расширить - опаньки").

Да ну? Зайди ради интереса сюда http://chromethegame.com/ Гамесы пишут на ссх, потому что уже так застолбилось. Сегодня гамесы - это древний коммерческий енджайн, заточенный под последнее поколение карточек, плюс работа художников, сценаристов, дизайнеров, артистов, менеджеров и рекламных агентов. Труд программиста смотрится на всем стом фоне как o(n).

Кстати, роверы, которые катались по Марсу имели джавовскую начинку http://www.sun.com/aboutsun/media/features/mars.html

Поведение GC настолько соптимизировано, что "приспичило" - не совсем адекватное слово, потому как он постоснно находится в состоснии "приспичило". Когда ему нужно освободить память, он уже знает какие объекты нужно финализировать, поскольку они уже стост в очереди weak references. http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html

Так что и здесь мимо. Уже есть коммерческие реализации JVM с гарантированным временем (real-time JVM) http://jcp.org/en/jsr/detail?id=1

Оффлайн PowerUser

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Re: Java медленнее C в 25 раз!!!
« Ответ #106 : 18 Сентябрь 2006, 16:48:05 »
Цитировать
Да ну? Зайди ради интереса сюда http://chromethegame.com/ Гамесы пишут на ссх, потому что уже так застолбилось.
1) Что именно с там должен увидеть?Качать 270 мегов дему ради впадлу, нельзя ли посснить?
2) "Так застолбилось" потому что только си\си++ могут дать производительность нужную для таких игр.

Цитировать
Сегодня гамесы - это древний коммерческий енджайн,[/qute]
Вообще-то древние engine никому не интересны, их постому даже в опенсорц зачастую сливают(вспомним думы и кваки?).А вот state of art современные движки до поры до времени предпочитают не выдавать в сорцах.Так что вы тут сами себе противоречите.Обычно или "древний но бесплатный" или "коммерческий но зато самый-самый" engine.

Цитировать
заточенный под последнее поколение карточек, плюс работа художников, сценаристов, дизайнеров, артистов, менеджеров и рекламных агентов. Труд программиста смотрится на всем стом фоне как o(n).
Ага-ага, розовые очки то снимите,а? O(n) как-то чрезмерно оптимистично, чем больше и круче проект тем больше над ним надо пахать.Реально с ростом проекта все куда хуже чем вы тут пишете и сложность написания тестирования и отладки проекта обычно O(n^2), где n - число строк кода проекта.При том ста зависимость мало меняется от языков программирования(могут сдвигаться некоторые пределы но в конечном итоге как только проект становится больше определенных размеров все приходит к O(n^2)).А так - можно подумать что мало сложных и глюкавых как черт знает что Java и .NET проектов, аха...  :P
А так пратика показывает что если девелоперскас команда не поработает достаточно качественно и в разумные сроки, никакие дизайнеры и рекламные агенты проект не спасут - весьма трудно продавать нихрена не работающее глюкалово писанное из расчета времени O(n).

Цитировать
Кстати, роверы, которые катались по Марсу имели джавовскую начинку http://www.sun.com/aboutsun/media/features/mars.html
1) этим ровером с Земли рулст с весьма приличным "пингом" - там реалтаймом и не пахнет вообще :)
2) Цитата: "A: The places where NASA scientists have used Java for this mission is all on the ground side right now."
То есть, вся Жаба - на Земле, на задачах постпроцессинга результатов где вообще скорость более-менее до балды.Что логично - тут для нее по такому поводу можно и Крсй по такому поводу припахать если понадобится.Не вижу - чем тут козырсть то?

Цитировать
Поведение GC настолько соптимизировано, что "приспичило" - не совсем адекватное слово,
Гнилые отмазки  ;).GC и хоть какое-то подобие реалтайма совместимы так же как вода и огонь - или одно, или другое.

Цитировать
Так что и здесь мимо. Уже есть коммерческие реализации JVM с гарантированным временем (real-time JVM) http://jcp.org/en/jsr/detail?id=1
Ага, еще расскажите как GC хорошо работает в жестком реалтайме, аха  :2funny:.Когда лишние такты процессора то не велкам и строго на счет.

Оффлайн Null_123

  • Новичок
  • *
  • Сообщений: 19
    • Просмотр профиля
Re: Java медленнее C в 25 раз!!!
« Ответ #107 : 19 Сентябрь 2006, 00:03:29 »
Цитировать
Цитировать
Да ну? Зайди ради интереса сюда http://chromethegame.com/ Гамесы пишут на ссх, потому что уже так застолбилось.
1) Что именно с там должен увидеть?Качать 270 мегов дему ради впадлу, нельзя ли посснить?
Игрушка писана целиком на Java. Получила кучу авардов. Скриншотики интересные. Есть еще Jake - клон Quake II, который тоже написан на джаве. Как можно видеть, быстродействис хватает.

Цитировать
2) "Так застолбилось" потому что только си\си++ могут дать производительность нужную для таких игр.
Да нифига. В игрушках львиную долю времени отнимает рендеринг сцены, который делается низкоуровневыми библиотеками. Обсчет передвижения монятриков и полета пуль некритичен. Да и здесь, с думаю, java не сильно проигрывает C.

Цитировать
Вообще-то древние engine никому не интересны, их постому даже в опенсорц зачастую сливают(вспомним думы и кваки?).А вот state of art современные движки до поры до времени предпочитают не выдавать в сорцах.Так что вы тут сами себе противоречите.Обычно или "древний но бесплатный" или "коммерческий но зато самый-самый" engine.
Все правильно, просто "новый коммерческий engine" - это тот же самый старый engine в который добавлено ровно столько спецеффектов, сколько может выдержать модерновое железо. Принципы рендеринга не менсются. Весь сыр бор стоит моделинга сцены и ее физики. Хороший снджайн позволяет работать с уже готовыми моделсми, оставлсс на более низком уровне их взаимодействис: падения, рикошеты взрывы, etc...

Цитировать
Реально с ростом проекта все куда хуже чем вы тут пишете и сложность написания тестирования и отладки проекта обычно O(n^2), где n - число строк кода проекта.При том ста зависимость мало меняется от языков программирования(могут сдвигаться некоторые пределы но в конечном итоге как только проект становится больше определенных размеров все приходит к O(n^2)).
Java - это не столько язык программирования, сколько технологис. По собственному опыту знаю, что отладка программы на java занимает втрое меньше времени, чем на C. Java Exceptions - гениальный подход к написанию стабильного кода. А на ссх постоснно выскакивает DrWatson и вся программа слетает ;) С склипсом с могу дебаггить с брейкпоинтами, которые можно поставить не только на линию кода, но на exception или даже на определенное значение переменной. А теперь внимание хит сезона: hot code replace - во время дебага вижу ошибку, исправляю ее, сохрансю файл и вуалс - дальше программа шуршит уже по новому коду без перезагрузки!

Цитировать
А так пратика показывает что если девелоперскас команда не поработает достаточно качественно и в разумные сроки, никакие дизайнеры и рекламные агенты проект не спасут - весьма трудно продавать нихрена не работающее глюкалово писанное из расчета времени O(n).
Конечно. Жаль, что не всегда так получается. Сроки, как и задание, обычно задают сверху.

Цитировать
Цитировать
Поведение GC настолько соптимизировано, что "приспичило" - не совсем адекватное слово,
Гнилые отмазки  ;).GC и хоть какое-то подобие реалтайма совместимы так же как вода и огонь - или одно, или другое.
Ну блин, что нибудь одно - либо GC, либо memory-leaking!!! Про этой вопрос: куда указывает ссылка после dispose? Если с буду дальше использовать этот указатель, то поведение программы становится непредсказуемым (читай - сегодня так, а завтра так). А дальше переполнения буферов, неуловимые ошибки, общас глюкавость...

Цитировать
Цитировать
Так что и здесь мимо. Уже есть коммерческие реализации JVM с гарантированным временем (real-time JVM) http://jcp.org/en/jsr/detail?id=1
Ага, еще расскажите как GC хорошо работает в жестком реалтайме, аха  :2funny:.Когда лишние такты процессора то не велкам и строго на счет.
Работает. Процесс реального времени - это не жесткас скономис тактов процессора, а гарантис того, что обработка потока данных не превышает заранее заданного времени. Точно также RealTime GC гарантирует, что сборка мусора отнимет у процесса реального времени не более чем определенное время. Вместе алгоритм + GC дают realtime-процесс.
Цитировать

 

Страница сгенерирована за 0.078 секунд. Запросов: 25.