Мы ничего не скрываем, просто писать статьи мы еще только учимся. Пока же основной формат донесения новых знания до человечества это презентации. Про HashMaps вообще я в свое время делал доклад: http://www.slideshare.net/elizarov/ss-13204837 Хороший concurrent hashmap должен быть в первый очередь быстрым при работе из одного потока и безусловно должен базироваться на тех же принципах.
А работа над более совершенными lock-free hash maps это пока еще work in progress. Это была одна из целей создания отдела исследований. Нас интересует не только теоретически корректный алгоритм, но и его правильная реализация. Даже попытки реализовать уже известные concurrent алгоритмы частенько приводят к очень тонким и труднообнаружимым багам, поэтому мы параллельно работаем над инструментами проверки корректности многопоточного кода.
Спасибо. Моя цель была сделать доклад интересным для программистов, которым не приходилось глубоко разбираться в возможностях JVM. Безусловно, если Вы знакомы c threadumps, java agents и bytecode manipulation, то Вы вряд ли найдете в этом докладе что-то нового для себя. Так же как, например, люди профессионально многие годы занимающиеся дизайном и оптимизацией высоконгруженных финансовых приложений не найдут для себя много новой информации в перечисленных выше докладах очень уважаемых людей. И это естественно, ибо это не научные статьи с новыми никому доселе не известными знаниями. Обо всём этом можно было прочитать много лет назад. У каждого доклада своя аудитория.
Еще раз спасибо за проявленный интерес и коментарии. Буду пытаться в будущих докладах расширить «диаппазон», то есть буду стараться сделать их интересными более широкому кругу слушателей.
К сожалению, очень часто говоря про «финансовую сферу и высокие нагрузки» начинают с придыханием рассказывать про какие-нибудь много-мегабайтные каркасы, библиотеки и иснтрументы, при этом вообще не понимая азов: как они устроены изнутри, почему и на каких принципах они работают. Инстументы это отличная вещь, если вы понимаете как они устроены. Например, зная внутренее устройство DTrace намного проще понимать когда его нужно применять, а когда нет.
Мне казалось, что в анонсе своего доклада на ADD-2011 я достачно полно расклыл суть того, о чем я буду говорить (цитирую): «В докладе пойдет речь о методиках изучения производительности Java приложений без использования готовых сторонних инструментов профилирования, а используя не так широко известные встроенные в JVM возможности (threaddumps, java agents, bytecode manipulation).»
Как это моголо сформировать какие-то ложные ожидания?
Блог это не мой memory dump :) Логичного повода упомянуть про RDTSC в блоге пока не было. Да и вообще вряд ли я смогу написать что-то новое про RDTSC — Google вам поможет если вы хотите про него больше знать.
Вы ничего не замеряете в своем коде. HotSpot (-server уж точно) оптимизует (уберет) ваши вызовы, ибо вы ни как не используете их результат. Я рекомендую внимательно изучить документацию к Google Caliper (там вполне адекватная подборка советов), а также другую литературу посвященную написанию microbenchmarks.
Кстати, большое спасибо за ссылку на Foursquare Heapaudit!
Приятно видеть, когда в других компаниях (в данном случае Foursquare) думают точно также как и мы — если готовые инструменты не решают нашу задачу (и да, мы, как я уверен и Foursquare, очень глубоко знакомы с DTrace и он эту задачу не решает), то инстурумент для её решения надо писать самим. Мы сделали это в 2005 год (и в прошлом году у меня долшли руки сделать на эту тему доклад).
Тот факт, что Foursquare сделало это сейчас, говорит о том, что DIY Java Profiling не потеряло актуальность за прошедшие 7 лет. Кстати, мы (Devexperts) тоже планируем выложить наш инструмент под открытой лицензией. Stay Tuned!
Есть у меня аккунт на хабре, только я сюда не пишу. Я пишу все свои техничесные заметки в свой журнал. Там же есть запись про этот доклад, в которой содержаться мои дополнительные мысли и разъяснения на тему доклада. Но я готов отвечать на вопросы и здесь.
System.nanoTime делает много больше, чем RDTSC. В числе прочего он пересчитывает такты процессора в наносекунды и гарантирует неубываемость результатов. Что именно вам подходит лучше (RDTSC или System.nanoTime) зависит от вашей конкретной ситуации.
Например, в своей серии статей о производительности я использую System.nanoTime для всех замеров, но в своей практике сталкивался с реальными случаями, когда был нужен именно RDTSC.
Бывает масса случаев когда и язык свой надо написать. Всё зависит от стоящей перед вами задачи. В любом случая, я считаю что каждый обязан знать как именно устроен компилятор, виртуальная машина, и операционная система и в принципе понимать как это можно всё написать. Тогда будет программист будет ценить уже готовые инструменты и понимать в каких случаях их нужно применять.
В этом докладе я не ставил себе целью дать исчерпывающий обзор инструментов профилирования. Их существует великое множество с теми или иными достоинствами и недостатками. Более того, мой доклад не содержал призывов всегда писать свои собственные инструменты, а вот знать каким образом можно получить тот или иной результат, как самому написать профилировщик того или иного типа должен каждый программист. Только тогда можно оценить тот или иной инструмент, понять что именно этот инструмент замеряет, где его сильные и слабые свойства.
Доклад был не о библиотеках профилирования, а о том как сделать самому. Конечно, если готовый профайлер решает вашу задачу, то логично им воспользоваться. А если нет, то приходится что-то делать самому.
Мне кажется что лучший ответ на этот вопрос дала компания Google в своем официальном блоге (см. секцию Why Kotlin): https://android-developers.googleblog.com/2017/05/android-announces-support-for-kotlin.html
Там раскрыты все основые причины. Попробуйте примерить туда Scala и вы поймете почему не Scala.
А работа над более совершенными lock-free hash maps это пока еще work in progress. Это была одна из целей создания отдела исследований. Нас интересует не только теоретически корректный алгоритм, но и его правильная реализация. Даже попытки реализовать уже известные concurrent алгоритмы частенько приводят к очень тонким и труднообнаружимым багам, поэтому мы параллельно работаем над инструментами проверки корректности многопоточного кода.
Еще раз спасибо за проявленный интерес и коментарии. Буду пытаться в будущих докладах расширить «диаппазон», то есть буду стараться сделать их интересными более широкому кругу слушателей.
Мне казалось, что в анонсе своего доклада на ADD-2011 я достачно полно расклыл суть того, о чем я буду говорить (цитирую): «В докладе пойдет речь о методиках изучения производительности Java приложений без использования готовых сторонних инструментов профилирования, а используя не так широко известные встроенные в JVM возможности (threaddumps, java agents, bytecode manipulation).»
Как это моголо сформировать какие-то ложные ожидания?
Приятно видеть, когда в других компаниях (в данном случае Foursquare) думают точно также как и мы — если готовые инструменты не решают нашу задачу (и да, мы, как я уверен и Foursquare, очень глубоко знакомы с DTrace и он эту задачу не решает), то инстурумент для её решения надо писать самим. Мы сделали это в 2005 год (и в прошлом году у меня долшли руки сделать на эту тему доклад).
Тот факт, что Foursquare сделало это сейчас, говорит о том, что DIY Java Profiling не потеряло актуальность за прошедшие 7 лет. Кстати, мы (Devexperts) тоже планируем выложить наш инструмент под открытой лицензией. Stay Tuned!
Например, в своей серии статей о производительности я использую System.nanoTime для всех замеров, но в своей практике сталкивался с реальными случаями, когда был нужен именно RDTSC.
В этом докладе я не ставил себе целью дать исчерпывающий обзор инструментов профилирования. Их существует великое множество с теми или иными достоинствами и недостатками. Более того, мой доклад не содержал призывов всегда писать свои собственные инструменты, а вот знать каким образом можно получить тот или иной результат, как самому написать профилировщик того или иного типа должен каждый программист. Только тогда можно оценить тот или иной инструмент, понять что именно этот инструмент замеряет, где его сильные и слабые свойства.