Гослинг доволен производительностью Java

> Я так понимаю в HPC используются большие многопроцессорные шкафы, но при этом балансировать нагрузку Фортран умеет не лучше чем любой другой императивный язык. Можно пояснить?

Фортран тут не при делах, это всё на библиотеки (такие, как MPI) ложится.

На Фортране пишутся сами вычисления. Причем, часто не напрямую на Фортране, а на языке высокого уровня (e.g., Mathematica), преобразуемом в Фортран для эффективности.

Жаба не нужна. После выхода Mono 2.0 можно сказать больше: жаба больше никому не нужна.

>Жаба не нужна. После выхода Mono 2.0 можно сказать больше: жаба больше никому не нужна.

Ну за всех то расписываться не надо, да?

> Я пока не говорю об HPC, ибо не являюсь в этой области хоть каким-то специалистом.

Ну и накойхер в тред влез? Тут про пригодность жабки для HPC разговор идёт.

> Я говорю об обычной области применения Java - разработке больших модульных систем (например, серверных).

Говори в другом месте.

> Надежность заключается в том, что язык позволяет отследить большинство проблем на этапе компиляции

Ты чушь сказал. Жаба не позволяет отследить ни хрена на этапе компиляции - это туповатый язык с весьма динамической системой типов. Посмотри на языки с зависимыми типами - например, Axiom. Вот там действительно можно отслеживать ошибки, там тебе никто не позволит метры с килограммами складывать. А жаба молча сложит целое с плавучим и не тявкнет.

> и не допустить их в рантайм (по сравнению с теми же низкоуровневыми сями..).

Да кого колышит си?!?

> И с ним не согласен.

Это от того, что ты очень мало чего знаешь и понимаешь. Учись.

> Скорее всего ты не работал с ней как следует.

Работал, ещё как работал. В том числе и компилятор жабы писал (в нативный код). Прекрасно знаю, как и в чём этот тупенький язычок ограничен. Просто я знаю ещё много-много других языков, парадигм и технологий, и мне есть с чем сравнивать. А тебе даже и сравнивать то не с чем.

> И все же, какова тогда твоя альтернатива яве, ответь конкретно, плз.

Альтернатива для чего? Не существует языка, универсально пригодного для всего.

Конкретно для HPC, например, даже голый Фортран подходит гораздо лучше чем Java. Я уж не говорю про связку Mathematica + Fortran, про специализированные языки типа Octave, и т.п.

>> Я так понимаю в HPC используются большие многопроцессорные шкафы, но при этом балансировать нагрузку Фортран умеет не лучше чем любой другой императивный язык. Можно пояснить?

>Фортран тут не при делах, это всё на библиотеки (такие, как MPI) ложится.

MPI - это ведь только библиотека для обмена промежуточными результатами вычислений в распределенной среде (или нет)? Кто должен разбить решение задачи на параллельные процессы? Можно ли это сделать автоматически с good-enough качеством?

>На Фортране пишутся сами вычисления. Причем, часто не напрямую на Фортране, а на языке высокого уровня (e.g., Mathematica), преобразуемом в Фортран для эффективности.

Почему сразу не в машкод?

> MPI - это ведь только библиотека для обмена промежуточными результатами вычислений в распределенной среде (или нет)?

Это библиотека для обмена сообщениями, заточенная под передачу численных данных. Ну и кой-какие средства для анализа и балансировки нагрузки (ты же про это спрашивал).

> Кто должен разбить решение задачи на параллельные процессы?

Очень умный математик.

> Можно ли это сделать автоматически с good-enough качеством?

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

> Почему сразу не в машкод?

А на кой? Фортран есть для всего, что шевелится. Компиляторы очень круто оптимизировать умеют, пока никто не обогнал. Зачем дублировать работу компилятора?

>Ну за всех то расписываться не надо, да?

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

>На машине с процессором x86 1550MHz и оперативкой 768 Mb eclipse , при открытии проекта "hello world", тормозит люто и в конечном итоге выбрасывает сообщение, что недостаточно памяти. Конечно сраный eclipse заведется на 2х ядерном процессоре с двумя гигабайтами оперативы, но если к этому добавить Azureus(Vuze) и еще что-нибуть Javaное, то наступит глобальное потепление.

Узнай про Xmx и удивись. У меня эклипс работал на 512М оперативы и 500МГц третьем пне без тормозов. А в шестой жабе, так и вообще можно настроить GC так, что вообще от нативной не отличишь.

Дааа.... Все неосилившое быдло ЛОРа вылезло в этот топик. НУ привет, друзья! Вы хоть на яве что-то больше "ХеллоуВорда" написали в своей жизни? А хоть что-то кроме Азуреуса запускали? Или судите только по одному Азуреусу и Еклипсу, который немного рассмотрели на 2м курсе университетов? Да и то кроме слова "Еклипс" икак примерно он выглядит ничего больше и не знаете.

Давайте ка назовите мне язык, который может:

1. Обеспечить 100% переносимость.

2. Под который такое же как под Яву количество сторонних библиотек и фреймворков.

3. Под который есть вменяемая среда разработки - хотя бы такая как Еклипс, а не всякие емаксы и блокноты.

4. И который можно использовать хотя бы на 50% Явы. Яву то можно хоть на сервер хоть на десктоп, хоть на веб.

>у них умный сборщик мусора

А ты что думаешь что ты руками заоптимизируешь лучше чем это сделает GCC на сколь нибудь сложной задаче?

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

У нас весь пользовательский софт на JavaScript: GWT+Gears. Сервер на JEE, память нужна только на нём. Java нужна только на серверах да на машинах разработчиках.

Да и что же вы тыкаете, а член стыдитесь своим словом называть?

> Delphi 2009 тормозит и жрет не меньше, при значительно более скромных возможностях, нежели Eclipse. Java там нету.

Зато там есть .NET, что, как минимум, не лучше жабы.

... Про балансировку нагрузки в HPC

>> Можно ли это сделать автоматически с good-enough качеством?

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

Ну а все-таки - есть какие-то средства анализа workflow на лету с целью его распараллеливания? Вроде бы чистые функциональные языки вроде Haskell должны в теории это уметь?

>1. Обеспечить 100% переносимость.

Считать достоинством явы кроссплатформенность все равно, что считать достоинством анального секса возможность заниматься им как с мужчинами, так и женщинами. (c) original bash.org

>Вроде бы чистые функциональные языки вроде Haskell должны в теории это уметь?

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

> Считать достоинством явы кроссплатформенность все равно, что считать достоинством анального секса возможность заниматься им как с мужчинами, так и женщинами. (c) original bash.org

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

>А ты что думаешь что ты руками заоптимизируешь лучше чем это сделает GCC на сколь нибудь сложной задаче?

А оптимизации gcc были написаны более высокоразвитой цивилизацией?

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

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

>Считать достоинством явы кроссплатформенность все равно, что считать достоинством анального секса возможность заниматься им как с мужчинами, так и женщинами. (c) original bash.org

Неужели с башорк? ЕМНИП Это боян с буржуйского Usenet более чем десятилетней давности.

>Считать достоинством явы кроссплатформенность все равно, что считать достоинством анального секса возможность заниматься им как с мужчинами, так и женщинами. (c) original bash.org

Думаю именно этой цитатой руководствуется Микрософт выпуская дотНет только под Виндовз.

>Узнай про Xmx и удивись. У меня эклипс работал на 512М оперативы и 500МГц третьем пне без тормозов. А в шестой жабе, так и вообще можно настроить GC так, что вообще от нативной не отличишь.

Узнал:

XMX is a standalone utility for sharing an X Window System session on multiple X displays.

удивился

> Ну а все-таки - есть какие-то средства анализа workflow на лету с целью его распараллеливания? Вроде бы чистые функциональные языки вроде Haskell должны в теории это уметь?

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

> Очень удобно и приятно вести разработку веб-приложения на линуксе,

Кто о чем, а вшивый о бане, пардон, быдлокодер о веб-приложениях.

Мир веб-приложениями, представь себе, не ограничивается.

> Ога, то-то все сколь-нибудь большие проекты на яве тащат с собой кучу зависимостей от конкретной платформы...

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

>Если разработчики дибилы - возможно. Но дибил на любом языке хрень всякую писать будет, даже на русском.

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

> Мир веб-приложениями, представь себе, не ограничивается.

И ? Я где-то утверждал обратное ? Или ты хочешь сказать что пхп глобально и надежно ?

З.Ы. Толсто

Проще написать небольшие платформозависимые модули для вин и для никс, к примеру, чем писать одно платформозависимое приложение.

>С численными методами всё хуже - там для разпараллеливания надо существенно менять логику вычислений.

А кто-нибудь занимался например автоматической генерацией распараллеливаемой логики по описанию задачи в некоем декларативном виде?

> А оптимизации gcc были написаны более высокоразвитой цивилизацией?

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

> А кто-нибудь занимался например автоматической генерацией распараллеливаемой логики по описанию задачи в некоем декларативном виде?

Вряд ли, мне такие работы не попадались. Слишком творческая задача.

быстро. надёжно. свиблово :)

> На машине с процессором x86 1550MHz и оперативкой 768 Mb eclipse , при открытии проекта "hello world", тормозит люто и в конечном итоге выбрасывает сообщение, что недостаточно памяти.

Странно... Какой Eclipse? какая JVM? на 6-ке приложения работают быстрее, особенно swing.

PS дома для себя программирую на 256 RAM. После изначальной загрузки прогается нормально. Рядом крутится FireFox... сижу под KDE 3.5.9

>>Планка 1GB стоит 500 рублей = час работы программиста.

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

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

Зависит от задачи. Люди не зря пользуются инлайнами, а уж как gcc выделяет mmx и остальные "расширенные" регистры, лучше вообще помолчать.

>Мир веб-приложениями, представь себе, не ограничивается.

Но это сегодня очень и очень приличный кусок рынка. Всё растущий и перспективный.

>>Мир веб-приложениями, представь себе, не ограничивается.

>Но это сегодня очень и очень приличный кусок рынка. Всё растущий и перспективный.

Разговор только не о нем. На фортране или аксиоме с октавой веб-сайт писать никто не станет.

> Но это сегодня очень и очень приличный кусок рынка. Всё растущий и перспективный.

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

> Зависит от задачи.

Арифметика. Тупо, арифметика.

> Люди не зря пользуются инлайнами,

В большинстве случаев - зря.

> а уж как gcc выделяет mmx и остальные "расширенные" регистры, лучше вообще помолчать.

Intel это делает гораздо лучше. Да и весьма ограниченная область применимости у SIMD-ов.

> раз их разлюбезная жаба годится для их веб-перделок, то она годится и для всего остального

Такого тут нету. Мной, ранее в этой теме, было сказано обратное. Читвй внимательнее/тоньше, еще тоньше.

>Что бы тут не спорили, но вычислительные мощности растут очень быстро.

Они уже давно почти не растут:P

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

Какой еще бум??? O_o o_o o_O (Аж переклинило). Давно уже застой, лет 10, не меньше. Мощности только выросли и остановились. Принципиально ничего с тех пор не изменилось.

>На машине с процессором x86 1550MHz и оперативкой 768 Mb eclipse , при открытии проекта "hello world", тормозит люто и в конечном итоге выбрасывает сообщение, что недостаточно памяти.

Я года два занимался разработкой проекта в 172 тыс. строк на Java (а также - 60 тыс. строк на JBForth, 104тыс. строк на Jython и 246 тыс. строк на XML), жрущий около 500Мб оперативы. Весь этот зоопарк под профайлером и дебагером. В Eclipse. На Celeron-1700 с 1Гб оперативы. Не скажу, что летало, работало неторопливо, но терпимо.

Если кому-то кажется, что я нетребователен к скорости - добро пожаловать в параллельную тему, где меня, наоборот, обвиняют в излишней требовательности к производительности :D

>JAVA это шаг от геморроя к проектированию

оберон:)

>> Люди не зря пользуются инлайнами,

>В большинстве случаев - зря.

Далеко не факт...

>> а уж как gcc выделяет mmx и остальные "расширенные" регистры, лучше вообще помолчать.

>Intel это делает гораздо лучше. Да и весьма ограниченная область применимости у SIMD-ов.

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

Даже для маленьких размерностей люди пишут mmx-расширения "руками", можно посмотреть исходники raid56 модулей.

>Разговор только не о нем. На фортране ...

Надо же, диалог до сих пор он топик? :) Я просто с конца читаю тему, похоже было, что обычный флейм пошёл...

>Ну да. Быдлокодеры, на которых и была расчитана Ява, не сумели ее правильно приготовить, поэтому софт на ней торомозит, будь Ява хоть быстрее компьютера.

В принципе дотнет создавали для того же самомго.

Все любят Гипножабу...

> Далеко не факт...

Факт, факт. Слишком много таких случаев видел. Руки бы отрывал за инлайны.

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

Проверь. Очень легко убедиться, что человечек, даже самый умный, весьма косолап и туп в сравнении с компилятором. Причем, если на таких платформах, как ia32, это ещё не очень заметно (поскольку регистров там как кот насрал), то на RISC-ах и пострисках (IA64, например) человеку вообще делать нечего.

>Жаба не нужна. После выхода Mono 2.0 можно сказать больше: жаба больше никому не нужна.

гы %) моно устарело еще до своего выхода:P

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

>1. Обеспечить 100% переносимость.

Как выясняется, Ява - это как раз одна из самых НЕкроссплатформенных технологий.

Вот список ОС, которые поддерживает Перл:

Acorn, AIX, Amiga, Apollo, Apple, Atari, AtheOS, BeOS, BSD, BSD/OS, Coherent, Compaq, Concurrent, Cygwin, Darwin, DEC OSF/1, DG/UX, Digital, Digital UNIX, DJGPP, DOS, Domain/OS, DragonFlyBSD, DYNIX/ptx, Embedix, EMC, EPOC, FreeBSD, Fujitsu, GNU Darwin, Guardian | HP, HP-UX, IBM, IRIX, Japanese, JPerl, Linux, LynxOS, Mac OS, Mac OS X, Macintosh, MachTen, MinGW, Minix, MiNT, MorphOS, MPE/iX, MS-DOS,/ MVS, NetBSD, NetWare, NEWS-OS, NextStep, NonStop, NonStop-UX, Novell, ODT, Open UNIX, OpenBSD, OpenVMS, OS/2, OS/390, OS/400, OSF/1, OSR, Plan 9, Pocket PC, PowerMAX, Psion, QNX, Reliant UNIX, RISCOS, SCO, Sequent, SGI, Sharp, Siemens, SINIX, Solaris, SONY, Stratus, Sun, Syllable, Symbian, Tandem, Tivo, Tru64, Ultrix, UNIX, Unixware, VMS, VOS, Win32, WinCE, Windows 3.1, Windows 95/98/Me/NT/2000/XP, z/OS

А Си вообще ВЕЗДЕ есть.

Линукс вместе с кучей софта под что только не скомпилен.

А Ява? Даже под x86 *BSD пришлось ждать стабильной jdk6 больше года (вроде два). А что тогда с поддержкой общепринятых ОС на разных аппаратных платформах? Что с менее популярными ОС?

>Под который такое же как под Яву количество сторонних библиотек и фреймворков.

Под Си/С++ как минимум не меньше.

>Под который есть вменяемая среда разработки - хотя бы такая как Еклипс, а не всякие емаксы и блокноты.

Ну хотя бы тот же Eclipse ;) Он много языков поддерживает.