Что, господа суровые С++ программисты, поспорим быстродействием с отстойной Джавой? ;)

Татарин> Заведомо известно, что нативный код будет выполняться как минимум с той же скоростью, как и код самой лучшей JVM с JIT или без

Это неправда.

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

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

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

Татарин> (а как правило - гораздо быстрее).

Не преувеличивайте. Разница есть, но она вполне приемлимая.

Nikita> У натива оптимизации выполняются один раз на фазе компиляции\сборки
Nikita> В managed же системах возможны оптимизации непосредственно в runtime, что позволяет учитывать все эти моменты каким угодно образом.
Это правда. Но компилятор натива никуда особо не спешит и может потратить на оптимизацию массу времени (компиляция даже сравнительно небольшого проекта может занимать десятки минут-часы). JIT себе этого позволить не может.
Да, работы у него на порядки меньше, но название говорит само за себя - от него требуется результат прям сейчас, сию же секунду.

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

Nikita> Так что всё ровно наоборот - потенциал получения более эффективного итогового машинного кода у managed-систем значительно выше.
Принципиально - да. Реализуется ли это когда-нибудь на практике - вопрос сложный, есть такая тенденция, что тяжесть программ и занимаемая ими память растут, как и мощность процессора.

Nikita> Другой вопрос, что реализация оного потенциала на данный момент никому особо не нужна, бо есть interop - критический участок реализуется в нативе и прикручивается ко всей остальной managed-части.
Э, нет.
Интероп - это извращение от большой тоски, которое убивает многие преимущества Явы (и вообще связано с некоторым количеством геммороя). Если бы написание более быстрой JIT было бы возможно - её бы написали, это очень востребовано.

Nikita> Не преувеличивайте. Разница есть, но она вполне приемлимая.
Я написал "гораздо". На десятки процентов - это для меня "гораздо" и есть. Были б единицы - написал бы "немного".
Приемлима? Да, для большинства приложений - пожалуй. Существенна? Опять же да.

Татарин> Но компилятор натива никуда особо не спешит

Компиляторы managed-систем тоже никуда не спешат. Особенно те что первый этап - трансляцию в промежуточный язык - делают.

Татарин> и может потратить на оптимизацию массу времени (компиляция даже сравнительно небольшого проекта может занимать десятки минут-часы). JIT себе этого позволить не может.

Наоборот, JIT может позволить себе компилировать программу хоть всё её - суммарное(!) за все запуски - время исполнения И всякие profile-guided и тому подобные техники оптимизации тут работают на ура, и лучше чем для нативных.

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

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

Татарин> Принципиально - да. Реализуется ли это когда-нибудь на практике - вопрос сложный,

Конечно реализуется. Только так можно получить мэйнстримовую высокую эффективность на всяких 80+ ядерных девайсах.

Татарин> есть такая тенденция, что тяжесть программ и занимаемая ими память растут, как и мощность процессора.

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

Татарин> Интероп - это извращение от большой тоски,

Ничего подобного. Грамотный interop - ключевой механизм кошерных managed-систем. Он позволяет спокойно и эффективно мигрировать на managed-платформу, не занимаясь переписыванием килотонн legacy-кода, и сохраняя практически все вложения сделанные ранее в натив.

Татарин> которое убивает многие преимущества Явы (и вообще связано с некоторым количеством геммороя).

В Java interop реализован через то самое место - это правда. А вот в .NET всё сделано очень хорошо.

Татарин> Если бы написание более быстрой JIT было бы возможно - её бы написали, это очень востребовано.

Да не нужно это сейчас никому. Проблемы производительности решаются грамотным interop'ом. Парить голову по части уберJIT'а ради этих сотых\тысячных долей кода никакого смысла нет.

Nikita>> Не преувеличивайте. Разница есть, но она вполне приемлимая.

Татарин> Я написал "гораздо". На десятки процентов - это для меня "гораздо" и есть. Были б единицы - написал бы "немного".
Татарин> Приемлима? Да, для большинства приложений - пожалуй. Существенна? Опять же да.

А это перпендикулярные характеристики

"Приемлимость" определяется итоговой эффективностью платформы как целого, тогда как "существенность" - голой производительностью изолированного куска машинного кода.

И те же web-приложения эту разницу очень хорошо показывают: нынче в оной области даже на элементарных задачах никакого натива и в микроскоп не увидишь. Бо в этом сегменте мэйнстрима никто не может себе позволить годами ковыряться во всяких там stack corruption'ах, memory leak'ах и тому подобных ужасах - всё нужно уже через неделю сдавать

И это даже не касаясь серьёзных вещей - масштабируемости, массивного параллелизма, безотказности, надёжности, <добавьте по вкусу>...

Nikita> Наоборот, JIT может позволить себе компилировать программу хоть всё её - суммарное(!) за все запуски - время исполнения
Что означает, что первое время - долгое время - программа будет работать медленно. Даже медленнее неоптимизированной: компилятор/оптимизатор тоже ест ресурсы.

Татарин>> Принципиально - да. Реализуется ли это когда-нибудь на практике - вопрос сложный,
Nikita> Конечно реализуется. Только так можно получить мэйнстримовую высокую эффективность на всяких 80+ ядерных девайсах.
Если программа изанчально предусматривает многопоточность/многопроцессность, то она, конечно, рантайм определит конфигурацию и соптимизируется, раскидает нагрузку по процесорам (причём, на уровне, недоступном JIT, и с куда бОльшим эффектом).
Если программа принципиально заточена жить в одном процессе, то JIT-компилятор (да и любой компилятор вообще) на большинстве задач сделать много не могут. Не побоюсь сказать, не смогут сделать ничего существенного.

Nikita> Мощность одиночного процессора уже практически не растёт - растёт количество доступных ядер. И как раз в этом раскладе возможности managed-систем по динамической рекомпиляции, профилировке и т.п. не оставляют прибитому гвоздями нативу ни шанса.
Почему же?
"Нативный" в контексте не означает "прибитый гвоздями и предопределённый раз и навсегда". "Нативный" означает лишь то, что компиляция в родной код делается заранее.
Если вдруг появятся чудесные алгоритмы распараллеливания на лету простых задач без участия программиста, то никто не помешает встроить эти алгоритмы в библиотеки. Даже в статически прикомпилируемые рантайм-библиотеки языка.
Скажем, для тех же БПФ и ОПФ существует куча реализаций для разных процессоров - с 3д-нау, MMX, SSE разных видов, и часто все эти реализации живут в одной либе. Которая часть выполнится - решение принимается именно во время исполнения.
Вопрос 1: сумеет ли JIT выполнить оптимизацию под набор инструкций конкретного проца на лету столь же качественно, как программист и его компилятор в процессе разработки либы? или даже так: сумеет ли выполнить оптимизацию вообще (ибо хорошее использование тех же векторных инструкций - бывает той ещё головной болью даже для хорошего программиста)?
Вопрос 2: если - предположим, лет через 100 - сумеет, то в чём тут выигрыш для исполнения? В том, что мы не несём с собой чуток лишнего кода (который и без того можно не загружать, и который может занимать лишь место на долговременном носителе)?

Татарин>> Интероп - это извращение от большой тоски,
Nikita> Ничего подобного. Грамотный interop - ключевой механизм кошерных managed-систем. Он позволяет спокойно и эффективно мигрировать на managed-платформу, не занимаясь переписыванием килотонн legacy-кода, и сохраняя практически все вложения сделанные ранее в натив.
Зачем отрицать, а затем сразу же объяснять частные случаи и причины появления большой тоски?

Nikita> В Java interop реализован через то самое место - это правда. А вот в .NET всё сделано очень хорошо.
В .Нет много меньше боли (и она почти незаметна). Тем не менее, интероп уничтожает и преимущества .Нет: теоретическая переносимость + защищённость.

Татарин>> Если бы написание более быстрой JIT было бы возможно - её бы написали, это очень востребовано.
Nikita> Да не нужно это сейчас никому. Проблемы производительности решаются грамотным interop'ом. Парить голову по части уберJIT'а ради этих сотых\тысячных долей кода никакого смысла нет.
Так если все проблемы производительности решает "интероп" (читать как "плюс-плюсный код"), фигли вообще использовать Яву для разработки?
Все проблемы С++ в интероп вставках остаются. Локализуются, да. Но остаются.
Нет, быстрый JIT - крайне нужен. Хотя бы потому, что позволяет без каких-либо переделок кода и/или оборудования повысить скорость работы приложений. Это дорого стОит. Скажем, новое железо, поднимающее производительность на десятки процентов легко может обойтись в двукратную-трёхкратную цену. И всё это - умножаем на количество ява-аппликачек по всему миру.
Спрос на ещё более быстрое исполнение байт-кода есть. Удовлетворить его сейчас не могут.

Татарин>> Приемлима? Да, для большинства приложений - пожалуй. Существенна? Опять же да.
Nikita> А это перпендикулярные характеристики
Я где-то заявлял их коллинеарность?

Nikita> И те же web-приложения эту разницу очень хорошо показывают: нынче в оной области даже на элементарных задачах никакого натива и в микроскоп не увидишь. Бо в этом сегменте мэйнстрима никто не может себе позволить годами ковыряться во всяких там stack corruption'ах, memory leak'ах и тому подобных ужасах - всё нужно уже через неделю сдавать
Мне остаётся лишь пожать плечами: нет смысла спорить с очевидным или доказывать его.

Татарин> Что означает, что первое время - долгое время - программа будет работать медленно.

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

Татарин> Даже медленнее неоптимизированной: компилятор/оптимизатор тоже ест ресурсы.

Для девайсов в 80+ ядер проблема как всё эффективно загрузить на 100%, а не то что мощи не хватает на JIT.

Татарин> Если программа изанчально предусматривает многопоточность/многопроцессность, то она, конечно, рантайм определит конфигурацию и соптимизируется, раскидает нагрузку по процесорам

Так вот именно в том и проблема, что на нативном C\C++ Вы такую программу будете 10+ лет писать. Я же специально привёл в пример web-приложения - на них полная беспомощность натива видна невооружённым глазом. И это при том, что web-приложения представляют один из самых простейших классов программ с массивной concurrency.

Татарин> (причём, на уровне, недоступном JIT, и с куда бОльшим эффектом).

Поехали по-кругу. JIT'у доступно всё то же что и обычным компиляторам, и даже больше.

Татарин> Если программа принципиально заточена жить в одном процессе, то JIT-компилятор (да и любой компилятор вообще) на большинстве задач сделать много не могут. Не побоюсь сказать, не смогут сделать ничего существенного.

Это очевидным образом зависит прежде всего от языка на котором писана программа. Ежели на специальном параллельном, то сделать можно очень много чего.

Татарин> "Нативный" в контексте не означает "прибитый гвоздями и предопределённый раз и навсегда". "Нативный" означает лишь то, что компиляция в родной код делается заранее.

"Заранее" и означает, что прибито гвоздями.

Татарин> Скажем, для тех же БПФ и ОПФ существует куча реализаций для разных процессоров - с 3д-нау, MMX, SSE разных видов, и часто все эти реализации живут в одной либе. Которая часть выполнится - решение принимается именно во время исполнения.

Приехали Вы считаете тупое блочное ветвление эквивалентом компиляции + оптимизации ???

Татарин> Вопрос 1: сумеет ли JIT выполнить оптимизацию под набор инструкций конкретного проца на лету столь же качественно, как программист и его компилятор в процессе разработки либы?

Конечно. Например, он может прямо использовать ту самую "качественную" либу

Татарин> Вопрос 2: если - предположим, лет через 100 - сумеет, то в чём тут выигрыш для исполнения?

Выигрыш в том, что не надо тратить 1000 лет на написание аналогичной по производительности программы на нативе.

Татарин> Зачем отрицать, а затем сразу же объяснять частные случаи и причины появления большой тоски?

Песен не надо, пожалуйста. Я чётко написал, что потенциал производительности 100%-managed кода на данный момент не реализован, и даже объяснил почему так получается.

Татарин> Тем не менее, интероп уничтожает и преимущества .Нет: теоретическая переносимость + защищённость.

Вы опять не с тем сравниваете. Решения типа managed + interop надо сравнивать не со 100%-managed решениями, а со 100%-нативными. Надеюсь понятно, что и по части переносимости, и по части защищённости managed + interop кроют чистый натив по полной программе ? Или надо разжёвывать ?

Татарин> Так если все проблемы производительности решает "интероп" (читать как "плюс-плюсный код"), фигли вообще использовать Яву для разработки?

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

Татарин> Все проблемы С++ в интероп вставках остаются.

Неправда. Исчезает самая главная проблема => 99.99999% (г)кода на C\C++. А уж оставшийся десяток килобайт как-нибудь отладим, доточим, и - если уж совсем надо - то даже и верифицируем.

Татарин> Нет, быстрый JIT - крайне нужен. Хотя бы потому, что позволяет без каких-либо переделок кода и/или оборудования повысить скорость работы приложений. Это дорого стОит.

Не стоит. Основная доля JVM\.NET решений упирается не в CPU, а в ввод\вывод всех сортов. Мы вон с нашим .NET-приложением как-то наблюдали сцены выжирания всех доступных TCP портов + полосы пары 10Gb сетевух. CPU при этом были загружены едва ли на треть...

Татарин> Спрос на ещё более быстрое исполнение байт-кода есть. Удовлетворить его сейчас не могут.

Нету спроса. Вот пойдут массовые 80+ ядерные монстры - тогда будет.

Татарин> Мне остаётся лишь пожать плечами: нет смысла спорить с очевидным или доказывать его.

Ну так а что Вы песни про крутые нативные либы поёте тогда ?

Татарин> Зачем отрицать, а затем сразу же объяснять частные случаи и причины появления большой тоски?

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

Татарин>> Нет, быстрый JIT - крайне нужен. Хотя бы потому, что позволяет без каких-либо переделок кода и/или оборудования повысить скорость работы приложений. Это дорого стОит.
Nikita> Не стоит. Основная доля JVM\.NET решений упирается не в CPU, а в ввод\вывод всех сортов. Мы вон с нашим .NET-приложением как-то наблюдали сцены выжирания всех доступных TCP портов + полосы пары 10Gb сетевух. CPU при этом были загружены едва ли на треть...

Exactly. Цепочка клиент <-(медленный канал)-> сервер приложений <-(быстрый канал)-> база данных на сегодня сверхтипична. Для всяких финансовых институтов и торговли - 99% всего кода. В этой цепочке узкие места - медленный канал от клиента и долгие вызовы к базе данных. Производительность собственно сервера приложений никакого критического значения не имеет. Будут service calls крутиться в пять раз быстрее или в десять раз медленнее - никто и не заметит (ну, в разумных пределах ). А уж про десятки процентов я и не говорю вообще. От десяти процентов улучшения JIT модемный канал на ржавой сопле быстрее не станет. И Оракл быстрее SQL выполнять не будет.

Не только сетка, на этом вся философия Жабы, Вижуал Бейсика итп и строится.Скрипт - обработчик событий и ГУЙ,на нем бежит мизерная часть ресурсов,а собственно работа делается импортами, написанными на других языках.Идея оптимизации мобильного кода и перевода на него ффсего ИМХО порочна.Есть прожорливый алгоритм - пиши DLL на С.

digger> Не только сетка, на этом вся философия Жабы, Вижуал Бейсика итп и строится.Скрипт - обработчик событий и ГУЙ,на нем бежит мизерная часть ресурсов,а собственно работа делается импортами, написанными на других языках.Идея оптимизации мобильного кода и перевода на него ффсего ИМХО порочна.Есть прожорливый алгоритм - пиши DLL на С.

Это не так. То, что вы написали не имеет места быть. Про прожорливый алгоритм, которыф надо переносить на C уже даже не смешно. Проблемы прожорливых алгоритмов вовсе не в языке. Скажем, у вас задача сводится к NP полной проблеме - и чем вы, извините, поможете переходом на C? 30% процентов быстродействия не волнуют практически НИКОГО, кроме драйверописателей, может быть. Если проблема в 30% быстродействии куда дешевле апгрейдить систему. В 95% случаев.

digger> Не только сетка, на этом вся философия Жабы, Вижуал Бейсика итп и строится.Скрипт - обработчик событий и ГУЙ,на нем бежит мизерная часть ресурсов,а собственно работа делается импортами, написанными на других языках.Идея оптимизации мобильного кода и перевода на него ффсего ИМХО порочна.Есть прожорливый алгоритм - пиши DLL на С.

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

Если уж на то пошло — а нафига на DLL — динамически подгружаема, адресация косвенная, часто поиск по таблице. Если уже тебе это быстродействие так важно, то статически лучше — быстрее. Ну и на ассемблере надо, а не на С, где компилятор всё убъёт.

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

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

Mishka> Если уж на то пошло — а нафига на DLL — динамически подгружаема, адресация косвенная, часто поиск по таблице.

Нет никакого поиска, один пойнтер.То же что math.sin(),или вы предпочитаете разлагать синус в ряд на скрипте.

Насчет ликов и деаллокаций.Это грязный код, который в скрипте этого не сделает, но фатальную логическую ошибку может допустить и убить пациента,например.Защита памяти в компилируемых языках для того и есть,чтобы отлавливать баги.
Сам синтаксис и среда разработки Жабы мне не нравится по сравнению с C++ и Дельфи.Есть мнение,что распространение Жабы там,где она не связана с портабельностью - это ничто иное,как дань моде в свое время, а потом поддержка существующего кода,во вред всему остальному.Мы пишем на Жабе - значит мы круты.

digger> Сам синтаксис и среда разработки Жабы мне не нравится по сравнению с C++ и Дельфи.

И какой из этого следует вывод? И кстати, как много проектов вы делали на Джаве?

Digger>Есть мнение,что распространение Жабы ...


Мало ли какие есть мнения. Есть мнение, что Земля плоская, есть мнение, что американцы не летали на Луну. Что с того?

Кстати заметьте, все здешние "джависты" имеют очень большой опыт с Си. А вот обратное неверно.

Кстати... вовремя ветка ожила.

Заметил, что программирование на Яве стимулирует писать более ресурсоёмкий код и вообще более пофигистично относиться к ресурсам машины. Просто вот сейчас перед глазами пример (тем более вопиющий, что со стороны клиента весьма ограниченый в памяти, сторидже и процессоре дивайс).

Это ортогонально утверждению "явисты - лохи" , я обвиняю язык в том, что поощряет программиста небрежное в смысле скорости исполнения и требуемой памяти написание кода точно так же, как он поощряет писать объектно.
В первую очередь, ИМХО, виновата вот эта самая прозрачность управления памятью: ведь даже для того чтобы вставить одну строку внутрь другой, требуется создать новый объект. И такая фигня по всему мясокомбинату. Во вторую - вот здесь в меня полетят табуретки, но - само объектно-ориентированное программирование. Максимальное переиспользование кода заставляет делать объекты универсальными и наследовать-наследовать-наследовать. В результате для создания микроскопического по объёму XML-енкодед запроса исполняется добрая сотня конструкторов, запрашиваются огромные куски памяти и т.д. и т.п.

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

Вот сейчас пример прямо перед глазами.
Два устройства. Одно - Андроид. Мощный гигагерцовый проц (2 инструкции на такт), полгига памяти... и ява. Второе - убогий телефон с BREW API (pure C), 66МГц, 4Мб. Одно и то же приложение написано разными программистами под эти две платформы. Зарплаты программистов сравнимы, проги написаны в одной стране (чтобы исключить национальный фактор).
Приложение на втором устройстве на некоторых операциях работает в РАЗЫ быстрее, чем первое (что вообще-то - чума), и никогда не медленнее.

Разве это не должно наводить на мысли, что что-то в консерватории надо менять?

digger> Есть мнение,что распространение Жабы там,где она не связана с портабельностью - это ничто иное,как дань моде в свое время, а потом поддержка существующего кода,во вред всему остальному.Мы пишем на Жабе - значит мы круты.
Есть мнение, что это неверное мнение.

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

Татарин> Разве это не должно наводить на мысли, что что-то в консерватории надо менять?

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

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

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

Exactly.

Сергей-4030> Андроидное приложение будет работать под все платформы с джавой.
Не будет. Ну, будет, но только в том смысле, в котором С-шное BREW-приложение способно поддерживаться платформами, для которых существует С-компилятор (тем же Андроидом).
Ява-приложение с Андроида на ту же j2me нужно по-честному портировать.

Сергей-4030> А скорость... ну поставят в следующей версии процессор в два раза быстрее и память вот проблемы и кончатся.
Вот! Вот само это отношение - корень зла.

Проблемы, кстати, не кончатся. Более быстрый проц при той же технологии жрёт более быстро батарейку. Ну, это помимо того, что он дорогой.

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

Сергей-4030> Косвенным признаком является количество приложений, кстати. Сколько под андроид и сколько под эту другую платформу?
Под Андроид больше, но тут виновата не техника, а маркетоложская политика Quallcomm: процедура регистрации приложения настолько трудо- и деньгоёмка, что отдельному независимому разработчику просто не под силу. А именно они да стартапы поставляют 99% всех сопелок и перделок, которые в свою очередь 99% всего программного обеспечения под Андроид сейчас.

digger> Неважно, их скорость или некритична,или зависит в основном от сетки и других факторов, не связанных с самим кодом.

Интересно, с чем и с кем ты споришь? Тебе сказал, что в большинстве задач так и бывает.

digger> Нет никакого поиска, один пойнтер.То же что math.sin(),или вы предпочитаете разлагать синус в ряд на скрипте.

Есть. Сильно зависит от того, как делать. Ну и косвенный вызов медленнее прямого. Если ты не знаешь этого и споришь о быстродействии, то это уже за пределами бобра. Про синус это вообще весело. Как насчёт других ф-ций? Или это не укладывается в модель?

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

Ы, а при чём тут лужков? И уж не С++ говорить про защиту памяти. В Джаве эта защита на порядок лучше.

digger> Сам синтаксис и среда разработки Жабы мне не нравится по сравнению с C++ и Дельфи.
Это твои проблемы.
digger> Есть мнение,что распространение
Оно не верное.
digger> Жабы там,где она не связана с портабельностью - это ничто иное,как дань моде в свое время, а потом поддержка существующего кода,во вред всему остальному.Мы пишем на Жабе - значит мы круты.
Собственно, распространение С++ есть дань моде и попытка сыграть на популярности С. А С — тоже дань распространения моде. А уж Дельфи двинулся в сторону Джавы и Смолтока давно.

.
Сергей-4030>> А скорость... ну поставят в следующей версии процессор в два раза быстрее и память вот проблемы и кончатся.
Татарин> Вот! Вот само это отношение - корень зла.

Ничуть. Увеличение быстродействия процессоров при уменьшении энергопотребления на сегодняшний день - объективная реальность, глупо не принимать ее в расчет. А вот если упрутся в какой фундаментальный предел, тогда можно будет и пооптимизировать существующие приложения. Глупо оптимизировать только чтоб було.

Татарин> В первую очередь, ИМХО, виновата вот эта самая прозрачность управления памятью:
Это фигня.
Татарин> Во вторую - вот здесь в меня полетят табуретки, но - само объектно-ориентированное программирование. Максимальное переиспользование кода заставляет делать объекты универсальными и наследовать-наследовать-наследовать.
Вот это более важное. И таки недоучки-программисты тут впереди планеты всей. Но это характерно и в других инженерных специальностей. Блоковый дизайн.

Аккуратно написанные объекты и классы живут вполне нормально. Вот только такие вещи мало людей писать умеют.

Татарин> В результате для создания микроскопического по объёму XML-енкодед запроса исполняется добрая сотня конструкторов, запрашиваются огромные куски памяти и т.д. и т.п.
К сожалению или к счастью, XML не является простым. Как ни крути. Достаточно почитать стандарт, стандарт на схемы, стандарт на разбор и т.д.

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


А зачем на мобильном устройстве полноценная обработка XML-а? Если хочеться XMPP, то приплыли. Это уже не Джава и программисткое требование. Надо понимать, что XML поддержка полная (а XMPP предпологает именно такую), это полноценные компиляторные технологии интерпретирующего типа. Грубо говоря, ты запускаешь полный компилятор-интерпретатор на каждое сообщение. Вот чтобы я тут сделал (и начал делать, но бросил) — предварительная компиляция схемы и сохранение её на внешнем накопителе, чтобы сэкономить время хотя бы на этом.

Татарин> Два устройства. Одно - Андроид. Мощный гигагерцовый проц (2 инструкции на такт), полгига памяти... и ява. Второе - убогий телефон с BREW API (pure C), 66МГц, 4Мб. Одно и то же приложение написано разными программистами под эти две платформы. Зарплаты программистов сравнимы, проги написаны в одной стране (чтобы исключить национальный фактор).
Татарин> Приложение на втором устройстве на некоторых операциях работает в РАЗЫ быстрее, чем первое (что вообще-то - чума), и никогда не медленнее.

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

Татарин> Разве это не должно наводить на мысли, что что-то в консерватории надо менять?

Сколько времени потратили первые и вторые на написание кода? Сколько времени надо на адаптацию новой схемы сообщений?

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

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

Заметьте, сейчас-то программирует ещё то поколение, которое успело попрограммировать на языках с меньшим уровнем абстракции, кое-кто и в машинных кодах поковырялся. Всего 10-15 лет прошло, недостаточно, чтобы сменилось поколение. А вот ещё лет через 10-20 оно-таки полностью сменится. И школа будет утеряна. Вот тогда и огребём...

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

Татарин>> В первую очередь, ИМХО, виновата вот эта самая прозрачность управления памятью:
Mishka> Это фигня.
Ну... как сказать.

Mishka> Вот это более важное. И таки недоучки-программисты тут впереди планеты всей. Но это характерно и в других инженерных специальностей. Блоковый дизайн.
Так вот блоковый дизайн и поощряется языком. Не, я не имею ничего против, и блоковый дизайн, и переиспользование кода, и ООП - великолепные вещи. И учить им надо. Плохо то, что не учат ничему другому. И Ява (а это сейчас язык начального обучения) это поощряет. Точнее даже отбивает желание обучать(-ся) иным подходам.

Татарин>> В результате для создания микроскопического по объёму XML-енкодед запроса исполняется добрая сотня конструкторов, запрашиваются огромные куски памяти и т.д. и т.п.
Mishka> К сожалению или к счастью, XML не является простым. Как ни крути. Достаточно почитать стандарт, стандарт на схемы, стандарт на разбор и т.д.
Там подмножество XML: после некоторых споров пошли-таки на компромисс...
Но это лишь подчёркивает идею: архитектор - вчерашний ява-программист серверных приложений - выбрал именно такой способ для общения клиента с сервером (ну а что? масштабируемо! открыто! понятно!).
Разве это не показательно?

Mishka> Тут надо смотреть на затраты ресурсов на создание кода, принятые решения, возможности расширения и удобства расширения. В лоб не сравнить. В том числе и квалификацию людей.
Э, нет. В лоб сравниваем расходы: по стоимости программистов (в денежном выражении) за период разработки. Количество примерно равно. Зарплаты примерно равны.
Возможности расширения? Да. Это обычно то, на что упирают, когда хочется протолкнуть что-нить "ленивое" для программиста. Но всегда ли это такой уж плюс?

Mishka> Сколько времени потратили первые и вторые на написание кода? Сколько времени надо на адаптацию новой схемы сообщений?
К сожалению второе уже невозможно: слишком большие изменения в большом количестве кода, который написан и уже работает на сервере и куче мобильных платформ.
А вот время потрачено сравнимое (не говорю бОльшее или меньшее, потому как точно не знаю - люди добавлялись и убавлялись к проектам, но примерно то же число людей работало столько же времени).

Mishka> Во, блин, а я не знал, что философия Жабы на гуях основана.


А я, вообще, гуёвых приложений на ней кроме Eclipse почти и не видел

digger> Сам синтаксис и среда разработки Жабы мне не нравится по сравнению с C++ и Дельфи.

«Мне еда нравится меньше, по сравнению с пищей :D»