elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
Анонс: JPoint 2014: Теоретический минимум, который надо знать, чтобы понять JMM
elizarov

В последнее время на Java конференциях стало появляться множество докладов, которые рассказывать про особенности многопоточного программированию в целом и про Java Memory Model (JMM), которая описана в 17-й главе спецификации языка Java (JLS).

Это не удивительно. В то время как многоядерные процессоры используются уже даже в телефонах, в тех областях программисткой деятельности, где для достижения преимущества над конкурентами надо победить в производительности, без многопоточного программирования не обойтись. И одной передачей сообщений без изменения общей памяти тут не обойтись. Чтобы выжать из современных вычислительных систем всё, что в них заложено, нужно использовать их по максимуму. Это значит, что придется разобраться не только в синтаксисе и семантике вашего языка программирования, как это было всего десять лет назад, но и в его модели памяти. Разобраться, что же происходит, когда несколько потоков одновременно читают или пишут одни и те же участки памяти.

И тут смелого программиста, отправившегося на поиски новых знаний, ждет неприятная новость. В то время, как практически в каждом вузе, будущего программиста обучают основам построения компиляторов, дают необходимый теоритический минимум, который позволяет разобраться в синтаксисе и семантике любого современного языка программирования, практически никто не учит теоритическим основам параллельных вычислений. С такими словами как «произошло до» и «последовательная согласованность» программист первый раз в жизни сталкивается, когда пытается разобраться в том, что такое «гонка данных», почему она происходит в его коде, и почему из-за этого его код не работает. Примерно как если бы, человек севший писать код на новом языке программирования и изучать его синтаксис и семантику, не знал бы что такое «регулярное выражение», «лексический анализ» и «нотация Бэкуса-Наура».

18 Апреля в Москве пройдет конференция JPoint 2014. На ней я сделаю доклад, который призван восполнить этот досадный пробел современной системы образования программистов, не успевшей еще, в своей массе, подстроиться под реалии многопоточного мира. Там будет минимум практики и максимум теории. Определения, понятия, теоремы. Прослушав этот доклад все термины, которые упоминаются в 17-ой главе JLS, обретут для слушателей понятный и законченный смысл.

Этот доклад будет сделан на основе моего доклада 2012 года "Теория параллельного программирования для программистов практиков". Тот доклад наглядно показал, что нельзя объять необъятное. Попытка впихнуть в отведенное слишком много приводит к тому, что большая часть слушателей так и остается в неведении. Я не буду больше пытаться совмещать теорию и практику, а начну с самых базовых теоритических основ. И не просто пробегусь по верхам, создав максимальную плотность определений в единицу времени, а попытаюсь донести до слушателей суть и смысл всех понятий, используя примеры и диаграммы.

UPDATE: А вот и развернутый комментарий о прошедшем докладе со слайдами с ссылками.


  • 1
:) я бы честно говоря пугнулся бы если б мне сказали что для изучения нового языка программирования regexp is a must :D (ну зачем мне еще один perl на голову?)

а если серьезно... то обычному ява программисту достаточно уметь пользоваться локами и уметь отвечать на вопрос как избегать deadlocks (как ты знаешь 90% на этот вопрос ответить не в состоянии)

для чуть больее продвинутых есть disruptor - тут все просто как с телевизором. включил и работает.

для совсем продвинутых JMM - не ответ. гораздо полезнее знать как работает железо. т.е. MM последних интеловых процессоров и как вообще работает память. вот про это расскажи может у 0.1% из тех кто прийдет что-то осядет в мозгу и они поймут что писать lockfree алгоритмы это не сложно

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

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

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

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

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

А при чему тут lazySet? Обычно программисты просто убирают synchronized чтобы сделать код более быстрым :)

Про volatile и final будет?

Желательно в примерах.

Скажем, http://cs.oswego.edu/pipermail/concurrency-interest/2014-March/012435.html и http://cs.oswego.edu/pipermail/concurrency-interest/2014-March/012434.html.

Re: Про volatile и final будет?

Очень немного. Про final точно ничего не будет. Вообще, вся идея сделать такой доклад у меня родилась после проислушивания докладов, в которых слушателям, не понимающим что такое "произошло до" и зачем оно вообще нужно, пытаются объяснить что делает volatile и final. По моим ощущениям результат нулевой -- кто ничего не понимал, так и остается в непонятках.

я честно говоря к любым "оптимизациям" на final отношусь более чем сдержанно. поскольку его МОЖНО менять. да многие возмущаются, но факт остается фактом... честно говоря для оптимизационного "щастья" очень хочется иметь в яве value types (struct csharp) вот это бы порадовало по-настоящему. блин с какого художника их нет и не предвидится... :( правда пришлось бы менять генерики из-за этого ... но даже наполовину (без измененных генериков) это уже было бы щастье

Уважаемый Роман

Чего не будет в вашем докладе, и что интересует многих, я уверен, рассказ о не интеловских и не АРМовских процессорах и памяти, которые, в отличии от архитектуры Фон-Неймана заточены специально для параллельного исполнения. Это печально и говорит о вторичности российских разработок.
С уважением, Иванов Андрей.

Edited at 2014-03-23 06:02 am (UTC)

Re: Уважаемый Роман

а смысл рассказывать о коне за пределами вселенной? (там явы нет) я и к jmm-то на интел/амд процессорах отношусь подозрительно :) (получается больше ограничений чем по факту есть в процессоре - и соотв. можно написать код который по jmm будет некорректен а по факту работать будет)

shared state вообще становится все более и более узко специальной нишей... еще лет пять и будет таким же спцифичным как фортран (я надеюсь)

так что "российскость" разработок тут вообще ни при делах...

Пределы вселенной

Боюсь, что скоро вселенная Интел и АРМ сдуется, пора изучать, что за пределами сферы коня.

Re: Пределы вселенной

И какие вы к этому видете предпосылки?

Re: Пределы вселенной

Уважаемый Евгений!
Очевидно, что в наше время основная вычислительная нагрузка - обработка изображений. Для этого 64 разрядные процессоры слегка не подходят и упёрлись в те проблемы, про которые ваш доклад: Многоядерность мешает одновременному доступу. Или то, или другое.
И вообще архитектура фон Неймана сюда не годится. Начнём с того, что буфер кадра - основное место боёв.Это вместо аккумулятора Видео 4К, а операнды могут быть разные, от 2D спрайтов до вертексов или викселов (3D пикселы).Операции не арифметика, а сдвиг, вращение, масштаб одной машинной командой, изменение цвета или прозрачности по всему операнду, а не циклом. Это всё можно делать на 100 нм ис пониженной тактовой, что минимизирует расход питания. Вот подача и чтение операндов может быть и 10ГГц.Я не прошу вас рассматривать, верен ли такой взгляд на дальнейшее развитие. По моему, он просто неизбежен. Для распознавания образов нужна похожая штука.
С уважением, Иванов А.

  • 1
?

Log in

No account? Create an account