Релиб / Программирование / Java / Отказ от кастинга / Latest Posts

RE: Отказ от кастинга

Dederer — Tue, 12 Dec 2006 09:54:18 GMT

Думаю самое простое в этом случае посмотреть исходники. Они не большие, да и лицензия позволяет - BSD однако.

RE: Отказ от кастинга

Danissimo — Mon, 11 Dec 2006 14:07:12 GMT

С подходами неблокирующих алгоритмов я знаком. Но они (в общем виде) грешат тем, что просто едят CPU. Это с одной стороны. С другой, они говорят: "When a thread enters a concurrent context..." Так используют они блокировки или нет? Если да, то -- thread contention. Если нет, то поедание CPU.

Соображения?

RE: Отказ от кастинга

Dederer — Mon, 11 Dec 2006 12:46:48 GMT

[quote]Вот это и противоречит концепции java, суть которой "вы создавайте больше новых обьектов, а мы будем совершенствовать GC" :).[/quote]

Если внимательнее почитать их сайт, то становится понятным их "поведение". Это сделано в угоду RTSJ - Real-Time Specification for Java.

А по поводу блокировок. Эти ребятки не так уж и просты чтобы использовать synchronization:
[i]Javolution's collection classes (map, list, table and set) are all RTSJ-Compliant and support concurrent access without synchronization! [/i]
[i]When a thread enters a concurrent context, it may execute multiple concurrent logics by calling any of the ConcurrentContext.execute(logic, arg0, arg1, ...) static methods. The logic is then executed at the same priority as the current thread and in the same memory area by a ConcurrentThread or by the current thread itself if there is no concurrent thread immediately available (as the number of concurrent threads is limited, see Javolution Configuration for details).[/i]

RE: Отказ от кастинга

mselez — Fri, 08 Dec 2006 16:05:31 GMT

[quote]За счет этого увеличивается производительность ([b]меньше операций new ObjecT()[/b]) и [b]меньше нагрузки на GC[/b].[/quote]

Вот это и противоречит концепции java, суть которой "вы создавайте больше новых обьектов, а мы будем совершенствовать GC" :).

RE: Отказ от кастинга

Danissimo — Fri, 08 Dec 2006 11:22:58 GMT

[quote][b]Dederer (08.12.2006)[/b][hr]Transient и управление памятью и Threads их и спасает. Дело в том, что их классы умеют делать пул объектов в рамках треда. За счет этого увеличивается производительность (меньше операций new ObjecT()) и меньше нагрузки на GC.[/quote]
С уменьшением нагрузки на GC я согласен. Но а как же thread contention? Ведь для того, чтобы получить объект из пула, мне нужно выполнить блокировку. Или они придумали неблокирующие алгоритмы? Теоретически это возможно. Но я не знаю неблокирующих алгоритмов, которые бы тупо не ели CPU. Вобщем, болше пока вопросов, чем ответов =))

RE: Отказ от кастинга

Dederer — Fri, 08 Dec 2006 10:52:08 GMT

Javolution вещь, безусловно, хорошая, но в реальном приложении чтобы получить большой выигрыш нужно чтобы все было на них организованно. Для WEB-приложений это не реально - нужно JBoss, Tomcat сначала на них перевезти.

Transient и управление памятью и Threads их и спасает. Дело в том, что их классы умеют делать пул объектов в рамках треда. За счет этого увеличивается производительность (меньше операций new ObjecT()) и меньше нагрузки на GC.

Также у них собственная реализация Number-классов которые работают быстрее на операциях parse и сверки.

RE: Отказ от кастинга

mselez — Thu, 07 Dec 2006 16:23:14 GMT

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

RE: Отказ от кастинга

Danissimo — Thu, 07 Dec 2006 13:15:41 GMT

Проще. А работает? Я вот каждый раз вспоминаю позырьковую сортировку. Представьте, что 100 тыс элементов она сортирует за 1 мин. Миллион -- за 100 минут (1.67 часа). Долго, да? Давайте увеличим тактовую частоту процессора в два раза. Тогда 100 тыс отсортируется за полминуты, а миллион -- за 50 мин =)) И это при том, что процессор в удвоенной частотой -- миф (видели 6-8 ГГц процы?), а если и не миф -- то состояние.

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

RE: Отказ от кастинга

mselez — Wed, 06 Dec 2006 19:04:43 GMT

[quote]я бы сто раз проверил каждую строчку кода[/quote]

Это и отпугивает. Сразу приходит на ум простая альтернатива - а не проще ли добавить еще один компьютер?

RE: Отказ от кастинга

Danissimo — Wed, 06 Dec 2006 16:53:58 GMT

Честно скажу, не пробовал. А вот код посмотрел. И вот че думаю:

1. Я не понял, зачем они в FastMap'е массив с Entry сделали прямоугольным. Есть идеи?
2. Мне не понравилось большое кол-во transient, что может привести (но не обязательно приведет) к борьбе за блокировку на шине памяти.
3. Я видел, что они используют Runnable(). Вопрос, они че, за моей спиной потоками рулят? Если да, то почему в доке я ни слова не встретил про то, какие ньюансы могут вылезти из-за этого? Dead-lock ли free этот код?
4. В чем смысл класса ReentrantLock? Нет, я понял, чего он делает. Я не понял, зачем он написан.

Дальше пока не смотрел. Но бенчмарки у них интересные. Очень даже. Ответственно заявляю. Только вот вопрос, они учитывали кол-во CPU, съедаемое GC?

Что не понравилсь: почему нету (или я не нашел) хеш-таблицы для long? Для остальных примитивных типов они не нужны, а вот для целых -- очень. Но их нету... И вообще нету коллекций для примитивных типов. Не понравилось.

Судя по названию классов, они пытаются управлять памятью. Смело. Настораживает. Пока не смотрел.

Вывод: перед использованием я бы сто раз проверил каждую строчку кода. И уж точно не доверял бы их бенчмаркам =))