Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Отличная статья, спасибо!
боттлнек — узкое место
Не программер, но очень понравилось.
«инлайнить»(подскажите правильное слово?)
если вы перевод просите, то слово «инлайн» переводится «открытая подстановка», правда на мой взгляд «межмодульная открытая подстановка» звучит не так прикольно как «межмодульный инлайн» =)
лучше не переводить технические термины, иначе никто не поймет друг друга
Поэтому я не верю, что эталоном виртуальной машины есть путь выбранный JVM. Джава не создана для вот такого будущего:
Конечно, не создана. Она создана для другого: а именно упростить работу с программными потоками как с независимыми друг от друга сущностями, разделяющими общее адресное пространство в одном процессе.
Ведь JVM сама по себе уже много лет не занимается шедулингом собственных (green threads) потоков, а перекладывает эту работу на системный планировщик (ULE3, к примеру, в FreeBSD 7.1) и библиотеку поддержки выполнения легковесных потоков пользовательского уровня (libkse или libthr с pthreads, к примеру). В Solaris и Linux подсистемы поддержки легковесных потоков (LWP) с нативным SMP-планировщиком MxN давно уже работают.
императивная модель конечно ближе, но только потому, что был актуальным на протяжении уже многих десятилетий. сейчас же имхо мы увидим сдвиг парадигмы — это неизбежно и это всегда воспринималось и всегда будет восприниматься в штыки.
java.util.concurrent возможно поможет, но не более чем помог эфир для объяснения природы света.
java.util.concurrent возможно поможет, но не более чем помог эфир для объяснения природы света.
На самом деле статья — скорее для программистов на эрланге, поэтому в ней ничего нету собственно о преимуществах подхода эрланга, подразумевается что и так все понятно.
В двух словах поясню: проблема с java.util.concurrent и другими библиотеками с «классическим подходом» ( java как таковая тут особо не при чем, она в рамках этого подхода как минимум не хуже других) — это
1) тяжеловесность потоков (создание нативного потока, переключение потоков — довольно тяжелая операция)
2) много данных часто расшарено между потоками — императивный подход этому способствует, и из-за большого количества блокировок программа может простаивать и хреново масштабироваться на большое количество процессоров
3) благодаря (2) нужно синхронизировать доступ к данным, а для этого используются такие весьма нетривиальные механизмы как мьютексы, condition variables, евенты и пр. При их использовании требуется немало усилий чтоб не допустить дедлоков и прочих приятных вещей, а отлаживать их нелегко.
В эрланге предлагается для решения проблемы (1) использовать суперлегкие потоки; чтоб обойти (2) он функциональный (хотя не строго — эрланг создавали очень практичные люди, для решения практических задач). (3) решается засчет того что расшаренных данных практически нет (кроме БД и хэш-таблиц), а основной способ общения между потоками — через сообщения.
Вообще говоря, это конечно создает и некоторые неудобства, и это не единственный способ решения этих проблем (см. еще Software Transactional Memory), но способ вполне рабочий и мощный.
В двух словах поясню: проблема с java.util.concurrent и другими библиотеками с «классическим подходом» ( java как таковая тут особо не при чем, она в рамках этого подхода как минимум не хуже других) — это
1) тяжеловесность потоков (создание нативного потока, переключение потоков — довольно тяжелая операция)
2) много данных часто расшарено между потоками — императивный подход этому способствует, и из-за большого количества блокировок программа может простаивать и хреново масштабироваться на большое количество процессоров
3) благодаря (2) нужно синхронизировать доступ к данным, а для этого используются такие весьма нетривиальные механизмы как мьютексы, condition variables, евенты и пр. При их использовании требуется немало усилий чтоб не допустить дедлоков и прочих приятных вещей, а отлаживать их нелегко.
В эрланге предлагается для решения проблемы (1) использовать суперлегкие потоки; чтоб обойти (2) он функциональный (хотя не строго — эрланг создавали очень практичные люди, для решения практических задач). (3) решается засчет того что расшаренных данных практически нет (кроме БД и хэш-таблиц), а основной способ общения между потоками — через сообщения.
Вообще говоря, это конечно создает и некоторые неудобства, и это не единственный способ решения этих проблем (см. еще Software Transactional Memory), но способ вполне рабочий и мощный.
а еще можно пробовать удешевлять создание и переключение потоков на уровне OS или даже ниже, на железе…
Тут, кстати, по поводу FutureTask интересный момент. В ерланге потоки это не «запутил, посчитал. закончил», там вообще все потоки. Это сложно понять, объяснить врядли смогу, но попробую :) В общем решил попробовать эрланг, сделать чтото типа дискового кэша, fault tolerant'ного. так вот после ломаний головы как это все организовать архитектурно, осуществить дублирование, взаимодейсвие отдельных частей и пр. и пр. пришел к тому что тупо запускаем 20-50 тыс. потоков, каждый из которых умеет оперировать строго определенным файлом, который знает кто его самого дублирует и кому пожаловатся, если что. И все заморочки архитектуры тутже пропадают. При этом все эти потоки прекрасно обмениваются друг с другом данными, запускают новые когда считают нужно, и не думают о всяких дедлоках, синхронизациях и пр.
дисклаймер: я сам кучу лет плотно сижу на игле жавы, просто не фанатик.
дисклаймер: я сам кучу лет плотно сижу на игле жавы, просто не фанатик.
Так а какая там нафиг синхронизация? все разделено, всем потокам пофиг на остальных
Вот вот, сложно измерить :) к томуже это скорее прототип, кучу оптимизацй не применено (я же говрю что я хотел лишь посмотреть что такое эрланг). но вообще желание измерить есть, так как именно ради этого я затеял эксперимент.
но перед этим я долго изучал сколько стоит поддержка стольки потоков, судя по многочисленным статьям и тестам это стоит копейки.
но перед этим я долго изучал сколько стоит поддержка стольки потоков, судя по многочисленным статьям и тестам это стоит копейки.
именно об этих синхронизациях данный топик :)
а вообще, об таких вещах не стоит заботится. вы же не заботитесь об том насколько эффективно ЖВМ выделяет вам память или насколько эффективно работает планировщик тех же FutureTasks?
заботится об этом надо как только оно станет проблемой производительности
а вообще, об таких вещах не стоит заботится. вы же не заботитесь об том насколько эффективно ЖВМ выделяет вам память или насколько эффективно работает планировщик тех же FutureTasks?
заботится об этом надо как только оно станет проблемой производительности
но ведь виртуальная машина как и любая другая платформа прячет от вас многие реализации и аспекты низкоуровневого программирования, чтоб можно было сконцентрироваться на конкретной реализации многопоточного алгоритма. поэтому я не понимаю что вас беспокоит? Эрланг очень хорош для прототипирования систем — попробуйте и если производительность будет на порядки ниже допустимой(то есть исключая возможность оптимизации до необходимого уровня) рассмотрите другие варианты.
1) Не совсем то — одновременно, получается, может выполняться только несколько FutureTask'ов, по количеству рабочих потоков. Ну и если например один блокируется (соединения к сокету ждет), то следующий за ним выполняться не начнет ведь. То бишь нельзя создать тыщу таких потоков чтобы они взаимодействовали между собой (хотя кстати в Scala это есть).
2) Разумеется, в java/C++ можно реализовать сообщения, и что угодно. Но ими будет не так удобно пользоваться, а в эрланге есть для этого все средства (прежде всего, pattern matching). Это не просто синтаксический сахар, это заметно упрощает дело.
3) Можно, конечно, придумать дедлок на сообщениях, но там это таки заметно сложнее.
Короче, erlang — не замена яве никак, и можно наверное соорудить аналог эрланга в виде библиотеки для явы. Только будет намного более громоздко и менее эффективно — зачем мучаться, если можно взять эрланг сразу (а там интерфейс к яве, если что, входит в стандартную поставку).
Что касается «навязывания» «правильных» методов программирования параллельных приложений — это нормально, особенно если не ставить цели создать универсальный инструмент. В конце концов, создатели явы в свое время неспроста не стали туда включать перегрузку операторов и множественное наследование из C++, хотя это, безусловно, добавило бы выразительности.
2) Разумеется, в java/C++ можно реализовать сообщения, и что угодно. Но ими будет не так удобно пользоваться, а в эрланге есть для этого все средства (прежде всего, pattern matching). Это не просто синтаксический сахар, это заметно упрощает дело.
3) Можно, конечно, придумать дедлок на сообщениях, но там это таки заметно сложнее.
Короче, erlang — не замена яве никак, и можно наверное соорудить аналог эрланга в виде библиотеки для явы. Только будет намного более громоздко и менее эффективно — зачем мучаться, если можно взять эрланг сразу (а там интерфейс к яве, если что, входит в стандартную поставку).
Что касается «навязывания» «правильных» методов программирования параллельных приложений — это нормально, особенно если не ставить цели создать универсальный инструмент. В конце концов, создатели явы в свое время неспроста не стали туда включать перегрузку операторов и множественное наследование из C++, хотя это, безусловно, добавило бы выразительности.
1) тут уже наверное вопрос в совершенности планировщика виртуальной машины.
2) вопрос глобальный — насколько дешевле будет разрабатывать систему на платформе без готовіх реализаций и без любіх ограничений? насколько высоким будет порог вхождения и насколько больше программистов вы сможете себе позволить?
3) Эрланг не позволяет написать программу наступающую на дэдлок на уровне доступа к памяти. дэдлок на уровне доступа к процессу вполне возможен, но это проблема где то на том же уровне сложности, что и зацикливание в императивном языке. найти и исправить значительно легче.
2) вопрос глобальный — насколько дешевле будет разрабатывать систему на платформе без готовіх реализаций и без любіх ограничений? насколько высоким будет порог вхождения и насколько больше программистов вы сможете себе позволить?
3) Эрланг не позволяет написать программу наступающую на дэдлок на уровне доступа к памяти. дэдлок на уровне доступа к процессу вполне возможен, но это проблема где то на том же уровне сложности, что и зацикливание в императивном языке. найти и исправить значительно легче.
Еще кстати немаловажный момент — в эрланге все можно так же легко и непринужденно разнести не только по потокам на одной системе, но и по разным машинам. Авторы (эрланга) последнее время очень любят заострять внимание именно на многоядерности и подобных плюшках, понятно, это модная тема, но все таки распределенность по-моему основной плюс, а вычислительные задачи чисто на эрланге делать не очень с руки: он же заметно медленнее явы, динамический язык все-таки.
«конкурентности Эрланга дает создателям значительно более вариантов оптимизации.» Поправьте пожалуйста.
«сборщик мусора JVM работает в жестком реальном времени
неподскажите который из? Метроном? Он только IBMовской виртуальной машине…
В Sun HotSpot AFAIK нет hard real time GC…
Кстати вы знакомы с компанией Azul? Они уже сейчас делают „железные Java-машины“, в которых число ядер измеряется сотянями… Так что говорить, что Java не готова к многопроцессорному будущему… Несколько не верно =)
я думаю статья о технологиях с которыми уже в ближайшем будущем(почти сегодня) будет иметь дело самый обычный программист.
я тут просмотрел сайт www.azulsystems.com и не нашел никаких цен. обычный программист может позволить себе использовать этот программный комплекс(или это не только программный но и аппаратный?) например дома?
Тут скорее имелась ввиду не JVM, а сама Java. Автор даже привел в пример Clojure который вроде как готов.
Вы ведь прекрасно понимаете что ускорить программу в 860 раз перенеся ее с 1просессорной машины на 860 процессорную можно лишь при условии что ее код написан так что там ровно 860 полностью независимых потоков, правильно?
Так что тут два подхода, или полностью менять VM (ну и язык к ней), чтобы программисту совсем выбора небыло. Или придумать язык для текущей VM который направит в нужное русло (но к сожалению не заставит). Erlang — первый путь, а Scala, Clojure, Fortress — второй.
Вы ведь прекрасно понимаете что ускорить программу в 860 раз перенеся ее с 1просессорной машины на 860 процессорную можно лишь при условии что ее код написан так что там ровно 860 полностью независимых потоков, правильно?
Так что тут два подхода, или полностью менять VM (ну и язык к ней), чтобы программисту совсем выбора небыло. Или придумать язык для текущей VM который направит в нужное русло (но к сожалению не заставит). Erlang — первый путь, а Scala, Clojure, Fortress — второй.
я понимаю, что топик достаточно холиварный для жавистов, и я должен признать что не знаю всех деталей реализации JVM и не могу аргументированно защищать позицию автора.
топик мне показался интересным в контексте информации об ВМ Эрланг, а не Ява — именно поэтому я и решил его перевести.
топик мне показался интересным в контексте информации об ВМ Эрланг, а не Ява — именно поэтому я и решил его перевести.
Русский не есть моим нативным языком
Истинный программист!
Истинный программист!
Извините но использование термина «жесткое реальном время» в применимости к JVM профанство и дальше можно уже не читать статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На передовой дизайна виртуальных машин