OpenOffice выходит в Интернет

>Жаба не нужна.

жаба конечно нужна. она довольно хороша в своей нише (а именно - EJB).

>Тогда почему если яво-прогу скомпилить gcj - она работает в несколько раз быстрее?

реально - она работает медленнее.

> Знаешь, сравнивать скорость работы Java против на C++ на основе программы, портированной с С++ на Java - это все равно что сравнивать удобство пользования OpenOffice после десяти лет работы в MS Office. Вроде кнопочки те же...

а что вы хотите сравнивать? Java => С++? давайте небольшую реализацию некоторого алгоритма на жабе, попробую портировать на С(++), сравним...

>Дружище, ты уж определись, тормозит оно или память отъедает?

владение памятью имеет цену, и немалую. начиная от TLB misses и gc, кончая свопингом.

>OOo написан на C++ и запускается на сервере пусть даже от имени непривелегированного пользователя, то есть неслабая возможность переполнить буфер (больная мозоль всех приложений на C/C++), используя активный контент, и получить права привелегированного пользователя/процесса.

если непривелегированный процесс может получить права привелегированного, то что то не так в консерватории. а вообще, даже в таком случае - SELinux.

ох - хотя что это я, у вас же бсд...

>а по памяти я думаю оно бы сравнялось с python (ну может на десяток метров меньше бы python требовал).

питон потребовал бы в несколько раз меньше.

>Ява может быть выгодна на серверной стороне, где её минусы нивелируются мощной машиной,

вашими устами глаголет истина.

> KTorrent намного функциональнее и быстрее

+1 имхо лучший torrent-клиент, азареус рядом не лежал...

>Тут на форуме пузомерка ка-то была. Я участвовал со стороны JAVA. Так в этой пузомерке JAVA обогнала GCC.

да ну! это про не про фибоначи ли? тогда жаба конечно НЕ обогнала даже ( довольно) тормозной gcc.

>Подтверждаю. Переносил k-ary btree упакованный в одномерный массив из джавы в С. Как не игрался с ключиками gcc, все получалось, что 'java - server' быстрее при случайном поиске на 10-100% в зависимости от размера дерева. В алгоритме много много трудоемких integer операций и совсем нет работы с указателями. Перед переносом я ожидал получить прирост при переходе на C в 1.5 - 2 раза, а получил падение производительности.

вы подтвердили только то, что очевидно вы не дружите с С.

Как вы думаете что делает sleep(1)?

> Аха, вот ещё пример: theora кодек, он реализован на С и перенесён на Java (cortado, один в один тот же код, только на Java перенесён). Ну и что же мы имеем? А и имеем мы примерно в 4 раза более медленный кодек.

Ну так может надо было переписать некоторые участки с учётом особенностей Явы? Лично я увидел в коде несколько моментов, которые на Яве можно было бы написать по другому. Например они используют функции Math.sin(), Math.cos(), которые принимают и выдают результат в double, и приводят результат в float. Налицо лишняя трата ресурсов. Если написать свой менее точный вариант float sin(float) и float cos(float), то можно сушественно поднять скорость.

>Как вы думаете что делает sleep(1)?

посмотрите 'man 3 sleep'. помоему любой школьник знает... а вы?

>а что вы хотите сравнивать? Java => С++? давайте небольшую реализацию некоторого алгоритма на жабе, попробую портировать на С(++), сравним...

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

+1, по мне так удобнее работать в ООФ, хотя бы при отсутствии в нем всяких отвлекающих излишеств как в МСОФ.
Насчет тормознутости - нагуиченный мсоф2007 ощутимо тяжелее ...

> сравнивать нужно не "небольшую реализацию", а наоборот, реальное приложение, оперирующее большой кучей объектов, имеющих различное время жизни.

ну нет, нет у меня сколько свободного времени, чтоб портировать "реальное приложение, оперирующее большой кучей объектов, имеющих различное время жизни"... кроме того, "приложение, оперирующее большой кучей объектов" может состоять из пяти строчек, а для "различного времени жизни" использовать rand() ;) поэтому повторюсь: не желаете ли подкинуть именно "небольшую реализацию" на жабе, так, чисто поиграться, посмотреть, самому же интересно ;)

> ибо тормоза жабЫ вовсе не от того, что в жвм хреновый оптимизатор байткод->нейтив.

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

>оказалось гмыл эти письма за спам принял :/

спасибо =)

> посмотрите 'man 3 sleep'. помоему любой школьник знает... а вы?
Насчет школьников не уверен. Увы, у меня детей ходящих в школу пока нет. А все-таки вы на вопрос не ответили.

> (Подвешивая петеьку на крючок) - давай, упади еще разок! Открой для себя ktorrent!

Поведаете о функциях недоступных в azureus и доступных в ktorrent (который, к слову сказать, довольно глюкавый)?

>не желаете ли подкинуть именно "небольшую реализацию" на жабе

пож-та:

class Fib {
  public static int fib( int n ) {
     if ( n < 2 )
       return n;
     else
       return fib(n-1) + fib(n-2);
  }
  public static void main( String args[] ) {
    int x = fib(45);
    System.out.println( "x = " + x );

  }
}

>Насчет школьников не уверен. Увы, у меня детей ходящих в школу пока нет.

я имел ввиду тех, что часто тусуются на лоре.

>А все-таки вы на вопрос не ответили.

отвечаю sleep(1) "усыпляет" вызывающего на 1 секунду (или до прихода сигнала).

>владение памятью имеет цену, и немалую. начиная от TLB misses и gc, кончая свопингом.

А если подумать, почему java-приложение начинает свопить? А?

Бебашенность в отношении создания новых объектов (при неумении использовать повторно уже созданные) может приводить к "шторму" аллокаций. Но это уже говорит о квалификации разработчика, о его руках. GC тут мало поможет.

> я имел ввиду тех, что часто тусуются на лоре.
Оставлю утвержденние о их осведомленности на вашей совести. Нет ни возможности ни желания проверять.

> отвечаю sleep(1) "усыпляет" вызывающего на 1 секунду (или до прихода
> сигнала).
Хорошо. Поставим вопрос по-другому. Что такое "усыпленный" процесс?

Кашмар

>Ладно, зайдем с другой стороны. Почему же тогда написанный на плюсах ОО тоже не летает, хотя все кричат что ++ быстрее жабы?

А где я упоминал о цпп? У вас, жабафилов, комплекс какой-то на тему С++, место ответа на поставленый вопрос начинаются крики "сам дурак".

>Сложновато будет. Ой как сложновато это всё написать на C++.

Во первых дорогие жабофилы, перестаньте наконец путать мужской половой орган с пальцем! Скорость разработки приложения != скорости его работы. Я полность согласен с тем, что ваять гуевые десктопные апликухи на жабе быстрее, и отсюда возникает вопрос: так почему же на жабе для десктопа никто не пишет? Почему на ней пишут только j2ee приложения, которые потом запускают на серваках с 16gb мозгов? Почему когда я пытаюсь заинсталить соплярку, ее инсталер требует минимум 768mb памяти для работы в графическом режиме, а инсталер Федоры, написаный на питоне, работает на чем угодно(нет, я не фанат питона)?

>Не передергивай. JAVA действительно быстрее C++

Ну да, как всегда у жабофилов "а мужики то и не знают". Глупенькие геймдевы и разработчики приложений для работы с графикой, продолжают бедненькие сношаться с кактусом. Они же ущербные не знают, что есть такая замечательная реактивная жаба, благодаря которой им больше не нужно будет вручную оптимизировать игру под многоядерники и собирать несколько разных бинарников под amd-intel. Все это за них сделает распрекрасная жаба не белом коне, да еще и бысрее работать будет. Может вы наконец отвлечетесь от промывки мозгов маркетологами Сан, и посмотрите правде в глаза: жабе уже сто лет в обед, а ее для десктопных приложений никто не юзает.

>А где я упоминал о цпп? У вас, жабафилов, комплекс какой-то на тему С++, место ответа на поставленый вопрос начинаются крики "сам дурак".

А где тут написано "сам дурак"? Я не "фил" и, в отдличии от вас, так не агрюсь на высказывания, спокойней надо, дышать чаще что ли...

>Во первых дорогие жабофилы, перестаньте наконец путать м...

Почему? А почему 90% установленных ос в мире на десктопе это виноуз? Вот и я не знаю, почему..

> пож-та:

плохой пример: алгоритм можно (и нужно) оптимизировать,
не индусы ж мы, всё-таки ;)

ну да ладно, пока оставим как есть:

$ time java Fib
x = 1134903170

real    0m43.150s
user    0m39.247s
sys     0m0.140s


$ time ./fib
x = 1134903170

real    0m38.113s
user    0m36.374s
sys     0m0.113s

хм... а теперь нафик фанатизм, вместе с рекурсией:

$ time ./fib2
x = 1134903170

real    0m0.005s
user    0m0.000s
sys     0m0.007s

зы: что-то я не понял юмора с этим примером. =/
    или мы хочем доказать одно и то же? ;)

>Не передергивай. JAVA действительно быстрее C++

Тогда милости просим сюда:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&am...

Лучше писькомерки по скорости языков нет! Автора в подтасовке обвинить в голову не приходит, чувак известен и приколен :)

Так что вперед - сабмитьте свой код чтоь всем им доказать :-)))

Ну а пока ... жаба сливает плюсне:
- по памяти - _всегда_
- по CPU - из 17 тестов - выиграла в 2х.
Первый regex-dna - в 1.7 раза (регэкспы),
другой sumfile - в 1.6 раза - тупое суммирование интов из файла. (кстати - тут непонятки - почему?)
- по размеру кода - выигрывает 9:8

из интересных сравнений - startup (Hello World!) - в 41 раз медленнее, у уж точно не для соман лайн утилиток типа ls/awk/cat/wd/ps/sed :)
А вот на серверах да га J2EE AS - самое оно :) Ну а на чем еще всю эту бодягу унылую типа бусинес-блин-логик делать?

НЕ IMHO
GR.

В ИЛ2 на java написан только GUI. Кстати посмотрите на его убогость.

http://www.ulteo.com/main/images/screenshots/ulteo-alpha1-scr01.jpg

Лажа. На скрине видно, что в браузере, на java, что-то вроде VNC клиента. На сервере обычный KDE с OpenOffice.

Каждому, кто может поднять свой VNC сервер, это не нужно.

>зы: что-то я не понял юмора с этим примером. или мы хочем доказать одно и то же? ;)

это пример, о котором говорил vada. видите ли, java -server активно инлайнит даже довольно большие (по размеру) методы, не взирая на потребление памяти (скорость выполнения в ущерб потреблению памяти). gсс, если явно не указано не инлайнит даже маленькие функции. подавляющее большинство пузомерок, где жаба (точнее сановская жвм ) выигрывает у gcc (там, где задействована нетривиальная рекурсия) играют именно на этом, но стоит указать gcc инлайнить мелкие функции ( -finline-functions ), как ситуация менается на противоположную и gcc оказывается впереди.

>А если подумать, почему java-приложение начинает свопить? А?

не знаю. просто ничего не приходит на ум. обычно это ядро ОС начинает свопить память процесса, как это происходит и почему - долго рассказывать. лучше почитайте.

>Бебашенность в отношении создания новых объектов (при неумении использовать повторно уже созданные) может приводить к "шторму" аллокаций.Но это уже говорит о квалификации разработчика, о его руках. GC тут мало поможет.

вы забываете об инфраструктуре. при работе жабского приложения, в память загружено много чего - интерпретатор, компилятор со всеми его таблицами, байт код приложения, куски найтив кода этого приложения, интернированные короткие строки и оберки над примитивными типами и т.д. и т.п. и все это жрет-с. посмотрите например на то, что написала сволочь:

>Тут еще просят пример хорошо приложения на Java. Вот вам: Jabber-ервер OpenFire 3.4.0 (кстати, имеющий коммерческое прошлое, что сразу заметно по качеству). Время работы 36 дней. По внутренним показателям потребляемая память 17 МБ (пр запуске было 13). Внешняя 80 МБ (при запуске было 60).

т.е. при увеличении портебления памяти приложением на 4М, память потребленная системой (приложение + жвм) увеличилась на 20М. я не перестаю удивляться, когда у меня idea показывает (на довольно большом загруженном проекте), что она стабильно жрет ~100-200М, а rss плавно растет до 700-850M легко.

>Хорошо. Поставим вопрос по-другому. Что такое "усыпленный" процесс?

процесс, который не получает процессорного времени. в линаксе, это процесс, у которого state в TASK_INTERRUPTIBLE или TASK_UNINTERRUPTIBLE или TASK_STOPPED (если правильно помню ).

> Поведаете о функциях недоступных в azureus и доступных в ktorrent (который, к слову сказать, довольно глюкавый)?

Это ваша задача - рассказывать о функциях и глюках азуреуса, раз у вас произошло выпадение стула.

>другой sumfile - в 1.6 раза - тупое суммирование интов из файла. (кстати - тут непонятки - почему?)

реализация iostream в gcc оставляет желать лучшего. при использовании fgets ситуация меняется на противоположную.

Неправда ваша. Все на том же сайте прога на 'C', так же отстала от Java 6 Server. Хотя она и использует fgets_unlocked который, кстати, быстрее fgets. Все это наводит на мысли, что где-то в JVM ручками сильно заоптимизировали чтение файлов с одновременным кастингом к базовым типам.

>А я помню движок ИЛ2 например, вроде ниче так был, правда? Кидаю камешек обратно, вот я наблюдаю перед собой ОО на плюсах и делаю вывод, что плюсы тормозят и жрут память аки фаерфокс :)

Я бы сказал, ничего хорошего. Смотрим на ТТХ летных симуляторов других фирм тех же лет и рыдаем.

У меня друг как раз увлекался - а уж в ИЛ года два играл.

>Во-первых, хоть какая ява тормозная, но скорость разработки на Java на несколько порядков выше чем на c++ (или с этим тоже будете спорить?). И поэтому, программисты будут писать на Java потому что это быстрее и легче.

Более того, часто скорость некритична. Посему у нас, например, сейчас приложение пишется, где серверная часть идет на java.

>KTorrent намного функциональнее и быстрее

В защиту лягушки могу сказать, что качает она быстрее. Уж не знаю почему - пускаешь ktorrent - сцуко, стоит как рыба об лед, че-то покачал, опять стоит.

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

Я уже и порты проверил и режимы работы - вроде все одно и то же. Мистика.

Это любители жабы специально на раздачу садятся и баннят тех у кого C++ ные torrent клиенты :).

> Это ваша задача - рассказывать о функциях и глюках азуреуса, раз у вас произошло выпадение стула.

Я ktorrent пользовался очень недолго и давно... но умеет ли он кикать и банить неугодные ip? Или вот например общая статистика скачанного? Ну или установить для отдельно взятой закачки up/down speed? Перемещать загруженные торренты в какую нибудь директорию? Или проверять какую-нибудь директорию и если там есть торренты, начать закачивать их?

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

> Да-да, мы знаем, что джава быстрее C и C++. Только сильнее тормозит. А так - быстрее.

Ну конечно же! Java ведь всё делает быстрее, лучше, сильнее. И тормозит -- тоже быстрее =))

> Ява может быть выгодна на серверной стороне, где её минусы нивелируются

Есть еще по меньшей мере один плюс именно на сервере. Была какая-то довольно древняя работа (2001 год), диплом про динамическую загрузку методов класса. Можно сделать умный линкер, который будет загружать только требуемые методы класса, и будет автоматически при загрузке/инстанцировании новых объектов грузить новую версию (естественно, если в новой версии не поломали совместимость). Постепенно старые объекты прибиваются и собираются GC, новые порождаются уже новой версии, то есть можно серверное Ява приложение обновлять "вживую", без остановки сервера/перезапуска. Естественно, это не во всех случаях работает, был набор ограничений когда так не получится (интерфейсы поломали например, но было что-то еще).

Ах эти мечты изобрести smalltalk :).