Эх. Современные кодогенераторы практически не используют инструкцию «loop». «Практически» — написано, потому что я не могу на 100% сказать про все существующие в природе кодогенераторы. ;)
С ней куча ненужного гемора по сравнению с обычными cmp & jmp. Начиная с помех регаллокатору, и заканчивая вложенными циклами.
С появлением макофьюжена — вообще стала бессмысленна.
Живет только потому, что Intel не выбрасывает ничего ненужного. ;)
Будет порожден один и тот же x86 код при использовании ключика -server.
Про -client просто не знаю. Но кому нужен -client?
Мой ноут по дефолту определяется как server-side machine. :)
ЗЫ Да я знаю случаи, когда вышесказанное не так. Но обычный и правильный девелопер с таким вряд ли столкнется. ;)
> Ели вы будете затем итерироваться по отображению/множеству, используйте LinkedHashMap/LinkedHashSet вместо HashSet/HashMap, поскольку для операция next() итератора существенно быстрее.
Замеры в студию!
> Кроме того, порядок итерации получается такой же, в котором объекты были добавлены.
А вот это уже совсем другое требование.
Если нет специфичных требований к месту использования — всегда используйте наименее ограниченный вариант.
Если нет требований к порядку итератора — надо юзать HashMap вместо LinkedHashMap.
Еще веселее — если нет требований к порядку итератора не нужно использовать SortedMap/SortedSet там где можно обойтись HashMap и т.д.
Ну а самое главное — LinkedHashMap не имеет аналога в java.util.concurrency, что может полностью сломать попытки улучшить скалабильность. HashMap (с точностью до приседаний вокруг null key/value) легко заменяется на ConcurrentHashMap.
;)
Notes:
Серверный JIT удалит нафиг не только деление, но и сам цикл. ;)
Меряем затраты на таймер. ;)
В других тестах (строки/коллекции) такого замечтельного эффекта так вот сразу и не добиться, но также много чего будет удалено.
Ааааа вот еще: мерять Hashtable — это клево. Я аж прослезился от ностальгии, ибо мало кто помнит временя Java 1.0 :)
> на доклад по Java Memory Model в Белом зале было в прямом смысле слова не пробиться.
Здесь необходимо пинать не сколько организаторов, сколько лично докладчика. За что и каюсь. Изначально, была идея объяснить JMM простым языком не вдаваясь в детали реализации. Для этого 20 минут достаточно. Буквально в последний момент у меня появилась возможность получить 45 минут и бОльший зал. Но я уже улетал в командировку, возвращался 9-го апреля вечером в Питер, оттуда через день уезжал в Москву и т.д.
Я просто не был уверен, что у меня будет время расширить слайды и подговится на больший доклад (этого времени кстати и не было).
Еще большой минус — я считаю, что мои слайды по JMM не очень хороши. Они не отчуждаемы от доклада, это набор картинок, к которым прилагается некоторое махание руками, а план махания — он в голове.
С ней куча ненужного гемора по сравнению с обычными cmp & jmp. Начиная с помех регаллокатору, и заканчивая вложенными циклами.
С появлением макофьюжена — вообще стала бессмысленна.
Живет только потому, что Intel не выбрасывает ничего ненужного. ;)
и
Будет порожден один и тот же x86 код при использовании ключика -server.
Про -client просто не знаю. Но кому нужен -client?
Мой ноут по дефолту определяется как server-side machine. :)
ЗЫ Да я знаю случаи, когда вышесказанное не так. Но обычный и правильный девелопер с таким вряд ли столкнется. ;)
Замеры в студию!
> Кроме того, порядок итерации получается такой же, в котором объекты были добавлены.
А вот это уже совсем другое требование.
Если нет специфичных требований к месту использования — всегда используйте наименее ограниченный вариант.
Если нет требований к порядку итератора — надо юзать HashMap вместо LinkedHashMap.
Еще веселее — если нет требований к порядку итератора не нужно использовать SortedMap/SortedSet там где можно обойтись HashMap и т.д.
Ну а самое главное — LinkedHashMap не имеет аналога в java.util.concurrency, что может полностью сломать попытки улучшить скалабильность. HashMap (с точностью до приседаний вокруг null key/value) легко заменяется на ConcurrentHashMap.
Да, любопытная либа хорошо работающая там для чего она создавалась.
Но ИМХО на парадигму не тянет.
Notes:
Серверный JIT удалит нафиг не только деление, но и сам цикл. ;)
Меряем затраты на таймер. ;)
В других тестах (строки/коллекции) такого замечтельного эффекта так вот сразу и не добиться, но также много чего будет удалено.
Ааааа вот еще: мерять Hashtable — это клево. Я аж прослезился от ностальгии, ибо мало кто помнит временя Java 1.0 :)
Автор хорошо знает C#, но слабо Java.
тыкаем пальцем в тест (попадаем в Div10Test)…
копируем к себе…
запускаем java -client:
405076.469 ops/msec (4 threads)
запускаем java -server:
8597842842313.524 ops/msec (4 threads)
отзываемся…
;)
Здесь необходимо пинать не сколько организаторов, сколько лично докладчика. За что и каюсь. Изначально, была идея объяснить JMM простым языком не вдаваясь в детали реализации. Для этого 20 минут достаточно. Буквально в последний момент у меня появилась возможность получить 45 минут и бОльший зал. Но я уже улетал в командировку, возвращался 9-го апреля вечером в Питер, оттуда через день уезжал в Москву и т.д.
Я просто не был уверен, что у меня будет время расширить слайды и подговится на больший доклад (этого времени кстати и не было).
Еще большой минус — я считаю, что мои слайды по JMM не очень хороши. Они не отчуждаемы от доклада, это набор картинок, к которым прилагается некоторое махание руками, а план махания — он в голове.