jEdit 4.3

>Поэтому джава может быть быстрей и Си и Ассемблера

Млжет быть джаба может быть еще и быстрей скорости света?

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

Хватит слушать маркетологов, а пора думать головой. Моны с дотнетами и жабами не заменят добротной проги на Си.

>p.s. я правда с серверной жабой пляшу с бубнами, а не с гуем.

Гыгыггы. Вот это записать и всех джабофобои/дотнетофобов тыкать мордочкой если они начинают борзо задвигать про память и Си. В больших апликухах на джабе, оказывается еще больше проблем чем если бы они были написаны на Си. непредсказуемость работы сборщика муссора иногда засаживает обезьянку на месяц за комп и подбор ключиков к GC. Другое дело Си - раз написао программу, отладил и таким маразмом больше не страдаешь.

>простой пример: -XX:+UseParallelGC + -XX:ParallelGCThreads=30 - тыч ситаешь, что дав 30 ниток под garbage на сингл процессоре, который может быть занят чем нибудь еще многонитевым (или само жаба приложения активно io юзает в нитях), ты не повлияешь на производительность системы?? уменьшится она адназначна.

Речь не о том как нагрузить систему до состояния клинической смерти, я тебе могу 1001 вариант расписать.

Речь о том, как сделать gui _отзывчивым_.

или дав размер стэка более (или не кратно в 2-4 раза) L2 ты не повлияешь? опять же уменьшишь латенси.

Нет. Латентность GUI не изменится.

p.s. я правда с серверной жабой пляшу с бубнами, а не с гуем.

p.p.s а для gui по моему всегда было простое правило, не юзать тришолды, ставить -batch и AggresiveOpts и обычно достаточно p.p.p.s http://java.sun.com/performance/reference/whitepapers/tuning.html - как стартовая точка - вполне

Всё это читано, перечитано и много раз перепробовано.

Объясняю, ни тришолды ни агрессивная оптимизация никак не влияют на квант времени выделяемый процессу. Это прерогатива ядра Linux. Чем меньше квант времени тем более отзывчивый будет GUI в том числе и java GUI, в ущерб разумеется производительности.

> Объясняю, ни тришолды ни агрессивная оптимизация никак не влияют на квант времени выделяемый процессу. Это прерогатива ядра Linux. Чем меньше квант времени тем более отзывчивый будет GUI в том числе и java GUI, в ущерб разумеется производительности.

я пожалуй соглашусь, я похоже к ГУЮ с сервачной линейкой подошел ;)

> Гыгыггы. Вот это записать и всех джабофобои/дотнетофобов тыкать мордочкой

обязательно запиши, только не забудь записать, что именно делает c/c++ приложение (сколько на него к тому же затрачено какими людскими ресурсами и прочее), а потом попытайся записать, что делает делает жаба приложение.... боюсь чернила в ручке кончатся ;))

>Пойми, такие языки как джаба быстрее Си, а тем более ассемблера быть не могут по определению. Тыбы еще сказал что джаба может быть быстрее машинного кода процессора.

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

>обязательно запиши, только не забудь записать, что именно делает c/c++ приложение (сколько на него к тому же затрачено какими людскими ресурсами и прочее), а потом попытайся записать, что делает делает жаба приложение.... боюсь чернила в ручке кончатся ;))

когда говорят Java обычно имеют ввиду язык java + набор стандартных классов. Если взять к примеру Qt и С++ тут никакой разницы не будет, те же грабли в профиль, и низким порогом вхождения.

>Джава может быть быстрее программы на С за счёт модификации исходного кода в рантайме.

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

Да, сишная прога тоже так может чисто теоретически, но не практически - самому в ручную это делать нереально сложно и не кроссплатформенно.

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

>а потом попытайся записать, что делает делает жаба приложение....

джаба приложение всегда тормозит. больше оно ничего никогда не делает.

Мне вот всегда было интересно. Почему жаба кодеры такие *бонутые на всю голову? Неужели вы и вправдо думаете, что переписав весь софт на джабе, вы спасете Вселенную? Тупые идиоты. Жаба нишевый язык. Универсального нет ничего. Тупее джаберов только дотнетчики те вообще готовы минеты Балмерцу строчить и с плакатами бегать.

Slava Pestov смотрит на jEdit как на самизнаетечто.

джаба приложение всегда тормозит. больше оно ничего никогда не делает.

Как эпичненько. Пиши ещо. У тебя получается

Жаба нишевый язык

На жабе клин светом не сошелся. Для JVM есть от Jython-а до CloJure и Kava. Сейчас у Sun одна задача, сделать возможным на клиенте запускать много много разных jar в одной JVM. Пока же для каждой программы запускается своя JVM, это вызывает огромный перерасход памяти на дублирующиеся либы

Посмотрю я на тебя как ты кернел на жавке похабной перепишешь.

Кернелу тому нужно обслуживать максимум 30 устройств. И шедулить максимум 100-150 процессов. не удивительно, что такую х..ню смог напейсать финский недоучка-студиозус на втором курсе.

А я на тебя посмотрю, как ты на своем Цы без Sping и JavaEE напишешь сайт а-ля www.nfl.com, который вынужден обслуживать сотню миллионов запросов с компов и мобил когда вся америка ломицца посмотреть турнирную таблицу и новости с любимого чемпионата. Удачи тебе с твоим дебаггером Цы

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

Android какбэ говорит разработчикам Цы «Прощайте, вы больше не нужны»

> А я на тебя посмотрю, как ты на своем Цы без Sping и JavaEE напишешь сайт а-ля www.nfl.com

А я на тебя посмотрю, как ты на своем Sping и JavaEE напишешь сайт а-ля www.nfl.com. Удачи тебе с твоим сборщиком мусора.

Гы. Знатно слил.

www.nfl.com FYI и написан на JavaEE

> > А я на тебя посмотрю, как ты...

Гы. Знатно слил.

www.nfl.com FYI и написан на JavaEE

Гы. Знатно слил.
При чём тут вообще JavaEE?

Я не говорил, что сайт невозможно написать на JavaEE. Я говорил, что _ты_ не сможешь этого сделать.

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

Все эти разговоры про «Жаба быстрее C» - маркетоидный бред. Выбрали одну вещь (branch prediction), которую Жаба может делать в рантайме, а компиляторы могут хуже (хотя profiling никто не отменял), и дрочат на нее.

Жаба может приближаться в скорости, скажем, в численных вычислениях, к неоптимизированному нативному коду, не более того (после того, как перекомпилит все в JIT). А так - действительно, достаточно включить мозг, и прикинуть, сколько времени тратит, скажем, Intel Compiler на компиляцию с сильными оптимизациями проекта эдак с миллион строк.

Уж если не смогу на JEE, то на цэ и подавно неасилю.

Скажите, а почему на ЛОРе программы на Ассемблерах, Сях, Сях с крестиками, Паскакале, Лиспе, Моне, Qt и на всех прочих языках программирования, платформах, рантаймах и либах попадают в категорию «Open source» или «GNOME», или «KDE», или «Игры», или еще куда, а которые на Java — в категорию «Java» вне зависимости от лицензии и предназначения? Это что, главная их отличительная черта?

On second thought, срач сразу начинается на тему «Нужна ли Java».

> в категорию «Java» вне зависимости от лицензии и предназначения

Исторически сложилось так. Изначально я хотел положить новость в категорию «Open Source», если бы не этот факт.

>Уж если не смогу на JEE, то на цэ и подавно неасилю.

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

>>а потом попытайся записать, что делает делает жаба приложение....

джаба приложение всегда тормозит. больше оно ничего никогда не делает.

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

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

если бы ты сказал perl а не пых - с тобой еще можно было бы споорить, а так ...

p.s. ты кстати memcached/db забыл - без этого точно не полетит и забыл сказать про легкие апачи на фронте, уж не говоря про модуль апача, это просто сливффффф..... ;)

Эти поцаны темнеменее уже год тужатся и не могут запустить gosuslugi.ru на своем сраном пыхе. Ололо. Хотя нагрузка на него предполагается всего в миллионы запросов. В день. А не сотни миллионов в час.

>А не сотни миллионов в час.

На NFL нагрузка 100M в час?! Можно пруфлинк?

>только сначала java программа потормозит некоторое время, пока код не перекомпилирует в рантайме и так каждый раз. Java не рассчитана на десктоп.

Не расчитана и не только по-этому.

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

Если вы компилируетесь с некоторой исошкой берёте в ней фунци. getMe() которая тупо возвращает значение - ниакой компилятор вам эту функцию не заинлайнит. А джава - завпросто. Джава рулит там, где велика косвенность - что критично на серверах, IoC всякие.

При кривом алгоритме и руках не и того места от куда нужно, никакой компилятор или jit не поможет.

Спасибо, К.О.

Вопрос: я слышал что .net компилит все приложение сразу, а Java по мере выполнения - поэтому кажется что тот быстрее явы. Можно ли яву опциями заставить себя вести так же?

ЗЫ Прописал опции в настройки NetBeans - действительно стало несколько быстрее. Но по сравнению с Qt Creator, в котором все молниеносно, у NetBeans сувствуется некоторая задержка. Причем на самой примитивной задаче - всего лишь какое-то там GUI... Эх, если б не скорость GUI - NetBans был бы моей IDE...

>я слышал что .net компилит все приложение сразу, а Java по мере выполнения - поэтому кажется что тот быстрее явы.

.НЕТ никогда не интерпретирует, но такое же поведение можно задать и в джаве указанием параметра. Это замедлит загрузку, но, возможно, уменьшит задержки в работе. у .НЕТ есть более интересная штука, AOT, что бы не компилить всё каждый раз заново.

>Вот это записать и всех джабофобои/дотнетофобов тыкать мордочкой
Школота такая школота.
Ты хоть знаешь что ты написал-то?
Дитятко не вкурсе смысла слова «фобия», гы-гы.

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

>Android какбэ говорит разработчикам Цы «Прощайте, вы больше не нужны»

В этом месте подробнее

Вопрос: я слышал что .net компилит все приложение сразу, а Java по мере выполнения - поэтому кажется что тот быстрее явы. Можно ли яву опциями заставить себя вести так же?

Можно. Нужно выбрать для исполнения серверную JVM, а не клиентскую:

netbeans_default_options="
-J-server
-J-Xms256m
-J-Xmx512m
-J-Xss20m
-J-Dsun.java2d.noddraw=false
-J-Dswing.aatext=true
-J-ea
--cp:p /home/igor/bin/netbeans/etc/PlafTheme.jar
--laf floresiris.plaf.metal.EmeraldMetalLookAndFeel
-J-Dswing.metalTheme=steel
-J-Dfile.encoding=UTF-8"

Кстати, а какой именно из этих параметров делает полную компиляцию программы перед выполнением?

>Можно. Нужно выбрать для исполнения серверную JVM, а не клиентскую:

школота, такая школота.

JVM запущенная с опцией -client выполняет компиляцию метода в нейтив после 1500 вызовов, JVM запущенная с опцией -server выполняет компиляцию метода в нейтив после 10000 вызовов. Для компиляции метода после нужного количества вызовов от 1 и более нужно использовать -XX:CompileThreshold= от 1 до X.

>Кстати, а какой именно из этих параметров делает полную компиляцию программы перед выполнением?

Никакой, -XX:CompileThreshold=1 позволяет после первого вызова метода в нейтив скомпилировать, но так будет при каждом запуске происходить. Ничего подобного AOT (Ahead Of Time), как в .Net/Mono в Java нет. Java не предназначена для десктопа изначально.

> Ничего подобного AOT (Ahead Of Time), как в .Net/Mono в Java нет. Java не предназначена для десктопа изначально.

А когда будет такое + опционально кэширование одной и той же программы - то есть шанс на десктопность? Только ли это различие корень проблемы?

>Ничего подобного AOT (Ahead Of Time), как в .Net/Mono в Java нет

Насколько я знаю, спецификация не предписывает метод компиляции. Точно есть JVM с AOT вместо JIT (например, Excelsior Jet - http://www.excelsior.ru/products/jet.html)

Да и кэширование скомпилированного кода вроде бы допиливают.

>А когда будет такое + опционально кэширование одной и той же программы - то есть шанс на десктопность? Только ли это различие корень проблемы?

Кэширование чего? Почитай. что такое AOT...

Когда будет реализован AOT Java сможет полноценно использоваться на десктопе, тормоза swing gui при правильных руках можно нивелировать почти полностью. Во всех остальных аспектах Java полностью готова.

>Насколько я знаю, спецификация не предписывает метод компиляции. Точно есть JVM с AOT вместо JIT (например, Excelsior Jet - http://www.excelsior.ru/products/jet.html)

ключевой момент - за деньги.

>Да и кэширование скомпилированного кода вроде бы допиливают.

Когда допилят тогда и будет что обсуждать, если сан раньше не загнётся.

Для андроида апликухи нужно писать на Java

Пруфлинка нет. Но в США живет около 350млн человек. ~100 млн. из них мужиков. Как ты думаешь, на каком сайте большинство из них смотрит показатели команд в дни игр?

-Xbatch

Именно то что вы хотели

То о чем вы говорите - оффтоп. Java вполне готова для десктопа. Sun просто все делает очень заумно, ключики разные, опции. Потом неосиляторы орут что у них Java тормозит. Читаем маны, а потом задаем правильные ключи JVM для собственных приложений

> Когда будет реализован AOT Java сможет полноценно использоваться на десктопе, тормоза swing gui при правильных руках можно нивелировать почти полностью.

Спасибо, прочитал про AOT. В общем, ждем-с! Что ж они сразу такое не сделали?.. ИМХО это проще чем считать что сколько раз было вызвано...

Сколько ни пробовал Жыедит под оффтопиком, постоянно глюкал, несмотря на тривиальность задачи и уже немалый возраст. Может Жаба тут и не виновата, но _такой_ редактор нинужын.

JVM запущенная с опцией -client выполняет компиляцию метода в нейтив после 1500 вызовов, JVM запущенная с опцией -server выполняет компиляцию метода в нейтив после 10000 вызовов.

Бред.

Тогда бы NetBeans ворочалась как незнамо что, так как работала бы практически в режиме интерпретатора JIT.

Токмо просветления ради:

These are the DLL's that implement the client and server JVM's - the same ones chose when you run «java -client» or «java -server». The one that is chosen by default depends on Java version, the OS, the number of processors and other such things.

For the most part, J2EE containers should use the server JVM as they are the ideal application type - one that tends to execute the same code over and over, that run for extended periods of time, etc. In this kind of scenario the more studious and aggressive dynamic compiler/optimizer provided in the server JVM can do its stuff and the program can receive a substantial benefit.

И ещё: http://www.sql.ru/forum/actualthread.aspx?tid=662259

Для 64-битных платформ по умолчанию используется серверная JVM. Интересно, к чему бы это? Ж)

>> Ничего подобного AOT (Ahead Of Time), как в .Net/Mono в Java нет. Java не предназначена для десктопа изначально.

А когда будет такое + опционально кэширование одной и той же программы - то есть шанс на десктопность? Только ли это различие корень проблемы?

AOT есть в GCJ. Потому он такой тормозной и глючный.

>Да и кэширование скомпилированного кода вроде бы допиливают.

Уже допилили c выходом Java SE 6 Update 10 «Preload Disk Cache».

>Бред.

Тогда бы NetBeans ворочалась как незнамо что, так как работала бы практически в режиме интерпретатора JIT.

Бред, это то что ты написал, специалист мля.

Java до компиляции в нейтив исполняет код именно в режиме интерпретатора и только после 1500 для клиента и 10000 для сервера производит компиляцию в нейтив. Это делается специально, чтобы не тормозить приложения при запуске и компилировать именно те участки кода, что вызываются наиболее часто. Так же, за это время происходит сбор статистики и помимо тупой компиляции происходит оптимизация компилируемого кода, подстановки и т.д. Когда указывается трезхолд=1 код тупо компилируется в нейтив без оптимизации на основе собранной статистики т.к. статистики ещё нет.

Для 64-битных платформ по умолчанию используется серверная JVM. Интересно, к чему бы это? Ж)

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

Уже допилили c выходом Java SE 6 Update 10 «Preload Disk Cache».

Бугагага, иди учи чем AOT отличается от Preload Disk Cache. Кратко для тебя специально - нужна поддержка со стороны приложения.