elizarov


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


Previous Entry Share Next Entry
По следам JavaOne: Что ждать от Java 7 (Часть 2: Concurrency)
elizarov
Доклад Brian Goets Concurrency Features in JDK 7 открывается весьма пессимистичным графиком, который наглядно показывает конец роста частоты и начало "multicore era" (по графику видно что это примерно 2003 год). Он рассказывает про парралелизацию вычислений с помощью библиотеки fork-join, которая войдет в Java 7. Это всё еще низкий уровень для прикладного программиста, однако именно такая реализация на низком уровне позволяет эффективно использовать множество ядер для вычислений не затыкаясь на общих локах в очередях заданий, и обеспечивает локальность доступа к памяти в этоху широкого распространения NUMA архитектур. Эффективность этого подхода так же обоснована в докладе Гоэтза.

В конце доклада он рассказаывает про библиотеку ParallelArray, которая построена поверх fork-join, и позволяет декларативно (sql-like образом) производить filter-map-reduce операции над массивами данных прозрачно распараллеливая их на множество ядер. Действительно удобной для использования эта библиотека станет только при добавлении в язык Java замыканый (closures).
Tags:

  • 1
Да, многоядерность сделала вызов и java его приняла. В тигре появилось много новых фич.
А книга Гоэтза (неужели его так зовут?!) про паровозы - это хит! Читать всем :)

На слух - скорее Гё[т]ц. Как и Joshua Bloch - Блок. А как "правильно писать кириллицей" - вопрос сложный...

Превосходно. Большое спасибо. Так и знал, что мама не назовет его Гоэтзом.

А про Блока - слышал такое... Но рука не поднимается писать Блок...
Надо будет себя заставить. Некоторые вообще его блочом кличут (ужас-ужас-ужас).

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

Подозреваю, кончится тем, что железячники просто будут запихивать кроме пары нормальных ядер ещё пару для урезаной Жабы Так делают в ARM. Во многих современных коммуникаторах (включая iPhone) стоит ARM процессор с нативной поддержкой Java Byte Code aka Jazelle.

А на серверах мне импонирует подход Azul -- HotSpot компиляция байт-кода + вообще не раскрывать для пользователя что там внутри за архитектура. Пользователь посылает на исполнение Java Byte Code, а на какой архитектуре оно выполняется его не сильно должно волновать. Главное чтобы выполнялись требования спецификации. Это дает возможность производителю железа не заботится об обратной совместимости, а в каждой новой версии делать те опитимизации архитектуры, которые максимизируют производительность. А пользователь может выбирать того вендора железа, который может быстрей/дешевле выполнять именно его код.


Edited at 2008-06-11 10:53 am (UTC)

А пользователь может выбирать того вендора железа, который может быстрей/дешевле выполнять именно его код.

Шаманские игры всегда дороже и дольше прицельной оптимизации (правда, если делают специалисты)

Тулы по оптимизации запросов для того же Оракла стоят безумных денег

Шаманские игры всегда дороже и дольше прицельной оптимизации (правда, если делают специалисты)

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

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

Проблема только в том, что фирмы вместо специалистов выращивают высококвалифицированных шаманов.

Это не проблема. Это прогресс.

Вот простая аналогия: мастер может выточить из дерева деталь любой формы с помощью ножа. Тоже самое можно сделать с помощью станка с ЧПУ. И оператор станка обучен "быстро находить нужные кнопочки" на станке и ничего не понимает в его устройстве. Это не проблема. Это повышение производительности труда путем более глубокой специализации -- одни специалисты делают станки, другие их программируют, третьи нажимают кнопочки (а на самом деле задействованы сотни различных специалистов). Это на порядок более эффективней, чем если бы все эти ребята сели и стали бы ножичком вырезать детальки из дерева.

То же происходит и в программировании. Уже сейчас понятие "программист" (без уточнения области) не имеет смысла на рынке труда. Тоже самое случилось уже давно с профессиями "физик", "математик", "инженер" и т.п., которые фрагметировались на десятки и сотни под-специализаций.


Не надо приводить аналогии из областей, в которых нет опыта.

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

Если "быстро находить нужные кнопочки" на станке и ничего не понимает в его устройстве, получается продукт кооператива дедушки Ляо.

А насчёт конвеера, в софтоиндустрии сидюки штампуются полностью автоматически.

Ром, я тут был на летней школе по Dependable Computer Systems, и там Bill Sherlis (Carnegie-Mellon) рассказывал про пару софтин от http://www.surelogic.com/, а именно JSure и Flashlight. Они скоро открывают EAP, и что-то мне подсказывает, что тебе будет интересно.

JSure - это имплементация JSR305, описание (аннотациями) намерений по работе с локами плюс плагин к Эклипсу, который ищет места, в которых заявленные намерения не выполняются (доступ с разными локами, доступ без локов, и так далее).

Flashlight - dynamic analysis tool, позволяет смотреть насколько часто брались локи, кто их брал, в каком месте кода, анализировать Locksets, и так далее. Очевидно, ловит возможные (sic!) race conditions.

Плагинов под идею пока не видел, но буду пинать :)

Спасибо! Пугает только что их сайт содержит обычный marketing bullshit. Даже ни одного screenshot-а нет.

Да, сайт пустой :)

Чуть менее пустой сайт проекта, из которого растут ноги - http://www.fluid.cs.cmu.edu:8080/Fluid

Но я видел JSure вживую, и могу отсканить хэндауты :)

Вот скриншоты, кстати: http://www.fluid.cs.cmu.edu:8080/Fluid/fluid-tool-gallery

Но старые, ещё до аннотаций и совместимости с JSR305

Edited at 2008-07-08 09:31 am (UTC)

  • 1
?

Log in

No account? Create an account