LINUX.ORG.RU

Доверьтесь виртуальной машине


0

0

Таков смысл одного из разделов интервью с популяризатором технологий Sun Брайаном Гетцом. В нем он поясняет этот тезис. "Разработчики очень любят оптимизировать код, и не зря. Это весело и увлекательно. Но гораздо важнее знать, когда стоит заниматься оптимизацией, а когда – нет. К сожалению, в основном разработчикам редко помогает интуиция в выборе участков приложения, требующих ускорения выполнения.

...Код на Java вполне может выполняться быстрее кода на C. ... Ирония в том, что C-программисты гордятся своей возможностью управлять указателями на самом низком уровне, и считают это своим самым мощным инструментом, и эта же самая возможность мешает C-компиляторам производить наиболее эффективно оптимизированный код. Отнимая эту возможность у программиста, вы предоставляете море возможностей для оптимизации компилятору, и будьте уверены, Java-компилятор знает об оптимизации больше, чем 99,99% обычных программистов.

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

...Если бы я мог послать волшебной палочкой сообщение всем разработчикам на Java, я бы сказал им: доверьтесь виртуальной машине. Она умнее, чем вы думаете. Перестаньте пытаться обставить и обогнать ее. Пишите в коде то, что вы хотите, чтобы она сделала и она сделает все возможное и даже чуть больше чтобы то, что вы задумали, выполнилось наиболее быстро."

>>> Подробности

anonymous

Проверено: Pi ()

Ответ на: комментарий от anonymous

С каких пор индусы стали христианами?

eXOR ★★★★★
()
Ответ на: комментарий от eXOR

Да не нервничай ты так. Глубоко вдохни, посчитай про себя до 5 и выдохни. Все хорошо.

Первый пункт - бред. Тебе сколько лет?

Второй пункт звучит типа: Почему аналогичная формочка на Java, которая по сложности будет примерно такой же отрисовываться будет значительно быстрее чем на QT?

Третий пункт - бред. Это же демка. Пример на простой базе (таблицах) без всевозможных прослоек. Между прочем точно также, можно сказать один в один, за место таблиц использовать SessionBean, либо работать через любой PersistenManager (Hibernate, TopLink). Да что тебе объяснять.

Твой пост понизил тебя больше чем ты думаешь.

gapik
()
Ответ на: комментарий от gapik

>Да и речь вроде шла про "Delphi" и "...быстрее чем на ней, ни на чем >более закодить нелься"

Да ты я вижу многократный победитель конкурсов вроде "трехзвенка за 10 минут" или "ajax за час для имбецилов" просто :)

anonymous
()
Ответ на: комментарий от gapik

> Первый пункт - бред. Тебе сколько лет?
25 это как-нибудь влияет на отвращение которое я приобрел к индускому коду? Соответственно вопрос к тебе - сколько лет тебе? И сколько из них ты потратил на работу в IT?

> Второй пункт звучит типа: Почему аналогичная формочка на Java,
> которая по сложности будет примерно такой же отрисовываться будет
> значительно быстрее чем на QT?
Я сужу о скорости по следующим моментам:
1. Когда товарищь делает resize формы нагенереной nb контролы начинают менять размер с заметной задержкой (см демо-ролик). Когда я делаю аналогичную форму в Designer или Glade2 то при изменении размера основного окна контролы меняют положение smooth'но в т.ч. на Athlon 1Gz (полагаю у товарища машина будет пошустрее). Опять же если посмотрим на те же IDEA/Eclipse - то отрисовква происходит гораздо глаже - похоже дело все-таки в товарищах из nb?

> Пример на простой базе (таблицах) без всевозможных прослоек.
Ок. Хорошо. Вопрос поставим иначе. Ты приходишь на проект поддержки. Разрабатываемый индийской мегакорпорацией. Какой источник данных будет использован товарищами из дружеской индии? Лично я предпочел бы чтобы средство разработки максимально ограничевало возможность использования вшитых SQL запросов в код.

> Между прочем точно также, можно сказать один в один, за место
> таблиц использовать SessionBean, либо работать через любой
> PersistenManager (Hibernate, TopLink).
Так почему это хорошо? Кстати часто вы пользуетесь Hibernate'ом? Как насчет того что для него очень желательно иметь специально спроектированную базу?

> Да что тебе объяснять.
Самое простое продемонстрировать себя д'Артаньяном и гордо удалиться. Честно я был бы признателен - если бы ты объяснил почему так лучше? Хотя бы с твоей точки зрения.

> Твой пост понизил тебя больше чем ты думаешь.
Смишно :).

> Да и речь вроде шла про "Delphi" и "...быстрее чем на ней, ни на
> чем более закодить нелься"
Ну сказки про быстроту разработки на Delphi мы слышали. Довелось поработать с экс дельфистами - у них класс и форма в голове связано так, что не выковырять никак. Это неперевоспитуемые люди.

eXOR ★★★★★
()
Ответ на: комментарий от gapik

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

Это может быть только в случае если помимо формочки на QT у меня отрисовывается еще окошко с Quake 4 в 1280x1024 :)

> Между прочем точно также, можно сказать один в один, за место таблиц >использовать SessionBean, либо работать через любой PersistenManager >(Hibernate, TopLink). Да что тебе объяснять.

Обьясни мне тупому анонимусу как ты собрался " точно также, можно сказать один в один, за место таблиц использовать SessionBean, либо работать через любой PersistenManager", о великий гуру джавы. Или это ниже твоего достойнства?

anonymous
()
Ответ на: комментарий от eXOR

> Ты приходишь на проект поддержки. Разрабатываемый индийской >мегакорпорацией.

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

> Какой источник данных будет использован товарищами из дружеской индии? >Лично я предпочел бы чтобы средство разработки максимально ограничевало >возможность использования вшитых SQL запросов в код.

Как показывает практика любое средство автоматизации в руках идиота может довести до дурки даже самую стойку техподдержку :)

anonymous
()
Ответ на: комментарий от anonymous

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

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

> Как показывает практика любое средство автоматизации в руках идиота
> может довести до дурки даже самую стойку техподдержку :)
Слава Богу тех поддержкой индописаной хероты заниматься не приходится. А вот доработкой индописаной и индокаканой хрени - занимаюсь последние три месяца. Становлюсь расистом.

eXOR ★★★★★
()
Ответ на: комментарий от eXOR

>А вот доработкой индописаной и индокаканой хрени - занимаюсь последние >три месяца. Становлюсь расистом.

Скажи честно -сколько раз порывался переписать все с нуля? :)

anonymous
()
Ответ на: комментарий от anonymous

Ни разу :) Знаю что бюджет под это дело никто не выделит, а дома я лучше буду писать интересные мне вещи, а еще лучше буду больше времени жене уделять. Пробовал рефакторить - но это как мертвому припарки. Куча файлов в проекте к которым не прикасались с 2003 года, куча закомментированного кода (надежда на то что пригодится потом гг :) ну и перлы разного рода круче чем в thedailywtf.com

eXOR ★★★★★
()

Эххххх.

Люди, посмотрите на Java внимательно. Все претензии сводятся к тому, что: а) тормозит, б) жрет много памяти.

По поводу тормозов: тормозит GUI и только GUI (т.к. обычно используется Swing, а Swing - 100% Pure Java и просто обязан жутко тормозить). Все остальное, если писать правльно работает примерно с заявленой скоростью (5-10 раз медленне C). Если задача не очень сложная и есть стандартные классы для решения и у программиста прямые руки, то работать будет "быстрее" программы на C/C++.

Пример, есть такой редактор под виндой Aditor (проект хороший, правда по-моему умер). В этом редакторе есть функция выравнивания текста по ширине. Реализовано таким образом, что чем больше размер файла, тем медленнее работает (на 2 Мб файлах может занять до 5 минут на процессоре около 1ГГц).

Писал прогу на Java, выполняющую то же самое. Если для обработки использовать стандартный класс String (который не модифицируемый!), скорость работы примерно аналогична Aditor'у. После этого переписал все то же самое с использованием StringBuffer, время форматирования 2 Мб текстовичка - 2-4 секунды (проц 2,4 ГГц).

А Вы говорите Java медленнее C/C++! :)

Вывод: 1) надо учить алгоритмы и стандартные библиотеки! 2) Если Вам говорят "Java быстрее C" - не следует понимать это буквально, имеется в виду то, что Java много чего умеет и при правильном использовании возможностей можно получить довольно простой и быстрый продукт!

P.S. Лично у меня программирование на Java начиналось так: нужно решить простенькую задачку, пару часов читаешь документацию, дописываешь несколько строчек кода и все работает, решение обычно элегантное. Со временем доки читаешь реже и реже.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.