Pull to refresh

Comments 51

да, такой вариант у меня был но я как то не решался его использовать :) спасибо, исправил
Не программер, но очень понравилось.
«инлайнить»(подскажите правильное слово?)


если вы перевод просите, то слово «инлайн» переводится «открытая подстановка», правда на мой взгляд «межмодульная открытая подстановка» звучит не так прикольно как «межмодульный инлайн» =)
UFO landed and left these words here
лучше не переводить технические термины, иначе никто не поймет друг друга
говорить на каком-то руглише тоже не всегда приятно… есть ведь красивые слова… «оперативный компилятор», «открытая подстановка», «среда исполнения», «распределение регистров»… так нет же постоянно джит, инлайн, рантайм и регаллок…
Не знаю почему, но согласен с вами ровно наполовину. Если быть точным — в отношении ужасности «рантайма» и «регаллока».
на работе некогда красиво выговаривать «распределение регистров в оперативном компиляторе среды исполнения»

поэтому «регаллок в джите рантайма»
Поэтому я не верю, что эталоном виртуальной машины есть путь выбранный JVM. Джава не создана для вот такого будущего:

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

Ведь JVM сама по себе уже много лет не занимается шедулингом собственных (green threads) потоков, а перекладывает эту работу на системный планировщик (ULE3, к примеру, в FreeBSD 7.1) и библиотеку поддержки выполнения легковесных потоков пользовательского уровня (libkse или libthr с pthreads, к примеру). В Solaris и Linux подсистемы поддержки легковесных потоков (LWP) с нативным SMP-планировщиком MxN давно уже работают.
UFO landed and left these words here
императивная модель конечно ближе, но только потому, что был актуальным на протяжении уже многих десятилетий. сейчас же имхо мы увидим сдвиг парадигмы — это неизбежно и это всегда воспринималось и всегда будет восприниматься в штыки.

java.util.concurrent возможно поможет, но не более чем помог эфир для объяснения природы света.
На самом деле статья — скорее для программистов на эрланге, поэтому в ней ничего нету собственно о преимуществах подхода эрланга, подразумевается что и так все понятно.

В двух словах поясню: проблема с java.util.concurrent и другими библиотеками с «классическим подходом» ( java как таковая тут особо не при чем, она в рамках этого подхода как минимум не хуже других) — это

1) тяжеловесность потоков (создание нативного потока, переключение потоков — довольно тяжелая операция)
2) много данных часто расшарено между потоками — императивный подход этому способствует, и из-за большого количества блокировок программа может простаивать и хреново масштабироваться на большое количество процессоров
3) благодаря (2) нужно синхронизировать доступ к данным, а для этого используются такие весьма нетривиальные механизмы как мьютексы, condition variables, евенты и пр. При их использовании требуется немало усилий чтоб не допустить дедлоков и прочих приятных вещей, а отлаживать их нелегко.

В эрланге предлагается для решения проблемы (1) использовать суперлегкие потоки; чтоб обойти (2) он функциональный (хотя не строго — эрланг создавали очень практичные люди, для решения практических задач). (3) решается засчет того что расшаренных данных практически нет (кроме БД и хэш-таблиц), а основной способ общения между потоками — через сообщения.

Вообще говоря, это конечно создает и некоторые неудобства, и это не единственный способ решения этих проблем (см. еще Software Transactional Memory), но способ вполне рабочий и мощный.
а еще можно пробовать удешевлять создание и переключение потоков на уровне OS или даже ниже, на железе…
UFO landed and left these words here
Тут, кстати, по поводу FutureTask интересный момент. В ерланге потоки это не «запутил, посчитал. закончил», там вообще все потоки. Это сложно понять, объяснить врядли смогу, но попробую :) В общем решил попробовать эрланг, сделать чтото типа дискового кэша, fault tolerant'ного. так вот после ломаний головы как это все организовать архитектурно, осуществить дублирование, взаимодейсвие отдельных частей и пр. и пр. пришел к тому что тупо запускаем 20-50 тыс. потоков, каждый из которых умеет оперировать строго определенным файлом, который знает кто его самого дублирует и кому пожаловатся, если что. И все заморочки архитектуры тутже пропадают. При этом все эти потоки прекрасно обмениваются друг с другом данными, запускают новые когда считают нужно, и не думают о всяких дедлоках, синхронизациях и пр.
дисклаймер: я сам кучу лет плотно сижу на игле жавы, просто не фанатик.
UFO landed and left these words here
Так а какая там нафиг синхронизация? все разделено, всем потокам пофиг на остальных
UFO landed and left these words here
Вот вот, сложно измерить :) к томуже это скорее прототип, кучу оптимизацй не применено (я же говрю что я хотел лишь посмотреть что такое эрланг). но вообще желание измерить есть, так как именно ради этого я затеял эксперимент.
но перед этим я долго изучал сколько стоит поддержка стольки потоков, судя по многочисленным статьям и тестам это стоит копейки.
именно об этих синхронизациях данный топик :)

а вообще, об таких вещах не стоит заботится. вы же не заботитесь об том насколько эффективно ЖВМ выделяет вам память или насколько эффективно работает планировщик тех же FutureTasks?

заботится об этом надо как только оно станет проблемой производительности
UFO landed and left these words here
но ведь виртуальная машина как и любая другая платформа прячет от вас многие реализации и аспекты низкоуровневого программирования, чтоб можно было сконцентрироваться на конкретной реализации многопоточного алгоритма. поэтому я не понимаю что вас беспокоит? Эрланг очень хорош для прототипирования систем — попробуйте и если производительность будет на порядки ниже допустимой(то есть исключая возможность оптимизации до необходимого уровня) рассмотрите другие варианты.
1) Не совсем то — одновременно, получается, может выполняться только несколько FutureTask'ов, по количеству рабочих потоков. Ну и если например один блокируется (соединения к сокету ждет), то следующий за ним выполняться не начнет ведь. То бишь нельзя создать тыщу таких потоков чтобы они взаимодействовали между собой (хотя кстати в Scala это есть).

2) Разумеется, в java/C++ можно реализовать сообщения, и что угодно. Но ими будет не так удобно пользоваться, а в эрланге есть для этого все средства (прежде всего, pattern matching). Это не просто синтаксический сахар, это заметно упрощает дело.

3) Можно, конечно, придумать дедлок на сообщениях, но там это таки заметно сложнее.

Короче, erlang — не замена яве никак, и можно наверное соорудить аналог эрланга в виде библиотеки для явы. Только будет намного более громоздко и менее эффективно — зачем мучаться, если можно взять эрланг сразу (а там интерфейс к яве, если что, входит в стандартную поставку).

Что касается «навязывания» «правильных» методов программирования параллельных приложений — это нормально, особенно если не ставить цели создать универсальный инструмент. В конце концов, создатели явы в свое время неспроста не стали туда включать перегрузку операторов и множественное наследование из C++, хотя это, безусловно, добавило бы выразительности.
1) тут уже наверное вопрос в совершенности планировщика виртуальной машины.

2) вопрос глобальный — насколько дешевле будет разрабатывать систему на платформе без готовіх реализаций и без любіх ограничений? насколько высоким будет порог вхождения и насколько больше программистов вы сможете себе позволить?

3) Эрланг не позволяет написать программу наступающую на дэдлок на уровне доступа к памяти. дэдлок на уровне доступа к процессу вполне возможен, но это проблема где то на том же уровне сложности, что и зацикливание в императивном языке. найти и исправить значительно легче.
Еще кстати немаловажный момент — в эрланге все можно так же легко и непринужденно разнести не только по потокам на одной системе, но и по разным машинам. Авторы (эрланга) последнее время очень любят заострять внимание именно на многоядерности и подобных плюшках, понятно, это модная тема, но все таки распределенность по-моему основной плюс, а вычислительные задачи чисто на эрланге делать не очень с руки: он же заметно медленнее явы, динамический язык все-таки.
«конкурентности Эрланга дает создателям значительно более вариантов оптимизации.» Поправьте пожалуйста.
«сборщик мусора JVM работает в жестком реальном времени


неподскажите который из? Метроном? Он только IBMовской виртуальной машине…
В Sun HotSpot AFAIK нет hard real time GC…

Кстати вы знакомы с компанией Azul? Они уже сейчас делают „железные Java-машины“, в которых число ядер измеряется сотянями… Так что говорить, что Java не готова к многопроцессорному будущему… Несколько не верно =)
UFO landed and left these words here
я думаю статья о технологиях с которыми уже в ближайшем будущем(почти сегодня) будет иметь дело самый обычный программист.
UFO landed and left these words here
я тут просмотрел сайт www.azulsystems.com и не нашел никаких цен. обычный программист может позволить себе использовать этот программный комплекс(или это не только программный но и аппаратный?) например дома?
нет, если он, конечно, не БГ…

с другой стороны у вас дома что 500 ядерная машина и вы на ней на Erlang колбасите?
500 ядерная машина будет и у меня и у вас уже через несколько лет.
Ну если поставить современную видюху то даже сегодня :)
Тут скорее имелась ввиду не JVM, а сама Java. Автор даже привел в пример Clojure который вроде как готов.
Вы ведь прекрасно понимаете что ускорить программу в 860 раз перенеся ее с 1просессорной машины на 860 процессорную можно лишь при условии что ее код написан так что там ровно 860 полностью независимых потоков, правильно?
Так что тут два подхода, или полностью менять VM (ну и язык к ней), чтобы программисту совсем выбора небыло. Или придумать язык для текущей VM который направит в нужное русло (но к сожалению не заставит). Erlang — первый путь, а Scala, Clojure, Fortress — второй.
И что? На Java нельзя написать код, который будет хорошо параллелиться?
Можно, но на порядок проще на clojure и fortres.
разве что синтаксически
А есть чтото важнее? :) ведь не спроста перестали на перфокартах писать код, синтаксис таки имеет значение :)
Ну а на самом деле, я имел ввиду что какой язык такое и приложение. Не буду приводить яркие примеры популярных языков, и поднимать этим еще один холивар, но думаю вы меня уже поняли :)
я понимаю, что топик достаточно холиварный для жавистов, и я должен признать что не знаю всех деталей реализации JVM и не могу аргументированно защищать позицию автора.

топик мне показался интересным в контексте информации об ВМ Эрланг, а не Ява — именно поэтому я и решил его перевести.
UFO landed and left these words here
Может, конечно может. Но на практике такие программы не встречаются :(
Вот тут была вроде хорошая машинка, 32 процессора, куча памяти, все дела. Так вот как ни странно лучше работал вариант с запуском нескольких копий приложения, нежели одного, но на все процессоры :(
UFO landed and left these words here
Русский не есть моим нативным языком
Истинный программист!
Извините но использование термина «жесткое реальном время» в применимости к JVM профанство и дальше можно уже не читать статью.

Видно был неправ. Если это есть в Java SE то уже этим они б'ют .NET очень сильно, правда реализация есть только под Солярку и Сюзю.
Only those users with full accounts are able to leave comments. Log in, please.