Java: как написать быструю программу?

>Что ты отнаследуешь из класса DateTime?

Я очень часто наследуюсь от Runnable, InputStream, *Model, *Provider, etc

>Она вполне могла быть заточена под яву.

Всмысле? Джава - это голый ООП без чего либо другого.

> Предложите код на плюсах, а мы попробуем портировать...

Лучше наоборот, предложи код на яве, а мы портируем.

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

>> Если класс вообще кому-то полезен то его рано или поздно кото-то унаследует.

>Что ты отнаследуешь из класса DateTime? Или он никому не полезен?

Я бы класс DateTime писать не стал. Или в ++ нет даже такой мелочи?

>> На хелловорлдах это будет нагромождением. >Не боюсь.

Что то типа такого - расширяемый (в рантайме) вики-процессор:

class BoldLineProcessor implement LineProcessor { public String process(String input) { return ...} ; }

class ItalicLineProcessor implement LineProcessor { public String process(String input) { return ...} ; }

class CommentLineProcessor implement LineProcessor { public String process(String input) { return ...} ; }

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

Или, например, в больших архитектурах всё API предоставляеттся интерфейсами (например в Eclipse). Благодаря рантайм-оптимизациям ((IMarker)marker).getValue(...) инлайнится в каждом плагине.

> Предложите код на плюсах, а мы попробуем портировать...

Если бы ты не прогуливал мои лекции^W^W^W^W читал все темы, что я пощу в development, то знал бы, что я постил конкретные примеры, где обработка исключений в плюсах сливает яве в ~ 100 раз. Т.е. уже при 0.4% кидаемых исключений ява обгоняет с++.

кстати да, помню
впрочем, я полагаю что топикстартера всё-таки интересуют не исключения, а числодробилки...

>>> Если класс вообще кому-то полезен то его рано или поздно кото-то унаследует.

>>Что ты отнаследуешь из класса DateTime? Или он никому не полезен?

> Я бы класс DateTime писать не стал. Или в ++ нет даже такой мелочи?

Я жду, когда же ты признаешь, что НЕ ЛЮБОЙ полезный класс предназначен для наследования.

> впрочем, я полагаю что топикстартера всё-таки интересуют не исключения, а числодробилки...

Тогда, полагаю, его и оптимизация виртуального наследования не интересует.

Вот тот пример с эклипсом и (IMaker) можно чуть подробнее? На словах, а потом можно и код состряпать.

s/виртуального наследования/виртуальных функций при наследовании/

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

Также как и на C

>>>> Если класс вообще кому-то полезен то его рано или поздно кото-то унаследует.

>>>Что ты отнаследуешь из класса DateTime? Или он никому не полезен?

>> Я бы класс DateTime писать не стал. Или в ++ нет даже такой мелочи?

>Я жду, когда же ты признаешь, что НЕ ЛЮБОЙ полезный класс предназначен для наследования.

Я этого не признаю, т.к изначальный автор никогда не может знать наперед всех аспектов той сущности которую он моделирует. А даты в Жабе таки наследуемы - java.util.Calendar это интерфейс.

>> Учитывая то, что каждый доступ к оперативки ~150 тактов, к 16 следующим закешированным байтам по ~10 такутов, то сложение за 1-2 такта скорее всего не играет никакой роли.

> Не в какие ворота не лезет. Скорость прокачки памяти в районе 8 GB/s дает в районе 2 Гигаобращений в секунду.

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

Здесь кусочек перевода. http://rus-linux.net/lib.php?name=/MyLDP/hard/memory/memory.html

> обработка исключений в плюсах сливает яве в ~ 100 раз

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

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

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

З.Ы. хотя все это и правда, но я флеймлю.

>Я жду, когда же ты признаешь, что НЕ ЛЮБОЙ полезный класс предназначен для наследования.

Думаю что любой содержательный. То, что всякие String & Integer не расширябельны - это скорее исключение из правила. Не зря в эклипсе следуют идеологии "каждому классу-по интерфейсу". Сначала это кажется идиотизмом, но через некоторое время писания плагинов понимаешь что без этого никак.

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

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

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

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

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

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

Разберем пример: класс Date, хранящий число дней c 1.1.1970.

Допустим, у него есть addDays(int), addMonths(int), ... . Кто-то решил его расшить до DateTime. Если кто-то делает это правильно, то addDays(int) сможет юзать старую байтовую реализацию и нет нужды делать ее виртуальной.

Если же кто-то решил полностью заменить реализацию, т.е. экстендить не путем хранения числа-секунд-с-начала-дня, а путем хранения числа-секунд-с-1.1.1970, **и** при этом класс предполагается использовать через несколько указателей/ссылок одновременно, то тогда да, придется бегать с монтировкой за автором Date.

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

Сегодня в колбасе потребности нет, ибо все потребности перепаханны вдоль и поперек в бесчисленных учебниках...

А у меня есть. Сделай, пожалуста, мне класс TaintedString. Чтобы он отслеживал наличие в строке юзерского инпута. И прозрачно бегал везде вместо обычного стринга, а в моих обращениях к БД, принтах, ... я уж буду проверять отравленность.

К чему я это: финальность стринга стоит требовать только тогда, когда он приходит в виде параметра во вполне определенные методы. А в других случаях, лучше чтобы он был расширяемый.

Этих двух проблем не существует и ты их выдумалю В жабе есть замечательные средства по работе со стрингами и датами. А вот отсутствие стрингов в С++ это проблема, да. Только не вспоминай про std::string, это несерьезно.

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

http://letoverlambda.com/back-cover.png

> Этих двух проблем не существует и ты их выдумал

Опять "потребности в колбасе сегодня нет" ?

А вот в perl-e каждый стринг -- TaintedString, почему мне нельзя такое в яве?

>А вот в perl-e каждый стринг -- TaintedString, почему мне нельзя такое в яве?

Потому что это костыль для решения проблем перла. Жаба инъекциям не подвержена.

> Потому что это костыль для решения проблем перла. Жаба инъекциям не подвержена.

Проблемы инъекции в яве и перле примерно на одном уровне.

>> Потому что это костыль для решения проблем перла. Жаба инъекциям не подвержена.

>Проблемы инъекции в яве и перле примерно на одном уровне.

eval() нет, в jdbc все параметры связываются через биндинг. Куда еще заинъектить можно?

Реализации перемножений матриц наверное можно посмотреть в jscience.org www.matheclipse.org

Кстати, не ты rsdn.ru/forum/java/3459828.flat.aspx искал матбиблиотеку?

> в jdbc все параметры связываются через биндинг. Куда еще заинъектить можно?

Маааленькая табличка с

5 полями, которые можно выводить/не выводить -- 32 варианта

3 атрибутами по которым можно группировать/не группировать и (не сортировать, сортировать по возрастанию, сортировать по убыванию) -- 4*4*4=64 варианта

Итого: 2000 вариантов запросов. Ты их все сможешь забиндить на одну строку?

Да, я знаю что Ява-Way -- это Создать Еще Один Монструозный Фреймворк, когда достаточно всего лишь убедиться, что подаваемый jdbc образец -- не отравлен. А к нему уже биндить.

* Создать Еще Один Монструозный Фреймворк с XML Конфигами

>> в jdbc все параметры связываются через биндинг. Куда еще заинъектить можно?

>Да, я знаю что Ява-Way -- это Создать Еще Один Монструозный Фреймворк, когда достаточно всего лишь убедиться, что подаваемый jdbc образец -- не отравлен.

Ты SQL-запросы на стороне клиента формируешь?

BTW Я хранимыми процедурами все обычно делаю, а на ORM-мазохистов и желающих это все когда-нибудь положить на MySQL кладу.

> Ты SQL-запросы на стороне клиента формируешь?

нет конечно

> ORM-мазохистов и желающих это все когда-нибудь положить на MySQL кладу.

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

http://markfalco.wordpress.com/2009/05/07/fun-with-micro-benchmarks-and-optim... кто на C под Windows перепишет? Померяем, во сколько раз жаба проиграет?

>> ORM-мазохистов и желающих это все когда-нибудь положить на MySQL кладу.

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

Лучше его вычислять однако через что-то типа DBMS_SQL передав хранимой процедуре список колонок и опции.

> Лучше его вычислять однако через что-то типа DBMS_SQL передав хранимой процедуре список колонок и опции.

Тогда все равно встает вопрос, а нет ли в списке колонок отравленных данных.

> ORM-мазохистов и желающих это все когда-нибудь положить на MySQL кладу

И в 5-м мускуле сделали таки хранимые процедуры (сам я их не юзал).

Если вернуться к начальной теме, то по ссылке Карапуза есть полезная ссылка:

http://wikis.sun.com/display/HotSpotInternals/MicroBenchmarks

Хотя сами по себе советы м.б. нечестны, но с точки зрения написания быстрого кода на яве интересны.

А вот ещё вопрос. Как жавовский менеджер памяти справится с большим количеством массивов размером в десятки-сотни мегов? А некоторые из них ещё и переаллоцироваться будут неоднократно... И всё это хозяйство по размеру примерно 70-80% от размера оперативки.

>> Лучше его вычислять однако через что-то типа DBMS_SQL передав хранимой процедуре список колонок и опции.

>Тогда все равно встает вопрос, а нет ли в списке колонок отравленных данных.

DBMS_ASSERT.ENQUOTE_NAME

> DBMS_ASSERT.ENQUOTE_NAME

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

> И всё это хозяйство по размеру примерно 70-80% от размера оперативки.

Докупить памяти или выбросить яву.

___________________________________________

Кстати, а как насчет непереаллоцируемых растущих массивов на х86_64 в с++? Идея в том, что в большом адресном пространстве массивы можно и не переаллоцировать. А наличие физической оперативки под неиспользуемыми адресами вовсе и не требуется.

s/Которую/А эту колонку/

Ты расскажи какие ты знаешь сервера приложений на C++ а потом вместе будем смеяться над числом % их установок от общего количества

>> DBMS_ASSERT.ENQUOTE_NAME

>Я не о том, а о случае, когда в список показываемых колонок попала отравленная строчка например password. Которую не следовало бы показывать.

Взять сделать вьюшку с неопасными колонками и выфетчивать из нее?

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

Старые объекты постепенно проваливаются в синглтонный пул куда gc почти не заходит.

> Ты расскажи какие ты знаешь сервера приложений на C++ а потом вместе будем смеяться над числом % их установок от общего количества

Пока саму JVM (а лучше, и ее библиотеки типа libjpeg) не переписали на Быстрой И Безопасной Яве, смеяться будем над ней.

> Кстати, а как насчет непереаллоцируемых растущих массивов на х86_64 в с++? Идея в том, что в большом адресном пространстве массивы можно и не переаллоцировать. А наличие физической оперативки под неиспользуемыми адресами вовсе и не требуется.

Прикольная идея... Надо её подумать и попробовать в task order пропихнуть...

> Взять сделать вьюшку с неопасными колонками и выфетчивать из нее?

Есть еще один реально встречающий случай дыр (правда, тут и TaintedString надо модифицировать тоже), для которого это не поможет.

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