Здравствуйте, WolfHound, Вы писали:
WH>Так что все эти расчеты идут в топку.
Не лез бы ты в очередной раз с указательными пальцами в темы, в которых ничего не понимаешь.
WH>Также смотри это
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 (по меньшей мере усложним до нужного уровня) мы не родим подобных недостатков?
На вопрос зачем так и не прозвучало конкретных аргументированных примеров.
А без конкретных юзкейсов и вариантов хороших решений все подобные рассуждения останутся лишь догадками.
Только людям работать надо.
Здравствуйте, 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-ов, и использует это при выводе. При наличии операций с плавающей запятой — не забудь поставить сверху гвард на флоат, тогда плавающая запятая скомпилируется в нативную.
