| 1.1, proninyaroslav (ok), 11:24, 08/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 >приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размер
Интересно, причина в OCaml или в прямых руках разработчиков?
| | |
| |
| 2.3, Ordu (ok), 11:58, 08/03/2019 [^] [^^] [^^^] [ответить]
| +9 +/– |
 Развитая система типов плюс статическая типизация позволяют создавать API, которые инкапсулируя всё, что требует тщательной проработки, обходятся везде где можно памятью со стека, не нагружая кучу и сборщик мусора. Это всё те же идеи, которые отрабатывались в haskell'е и в C++. Плюс к этому оно не прибито гвоздями к какой-то выбранной парадигме, позволяя использовать те парадигмы, которые лучше ложатся на задачу.
То есть причина в OCaml. Но вероятно причина также в программистах: я полагаю, что люди пользующиеся ocaml'ом -- это существенно не случайная выборка из генсовокупности программистов. Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих. А такой человек, как минимум, не заурядная web-макака.
| | |
| |
| 3.12, Vkni (ok), 15:35, 08/03/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих.
В Хаскелях не хватает скорости.
| | |
| 3.25, Аноним (25), 13:59, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
> обходятся везде где можно памятью со стека,
> не нагружая кучу и сборщик мусора.
Вообще-то стэк OCaml-а аллоцирован в куче.
| | |
| |
| 4.27, Ordu (ok), 14:14, 09/03/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> обходятся везде где можно памятью со стека,
>> не нагружая кучу и сборщик мусора.
> Вообще-то стэк OCaml-а аллоцирован в куче.
Какая разница где он аллоцирован, если аллокация со стека сводится к одной арифметической инструкции процессора?
| | |
| |
| 5.29, Аноним (25), 14:24, 09/03/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости переаллоцируя весь "стек".
| | |
| |
| 6.30, Ordu (ok), 15:35, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
"стеке процессора"? Что за странное словосочетание? Ты хочешь сказать, что ocaml использует два стека? Один для нужд рантайма и параллельный стек для собственно программы? Да ладно, не может быть.
И да, о какой пересылке речь?
> Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые
> инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости
> переаллоцируя весь "стек".
Большую часть этих проверок можно делать статически. Или даже все эти проверки можно выполнять статически. Но тут уже от языка зависит, скажем от того, позволяет ли он выделять со стека куски памяти динамического размера, и используется ли при этом рекурсия, глубину которой компилятор просчитать не в состоянии.
> переаллоцируя весь "стек".
Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае плохо, и если на это идёт заточка, то переаллокации должны происходить только в сторону увеличения, чтобы их было бы немного за всё время выполнения программы. А вообще, я бы просто выкидывал исключение -- за стеком надо следить, и если его мало, то надо заранее заказать побольше.
Вообще мне странны твои слова, в том смысле, что я в Common Lisp'е постоянно выделял на стеке, и я был уверен в том, что стоимость этого выделения в большинстве ситуаций O(1) -- то есть проверка на переполнение и сложение. Что там sbcl делал в случае переполнения, я не задумывался никогда.
| | |
| |
| 7.31, Ordu (ok), 15:41, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Хотя я так подумал... про ocaml пишут, что у него generational gc, а выделение памяти из такой кучи, как я понимаю, не сильно дороже, чем выделение памяти из стека.
Разница будет при сборке мусора. Всё что было выделено на стеке эффективно освобождается перемещением указателя стека. А вот выделенное в куче там и остаётся, и каждое выделение из кучи приближает момент, когда будет необходим цикл сборки мусора.
| | |
| 7.32, Аноним (25), 18:11, 09/03/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Обычное название для стека, который адресуется регистром процессора RSP в случа... большой текст свёрнут, показать | | |
| |
| |
| 9.39, Аноним (25), 13:22, 10/03/2019 [^] [^^] [^^^] [ответить] | +/– | Контролем стека процессора занимается ОС см man limits conf , ставит сторожеву... текст свёрнут, показать | | |
|
| 8.35, Vkni (ok), 21:11, 09/03/2019 [^] [^^] [^^^] [ответить] | +/– | Только за счёт того, что компиляция программ занимает минуты или даже десятки ми... текст свёрнут, показать | | |
|
| 7.36, Vkni (ok), 21:14, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Один для нужд рантайма и параллельный стек для собственно
> программы? Да ладно, не может быть.
Почему? В Clean, например, 3 стека - ABC (atomic/boxed/control по типу того, что туда засовывается).
| | |
| |
| 8.37, Ordu (ok), 12:15, 10/03/2019 [^] [^^] [^^^] [ответить] | +/– | Потому что cache-locality Стек хорош в этом функции работают преимущественно с... текст свёрнут, показать | | |
| |
| 9.38, Vkni (ok), 13:11, 10/03/2019 [^] [^^] [^^^] [ответить] | +/– | Я думаю, что раза в полтора - всё-таки, рабочая глубина этих стеков будет меньше... текст свёрнут, показать | | |
| |
| 10.40, Ordu (ok), 14:06, 10/03/2019 [^] [^^] [^^^] [ответить] | +/– | Тут сложно навскидку рассуждать, но если с каждого из тех стеков надо всего одну... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 2.5, Cradle (?), 12:31, 08/03/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
популярен во франкоязычных странах. Сам по себе вполне не плох, но вот только в остальных странах к сожалению не особо популярен, нужно реально быть в голове французом чтобы предпочесть его плюсам или яве. В том смысле что начиная проект обычно сразу задумываешся с какими людьми будешь его делать вместе и как с ними будешь общаться; французы в этом плане довольно замкнуты.
| | |
| |
| 3.11, Vkni (ok), 15:34, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Зависит от задачи. Вычислительный код писать, например, очень неудобно, если не переопределить операторы. Многопоточности пока нет.
| | |
| 3.23, KonstantinB (ok), 00:41, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Ну почему же? В фейсбуке используют (см. reasonml). Docker for Mac тоже на нем написан.
| | |
|
| 2.10, Vkni (ok), 15:34, 08/03/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
И то, и другое. Ocaml - это в девичестве Caml Light, который был создан Ксавье Леруа и компанией в качестве высокопроизводительного компилятора функционального языка. И это у них осталось в культуре: одно из основных требований - это быстрота программ. Это требование, например, заставило их делать все вычисления "справа налево", сломав традиционное для ML слева направо.
| | |
| |
| 3.13, Vkni (ok), 15:37, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Упомянутая выше dune, кстати, тоже отрабатывает мгновенно за счёт умного кеширования. В Jane Street недавно был доклад на эту тему.
| | |
| 3.28, Аноним (25), 14:18, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
MLton для оптимизации выполняет unboxing, в аналогичных местах OCaml будет проверять младший бит, что бы различить значения и указатели. А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?
| | |
| |
| 4.34, Vkni (ok), 21:05, 09/03/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?
Чтобы выражение (f a b c d), которое обязано быть равным ((((f a) b) c) d), можно было заменять на прямой вызов функции f с вычисленными параметрами a b c d. Это изложено в книжке https://xavierleroy.org/bibrefs/Leroy-ZINC.html (ссылка local copy), на странице 14.
Они ребята последовательные, поэтому это вычисление справа налево у них везде - я проверял. Делается структура, массив, кортеж, что угодно - везде справа налево. Ну кроме блока последовательных процедур, конечно.
| | |
| |
| 5.41, Аноним (25), 14:12, 10/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Благодарю. Однако, там же сказано (со ссылкой на Драгонбук), что преимущество может дать неопределённый порядок вычисления аргументов, принятый в C.
In Objective CAML, the order of evaluation of arguments is not specified. As it happens, today all implementations of Objective CAML evaluate arguments from left to right. All the same, making use of this implementation feature could turn out to be dangerous if future versions of the language modify the implementation.
http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora029.html
| | |
| |
| 6.43, Vkni (ok), 14:47, 10/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Ну там лажа написана - надо поменять. Простейшая проверка показывает, что right to left:
# let f x y = (x, y);;
val f : 'a -> 'b -> 'a * 'b = <fun>
# f (print_string "Left") (print_string "Right");;
RightLeft- : unit * unit = ((), ())
Понятно, что чем больше у компилятора возможностей, тем больше может быть степень оптимизации. Но сейчас всё согласовано - right to left.
| | |
| |
| 7.44, Аноним (25), 16:23, 10/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если там перепутали порядок вычисления аргументов в существующих имплементациях, это одно. Другое дело, что кроме того там написано "порядок не определён; так получилось, что аргументы вычисляются так-то, но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".
| | |
| |
| 8.45, Vkni (ok), 19:26, 10/03/2019 [^] [^^] [^^^] [ответить] | +/– | Ну я бы не стал рассчитывать на такие тонкости, с учётом тех серьёзных изменений... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.26, Аноним (25), 14:08, 09/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
print_endline "Hello World!";;
компилируется в 355944 байт (ocamlopt)
либо в 17793 байт (ocaml, байт-код)
| | |
|
| |
| |
| |
| 4.9, Cradle (?), 14:56, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
ок, спасибо, не знал. Сам на нее смотрел пару лет назад как на альтернативу freertos для allwiner (была идея выделить у A20 одно ядро под реалтайм), но не решился, да и не пошел тот проект у нас.
| | |
|
|
| 2.24, KonstantinB (ok), 00:45, 09/03/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это ОС в виде библиотеки (статически линкуемой, разумеется). В эмбедовке такой подход применяется повсеместно.
| | |
|
| 1.4, Аноним (4), 12:17, 08/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Гайс, обоснуйте в ней можно будет полноценно установить/запустить например брайзер чтобы он там в своём соку варилась и ни как не взаймидействовала с основной системой? Или есть что-то другое что вы можете предложить.
| | |
| |
| 2.15, Аноним (15), 16:56, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это для краснoглазиков любящих сервера и консоли, гуй не нужен.
| | |
| 2.19, Аноним (19), 18:43, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это хромопроблемы. В файрфокс метрики нет от слова "вообще", его хоть из-под рута можно запускать (я и запускаю иногда, кстати) и ничего не случится. Недавно добавили защиту от биткоина например. Ждем тебя в своих рядах, хромер!
| | |
|
| 1.18, erthink (ok), 17:21, 08/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 О mirage-kv написано совершенно не верно. Это не библиотека, а набор сигнатур OCaml (спецификация интерфейса) для взаимодействия с абстрактным key-value storage engine. К git это никакого отношения не имеет, совсем.
Далее, есть отдельный проект https://github.com/mirage/irmin, реализующий некую модульную базу данных. Так вот в этом Irwin-не есть модули для взаимодействия с git и для хранения данных внутри (с опорой на сервисы) Mirage-OS. В том числе этот Irwin конечно умеет предоставлять доступ через интерфейс описанный в mirage-kv.
Т.е. при жалении этот Irwin и его взаимодействие с Git можно пользовать без Mirage-OS (но не стоит думать что оно может конкурировать по скорости с RocksDB, Tarantool или libmdbx).
| | |
| |
| 2.21, Cradle (?), 22:34, 08/03/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
да, кстати, сам только сейчас понял что действительно скучаю по такой юнности в которой дос был бы аккуратно написан в открытых исходниках на окамле...
| | |
|
|
