Здравствуйте, Gaperton, Вы писали:
G>У "телефонной сети" (AXD301) практическая надежность
А почему, стоит заговорить об эрланге, всегда приводится только этот конкретный девайс? Что, ни одного успешного проекта больше на эрланге нет? Выпускались ли подобные девайсы после AXD301? Использовался ли в них тоже эрланг, если нет, то почему? Или AXD301 — вершина человеческого гения, больше уже ничего делать не надо?
Просто слишком частые ссылки на один единственный пример уже оскомину набили. Так можно найти пример работающей системы, написанной на С, и каждый раз приводить в пример, как доказательство супернадежности С. Ведь на нем embedded софта понаписано гораздо больше, и он даже хорошо работает.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>Потому как хуже HiPE уже сложно сделать. G>>Обоснуй. C>Из опыта. У меня он не ускорил ни одну из моих программ. Даже Питоновский psyco лучшие реузльтаты показывал.
Обычно HiPE ускоряет раза в два — и на это вполне можно рассчитывать. Иногда я получал больше, иногда — меньше (реже). Скажем, общая производительность управляющей программы AXD301 возрасла вдвое при компиляции Хайпом. Если твои программы не ускоряются — значит они упираются в обмен сообщениями и ввод-вывод. Либо — ты неправильно пользуешься Хайпом — например, у тебя слишком много переключений режимов байт-код-нэйтив.
И вообще — приведи пример кода, который не ускоряется Хайпом, в студию.
C>>>Если серьёзно, то система типов в стандартной библиотеке вместе с достаточно даже примитивным JITом существенно улучшит ситуацию. G>>Система типов — это EEP 8. G>>http://www.erlang.org/eeps/eep-0008.html C>Я знаю. Пока только оно всё ещё не дало видимых результатов.
Пока оно не реализовано, когда будет реализовано — тогда и видно будет. Но Хайп неплохо выводит типы из контекста уже сейчас.
G>>HiPE вообще-то выводит типы из контекста, кстати. А каким именно образом примитивный JIT может улучшить ситуацию — не вполне понятно. Я тебя уже в третий раз подряд об этом спрашиваю. Объяснишь? C>Банально — инлайнинг функций, компиляция и инлайнинг ПМ (как в OCaml'е, где ПМ пока самый быстрый из всех, которых я видел). Это две основные вещи, которые могут дать большой прирост скорости.
Банально — все перечисленное тобой Хайп уже делает статически, и я не понимаю, зачем нужен JIT и почему именно он поможет. Добавь вот эти строки в начало своих модулей:
И ни в коем случае не используй export_all — чем меньше межмодульный интерфейс, и чем больше модули, тем лучше Хайп выводит из контекста типы (ага, выводит) и устраняет лишние проверки типов (именно, устраняет). Например, Хайп знает сигнатуры большинства BIF-ов, и использует это при выводе. При наличии операций с плавающей запятой — не забудь поставить сверху гвард на флоат, тогда плавающая запятая скомпилируется в нативную.
К>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Ulf Wiger
It was mentioned in another post that pattern-matching is atomic in the VM. That's correct — the VM will not schedule another process while inside a pattern match (except, of course, in the SMP version, where other schedulers might).
В другом сообщении было отмечено, что сопоставление с образцом является атомарной операцией в VM. Так и есть — VM не будет планировать выполнение других процессов, пока производится выполнение сопоставления(за исключением версии SMP, в которой другие планировщики могут продолжать работу)
уже Трурль указывал. Не 50К там, а 50К*50К, почувствуйте разницу что называется. А 50К можете сами взять и проверить, все матчится мгновенно.
HDL>Пардон, невнимательно посмотрел. То есть, если не ошибаюсь, там матчили списковые структуры по 18 гигобайт
50K*50K = 2500M = 2,5G.
Размер списка чисел = размер слова * 2 * количество элементов = 16 * 2,5G. Сколько получается? Правильно, 16+16+8=40G. Я взял размер слова 8 байт, потому, что очевидно, это будет работать на 64-битном эрланге. На 32-х битном будет 20G, но столько памяти там выделить просто нельзя. Если не разделять подсписки, конечно. Ну что, очень страшная проблема, да? Просто "косяк спецификации языка" ((с)Кодт), и "антипаттерн".
Проблема в том, что некоторые товарищи, в число которых в этот раз попал Кодт, разводят истерику на ровном месте, не затрудняя себя при этом элементарной проверкой фактов. И все бы ничего, но посты этих уважаемых людей читают другие люди, и начинают делать выводы, опять же не затрудняя себя проверками, потому что написали такие уважаемые люди как Кодт.
Здравствуйте, Кодт, Вы писали:
M>>В другом сообщении было отмечено, что сопоставление с образцом является атомарной операцией в VM. Так и есть — VM не будет планировать выполнение других процессов, пока производится выполнение сопоставления(за исключением версии SMP, в которой другие планировщики могут продолжать работу)
К>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка. У меня почему-то фантазии не хватает, и у разработчиков Erlang VM — тоже в свое время не хватило (иначе бы подумали о том, как прервать сопоставление с образцом), и за последние 10 лет эксплуатации production-систем на Эрланге никто не жаловался на дикие блокировки рантайма. И ведь знаешь, что интересно — после обсуждения этой дури в erlang mail-list никто даже дефекта не открыл .
К>А это косяк конкретной реализации машины, или косяк спецификации языка?
Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память. А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто .
К>Ведь, по большому счёту, кому здесь нужна атомарность?
Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Очень редкая ситуация напрактике, Кодт. Боюсь, до такой степени редкая, что является скорее надуманной, и исправлять это никто не будет. Длинные строки, сравнение которых заблокирует рантайм, надо G>>1) Откуда-то взять такие строки, а с этим проблемы. G>>2) Зачем-то пытаться сравнивать две огромные строки, едва влезающих в память и отличающиеся последними символами, тем более в гварде — а это ну совершенно никому не вперлось почему-то. Потому, что длинные строки обычно парсят, а не сравнивают друг с другом.
К>50 килосимволов — это "едва влезает в рантайм"? К>Если про строку изначально известно, что она может быть длинной — это одна ситуация. А если это следствие ошибки — другая. К>Вариант, когда юзер придумал себе 50к-буквенный логин, просто из злого намерения задосить железку.
1) Сомнительно, чтобы 50К строка заблокировала рантайм.
2) Надо сравнивать на равенство одинаковые 50К строки, чтобы это случилось.
3) Ты до сих пор не привел реального примера, подтверждающего высокий приритет проблемы. Все какие-то ахи и вздохи.
4) Никто не даст вводить логин такой длины — пошлют сразу на этапе регистрации.
G>>Вот характерный пример — сейчас обсуждается EEP9, в котором введут встроенные в рантайм функции для работы со строками на binaries. В частности поиск и парсинг регулярных выражений. И ведь знаешь что интересно. Эти функции будут так же блокировать рантайм, да — можно привести исскуственный пример, когда рантайм на короткое время будет заблокирован. Если удастся создать бинарис такой длины, конечно. И знаешь, все совершенно спокойны почему-то насчет этой проблемы.
К>Это, видимо, вообще отношение эрлангистов к проблемам — олимпийское спокойствие.
Как любые нормальные инженеры в любой нормальной организации, разрабатывающей софт — эрлангисты из эрикссона расставляют проблемам приоритеты, и действуют в соответствии с ним. Чтобы исправлять в первую очередь полезные вещи, а фигню всякую, которая никому не нужна — оставлять на потом.
Приоритет этой "проблемы" — низкий, практически нулевой, так как она носит гипотетический характер. С ней на практике никто не столкнулся, иначе бы ее давно уже исправили. Тебя это удивляет? Странно.
К>Вот давеча, когда телефонная сеть рухнула при апгрейде (когда маршрутизаторы ребутили друг друга)... Ну исправили, ну подняли вручную, ну и фиг с ним. К>Уважаю.
У "телефонной сети" (AXD301) практическая надежность девять девяток, к твоему сведению, и при апгрейде комплекс продолжает обрабатывать звонки, и даже не рвет текущих соединений. Repeated Failure, про который ты тут пишешь, так же не приводит к падению throughput в случае Эрланга. Напишешь комплекс такой надежности — будешь эрлангистов учить, что им править, а что нет. А пока извини.
Здравствуйте, http://deadbee.livejournal.com/, Вы писали:
HDL>Я, как и Кодт, видимо, где-то увидел циферь 50000, и смел поверить, что оно матчится сколько-либо заметно для рантайма. Удивительно, как там вообще смогли выделить, если говорить точно, в общей сложности 74 с половиной гигабайт, перед тем, как дивиться чему-либо.
Смотрим еще раз внимательно.
Там не 50К списков из 50К элементов, а 50К ссылок на один список из 50К элементов
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, http://deadbee.livejournal.com/, Вы писали:
HDL>>Я, как и Кодт, видимо, где-то увидел циферь 50000, и смел поверить, что оно матчится сколько-либо заметно для рантайма. Удивительно, как там вообще смогли выделить, если говорить точно, в общей сложности 74 с половиной гигабайт, перед тем, как дивиться чему-либо. WH>Смотрим еще раз внимательно. WH>Там не 50К списков из 50К элементов, а 50К ссылок на один список из 50К элементов
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Курилка, Вы писали:
К>>А теперь отвечаем: откуда в эрланге ссылки? WH>А что в эрланге объекты передаются по значению?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Курилка, Вы писали:
К>>А теперь отвечаем: откуда в эрланге ссылки? WH>Еще можешь покурить вот такую программу:
[cut]
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>Банально — инлайнинг функций, компиляция и инлайнинг ПМ (как в OCaml'е, где ПМ пока самый быстрый из всех, которых я видел). Это две основные вещи, которые могут дать большой прирост скорости. К>>Банально инлайнинг порушит (или переусложнит) текущую систему модулей и хот апдейт C>Чем? У нас остаётся исходный байт-код. Кто мешает по требованию откатить оптимизации и перейти в режим интерпретации, когда потребуется? Ну это, как Sun JVM сейчас делает.
Если ты предоставишь реальный юзкейс и реальный механизм где это будет полезно, то можно поговорить.
А так могу заметить ещё факт, что дискретизация параллелизма построена на редукциях и при увеличении тел функций этот параллелизм будет "страдать" (в зависимости от кода, конечно). Плюс не вижу нахрена тут нужен джит, когда этот инлайнинг вполне себе можно делать в HiPE. Или ты предлагаешь держать рантайм статистику вызовов, ещё более "ускоряя" выполнение эрлангового кода, и по ней делать инлайнинг на базе неких эвристик?
Ну нафига нам JVM для эрланга?
Здравствуйте, WolfHound, Вы писали:
WH>Так что все эти расчеты идут в топку.
Не лез бы ты в очередной раз с указательными пальцами в темы, в которых ничего не понимаешь.
WH>Также смотри это
Здравствуйте, Курилка, Вы писали:
К>Забавный финт обнаружили в эрланговом мейллисте К>Эрланг — тоже верёвка достаточной длины чтобы выстрелить себе в ногу
А можешь обрисовать, в чём конкретно там заподло?
Казалось бы, процесс Tick не взаимодействует с мега-функцией надругательства над списками.
Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Здравствуйте, Кодт, Вы писали:
К>А можешь обрисовать, в чём конкретно там заподло? К>Казалось бы, процесс Tick не взаимодействует с мега-функцией надругательства над списками. К>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Основной сиглетон там — эрланговая ВМ, которая есть 1 процесс с т.зр. ОС (не с т.зр. эрланговой ВМ).
Собственно Мамут всё правильно написал.
Здравствуйте, Кодт, Вы писали:
К>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Эрланговская машина — она однопоточная (в первом приближении). И паттерн-матчинг внутри интерпретатора реализован как обычная нативная функция. Со всеми вытекающими последствиями.
Здравствуйте, Mamut, Вы писали:
К>>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
M>В другом сообщении было отмечено, что сопоставление с образцом является атомарной операцией в VM. Так и есть — VM не будет планировать выполнение других процессов, пока производится выполнение сопоставления(за исключением версии SMP, в которой другие планировщики могут продолжать работу)
Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
А это косяк конкретной реализации машины, или косяк спецификации языка?
Ведь, по большому счёту, кому здесь нужна атомарность?
Здравствуйте, Кодт, Вы писали:
К>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
Уходит, куда она денется-то...
К>А это косяк конкретной реализации машины, или косяк спецификации языка? К>Ведь, по большому счёту, кому здесь нужна атомарность?
Ну вроде спецификации как таковой нету (насколько я знаю), там ISO или типа того
Насколько я понимаю фактически рантайм дискретизирует выполнение процессов по редукциям. Т.е. любой кусок функции, который не вызывает других функций будет выполняться атомарно.
Здравствуйте, Кодт, Вы писали:
К>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
Угу. На практике просто такое не встречается часто.
К>А это косяк конкретной реализации машины, или косяк спецификации языка? К>Ведь, по большому счёту, кому здесь нужна атомарность?
Это банальный недостаток реализации. Атомарный алгоритм PM написать очень просто — я слабо представляю как там его переписать в прерываемый вид.
В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Кодт, Вы писали:
К>>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить? C>Угу. На практике просто такое не встречается часто.
К>>А это косяк конкретной реализации машины, или косяк спецификации языка? К>>Ведь, по большому счёту, кому здесь нужна атомарность? C>Это банальный недостаток реализации. Атомарный алгоритм PM написать очень просто — я слабо представляю как там его переписать в прерываемый вид.
C>В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще.
Только для этого надо переделывать рантайм (вводить уровень управляемого кода), или можно что-нибудь типа хаскельного заюзать, только тоже передалывать рантайм.
Здравствуйте, Курилка, Вы писали:
C>>В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще. К>Только для этого надо переделывать рантайм (вводить уровень управляемого кода), или можно что-нибудь типа хаскельного заюзать, только тоже передалывать рантайм.
Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену.
А нормальный JIT всё равно когда-нибудь нужен будет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще. К>>Только для этого надо переделывать рантайм (вводить уровень управляемого кода), или можно что-нибудь типа хаскельного заюзать, только тоже передалывать рантайм. C>Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену.
Дык о том и речь, что для решения такой проблемы нужен другой управляемый язык.
C>А нормальный JIT всё равно когда-нибудь нужен будет.
Ну за 20 лет пока не понадобился, с джитом это уже имхо будет не эрланг, а другой язык, хотя конкретно не скажу в чём может проявиться разница, могу врать.
Здравствуйте, Курилка, Вы писали:
C>>Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену. К>Дык о том и речь, что для решения такой проблемы нужен другой управляемый язык.
Совсем необязательно. Достаточно сделать, чтобы Erlang-код компилировался в низкоуровневый байт-код (по типу C#/Java), в котором прямо можно записать алгоритм PM.
C>>А нормальный JIT всё равно когда-нибудь нужен будет. К>Ну за 20 лет пока не понадобился, с джитом это уже имхо будет не эрланг, а другой язык, хотя конкретно не скажу в чём может проявиться разница, могу врать.
Нормальные JITы просто не так давно появились. А целиком переделывать Erlang никому не хочется.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену. К>>Дык о том и речь, что для решения такой проблемы нужен другой управляемый язык. C>Совсем необязательно. Достаточно сделать, чтобы Erlang-код компилировался в низкоуровневый байт-код (по типу C#/Java), в котором прямо можно записать алгоритм PM.
Т.е. низкоуровневый байт-код это не есть другой управляемый язык?
C>Нормальные JITы просто не так давно появились. А целиком переделывать Erlang никому не хочется.
Здравствуйте, Gaperton, Вы писали:
К>>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить? G>А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка.
Например, в результате бага.
G>У меня почему-то фантазии не хватает, и у разработчиков Erlang VM — тоже в свое время не хватило (иначе бы подумали о том, как прервать сопоставление с образцом), и за последние 10 лет эксплуатации production-систем на Эрланге никто не жаловался на дикие блокировки рантайма. И ведь знаешь, что интересно — после обсуждения этой дури в erlang mail-list никто даже дефекта не открыл .
Так а смысл открывать-то? Это не бага, это фича такая.
К>>А это косяк конкретной реализации машины, или косяк спецификации языка? G>Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память.
А почему он будет тормозить? Я так не пробовал делать, но вроде причин для тормозов не должно быть. Ну кроме внешних, типа излишнего свопинга.
G>А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто .
Это не косяк — эти два процесса не будут мешать остальным процессам. Ну только если вся память совсем не закончится, что тоже сделано в Erlang'е не самым лучшим образом.
К>>Ведь, по большому счёту, кому здесь нужна атомарность? G>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать.
На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет.
Здравствуйте, Gaperton, Вы писали:
G>А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка. У меня почему-то фантазии не хватает, и у разработчиков Erlang VM — тоже в свое время не хватило (иначе бы подумали о том, как прервать сопоставление с образцом), и за последние 10 лет эксплуатации production-систем на Эрланге никто не жаловался на дикие блокировки рантайма. И ведь знаешь, что интересно — после обсуждения этой дури в erlang mail-list никто даже дефекта не открыл .
Я тоже сперва думал, что паттерн-матчинг с мегасписком — это пальцы отвалятся писать.
Но ведь мегасписком может быть пользовательская строка, приехавшая откуда-нибудь извне.
К>>А это косяк конкретной реализации машины, или косяк спецификации языка? G>Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память. А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто .
Если переполнение очереди сообщений пользовательского процесса убивает всю виртуальную машину — это косяк.
К>>Ведь, по большому счёту, кому здесь нужна атомарность? G>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать.
Не хочешь — не надо. Я просто не знаю масштаб бедствия — почему атомарность ПМ является фундаментальной. Это прихоть, или на неё что-то ещё завязано?
Насколько я понимаю (возможно, заблуждаюсь), ПМ состоит из 3 частей применительно к каждому паттерну:
1) сопоставление структуры паттерна (как он записан!) со структурой аргумента;
2) связывание переменных;
3) сравнение значений в соответствующих узлах структуры паттерна и аргумента; а также проверка условий в guard sequence.
Все претензии по мегасписку — к последнему пункту. Но в нём ведь мы ничего "специального" не делаем, почему бы не выполнять проверки в обычном темпе?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
К>>>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить? G>>А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка. C>Например, в результате бага.
Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится?
К>>>А это косяк конкретной реализации машины, или косяк спецификации языка? G>>Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память. C>А почему он будет тормозить? Я так не пробовал делать, но вроде причин для тормозов не должно быть. Ну кроме внешних, типа излишнего свопинга.
Своппинг и будет. Например — в результате бага.
G>>А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто . C>Это не косяк — эти два процесса не будут мешать остальным процессам. Ну только если вся память совсем не закончится, что тоже сделано в Erlang'е не самым лучшим образом.
Да ты что — это же самый настоящий косяк спецификации языка!
К>>>Ведь, по большому счёту, кому здесь нужна атомарность? G>>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать. C>На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет.
Чем тебя не устраивает HiPE? Зачем нужен именно JIT?
Здравствуйте, Gaperton, Вы писали:
C>>Например, в результате бага. G>Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится?
Просто сложный PM по большому списку. Хотя тоже не так просто получить это...
C>>А почему он будет тормозить? Я так не пробовал делать, но вроде причин для тормозов не должно быть. Ну кроме внешних, типа излишнего свопинга. G>Своппинг и будет. Например — в результате бага.
Со свопингом можно (и нужно!) бороться. Про удивительно плохую работу Erlang'а в условиях недостатка памяти тут уже писали.
C>>Это не косяк — эти два процесса не будут мешать остальным процессам. Ну только если вся память совсем не закончится, что тоже сделано в Erlang'е не самым лучшим образом. G>Да ты что — это же самый настоящий косяк спецификации языка!
Это конкретно — нет.
G>>>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать. C>>На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет. G>Чем тебя не устраивает HiPE?
Ну тормозит он, тормозит.
G>Зачем нужен именно JIT?
Потому, что я не могу из-за тормознутости использовать Erlang на моих устройствах. А так хотелось бы — там вообще идеальная для него задача.
Здравствуйте, Cyberax, Вы писали:
G>>>>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать. C>>>На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет. G>>Чем тебя не устраивает HiPE? C>Ну тормозит он, тормозит.
G>>Зачем нужен именно JIT? C>Потому, что я не могу из-за тормознутости использовать Erlang на моих устройствах. А так хотелось бы — там вообще идеальная для него задача.
Поставим вопрос так — а почему ты думаешь, что JIT будет лучше чем HiPE?
Здравствуйте, Cyberax, Вы писали:
C>>>Например, в результате бага. G>>Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится? C>Просто сложный PM по большому списку. Хотя тоже не так просто получить это...
Например, читаем имена из файла, в котором случилась проблема с разметкой.
И дальше — хотя бы сортируем список этих имён.
Каждое сравнение элементов атомарно (по крайней мере, для наивной реализации, не ждущей заподлянки от пользователя).
Паттерны простейшие, и список небольшой. Всего из двух строк...
Здравствуйте, Gaperton, Вы писали:
G>>>Зачем нужен именно JIT? C>>Потому, что я не могу из-за тормознутости использовать Erlang на моих устройствах. А так хотелось бы — там вообще идеальная для него задача. G>Поставим вопрос так — а почему ты думаешь, что JIT будет лучше чем HiPE?
Потому как хуже HiPE уже сложно сделать.
Если серьёзно, то система типов в стандартной библиотеке вместе с достаточно даже примитивным JITом существенно улучшит ситуацию.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Cyberax, Вы писали:
C>>>>Например, в результате бага. G>>>Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится? C>>Просто сложный PM по большому списку. Хотя тоже не так просто получить это...
К>Например, читаем имена из файла, в котором случилась проблема с разметкой. К>И дальше — хотя бы сортируем список этих имён. К>Каждое сравнение элементов атомарно (по крайней мере, для наивной реализации, не ждущей заподлянки от пользователя). К>Паттерны простейшие, и список небольшой. Всего из двух строк...
Сравнение элементов при сортировке происходит по меньше либо равно Что делается не паттерн-матчингом, а вызовом функции, которая сравнивает строки по одному символу. Поэтому — все будет в порядке. У тебя не получилось. Попробуй еще.
Здравствуйте, Gaperton, Вы писали:
К>>Например, читаем имена из файла, в котором случилась проблема с разметкой. К>>И дальше — хотя бы сортируем список этих имён. К>>Каждое сравнение элементов атомарно (по крайней мере, для наивной реализации, не ждущей заподлянки от пользователя). К>>Паттерны простейшие, и список небольшой. Всего из двух строк...
G> Сравнение элементов при сортировке происходит по меньше либо равно Что делается не паттерн-матчингом, а вызовом функции, которая сравнивает строки по одному символу. Поэтому — все будет в порядке. У тебя не получилось. Попробуй еще.
Э, секундочку! Вызов функции в составе guard sequence — разве не относятся к паттерн-матчингу?
Ну ладно. Взяли и отсортировали этот список мегастрок с использованием непримитивных действий (что оправданно: словарный порядок отличается от поэлементного и зависит от локали).
Но мы же дальше с этими мегастроками что-то делаем. Например, проверяем — принадлежит ли строка списку.
Здравствуйте, Трурль, Вы писали:
Т>Вызов функции в составе guard sequence запрещен.
Зато там разрешены сравнения (<,>,=).
Сравнение строк — примитивная операция или нет?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Трурль, Вы писали:
Т>>Вызов функции в составе guard sequence запрещен. К>Зато там разрешены сравнения (<,>,=). К>Сравнение строк — примитивная операция или нет?
string:equal(String1, String2) -> bool()
Tests whether two strings are equal. Returns true if they are, otherwise false.
Здравствуйте, Gaperton, Вы писали:
G>string:equal(String1, String2) -> bool() G>Tests whether two strings are equal. Returns true if they are, otherwise false.
Какой смысл использовать equals(A,B) вместо A==B, до тех пор, пока не наступишь на грабли с мегастроками?
Логика-то та же самая.
Я не говорю, что косяк непреодолимый. Разумеется, есть способы написать программу, не попадающуюся на этот косяк.
Но антипаттерн с его использованием слишком уж прост и симпатичен...
Что теперь, просмотреть все листинги со всеми гвардами на предмет "нет ли там сравнения списков неконтролируемого размера"?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>string:equal(String1, String2) -> bool() G>>Tests whether two strings are equal. Returns true if they are, otherwise false.
К>Какой смысл использовать equals(A,B) вместо A==B, до тех пор, пока не наступишь на грабли с мегастроками? К>Логика-то та же самая.
К>Я не говорю, что косяк непреодолимый. Разумеется, есть способы написать программу, не попадающуюся на этот косяк. К>Но антипаттерн с его использованием слишком уж прост и симпатичен... К>Что теперь, просмотреть все листинги со всеми гвардами на предмет "нет ли там сравнения списков неконтролируемого размера"?
Очень редкая ситуация напрактике, Кодт. Боюсь, до такой степени редкая, что является скорее надуманной, и исправлять это никто не будет. Длинные строки, сравнение которых заблокирует рантайм, надо
1) Откуда-то взять такие строки, а с этим проблемы.
2) Зачем-то пытаться сравнивать две огромные строки, едва влезающих в память и отличающиеся последними символами, тем более в гварде — а это ну совершенно никому не вперлось почему-то. Потому, что длинные строки обычно парсят, а не сравнивают друг с другом.
Вот характерный пример — сейчас обсуждается EEP9, в котором введут встроенные в рантайм функции для работы со строками на binaries. В частности поиск и парсинг регулярных выражений. И ведь знаешь что интересно. Эти функции будут так же блокировать рантайм, да — можно привести исскуственный пример, когда рантайм на короткое время будет заблокирован. Если удастся создать бинарис такой длины, конечно. И знаешь, все совершенно спокойны почему-то насчет этой проблемы.
Здравствуйте, Gaperton, Вы писали:
G>Очень редкая ситуация напрактике, Кодт. Боюсь, до такой степени редкая, что является скорее надуманной, и исправлять это никто не будет. Длинные строки, сравнение которых заблокирует рантайм, надо G>1) Откуда-то взять такие строки, а с этим проблемы. G>2) Зачем-то пытаться сравнивать две огромные строки, едва влезающих в память и отличающиеся последними символами, тем более в гварде — а это ну совершенно никому не вперлось почему-то. Потому, что длинные строки обычно парсят, а не сравнивают друг с другом.
50 килосимволов — это "едва влезает в рантайм"?
Если про строку изначально известно, что она может быть длинной — это одна ситуация. А если это следствие ошибки — другая.
Вариант, когда юзер придумал себе 50к-буквенный логин, просто из злого намерения задосить железку.
G>Вот характерный пример — сейчас обсуждается EEP9, в котором введут встроенные в рантайм функции для работы со строками на binaries. В частности поиск и парсинг регулярных выражений. И ведь знаешь что интересно. Эти функции будут так же блокировать рантайм, да — можно привести исскуственный пример, когда рантайм на короткое время будет заблокирован. Если удастся создать бинарис такой длины, конечно. И знаешь, все совершенно спокойны почему-то насчет этой проблемы.
Это, видимо, вообще отношение эрлангистов к проблемам — олимпийское спокойствие.
Вот давеча, когда телефонная сеть рухнула при апгрейде (когда маршрутизаторы ребутили друг друга)... Ну исправили, ну подняли вручную, ну и фиг с ним.
Уважаю.
Здравствуйте, Gaperton, Вы писали:
К>>Вот давеча, когда телефонная сеть рухнула при апгрейде (когда маршрутизаторы ребутили друг друга)... Ну исправили, ну подняли вручную, ну и фиг с ним. К>>Уважаю. G>У "телефонной сети" (AXD301) практическая надежность девять девяток, к твоему сведению, и при апгрейде комплекс продолжает обрабатывать звонки, и даже не рвет текущих соединений. Repeated Failure, про который ты тут пишешь, так же не приводит к падению throughput в случае Эрланга. Напишешь комплекс такой надежности — будешь эрлангистов учить, что им править, а что нет. А пока извини.
Впрочем — почему же "извини". Чего это я в самом деле за других-то говорю. Это я зря. Велкам в эрланг мэл-лист, возможно там отнесутся к твоей аргументации и примерам из 50К-символьных логинов более отзывчиво. В чем я лично сомневаюсь.
Здравствуйте, Gaperton, Вы писали:
G>Вот характерный пример — сейчас обсуждается EEP9, в котором введут встроенные в рантайм функции для работы со строками на binaries. В частности поиск и парсинг регулярных выражений.
А здесь можно подробнее? Я в последнее время не слежу за Erlang mail list — времени нет.
Какие именно регэкспы будут? Некоторые имеют весьма неприятную тенденцию работать слишком долго.
G>И ведь знаешь что интересно. Эти функции будут так же блокировать рантайм, да — можно привести исскуственный пример, когда рантайм на короткое время будет заблокирован. Если удастся создать бинарис такой длины, конечно. И знаешь, все совершенно спокойны почему-то насчет этой проблемы.
Так сделать с проблемой-то особо ничего нельзя. Вот и спокойны — какой смысл напрасно паниковать?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вот характерный пример — сейчас обсуждается EEP9, в котором введут встроенные в рантайм функции для работы со строками на binaries. В частности поиск и парсинг регулярных выражений. C>А здесь можно подробнее? Я в последнее время не слежу за Erlang mail list — времени нет. http://www.erlang.org/eeps/eep-0009.html
Уже есть reference implementation, насколько я понялю
C>Какие именно регэкспы будут? Некоторые имеют весьма неприятную тенденцию работать слишком долго.
Там же. Плюс обсуждение в mailing list. Крайне любопытное.
G>>И ведь знаешь что интересно. Эти функции будут так же блокировать рантайм, да — можно привести исскуственный пример, когда рантайм на короткое время будет заблокирован. Если удастся создать бинарис такой длины, конечно. И знаешь, все совершенно спокойны почему-то насчет этой проблемы. C>Так сделать с проблемой-то особо ничего нельзя. Вот и спокойны — какой смысл напрасно паниковать?
Вообще-то можно. Достаточно научить BIF-ы прерываться по таймеру, и написать обертку на Эрланге, которая будет гонять их в цикле. Все. Ничего особо сложного.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Gaperton, Вы писали:
G>>У "телефонной сети" (AXD301) практическая надежность
DM>А почему, стоит заговорить об эрланге, всегда приводится только этот конкретный девайс? Что, ни одного успешного проекта больше на эрланге нет? Выпускались ли подобные девайсы после AXD301? Использовался ли в них тоже эрланг, если нет, то почему? Или AXD301 — вершина человеческого гения, больше уже ничего делать не надо?
Про другие продукты нет подробных отчетов. Поэтому нет и точных данных. Претензии по поводу отсутствия публичных отчетов о разработке прошу адресовать не мне, а авторам проектов.
Насчет других продуктов Per Berkvist (работал в Эрикссон) говорил мне в 2006, что все успешные проекты продукты Эрикссон за последние 7 лет сделаны с применением Erlang.
Вот, допустим, есть решения synapse (synap.se) для операторов мобильной связи, директором которого является Берквист. Он отчетов не пишет как-то, знаете ли.
DM>Просто слишком частые ссылки на один единственный пример уже оскомину набили.
Извините, это не моя проблема, а ваша. Другие примеры ищите сами.
DM>Так можно найти пример работающей системы, написанной на С, и каждый раз приводить в пример, как доказательство супернадежности С. Ведь на нем embedded софта понаписано гораздо больше, и он даже хорошо работает.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>>>Зачем нужен именно JIT? C>>>Потому, что я не могу из-за тормознутости использовать Erlang на моих устройствах. А так хотелось бы — там вообще идеальная для него задача. G>>Поставим вопрос так — а почему ты думаешь, что JIT будет лучше чем HiPE? C>Потому как хуже HiPE уже сложно сделать.
Обоснуй.
C>Если серьёзно, то система типов в стандартной библиотеке вместе с достаточно даже примитивным JITом существенно улучшит ситуацию.
Система типов — это EEP 8. http://www.erlang.org/eeps/eep-0008.html
HiPE вообще-то выводит типы из контекста, кстати. А каким именно образом примитивный JIT может улучшить ситуацию — не вполне понятно. Я тебя уже в третий раз подряд об этом спрашиваю. Объяснишь?
Re[18]: Как замучать эрланговый рантайм
От:
Аноним
Дата:
28.03.08 07:58
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Приоритет этой "проблемы" — низкий, практически нулевой, так как она носит гипотетический характер. С ней на практике никто не столкнулся, иначе бы ее давно уже исправили. Тебя это удивляет? Странно.
Мне, например, тоже часто приходило в голову "сравнивать" паттернматчингом. Особенно, когда выгодно позволить рухнуть мелкому процессу при неправильных данных и ловить badmatch не нужно. Вроде как erlang даже поощряет такое. Теперь знаю, что это антипаттерн. 50 килосимволов — это не так много и на других системах число может быть меньше. Не понимаю, почему вы думаете, что проблема на столько гипотетическая
Здравствуйте, http://deadbee.livejournal.com/, Вы писали:
HDL>Здравствуйте, Gaperton, Вы писали:
G>>Приоритет этой "проблемы" — низкий, практически нулевой, так как она носит гипотетический характер. С ней на практике никто не столкнулся, иначе бы ее давно уже исправили. Тебя это удивляет? Странно.
HDL>Мне, например, тоже часто приходило в голову "сравнивать" паттернматчингом. Особенно, когда выгодно позволить рухнуть мелкому процессу при неправильных данных и ловить badmatch не нужно. Вроде как erlang даже поощряет такое. Теперь знаю, что это антипаттерн. 50 килосимволов — это не так много и на других системах число может быть меньше. Не понимаю, почему вы думаете, что проблема на столько гипотетическая
Здравствуйте, Gaperton, Вы писали:
G>Размер списка чисел = размер слова * 2 * количество элементов = 16 * 2,5G. Сколько получается? Правильно, 16+16+8=40G. Я взял размер слова 8 байт, потому, что очевидно, это будет работать на 64-битном эрланге.
tails [1..50]
Люди, я люблю вас! Будьте бдительны!!!
Re[22]: Как замучать эрланговый рантайм
От:
Аноним
Дата:
01.04.08 02:13
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Проблема в том, что некоторые товарищи, в число которых в этот раз попал Кодт, разводят истерику на ровном месте, не затрудняя себя при этом элементарной проверкой фактов. И все бы ничего, но посты этих уважаемых людей читают другие люди, и начинают делать выводы, опять же не затрудняя себя проверками, потому что написали такие уважаемые люди как Кодт.
Я, как и Кодт, видимо, где-то увидел циферь 50000, и смел поверить, что оно матчится сколько-либо заметно для рантайма. Удивительно, как там вообще смогли выделить, если говорить точно, в общей сложности 74 с половиной гигабайт, перед тем, как дивиться чему-либо. Вот кстати, в тему топика: почему рантайм не убивает процесс, который захотел памяти, сколько ее нет, а рушится сам?
Здравствуйте, http://deadbee.livejournal.com/, Вы писали:
HDL>Я, как и Кодт, видимо, где-то увидел циферь 50000, и смел поверить, что оно матчится сколько-либо заметно для рантайма. Удивительно, как там вообще смогли выделить, если говорить точно, в общей сложности 74 с половиной гигабайт, перед тем, как дивиться чему-либо. Вот кстати, в тему топика: почему рантайм не убивает процесс, который захотел памяти, сколько ее нет, а рушится сам?
Предложите решение которое бы убивало процесс, с сохранением всей семантики и нынешней скорости выполнения.
Здравствуйте, Курилка, Вы писали:
К>А теперь отвечаем: откуда в эрланге ссылки?
Еще можешь покурить вот такую программу:
using System;
using System.Console;
using Nemerle.Utility;
module Program
{
variant Tree
{
| Nil
| Node { l : Tree; r : Tree; }
public Size : int
{
get
{
match (this)
{
| Nil => 1;
| Node(l, r) => 1 + l.Size + r.Size;
}
}
}
}
Main() : void
{
def next(t : Tree) : Tree
{
WriteLine(t.Size);
Tree.Node(t, t);
}
def t : Tree = Tree.Nil();
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
def t = next(t);
_ = ReadKey();
}
}
Таже фигня только в гораздо болие жестоком виде... памяти раз два и обчелся но матчить... особенно если если next раз 100 позвать (ессно подсчет размера придется убрать)
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Курилка, Вы писали:
К>>>А теперь отвечаем: откуда в эрланге ссылки? WH>>А что в эрланге объекты передаются по значению?
К>В эрланге нет объектов
Не в пику — мне очень нравятся твои ответы, а исключительно заради справедливости и занудства. Процесс является вполне себе настоящим объектом, со всеми необходимыми аттрибутами объекта. А pid — его identity, ссылкой.
Кроме того, есть (редкие) исключения в виде штуковин типа ets и dets, которые мутабельны, и ничего кроме ссылок на них нет. Соответственно, абстрактные типы данных, которые на построены — например модуль граф из стандартной либы — это самый настоящий объект со ссылками на него, который надо создать и не забыть удалить.
Здравствуйте, Gaperton, Вы писали:
C>>Потому как хуже HiPE уже сложно сделать. G>Обоснуй.
Из опыта. У меня он не ускорил ни одну из моих программ. Даже Питоновский psyco лучшие реузльтаты показывал.
C>>Если серьёзно, то система типов в стандартной библиотеке вместе с достаточно даже примитивным JITом существенно улучшит ситуацию. G>Система типов — это EEP 8. G>http://www.erlang.org/eeps/eep-0008.html
Я знаю. Пока только оно всё ещё не дало видимых результатов.
G>HiPE вообще-то выводит типы из контекста, кстати. А каким именно образом примитивный JIT может улучшить ситуацию — не вполне понятно. Я тебя уже в третий раз подряд об этом спрашиваю. Объяснишь?
Банально — инлайнинг функций, компиляция и инлайнинг ПМ (как в OCaml'е, где ПМ пока самый быстрый из всех, которых я видел). Это две основные вещи, которые могут дать большой прирост скорости.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>HiPE вообще-то выводит типы из контекста, кстати. А каким именно образом примитивный JIT может улучшить ситуацию — не вполне понятно. Я тебя уже в третий раз подряд об этом спрашиваю. Объяснишь? C>Банально — инлайнинг функций, компиляция и инлайнинг ПМ (как в OCaml'е, где ПМ пока самый быстрый из всех, которых я видел). Это две основные вещи, которые могут дать большой прирост скорости.
Банально инлайнинг порушит (или переусложнит) текущую систему модулей и хот апдейт
Здравствуйте, WolfHound, Вы писали:
WH>Смотрим еще раз внимательно. WH>Там не 50К списков из 50К элементов, а 50К ссылок на один список из 50К элементов
Eshell V5.5.2 (abort with ^G)
1> lists:duplicate(5,lists:seq(1,5)).
[[1,2,3,4,5],[1,2,3,4,5],[1,2,3,4,5],[1,2,3,4,5],[1,2,3,4,5]]
Значит, при 50K элементах будет список из 50К подсписков, каждый из которых по 50К элементов... всего 2.5G элементов...
Здравствуйте, geniepro, Вы писали:
G>Значит, при 50K элементах будет список из 50К подсписков, каждый из которых по 50К элементов... всего 2.5G элементов...
Еще раз. Там физически ровно 2 списка.
Список интов и список ссылок на список интов.
Ибо никто в здравом уме не станет клонировать неизменяемую структуру данных.
Так что все эти расчеты идут в топку.
Также смотри это
Здравствуйте, Курилка, Вы писали:
C>>Банально — инлайнинг функций, компиляция и инлайнинг ПМ (как в OCaml'е, где ПМ пока самый быстрый из всех, которых я видел). Это две основные вещи, которые могут дать большой прирост скорости. К>Банально инлайнинг порушит (или переусложнит) текущую систему модулей и хот апдейт
Чем? У нас остаётся исходный байт-код. Кто мешает по требованию откатить оптимизации и перейти в режим интерпретации, когда потребуется? Ну это, как Sun JVM сейчас делает.
Sapienti sat!
Re[26]: Как замучать эрланговый рантайм
От:
Аноним
Дата:
02.04.08 01:11
Оценка:
Здравствуйте, WolfHound, Вы писали: G>Значит, при 50K элементах будет список из 50К подсписков, каждый из которых по 50К элементов... всего 2.5G элементов... WH>Еще раз. Там физически ровно 2 списка. WH>Список интов и список ссылок на список интов. WH>Ибо никто в здравом уме не станет клонировать неизменяемую структуру данных. WH>Так что все эти расчеты идут в топку.
В топку идут догадки.
$ erl
Erlang (BEAM) emulator version 5.5.2 [source] [async-threads:0] [kernel-poll:false]
Eshell V5.5.2 (abort with ^G)
1> N=50000, A=lists:duplicate(N,lists:seq(1,N)).
Crash dump was written to: erl_crash.dump
eheap_alloc: Cannot reallocate 2501920024 bytes of memory (of type "heap").
Aborted
werl.exe занял 200MB ОЗУ (похоже, на каждый элемент списка уходит по 8 байт на 32-битной WinXP -- 4 байта на число и 4 байта на ссылку на след. элемент...)
1> N=50000, A=lists:duplicate(N,lists:seq(1,N)), L=lists:last(lists:last(A)).
Crash dump was written to: erl_crash.dump
eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type "heap").
Abnormal termination
werl.exe долго о чём-то думал, занимая при этом всего 10MB памяти, а потом выдал сообщение об ошибке.
Ну тут-то уж не нужно трёх с половиной гигабайт для печати числа 50000...
G>werl.exe занял 200MB ОЗУ (похоже, на каждый элемент списка уходит по 8 байт на 32-битной WinXP -- 4 байта на число и 4 байта на ссылку на след. элемент...)
A good start when programming efficiently is to have knowledge about how much memory different data types and operations require. It is implementation-dependent how much memory the Erlang data types and other items consume, but here are some figures for erts-5.2 system (OTP release R9B). (There have been no significant changes in R12B.)
The unit of measurement is memory words. There exists both a 32-bit and a 64-bit implementation, and a word is therefore, 4 bytes or 8 bytes, respectively.
Memory size of different data types
Data type Memory size
Integer (-16#7FFFFFF < i <16#7FFFFFF) 1 word
Integer (big numbers) 3..N words
Atom 1 word. Note: an atom refers into an atom table which also consumes memory. The atom text is stored once for each unique atom in this table. The atom table is not garbage-collected.
Float On 32-bit architectures: 4 words
On 64-bit architectures: 3 words
Binary 3..6 + data (can be shared)
List 1 word per element + the size of each element
String (is the same as a list of integers) 2 words per character
Tuple 2 words + the size of each element
Pid 1 word for a process identifier from the current local node, and 5 words for a process identifier from another node. Note: a process identifier refers into a process table and a node table which also consumes memory.
Port 1 word for a port identifier from the current local node, and 5 words for a port identifier from another node. Note: a port identifier refers into a port table and a node table which also consumes memory.
Reference On 32-bit architectures: 5 words for a reference from the current local node, and 7 words for a reference from another node.
On 64-bit architectures: 4 words for a reference from the current local node, and 6 words for a reference from another node. Note: a reference refers into a node table which also consumes memory.
Fun 9..13 words + size of environment. Note: a fun refers into a fun table which also consumes memory.
Ets table Initially 768 words + the size of each element (6 words + size of Erlang data). The table will grow when necessary.
Erlang process 327 words when spawned including a heap of 233 words.
Здравствуйте, Gaperton, Вы писали:
G>Не лез бы ты в очередной раз с указательными пальцами в темы, в которых ничего не понимаешь.
А тебе не кажется что этот твой камент и + на этом
несколько протеворечат друг другу?
Или ты таки хочешь сказать что авторы эрланга совсем больные и клонируют неизменяемые структуры данных?
G>В топку идут такие программы, не имеющие никакого отношения к теме дискуссии.
Очень даже имеет.
Это пример того как можно построить огромную с логической точки зрения структуру данных затратив при это очень мало памяти.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
G>>Не лез бы ты в очередной раз с указательными пальцами в темы, в которых ничего не понимаешь. WH>А тебе не кажется что этот твой камент и + на этом
несколько протеворечат друг другу? WH>Или ты таки хочешь сказать что авторы эрланга совсем больные и клонируют неизменяемые структуры данных?
Я поставил плюс на твоем комменте, потому что с ним согласен. Я написал тебе предыдущий коммент — потому, что не согласен с твоим следующим замечанием.
1) Структура с разделением данных не отменяет рассчета количества элементов, по которым будет пробежка при сопоставлении с образцом. Он был проведен автором корректно.
2) "В топку" оправлять рассчеты вот так запросто — вообще нехорошо. Люди от этого заводятся. Температура дискуссии повышается.
G>>В топку идут такие программы, не имеющие никакого отношения к теме дискуссии. WH>Очень даже имеет. WH>Это пример того как можно построить огромную с логической точки зрения структуру данных затратив при это очень мало памяти.
Если ты это хотел сказать своим примером — то тогда конечно имеет. Только откуда мне (да и другим) знать, что ты хотел этим примером сказать, выводы можно сделать самые разные. Добавил бы сразу это короткое предложение — вопросов бы не было.
Здравствуйте, Курилка, Вы писали:
C>>Чем? У нас остаётся исходный байт-код. Кто мешает по требованию откатить оптимизации и перейти в режим интерпретации, когда потребуется? Ну это, как Sun JVM сейчас делает. К>Если ты предоставишь реальный юзкейс и реальный механизм где это будет полезно, то можно поговорить.
Ровно точно такой же, как и в Sun JVM — оптимизация кода на базе собраной статистики после некоторого периода интерпретации. А потом деоптимизация и переключение в режим интерпретации по требованию (при перезагрузке кода, например).
К>А так могу заметить ещё факт, что дискретизация параллелизма построена на редукциях и при увеличении тел функций этот параллелизм будет "страдать" (в зависимости от кода, конечно). Плюс не вижу нахрена тут нужен джит, когда этот инлайнинг вполне себе можно делать в HiPE. Или ты предлагаешь держать рантайм статистику вызовов, ещё более "ускоряя" выполнение эрлангового кода, и по ней делать инлайнинг на базе неких эвристик?
Да. Плюс, может быть, ещё удастся сделать инлайнинг посылки сообщений (т.е. превратить посылку в прямой вызов).
К>Ну нафига нам JVM для эрланга?
JVM быстрая.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>Чем? У нас остаётся исходный байт-код. Кто мешает по требованию откатить оптимизации и перейти в режим интерпретации, когда потребуется? Ну это, как Sun JVM сейчас делает. К>>Если ты предоставишь реальный юзкейс и реальный механизм где это будет полезно, то можно поговорить. C>Ровно точно такой же, как и в Sun JVM — оптимизация кода на базе собраной статистики после некоторого периода интерпретации. А потом деоптимизация и переключение в режим интерпретации по требованию (при перезагрузке кода, например).
См. последний коммент.
К>>А так могу заметить ещё факт, что дискретизация параллелизма построена на редукциях и при увеличении тел функций этот параллелизм будет "страдать" (в зависимости от кода, конечно). Плюс не вижу нахрена тут нужен джит, когда этот инлайнинг вполне себе можно делать в HiPE. Или ты предлагаешь держать рантайм статистику вызовов, ещё более "ускоряя" выполнение эрлангового кода, и по ней делать инлайнинг на базе неких эвристик? C>Да. Плюс, может быть, ещё удастся сделать инлайнинг посылки сообщений (т.е. превратить посылку в прямой вызов).
См. альтернативные модели памяти для Эрланга, это уже давно рассматривалось
К>>Ну нафига нам JVM для эрланга? C>JVM быстрая.
Здравствуйте, Курилка, Вы писали:
C>>Да. Плюс, может быть, ещё удастся сделать инлайнинг посылки сообщений (т.е. превратить посылку в прямой вызов). К>См. альтернативные модели памяти для Эрланга, это уже давно рассматривалось
Это не имеет отношения к модели памяти как таковой. Я хочу, чтобы можно было вообще выбросить создание отдельного процесса, если к нему обращение только из одного процесса потом будет. Это радикально ускорит посылку сообщений в некоторых случаях.
К>>>Ну нафига нам JVM для эрланга? C>>JVM быстрая. К>Дак зачем тебе нужен эрланг-то тогда???
Удобный параллелизм, замена кода, удобный функциональный язык.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>Да. Плюс, может быть, ещё удастся сделать инлайнинг посылки сообщений (т.е. превратить посылку в прямой вызов). К>>См. альтернативные модели памяти для Эрланга, это уже давно рассматривалось C>Это не имеет отношения к модели памяти как таковой. Я хочу, чтобы можно было вообще выбросить создание отдельного процесса, если к нему обращение только из одного процесса потом будет. Это радикально ускорит посылку сообщений в некоторых случаях.
Т.е. ты хочешь чтоб думал, не человек, который дизайнит систему, а ИИ, встроенный в эрланговый рантайм. Понятно...
Странно, но вот почему-то пользователи Эрланга не согласны с тобой судя по всему.
К>>>>Ну нафига нам JVM для эрланга? C>>>JVM быстрая. К>>Дак зачем тебе нужен эрланг-то тогда??? C>Удобный параллелизм, замена кода, удобный функциональный язык.
Скалу возьми чтоль...
Здравствуйте, Курилка, Вы писали:
C>>Это не имеет отношения к модели памяти как таковой. Я хочу, чтобы можно было вообще выбросить создание отдельного процесса, если к нему обращение только из одного процесса потом будет. Это радикально ускорит посылку сообщений в некоторых случаях. К>Т.е. ты хочешь чтоб думал, не человек, который дизайнит систему, а ИИ, встроенный в эрланговый рантайм. Понятно...
Ага.
К>Странно, но вот почему-то пользователи Эрланга не согласны с тобой судя по всему.
Странно, почему это пользователи GCC ещё не начали кампаний по отмене оптимизаций и возврату к ассемблеру...
К>>>Дак зачем тебе нужен эрланг-то тогда??? C>>Удобный параллелизм, замена кода, удобный функциональный язык. К>Скалу возьми чтоль...
Актёры в Скале — это здорово. Но это всего лишь удачные обходы недостатков самой JVM.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
К>>Странно, но вот почему-то пользователи Эрланга не согласны с тобой судя по всему. C>Странно, почему это пользователи GCC ещё не начали кампаний по отмене оптимизаций и возврату к ассемблеру...
Доказательства по аналогии идут сам понимаешь какой траекторией.
Кстати, в твоей аналогии Эрланг выходит ассемблером чтоли?
И из этого ассемблера ты хочешь сделать GCC? Может С++0X в Эрланг транслировать?
К>>>>Дак зачем тебе нужен эрланг-то тогда??? C>>>Удобный параллелизм, замена кода, удобный функциональный язык. К>>Скалу возьми чтоль... C>Актёры в Скале — это здорово. Но это всего лишь удачные обходы недостатков самой JVM.
Т.е. сделав в эрланге по сути JVM (по меньшей мере усложним до нужного уровня) мы не родим подобных недостатков?
На вопрос зачем так и не прозвучало конкретных аргументированных примеров.
А без конкретных юзкейсов и вариантов хороших решений все подобные рассуждения останутся лишь догадками.
Только людям работать надо.