Pull to refresh

Comments 40

«за каждый день спектакля я считаю, что частная модель памяти кучи быть очень мощным инструментом в Erlang ящик «с. Она режет целые классы механизмы блокировки из системы во время выполнения и, что означает, что она будет масштабироваться лучше, чем Java будет с той же целью. Java-жесткие ограничения на память сохранить бекон, когда ваша система затопления или DDoSed.»

Made my day!
Извиняюст, случайно вставился лишний фрагмент ) Убрал )
* Извиняюсь
Да чтож такое )
По-моему совсем не лишний. Отлично вписался.
красота!
немедля вернуть!

и меня немного ввело в ступор

>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.

может всетаки точно в 1024?
>Мне кажется, что для Erlang-потока требуется около 512 байт. Для Java-потоков, как правило, необходимо около 512 килобайт, что примерно в 1000 раз больше.

может всетаки точно в 1024?

Ну, в оригинале именно так… Тем более и там и там используется ОКОЛО 512… Видимо поэтому, ПРИМЕРНО в 1000 раз )
Нет. кило- — это ровно 10³.
вы на кибибайт намекаете?
не, я пока по старинке :)

да и в контексте статьи, с моей стороны, было неразумно прицепиться к этому мнимому несоответсвию.

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

Вы их не перекармливайте ;)
Их кормят злые анонимусы из ионной пушки ;-)
Есть ровно два типа утечек памяти, требующих прибивания процесса:

1) невыгребание сообщений
2) накопление данных в состоянии процесса без их сброса

Других ошибок нет и быть не может by design. Долго и неоднократно обсуждали это в рассылке по эрлангу, но ни к чему внятному не пришли. Моё мнение — трекать процесс с максимально забитой памятью и в случае OOM, первым прибивать его. Дешево, практично и логично.
512 кибибайт в 1024 раз больше 512 байт
512 килобайт в 1000 раз больше 512 байт

всегда ваша, матчасть
UFO just landed and posted this here
Опции чтобы менять дефолтные значения, которые, как правило являются дефолтными.
TLAB — это чуть другое, это выделение памяти под объект без использования блокировок. Но это для объектов молодого поколения разумного размера.
UFO just landed and posted this here
краткое содержание:

эрланг поток 512 байт java поток 1000 раз больше эрланг функциональный java общая куча эрланг куча каждому потоку много планировщиков очередь растёт память кончается машины подвисают
>Я выбираю Erlang в случае, когда нужна поток-ориентированная системы обмена сообщениями.
Как насчет Scala? Вроде бы она как раз совмещает в себе преимущества Java и, отчасти, Erlang, особенно если использовать вместе с Akka… Конечно это касается языка, виртуальная машина все равно jvm.
А еще у нее более приятный синтаксис, что тоже немаловажно.
Язык богаче и выразительнее, синтаксис потом будет.
Вы про Эрланг? Когда будет? Дело в том, что ему уже больше двадцати лет и все никак.
Вон Elixir попробуйте если синтаксис уж совсем не нравится (хотя как по мне, то ничего так синтаксис, сносный)
Очень круто, спасибо, обязательно попробую.
Может быть, со мной что-то не так, но почти во всём (кроме, разве что, доступа ко вложенным структурам данных — без синтаксического сахарка тяжеловато) мне эрланг больше питона нравится.
Я читал наискосок, подумал что вы про скалу и джаву. :-)

Про синтаксис эрланга ничего особо не скажу, баловался несколько дней, ничего серьезного не писал. В принципе сносно, тем более что в своё прекрасная учительница в школе давала нам Пролог :-)

Конечно есть фанатики, орущие про ';', '.', ',', но это их удел. Синтаксис специфичен, но не более.
У Акки не все хорошо с документацией и стабильностью, и почти нет эксклюзивных для jvm фишек. Ну и Эрланг это тоже не только много потоков и message-passing.
Если говорить о потоковости то Scala я так подозреваю переисспользует модель из Java.
Java уже проходила этап своих потоков, потому пришлось вернуться к native потокам.
У обоих моделей есть свои как плюсы так и минусы. Есть подозрение что если с этих Erlang потоков нужно обращение к ресурсам системы то большинство преимуществ будут потеряны.
У Erlang VM есть отдельный пул потоков для i/o. Там с этим всё продумано, он создавался исключительно под нужды телекома.
Мне кажется, что статья предвзята. Автор анализирует, что плохого в нативном трэд мэнеджменте JVM при этом абсолютно игнорирую Akka, нацеленный как раз на реализацию микротрэдов из Erlang в JVM.
1) это джава
2) когда её отладят и вылижут из неё хотя бы основную массу детских глюков, будет с чем сравнивать
Мой товарищ недавно нашел утечку памяти в unlink (!) скалы.
3) она _никогда_ не будет такой же стабильной в части использования памяти, потому что куча всё равно общая
К вопросу об ожидаемой критике. Просто интересно. Почему вы считаете, что на функциональных языках нельзя писать реальные приложения?
Вопрос не ко мне, а к автору — я лишь перевел ) лично я функциональные языки обожаю. но к слову сказать, ведь «реальных» приложений на них действительно очень мало.
Мало. Хотя это вопрос терминологии, что считать «реальным» приложением. Функциональные языки не особо востребованы в бизнес-сфере, что, по-моему, им только в плюс
Это не мешает пользоваться функциональной парадигмой в «реальных» приложениях ;)

Буквально недавно начал нырять в функциональный Ruby, открыл для себя очень аккуратные ленивые списки :)

Вообще много где можно писать в функциональном стиле, надо просто знать как это хорошо делать в контексте используемого языка. Иногда получаются очень красивые решения.
Семантика копирования, а не копирование семантики. ;)
Никто не упоминул о таком свойстве JVM, как невозможность возвратить ядру операционной системы страниц памяти, если они больше не нужны — JVM в течении жизни процесса умеет только расти. Erlang это умеет возвращать.

Это очень актуально в облаках, когда оперативная память выделяется по необходимости.
Only those users with full accounts are able to leave comments. Log in, please.

Articles