Comments 40
«за каждый день спектакля я считаю, что частная модель памяти кучи быть очень мощным инструментом в Erlang ящик «с. Она режет целые классы механизмы блокировки из системы во время выполнения и, что означает, что она будет масштабироваться лучше, чем Java будет с той же целью. Java-жесткие ограничения на память сохранить бекон, когда ваша система затопления или DDoSed.»
Made my day!
Made my day!
Извиняюст, случайно вставился лишний фрагмент ) Убрал )
* Извиняюсь
Да чтож такое )
Да чтож такое )
По-моему совсем не лишний. Отлично вписался.
красота!
немедля вернуть!
и меня немного ввело в ступор
>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.
может всетаки точно в 1024?
немедля вернуть!
и меня немного ввело в ступор
>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.
может всетаки точно в 1024?
>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.
может всетаки точно в 1024?
Ну, в оригинале именно так… Тем более и там и там используется ОКОЛО 512… Видимо поэтому, ПРИМЕРНО в 1000 раз )
Нет. кило- — это ровно 10³.
вы на кибибайт намекаете?
не, я пока по старинке :)
да и в контексте статьи, с моей стороны, было неразумно прицепиться к этому мнимому несоответсвию.
думаю стоит лучше выяснить как килять зажравшиеся процессы и главное какие типы задач наиболее подвержены такому разрастанию в памяти.
не, я пока по старинке :)
да и в контексте статьи, с моей стороны, было неразумно прицепиться к этому мнимому несоответсвию.
думаю стоит лучше выяснить как килять зажравшиеся процессы и главное какие типы задач наиболее подвержены такому разрастанию в памяти.
>выяснить как килять зажравшиеся процессы
Вы их не перекармливайте ;)
Вы их не перекармливайте ;)
Есть ровно два типа утечек памяти, требующих прибивания процесса:
1) невыгребание сообщений
2) накопление данных в состоянии процесса без их сброса
Других ошибок нет и быть не может by design. Долго и неоднократно обсуждали это в рассылке по эрлангу, но ни к чему внятному не пришли. Моё мнение — трекать процесс с максимально забитой памятью и в случае OOM, первым прибивать его. Дешево, практично и логично.
1) невыгребание сообщений
2) накопление данных в состоянии процесса без их сброса
Других ошибок нет и быть не может by design. Долго и неоднократно обсуждали это в рассылке по эрлангу, но ни к чему внятному не пришли. Моё мнение — трекать процесс с максимально забитой памятью и в случае OOM, первым прибивать его. Дешево, практично и логично.
512 кибибайт в 1024 раз больше 512 байт
512 килобайт в 1000 раз больше 512 байт
всегда ваша, матчасть
512 килобайт в 1000 раз больше 512 байт
всегда ваша, матчасть
UFO just landed and posted this here
можно приложить ссылочку и на саму дисертацию) www.it.uu.se/research/publications/lic/2005-001/
UFO just landed and posted this here
краткое содержание:
эрланг поток 512 байт java поток 1000 раз больше эрланг функциональный java общая куча эрланг куча каждому потоку много планировщиков очередь растёт память кончается машины подвисают
эрланг поток 512 байт java поток 1000 раз больше эрланг функциональный java общая куча эрланг куча каждому потоку много планировщиков очередь растёт память кончается машины подвисают
>Я выбираю Erlang в случае, когда нужна поток-ориентированная системы обмена сообщениями.
Как насчет Scala? Вроде бы она как раз совмещает в себе преимущества Java и, отчасти, Erlang, особенно если использовать вместе с Akka… Конечно это касается языка, виртуальная машина все равно jvm.
Как насчет Scala? Вроде бы она как раз совмещает в себе преимущества Java и, отчасти, Erlang, особенно если использовать вместе с Akka… Конечно это касается языка, виртуальная машина все равно jvm.
А еще у нее более приятный синтаксис, что тоже немаловажно.
Язык богаче и выразительнее, синтаксис потом будет.
Вы про Эрланг? Когда будет? Дело в том, что ему уже больше двадцати лет и все никак.
Вон Elixir попробуйте если синтаксис уж совсем не нравится (хотя как по мне, то ничего так синтаксис, сносный)
Очень круто, спасибо, обязательно попробую.
еще ссылочка habrahabr.ru/blogs/erlang/115372/
Ещё, кстати, есть Reia
Может быть, со мной что-то не так, но почти во всём (кроме, разве что, доступа ко вложенным структурам данных — без синтаксического сахарка тяжеловато) мне эрланг больше питона нравится.
Я читал наискосок, подумал что вы про скалу и джаву. :-)
Про синтаксис эрланга ничего особо не скажу, баловался несколько дней, ничего серьезного не писал. В принципе сносно, тем более что в своё прекрасная учительница в школе давала нам Пролог :-)
Конечно есть фанатики, орущие про ';', '.', ',', но это их удел. Синтаксис специфичен, но не более.
Про синтаксис эрланга ничего особо не скажу, баловался несколько дней, ничего серьезного не писал. В принципе сносно, тем более что в своё прекрасная учительница в школе давала нам Пролог :-)
Конечно есть фанатики, орущие про ';', '.', ',', но это их удел. Синтаксис специфичен, но не более.
У Акки не все хорошо с документацией и стабильностью, и почти нет эксклюзивных для jvm фишек. Ну и Эрланг это тоже не только много потоков и message-passing.
Если говорить о потоковости то Scala я так подозреваю переисспользует модель из Java.
Java уже проходила этап своих потоков, потому пришлось вернуться к native потокам.
У обоих моделей есть свои как плюсы так и минусы. Есть подозрение что если с этих Erlang потоков нужно обращение к ресурсам системы то большинство преимуществ будут потеряны.
Java уже проходила этап своих потоков, потому пришлось вернуться к native потокам.
У обоих моделей есть свои как плюсы так и минусы. Есть подозрение что если с этих Erlang потоков нужно обращение к ресурсам системы то большинство преимуществ будут потеряны.
Мне кажется, что статья предвзята. Автор анализирует, что плохого в нативном трэд мэнеджменте JVM при этом абсолютно игнорирую Akka, нацеленный как раз на реализацию микротрэдов из Erlang в JVM.
1) это джава
2) когда её отладят и вылижут из неё хотя бы основную массу детских глюков, будет с чем сравнивать
Мой товарищ недавно нашел утечку памяти в unlink (!) скалы.
3) она _никогда_ не будет такой же стабильной в части использования памяти, потому что куча всё равно общая
2) когда её отладят и вылижут из неё хотя бы основную массу детских глюков, будет с чем сравнивать
Мой товарищ недавно нашел утечку памяти в unlink (!) скалы.
3) она _никогда_ не будет такой же стабильной в части использования памяти, потому что куча всё равно общая
К вопросу об ожидаемой критике. Просто интересно. Почему вы считаете, что на функциональных языках нельзя писать реальные приложения?
Вопрос не ко мне, а к автору — я лишь перевел ) лично я функциональные языки обожаю. но к слову сказать, ведь «реальных» приложений на них действительно очень мало.
Мало. Хотя это вопрос терминологии, что считать «реальным» приложением. Функциональные языки не особо востребованы в бизнес-сфере, что, по-моему, им только в плюс
Это не мешает пользоваться функциональной парадигмой в «реальных» приложениях ;)
Буквально недавно начал нырять в функциональный Ruby, открыл для себя очень аккуратные ленивые списки :)
Вообще много где можно писать в функциональном стиле, надо просто знать как это хорошо делать в контексте используемого языка. Иногда получаются очень красивые решения.
Буквально недавно начал нырять в функциональный Ruby, открыл для себя очень аккуратные ленивые списки :)
Вообще много где можно писать в функциональном стиле, надо просто знать как это хорошо делать в контексте используемого языка. Иногда получаются очень красивые решения.
Семантика копирования, а не копирование семантики. ;)
Никто не упоминул о таком свойстве JVM, как невозможность возвратить ядру операционной системы страниц памяти, если они больше не нужны — JVM в течении жизни процесса умеет только расти. Erlang это умеет возвращать.
Это очень актуально в облаках, когда оперативная память выделяется по необходимости.
Это очень актуально в облаках, когда оперативная память выделяется по необходимости.
Sign up to leave a comment.
Архитектура памяти: Erlang против Java