forum.opennet.ru - "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." (47)

"Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
Сообщение от opennews (ok), 08-Мрт-19, 11:24
Состоялся (https://mirage.io/blog/announcing-mirage-35-release) релиз операционной системы MirageOS 3.5 (https://mirage.io), позволяющая формировать операционные системы одного приложения, в которых приложение поставляется как самодостаточный "unikernel", способный выполняться без применения операционных систем, отдельного ядра ОС и каких-либо прослоек. Для разработки приложений применяется язык OCaml. Код проекта распространяется (https://github.com/mirage/mirage) под свободной лицензией ISC. Вся низкоуровневая функциональность, свойственная операционной системе, реализована в форме библиотеки, прикрепляемой к приложению. Приложение может быть разработано в любой ОС, после чего компилируется в специализированное ядро (концепция unikernel (http://queue.acm.org/detail.cfm?id=2566628)), которое может запускаться напрямую поверх гипервизоров Xen, KVM, BHyve и VMM (OpenBSD), поверх мобильных платформ, в форме процесса в POSIX-совместимом окружении или в облачных окружениях Amazon Elastic Compute Cloud и Google Compute Engine. Сгенерированное окружение не содержит ничего лишнего и взаимодействует непосредственно с гипервизором без драйверов и системных прослоек, что позволяет добиться существенного снижения накладных расходов и повышения безопасности. Работа с MirageOS сводится к трём стадиям: подготовка конфигурации с определением используемых в окружении OPAM-пакетов (https://opam.ocaml.org/), сборка окружения и запуск окружения. Runtime для обеспечения работы поверх Xen основан на урезанном ядре Mini-OS (https://wiki.xenproject.org/wiki/Mini-OS), а для других гипервизоров и систем на базе ядра Solo5 (https://github.com/solo5/solo5). Несмотря на то, что приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размер (например, DNS-сервер занимает всего 200 Кб). Упрощается и сопровождение окружений, так как при необходимости обновления программы или изменения конфигурации, достаточно создать и запустить новое окружение. Поддерживается несколько десятков библиотек (https://github.com/mirage) на языке OCaml для выполнения сетевых операций (DNS, SSH, OpenFlow, HTTP, XMPP и т.п.), работы с хранилищами и обеспечения параллельной обработки данных. Основные новшества: - Расширена спецификация интерфейсов для работы с БД в формате ключ/значение (mirage-kv), добавлено новое хранилище в формате ключ/значение с поддержкой операций чтения и записи, а также вариант хранилища для непостоянного хранения данных в оперативной памяти. Целью проведённое работы является замена интерфейса mirage-fs на хранилище в формате ключ/значение. Кроме того развивается распределённое хранилище irmin, предоставлявшее возможность создания ответвлений БД и доступа с использованием протокола Git, а также файловая система wodan, которая сможет использоваться на Flash-накопителях; - Расширены API библиотек mirage-clock (системные часы), mirage-protocols (сетевые протоколы) и mirage-net (сетевые устройства); - Повышено качестве предоставляемого генератора псевдослучайных чисел; - В реализации стека TCP/IP добавлена поддержка пересборки фрагментов пакетов IPv4 (fragment reassembly). Для TCP добавлена поддержка keepalive. Код для инкапсулирования/декапсулирования Ethernet и реализация протокола определения адресов (ARP) вынесены в отдельные OPAM-пакеты; - Добавлена поддержка запуска в качестве unikernel высокопроизводительного http-сервера httpaf (https://github.com/inhabitedtype/httpaf); - В пакете mirage-net, предоставляющем средства для низкоуровневого взаимодействия с сетевыми устройствами, реализованы бэкенды xen, solo5, unix, macos и vnetif; - В runtime на базе Solo5 добавлена поддержка работы поверх гипервизоров FreeBSD bhyve и OpenBSD VMM, обеспечена поддержка ARM64 и KVM, добавлена возможность работы с использованием микроядра GenodeOS; - Большинство пакетов переведены на использование сборочной системы dune (https://dune.build/) (jbuilder). Всего для MirageOS подготовлено более 100 OPAM-пакетов; - Добавлена возможность прикрепления пакетов-зависимостей к unikernel, для работы с которыми требуется наличие пакетного менеджера opam 2.0.2 или более новой версии; - Добавлена поддержка языка OCaml 4.06.0 в режиме безопасной работы со строками (safe-string). URL: https://mirage.io/blog/announcing-mirage-35-release Новость: https://www.opennet.dev/opennews/art.shtml?num=50278
Ответить \| Правка \| Cообщить модератору

Оглавление

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., proninyaroslav (ok), 11:24 , 08-Мрт-19, (1) –1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 11:58 , 08-Мрт-19, (3) +9

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 15:35 , 08-Мрт-19, (12) –2
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 13:59 , 09-Мрт-19, (25)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 14:14 , 09-Мрт-19, (27) +1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 14:24 , 09-Мрт-19, (29) +1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 15:35 , 09-Мрт-19, (30)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 15:41 , 09-Мрт-19, (31)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 18:11 , 09-Мрт-19, (32) +1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 18:49 , 09-Мрт-19, (33)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 13:22 , 10-Мрт-19, (39)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 21:11 , 09-Мрт-19, (35)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 21:14 , 09-Мрт-19, (36)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 12:15 , 10-Мрт-19, (37)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 13:11 , 10-Мрт-19, (38)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Ordu (ok), 14:06 , 10-Мрт-19, (40)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 14:23 , 10-Мрт-19, (42)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним84701 (ok), 22:05 , 10-Мрт-19, (46)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (47), 16:05 , 11-Мрт-19, (47)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним84701 (ok), 17:07 , 11-Мрт-19, (48)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (47), 06:51 , 12-Мрт-19, (49)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Cradle (?), 12:31 , 08-Мрт-19, (5) –1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 15:34 , 08-Мрт-19, (11)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., KonstantinB (ok), 00:41 , 09-Мрт-19, (23)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 15:34 , 08-Мрт-19, (10) –1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 15:37 , 08-Мрт-19, (13)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 14:18 , 09-Мрт-19, (28)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 21:05 , 09-Мрт-19, (34) +1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 14:12 , 10-Мрт-19, (41)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 14:47 , 10-Мрт-19, (43)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 16:23 , 10-Мрт-19, (44)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Vkni (ok), 19:26 , 10-Мрт-19, (45)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (25), 14:08 , 09-Мрт-19, (26)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Твоя мама (?), 11:52 , 08-Мрт-19, (2) +4

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Cradle (?), 12:46 , 08-Мрт-19, (6)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (8), 14:16 , 08-Мрт-19, (8) –2

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Cradle (?), 14:56 , 08-Мрт-19, (9)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., KonstantinB (ok), 00:45 , 09-Мрт-19, (24) +1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (4), 12:17 , 08-Мрт-19, (4)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (7), 13:19 , 08-Мрт-19, (7) +1
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (14), 16:27 , 08-Мрт-19, (14)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (15), 16:56 , 08-Мрт-19, (15)
Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (19), 18:43 , 08-Мрт-19, (19)

Неверное описание mirage-kv, erthink (ok), 17:21 , 08-Мрт-19, (18) +1

Неверное описание mirage-kv, erthink (ok), 22:39 , 08-Мрт-19, (22)

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Аноним (20), 21:51 , 08-Мрт-19, (20) –1

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., Cradle (?), 22:34 , 08-Мрт-19, (21) +4

Сообщения по теме [Сортировка по времени | RSS]

1. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." –1 +/–

Сообщение от proninyaroslav (ok), 08-Мрт-19, 11:24

>приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размер
Интересно, причина в OCaml или в прямых руках разработчиков?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +9 +/–

Сообщение от Ordu (ok), 08-Мрт-19, 11:58

Развитая система типов плюс статическая типизация позволяют создавать API, которые инкапсулируя всё, что требует тщательной проработки, обходятся везде где можно памятью со стека, не нагружая кучу и сборщик мусора. Это всё те же идеи, которые отрабатывались в haskell'е и в C++. Плюс к этому оно не прибито гвоздями к какой-то выбранной парадигме, позволяя использовать те парадигмы, которые лучше ложатся на задачу.
То есть причина в OCaml. Но вероятно причина также в программистах: я полагаю, что люди пользующиеся ocaml'ом -- это существенно не случайная выборка из генсовокупности программистов. Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих. А такой человек, как минимум, не заурядная web-макака.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

12. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." –2 +/–

Сообщение от Vkni (ok), 08-Мрт-19, 15:35

> Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих.
В Хаскелях не хватает скорости.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

25. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 09-Мрт-19, 13:59

> обходятся везде где можно памятью со стека,
> не нагружая кучу и сборщик мусора.
Вообще-то стэк OCaml-а аллоцирован в куче.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

27. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +1 +/–

Сообщение от Ordu (ok), 09-Мрт-19, 14:14

>> обходятся везде где можно памятью со стека,
>> не нагружая кучу и сборщик мусора.
> Вообще-то стэк OCaml-а аллоцирован в куче.
Какая разница где он аллоцирован, если аллокация со стека сводится к одной арифметической инструкции процессора?

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

29. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +1 +/–

Сообщение от Аноним (25), 09-Мрт-19, 14:24

Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости переаллоцируя весь "стек".

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Ordu (ok), 09-Мрт-19, 15:35

> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
"стеке процессора"? Что за странное словосочетание? Ты хочешь сказать, что ocaml использует два стека? Один для нужд рантайма и параллельный стек для собственно программы? Да ладно, не может быть.
И да, о какой пересылке речь?
> Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые
> инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости
> переаллоцируя весь "стек".
Большую часть этих проверок можно делать статически. Или даже все эти проверки можно выполнять статически. Но тут уже от языка зависит, скажем от того, позволяет ли он выделять со стека куски памяти динамического размера, и используется ли при этом рекурсия, глубину которой компилятор просчитать не в состоянии.
> переаллоцируя весь "стек".
Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае плохо, и если на это идёт заточка, то переаллокации должны происходить только в сторону увеличения, чтобы их было бы немного за всё время выполнения программы. А вообще, я бы просто выкидывал исключение -- за стеком надо следить, и если его мало, то надо заранее заказать побольше.
Вообще мне странны твои слова, в том смысле, что я в Common Lisp'е постоянно выделял на стеке, и я был уверен в том, что стоимость этого выделения в большинстве ситуаций O(1) -- то есть проверка на переполнение и сложение. Что там sbcl делал в случае переполнения, я не задумывался никогда.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Ordu (ok), 09-Мрт-19, 15:41

Хотя я так подумал... про ocaml пишут, что у него generational gc, а выделение памяти из такой кучи, как я понимаю, не сильно дороже, чем выделение памяти из стека.
Разница будет при сборке мусора. Всё что было выделено на стеке эффективно освобождается перемещением указателя стека. А вот выделенное в куче там и остаётся, и каждое выделение из кучи приближает момент, когда будет необходим цикл сборки мусора.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

32. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +1 +/–

Сообщение от Аноним (25), 09-Мрт-19, 18:11

>> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
> "стеке процессора"? Что за странное словосочетание?
Обычное название для стека, который адресуется регистром процессора (RSP в случае AMD64).
> Ты хочешь сказать, что ocaml использует
> два стека?
Да, именно о том я и писал выше.
> Один для нужд рантайма и параллельный стек для собственно
> программы? Да ладно, не может быть.

    Instruct(PUSH): Instruct(PUSHACC0):
      *--sp = accu; Next;
    Instruct(PUSHACC1):
      *--sp = accu; accu = sp[1]; Next;
    Instruct(PUSHACC2):
      *--sp = accu; accu = sp[2]; Next;
    Instruct(PUSHACC3):
      *--sp = accu; accu = sp[3]; Next;
    Instruct(PUSHACC4):
      *--sp = accu; accu = sp[4]; Next;
    Instruct(PUSHACC5):
      *--sp = accu; accu = sp[5]; Next;
    Instruct(PUSHACC6):
      *--sp = accu; accu = sp[6]; Next;
    Instruct(PUSHACC7):
      *--sp = accu; accu = sp[7]; Next;
> И да, о какой пересылке речь?
Пересылка данных из сохраняемого регистра в память (и наоборот).
>> Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые
>> инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости
>> переаллоцируя весь "стек".
> Большую часть этих проверок можно делать статически. Или даже все эти проверки
> можно выполнять статически. Но тут уже от языка зависит, скажем от
> того, позволяет ли он выделять со стека куски памяти динамического размера,
> и используется ли при этом рекурсия, глубину которой компилятор просчитать не
> в состоянии.

/* Stack checks */
    check_stacks:
      if (sp < caml_stack_threshold) {
        caml_extern_sp = sp;
        caml_realloc_stack(Stack_threshold / sizeof(value));
        sp = caml_extern_sp;
      }
      /* Fall through CHECK_SIGNALS */
>> переаллоцируя весь "стек".
> Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае
> плохо, и если на это идёт заточка, то переаллокации должны происходить
> только в сторону увеличения, чтобы их было бы немного за всё
> время выполнения программы. А вообще, я бы просто выкидывал исключение --
> за стеком надо следить, и если его мало, то надо заранее
> заказать побольше.
Так и сделано. Лимит можно задать перед выполнением.
> Вообще мне странны твои слова, в том смысле, что я в Common
> Lisp'е постоянно выделял на стеке, и я был уверен в том,
> что стоимость этого выделения в большинстве ситуаций O(1) -- то есть
> проверка на переполнение и сложение. Что там sbcl делал в случае
> переполнения, я не задумывался никогда.
В OCaml на уровне языка отсутствует понятие "выделить на стеке". В случае ocamlopt целые числа могут быть аллоцированы в регистрах процессора, за что приходится платить проверкой младшего бита (что бы отличать их от boxed) и суженным вдвое диапазоном возможных значений. Кстати, в MLton эти проблемы решены, как и бесшовное взаимодействие с С.
С другой стороны, даже несмотря на простор для низкоуровневых оптимизаций, OCaml действительно в ряде случаев конкурирует с C, значит выигрыш достигается за счёт простоты реализации сложных алгоритмов и компетенции разработчиков.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

33. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Ordu (ok), 09-Мрт-19, 18:49

> Так и сделано. Лимит можно задать перед выполнением.
На оба стека?

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

39. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 10-Мрт-19, 13:22

Контролем стека процессора занимается ОС (см. man limits.conf), ставит сторожевую страницу (в общем случае не даёт гарантий от переполнения).

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

35. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 09-Мрт-19, 21:11

> Кстати, в MLton эти проблемы решены, как и бесшовное взаимодействие с С.
Только за счёт того, что компиляция программ занимает минуты или даже десятки минут.
Компиляция же самого компилятора ocaml (make world -j1000/make world.opt -j1000) на серьёзном сервере проходит секунд за 40.
Я не хочу умалять достоинства MLton, но это, всё-таки, исследовательский компилятор.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

36. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 09-Мрт-19, 21:14

> Один для нужд рантайма и параллельный стек для собственно
> программы? Да ладно, не может быть.
Почему? В Clean, например, 3 стека - ABC (atomic/boxed/control по типу того, что туда засовывается).

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

37. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Ordu (ok), 10-Мрт-19, 12:15

Потому что cache-locality. Стек хорош в этом: функции работают преимущественно с локальными переменными, которые либо в регистрах либо на стеке. Всякие там адреса возврата туда же попадают, и всё получается неплохо. Если же мы начинаем раскидывать это по трём стекам, то в кеш начинает попадать больше ненужного -- из стека же в кеш переносится не нужная переменная, а кусок памяти в 64 байта (cache line), содержащий эту переменную. Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше.
Ну и потому, что накладные расходы на поддержание этих трёх стеков. Одно дело, когда всё сводится к одному указателю, под который мы условились в нашем ABI использовать один регистр, и даже не паримся хранить этот указатель где-то ещё в памяти, другое дело, когда у тебя три указателя, тут даже на x86-64, где регистров общего назначения не 8 а 16, будет не очень комфортно три регистра терять под стек. А уж на 32-х битной платформе, ты неизбежно упрёшься в необходимость хранить эти указатели в статических переменных, а эти статические переменные в кеше. И это добавит тебе лишний уровень индирекции: чтобы взять значение по его смещению от вершины стека, надо прочитать указатель стека из памяти в регистр, а потом разадресовать регистр.
При этом, я не удивлюсь, если x86 имеет в себе специальные фишки, которые делают операции со стеком быстрее, если стек построен на bp/ebp/rbp, а не на каком-нибудь там esi или r15. По-моему я даже читал об этом что-то когда-то.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 10-Мрт-19, 13:11

> Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше.
Я думаю, что раза в полтора - всё-таки, рабочая глубина этих стеков будет меньше. Кроме того, Clean очень лёгкий:
module Hello
Start :: String
Start = "Hello World!"
компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля.
С третьей стороны, возможно они и как-то сливают вместе эти стеки - надо посмотреть кодогенератор.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

40. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Ordu (ok), 10-Мрт-19, 14:06

> рабочая глубина этих стеков будет меньше
Тут сложно навскидку рассуждать, но если с каждого из тех стеков надо всего одну 64-битную переменную, то выходит что две 64-байтовые кеш-линии заняты под 16 байт полезных данных. Это, наверное, чёрт с ним, двумя кеш-линиями больше, двумя меньше, какая собственно разница.
> Кроме того, Clean очень лёгкий:
> module Hello
> Start :: String
> Start = "Hello World!"
> компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля.
113Kb на hello world -- это "лёгкий"? ;) Лёгкий -- это 142 байта: http://timelessname.com/elfbin/
Но я это не к тому, что Clean тяжёлый, я это к тому, что размер этих 113 килобайт или мегабайтов Хаскеля определяются вовсе не количеством стеков. Хаскель скорее всего тащит статически вкомпонованные библиотеки, поэтому и бинари такие огромные.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

42. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 10-Мрт-19, 14:23

142 многовато, вот 128

$ cat hello.asm
; fasm demonstration of writing simple ELF executable
format ELF executable 3
entry start
segment readable executable
start:
        mov     eax,4
        mov     ebx,1
        mov     ecx,msg
        mov     edx,msg_size
        int     0x80
        mov     eax,1
        xor     ebx,ebx
        int     0x80
;segment readable writeable
msg db 'Hello world!',0xA
msg_size = $-msg

$ fasm hello.asm
flat assembler  version 1.73.06  (16384 kilobytes memory)
2 passes, 128 bytes.

$ ./hello
Hello world!

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

46. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним84701 (ok), 10-Мрт-19, 22:05

> 142 многовато, вот 128
ЖЫрнота, особенно по зависимостям!

% cat real_hello_world.asm
BASE equ 07c00h
VIDEO_MEM equ 0b800h
COLOR equ 02h * 100h
org BASE
use16
jmp 0:start
start:
cli
cld
xor ax,ax
mov ds,ax
sti
;*******************************
;set video out=80x25, 16 colors, page 0
;*******************************
mov ax,3
int 10h
mov ax, 500h ;0 page
int 10h
mov ax, VIDEO_MEM
mov es, ax
xor di, di
mov si, msg
mov ax, COLOR
mov cx, msg.len
print:
  lodsb
  stosw
  loop print
cli
hlt
msg db "Hello World!"
msg.len = $ - msg
;db BASE+510-$ dup(0)
;signature:
;dw 0aa55h
% fasm real_hello_world.asm
flat assembler  version 1.73.09  (16384 kilobytes memory)
2 passes, 56 bytes
% dd if=/dev/zero count=454 conv=notrunc seek=56 bs=1 of=real_hello_world.bin
% echo -n "\0x55\xaa" >> real_hello_world.bin

У меня длиннее (или что именно меряли последние два замера?) :) ?

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

47. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (47), 11-Мрт-19, 16:05

Это же MBR размером 512 байт (на некотором железе не запустится), а было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок).

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

48. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним84701 (ok), 11-Мрт-19, 17:07

> размером 512 байт
Неа, см:
>> 2 passes, 56 bytes
Специально считерил, "срезав" (см. последние три строчки - ";" в интел-синтаксисе комментарий) конец и дав подходящую команду для записи с помощью dd.
В принципе, можно и сам код еще (существенно) сделать меньше, но тогда оно может резко стать "qemu-only".
Но даже при размере в 512 байт оно выигрывает по размеру общих зависимостей (ни ld-elf, ни ядра не нужно) :P
Кстати, могу еще предложить:

cat hello.asm
org 100h
use16
mov dx, msg
mov ah, 09h
int 21h
int 20h
msg db 'Hello World!',0Ah,'$'
% fasm hello.asm
flat assembler  version 1.73.09  (16384 kilobytes memory)
2 passes, 23 bytes.

> (на некотором железе не запустится),
Оно ж уже и не модно, давно. Тем более и на "том" железе была куча проблем и проблемок (а так же костылей, костыликов и подпорочек -- достаточно откопать LILO или глянуть (возможно, в старый вариант) GRUB).
Хотя замена старых костылей на "молодежные" PE + FAT32 вообще за гранью добра и зла …

> было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок).
Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках ;)
см.
>> компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля
На самом деле тут еще желательно знать, что там линкуется статистически, а что динамически, т.к. тот же HelloWorld на Си при "gcc -static -s" запросто может выдать бинарник на 500КБ c гаком, а для плюсов и на все полтора, но те кто обсуждают, скорее всего более-менее в курсе или же могут посмотреть.
Однако, одно дело "стандартный" бинарник с использованием стандартной библиотеки/рантайма и совершенно другое -- "минимальный бинарник", с вставками ASM и прямыми сискол-вызовами ядра.
Оно конечно прикольно, но вот желающих писать реальный софт таким макаром почему-то особо не видно и практическая ценность таких замеров примерно на том же уровне, что и замер кое-чего другого  ;)

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

49. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (47), 12-Мрт-19, 06:51

>> размером 512 байт
> Неа, см:
>>> 2 passes, 56 bytes
Сами по себе эти 56 байт разве запустятся? Всё одно, требуется некий аналог "executable format".
>[оверквотинг удален]
> use16
> mov dx, msg
> mov ah, 09h
> int 21h
> int 20h
> msg db 'Hello World!',0Ah,'$'
>  % fasm hello.asm
> flat assembler  version 1.73.09  (16384 kilobytes memory)
> 2 passes, 23 bytes.
Интересно, сколько выйдет подобное на каком-нибудь Sinclair BASIC, где PRINT занимает 1 байт, плюс 2 байта на номер строки, наверное, ещё что-то.
> Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках
> ;)
> см.
>>> компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля
Ну так то да, килобайты ныне "мало". :)
> На самом деле тут еще желательно знать, что там линкуется статистически, а
> что динамически, т.к. тот же HelloWorld на Си при "gcc -static
> -s" запросто может выдать бинарник на 500КБ c гаком, а для
> плюсов и на все полтора, но те кто обсуждают, скорее всего
> более-менее в курсе или же могут посмотреть.
> Однако, одно дело "стандартный" бинарник с использованием стандартной библиотеки/рантайма
> и совершенно другое -- "минимальный бинарник", с вставками ASM и прямыми
> сискол-вызовами ядра.
С++ с использованием std::cout -- 24.5 Kb. В зависимостях лишь обёртка над сисколами (ntdll).
https://code.google.com/archive/p/ontl/wikis/HelloWorld.wiki Полагаю, ничего не мешает портировать и в Linux.
> Оно конечно прикольно, но вот желающих писать реальный софт таким макаром почему-то
> особо не видно и практическая ценность таких замеров примерно на том
> же уровне, что и замер кое-чего другого  ;)
А если отправить в рассылку ядра какой-нибудь драйвер, скажем, на Rust. Линус выступит, покажет палец, тут впишется кто-то из этих, простите... ну, Вы поняли (надо же их наличие конвертировать в пользу для общества). Люди начнут об этом говорить, а? :)

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

5. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." –1 +/–

Сообщение от Cradle (?), 08-Мрт-19, 12:31

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 08-Мрт-19, 15:34

Зависит от задачи. Вычислительный код писать, например, очень неудобно, если не переопределить операторы. Многопоточности пока нет.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

23. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от KonstantinB (ok), 09-Мрт-19, 00:41

Ну почему же? В фейсбуке используют (см. reasonml). Docker for Mac тоже на нем написан.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." –1 +/–

Сообщение от Vkni (ok), 08-Мрт-19, 15:34

И то, и другое. Ocaml - это в девичестве Caml Light, который был создан Ксавье Леруа и компанией в качестве высокопроизводительного компилятора функционального языка. И это у них осталось в культуре: одно из основных требований - это быстрота программ. Это требование, например, заставило их делать все вычисления "справа налево", сломав традиционное для ML слева направо.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

13. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 08-Мрт-19, 15:37

Упомянутая выше dune, кстати, тоже отрабатывает мгновенно за счёт умного кеширования. В Jane Street недавно был доклад на эту тему.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

28. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 09-Мрт-19, 14:18

MLton для оптимизации выполняет unboxing, в аналогичных местах OCaml будет проверять младший бит, что бы различить значения и указатели. А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

34. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +1 +/–

Сообщение от Vkni (ok), 09-Мрт-19, 21:05

> А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?
Чтобы выражение (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.
Они ребята последовательные, поэтому это вычисление справа налево у них везде - я проверял. Делается структура, массив, кортеж, что угодно - везде справа налево. Ну кроме блока последовательных процедур, конечно.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

41. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 10-Мрт-19, 14:12

Благодарю. Однако, там же сказано (со ссылкой на Драгонбук), что преимущество может дать неопределённый порядок вычисления аргументов, принятый в 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....

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

43. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 10-Мрт-19, 14:47

Ну там лажа написана - надо поменять. Простейшая проверка показывает, что 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.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

44. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 10-Мрт-19, 16:23

Если там перепутали порядок вычисления аргументов в существующих имплементациях, это одно. Другое дело, что кроме того там написано "порядок не определён; так получилось, что аргументы вычисляются так-то, но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

45. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Vkni (ok), 10-Мрт-19, 19:26

> но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".
Ну я бы не стал рассчитывать на такие тонкости, с учётом тех серьёзных изменений в stdlib, которые произошли между 3 и 4. С другой стороны, то руководство вообще для дремучей версии 2.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

26. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (25), 09-Мрт-19, 14:08

print_endline "Hello World!";;
компилируется в 355944 байт (ocamlopt)
либо в 17793 байт (ocaml, байт-код)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +4 +/–

Сообщение от Твоя мама (?), 08-Мрт-19, 11:52

TL;DR: чуваки написали ядро ОС без поддержки userspace-процессов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Cradle (?), 08-Мрт-19, 12:46

да, это для эмбедовки

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." –2 +/–

Сообщение от Аноним (8), 08-Мрт-19, 14:16

MirageOS в первую очередь применяется в докере.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Cradle (?), 08-Мрт-19, 14:56

ок, спасибо, не знал. Сам на нее смотрел пару лет назад как на альтернативу freertos для allwiner (была идея выделить у A20 одно ядро под реалтайм), но не решился, да и не пошел тот проект у нас.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

24. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +1 +/–

Сообщение от KonstantinB (ok), 09-Мрт-19, 00:45

Это ОС в виде библиотеки (статически линкуемой, разумеется). В эмбедовке такой подход применяется повсеместно.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (4), 08-Мрт-19, 12:17

Гайс, обоснуйте в ней можно будет полноценно установить/запустить например брайзер чтобы он там в своём соку варилась и ни как не взаймидействовала с основной системой? Или есть что-то другое что вы можете предложить.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +1 +/–

Сообщение от Аноним (7), 08-Мрт-19, 13:19

ne

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

14. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (14), 08-Мрт-19, 16:27

Тебе как минимум для гуя нужно взаимодействие с системой.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

15. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (15), 08-Мрт-19, 16:56

Это для краснoглазиков любящих сервера и консоли, гуй не нужен.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

19. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +/–

Сообщение от Аноним (19), 08-Мрт-19, 18:43

Это хромопроблемы. В файрфокс метрики нет от слова "вообще", его хоть из-под рута можно запускать (я и запускаю иногда, кстати) и ничего не случится. Недавно добавили защиту от биткоина например. Ждем тебя в своих рядах, хромер!

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

18. "Неверное описание mirage-kv" +1 +/–

Сообщение от erthink (ok), 08-Мрт-19, 17:21

О 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).

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Неверное описание mirage-kv" +/–

Сообщение от erthink (ok), 08-Мрт-19, 22:39

Вижу что уже поправили. Теперь норм.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." –1 +/–

Сообщение от Аноним (20), 08-Мрт-19, 21:51

Это для тех, кто скучает по DOSу?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..." +4 +/–

Сообщение от Cradle (?), 08-Мрт-19, 22:34

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	–1 +/–
Сообщение от proninyaroslav (ok), 08-Мрт-19, 11:24
>приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размер Интересно, причина в OCaml или в прямых руках разработчиков?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+9 +/–
	Сообщение от Ordu (ok), 08-Мрт-19, 11:58
	Развитая система типов плюс статическая типизация позволяют создавать API, которые инкапсулируя всё, что требует тщательной проработки, обходятся везде где можно памятью со стека, не нагружая кучу и сборщик мусора. Это всё те же идеи, которые отрабатывались в haskell'е и в C++. Плюс к этому оно не прибито гвоздями к какой-то выбранной парадигме, позволяя использовать те парадигмы, которые лучше ложатся на задачу. То есть причина в OCaml. Но вероятно причина также в программистах: я полагаю, что люди пользующиеся ocaml'ом -- это существенно не случайная выборка из генсовокупности программистов. Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих. А такой человек, как минимум, не заурядная web-макака.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	12. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	–2 +/–
	Сообщение от Vkni (ok), 08-Мрт-19, 15:35
	> Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих. В Хаскелях не хватает скорости.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	25. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (25), 09-Мрт-19, 13:59
	> обходятся везде где можно памятью со стека, > не нагружая кучу и сборщик мусора. Вообще-то стэк OCaml-а аллоцирован в куче.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	27. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+1 +/–
	Сообщение от Ordu (ok), 09-Мрт-19, 14:14
	>> обходятся везде где можно памятью со стека, >> не нагружая кучу и сборщик мусора. > Вообще-то стэк OCaml-а аллоцирован в куче. Какая разница где он аллоцирован, если аллокация со стека сводится к одной арифметической инструкции процессора?
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	29. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+1 +/–
	Сообщение от Аноним (25), 09-Мрт-19, 14:24
	Во-первых, говоря о стеке процессора, ты забыл про пересылку данных. Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости переаллоцируя весь "стек".
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	30. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Ordu (ok), 09-Мрт-19, 15:35
	> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных. "стеке процессора"? Что за странное словосочетание? Ты хочешь сказать, что ocaml использует два стека? Один для нужд рантайма и параллельный стек для собственно программы? Да ладно, не может быть. И да, о какой пересылке речь? > Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые > инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости > переаллоцируя весь "стек". Большую часть этих проверок можно делать статически. Или даже все эти проверки можно выполнять статически. Но тут уже от языка зависит, скажем от того, позволяет ли он выделять со стека куски памяти динамического размера, и используется ли при этом рекурсия, глубину которой компилятор просчитать не в состоянии. > переаллоцируя весь "стек". Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае плохо, и если на это идёт заточка, то переаллокации должны происходить только в сторону увеличения, чтобы их было бы немного за всё время выполнения программы. А вообще, я бы просто выкидывал исключение -- за стеком надо следить, и если его мало, то надо заранее заказать побольше. Вообще мне странны твои слова, в том смысле, что я в Common Lisp'е постоянно выделял на стеке, и я был уверен в том, что стоимость этого выделения в большинстве ситуаций O(1) -- то есть проверка на переполнение и сложение. Что там sbcl делал в случае переполнения, я не задумывался никогда.
	Ответить \| Правка \| ^ к родителю #29 \| Наверх \| Cообщить модератору


	31. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Ordu (ok), 09-Мрт-19, 15:41
	Хотя я так подумал... про ocaml пишут, что у него generational gc, а выделение памяти из такой кучи, как я понимаю, не сильно дороже, чем выделение памяти из стека. Разница будет при сборке мусора. Всё что было выделено на стеке эффективно освобождается перемещением указателя стека. А вот выделенное в куче там и остаётся, и каждое выделение из кучи приближает момент, когда будет необходим цикл сборки мусора.
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	32. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+1 +/–
	Сообщение от Аноним (25), 09-Мрт-19, 18:11
	>> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных. > "стеке процессора"? Что за странное словосочетание? Обычное название для стека, который адресуется регистром процессора (RSP в случае AMD64). > Ты хочешь сказать, что ocaml использует > два стека? Да, именно о том я и писал выше. > Один для нужд рантайма и параллельный стек для собственно > программы? Да ладно, не может быть. Instruct(PUSH): Instruct(PUSHACC0): --sp = accu; Next; Instruct(PUSHACC1): --sp = accu; accu = sp[1]; Next; Instruct(PUSHACC2): --sp = accu; accu = sp[2]; Next; Instruct(PUSHACC3): --sp = accu; accu = sp[3]; Next; Instruct(PUSHACC4): --sp = accu; accu = sp[4]; Next; Instruct(PUSHACC5): --sp = accu; accu = sp[5]; Next; Instruct(PUSHACC6): --sp = accu; accu = sp[6]; Next; Instruct(PUSHACC7): --sp = accu; accu = sp[7]; Next; > И да, о какой пересылке речь? Пересылка данных из сохраняемого регистра в память (и наоборот). >> Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые >> инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости >> переаллоцируя весь "стек". > Большую часть этих проверок можно делать статически. Или даже все эти проверки > можно выполнять статически. Но тут уже от языка зависит, скажем от > того, позволяет ли он выделять со стека куски памяти динамического размера, > и используется ли при этом рекурсия, глубину которой компилятор просчитать не > в состоянии. /* Stack checks / check_stacks: if (sp < caml_stack_threshold) { caml_extern_sp = sp; caml_realloc_stack(Stack_threshold / sizeof(value)); sp = caml_extern_sp; } / Fall through CHECK_SIGNALS */ >> переаллоцируя весь "стек". > Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае > плохо, и если на это идёт заточка, то переаллокации должны происходить > только в сторону увеличения, чтобы их было бы немного за всё > время выполнения программы. А вообще, я бы просто выкидывал исключение -- > за стеком надо следить, и если его мало, то надо заранее > заказать побольше. Так и сделано. Лимит можно задать перед выполнением. > Вообще мне странны твои слова, в том смысле, что я в Common > Lisp'е постоянно выделял на стеке, и я был уверен в том, > что стоимость этого выделения в большинстве ситуаций O(1) -- то есть > проверка на переполнение и сложение. Что там sbcl делал в случае > переполнения, я не задумывался никогда. В OCaml на уровне языка отсутствует понятие "выделить на стеке". В случае ocamlopt целые числа могут быть аллоцированы в регистрах процессора, за что приходится платить проверкой младшего бита (что бы отличать их от boxed) и суженным вдвое диапазоном возможных значений. Кстати, в MLton эти проблемы решены, как и бесшовное взаимодействие с С. С другой стороны, даже несмотря на простор для низкоуровневых оптимизаций, OCaml действительно в ряде случаев конкурирует с C, значит выигрыш достигается за счёт простоты реализации сложных алгоритмов и компетенции разработчиков.
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	33. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Ordu (ok), 09-Мрт-19, 18:49
	> Так и сделано. Лимит можно задать перед выполнением. На оба стека?
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	39. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (25), 10-Мрт-19, 13:22
	Контролем стека процессора занимается ОС (см. man limits.conf), ставит сторожевую страницу (в общем случае не даёт гарантий от переполнения).
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	35. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Vkni (ok), 09-Мрт-19, 21:11
	> Кстати, в MLton эти проблемы решены, как и бесшовное взаимодействие с С. Только за счёт того, что компиляция программ занимает минуты или даже десятки минут. Компиляция же самого компилятора ocaml (make world -j1000/make world.opt -j1000) на серьёзном сервере проходит секунд за 40. Я не хочу умалять достоинства MLton, но это, всё-таки, исследовательский компилятор.
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	36. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Vkni (ok), 09-Мрт-19, 21:14
	> Один для нужд рантайма и параллельный стек для собственно > программы? Да ладно, не может быть. Почему? В Clean, например, 3 стека - ABC (atomic/boxed/control по типу того, что туда засовывается).
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	37. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Ordu (ok), 10-Мрт-19, 12:15
	Потому что cache-locality. Стек хорош в этом: функции работают преимущественно с локальными переменными, которые либо в регистрах либо на стеке. Всякие там адреса возврата туда же попадают, и всё получается неплохо. Если же мы начинаем раскидывать это по трём стекам, то в кеш начинает попадать больше ненужного -- из стека же в кеш переносится не нужная переменная, а кусок памяти в 64 байта (cache line), содержащий эту переменную. Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше. Ну и потому, что накладные расходы на поддержание этих трёх стеков. Одно дело, когда всё сводится к одному указателю, под который мы условились в нашем ABI использовать один регистр, и даже не паримся хранить этот указатель где-то ещё в памяти, другое дело, когда у тебя три указателя, тут даже на x86-64, где регистров общего назначения не 8 а 16, будет не очень комфортно три регистра терять под стек. А уж на 32-х битной платформе, ты неизбежно упрёшься в необходимость хранить эти указатели в статических переменных, а эти статические переменные в кеше. И это добавит тебе лишний уровень индирекции: чтобы взять значение по его смещению от вершины стека, надо прочитать указатель стека из памяти в регистр, а потом разадресовать регистр. При этом, я не удивлюсь, если x86 имеет в себе специальные фишки, которые делают операции со стеком быстрее, если стек построен на bp/ebp/rbp, а не на каком-нибудь там esi или r15. По-моему я даже читал об этом что-то когда-то.
	Ответить \| Правка \| ^ к родителю #36 \| Наверх \| Cообщить модератору


	38. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Vkni (ok), 10-Мрт-19, 13:11
	> Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше. Я думаю, что раза в полтора - всё-таки, рабочая глубина этих стеков будет меньше. Кроме того, Clean очень лёгкий: module Hello Start :: String Start = "Hello World!" компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля. С третьей стороны, возможно они и как-то сливают вместе эти стеки - надо посмотреть кодогенератор.
	Ответить \| Правка \| ^ к родителю #37 \| Наверх \| Cообщить модератору


	40. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Ordu (ok), 10-Мрт-19, 14:06
	> рабочая глубина этих стеков будет меньше Тут сложно навскидку рассуждать, но если с каждого из тех стеков надо всего одну 64-битную переменную, то выходит что две 64-байтовые кеш-линии заняты под 16 байт полезных данных. Это, наверное, чёрт с ним, двумя кеш-линиями больше, двумя меньше, какая собственно разница. > Кроме того, Clean очень лёгкий: > module Hello > Start :: String > Start = "Hello World!" > компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля. 113Kb на hello world -- это "лёгкий"? ;) Лёгкий -- это 142 байта: http://timelessname.com/elfbin/ Но я это не к тому, что Clean тяжёлый, я это к тому, что размер этих 113 килобайт или мегабайтов Хаскеля определяются вовсе не количеством стеков. Хаскель скорее всего тащит статически вкомпонованные библиотеки, поэтому и бинари такие огромные.
	Ответить \| Правка \| ^ к родителю #38 \| Наверх \| Cообщить модератору


	42. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (25), 10-Мрт-19, 14:23
	142 многовато, вот 128 $ cat hello.asm ; fasm demonstration of writing simple ELF executable format ELF executable 3 entry start segment readable executable start: mov eax,4 mov ebx,1 mov ecx,msg mov edx,msg_size int 0x80 mov eax,1 xor ebx,ebx int 0x80 ;segment readable writeable msg db 'Hello world!',0xA msg_size = $-msg $ fasm hello.asm flat assembler version 1.73.06 (16384 kilobytes memory) 2 passes, 128 bytes. $ ./hello Hello world!
	Ответить \| Правка \| ^ к родителю #40 \| Наверх \| Cообщить модератору


	46. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним84701 (ok), 10-Мрт-19, 22:05
	> 142 многовато, вот 128 ЖЫрнота, особенно по зависимостям! % cat real_hello_world.asm BASE equ 07c00h VIDEO_MEM equ 0b800h COLOR equ 02h * 100h org BASE use16 jmp 0:start start: cli cld xor ax,ax mov ds,ax sti ;***************************** ;set video out=80x25, 16 colors, page 0 ;***************************** mov ax,3 int 10h mov ax, 500h ;0 page int 10h mov ax, VIDEO_MEM mov es, ax xor di, di mov si, msg mov ax, COLOR mov cx, msg.len print: lodsb stosw loop print cli hlt msg db "Hello World!" msg.len = $ - msg ;db BASE+510-$ dup(0) ;signature: ;dw 0aa55h % fasm real_hello_world.asm flat assembler version 1.73.09 (16384 kilobytes memory) 2 passes, 56 bytes % dd if=/dev/zero count=454 conv=notrunc seek=56 bs=1 of=real_hello_world.bin % echo -n "\0x55\xaa" >> real_hello_world.bin У меня длиннее (или что именно меряли последние два замера?) :) ?
	Ответить \| Правка \| ^ к родителю #42 \| Наверх \| Cообщить модератору


	47. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (47), 11-Мрт-19, 16:05
	Это же MBR размером 512 байт (на некотором железе не запустится), а было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок).
	Ответить \| Правка \| ^ к родителю #46 \| Наверх \| Cообщить модератору


	48. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним84701 (ok), 11-Мрт-19, 17:07
	> размером 512 байт Неа, см: >> 2 passes, 56 bytes Специально считерил, "срезав" (см. последние три строчки - ";" в интел-синтаксисе комментарий) конец и дав подходящую команду для записи с помощью dd. В принципе, можно и сам код еще (существенно) сделать меньше, но тогда оно может резко стать "qemu-only". Но даже при размере в 512 байт оно выигрывает по размеру общих зависимостей (ни ld-elf, ни ядра не нужно) :P Кстати, могу еще предложить: cat hello.asm org 100h use16 mov dx, msg mov ah, 09h int 21h int 20h msg db 'Hello World!',0Ah,'$' % fasm hello.asm flat assembler version 1.73.09 (16384 kilobytes memory) 2 passes, 23 bytes. > (на некотором железе не запустится), Оно ж уже и не модно, давно. Тем более и на "том" железе была куча проблем и проблемок (а так же костылей, костыликов и подпорочек -- достаточно откопать LILO или глянуть (возможно, в старый вариант) GRUB). Хотя замена старых костылей на "молодежные" PE + FAT32 вообще за гранью добра и зла … > было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок). Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках ;) см. >> компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля На самом деле тут еще желательно знать, что там линкуется статистически, а что динамически, т.к. тот же HelloWorld на Си при "gcc -static -s" запросто может выдать бинарник на 500КБ c гаком, а для плюсов и на все полтора, но те кто обсуждают, скорее всего более-менее в курсе или же могут посмотреть. Однако, одно дело "стандартный" бинарник с использованием стандартной библиотеки/рантайма и совершенно другое -- "минимальный бинарник", с вставками ASM и прямыми сискол-вызовами ядра. Оно конечно прикольно, но вот желающих писать реальный софт таким макаром почему-то особо не видно и практическая ценность таких замеров примерно на том же уровне, что и замер кое-чего другого ;)
	Ответить \| Правка \| ^ к родителю #47 \| Наверх \| Cообщить модератору


	49. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (47), 12-Мрт-19, 06:51
	>> размером 512 байт > Неа, см: >>> 2 passes, 56 bytes Сами по себе эти 56 байт разве запустятся? Всё одно, требуется некий аналог "executable format". >[оверквотинг удален] > use16 > mov dx, msg > mov ah, 09h > int 21h > int 20h > msg db 'Hello World!',0Ah,'$' > % fasm hello.asm > flat assembler version 1.73.09 (16384 kilobytes memory) > 2 passes, 23 bytes. Интересно, сколько выйдет подобное на каком-нибудь Sinclair BASIC, где PRINT занимает 1 байт, плюс 2 байта на номер строки, наверное, ещё что-то. > Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках > ;) > см. >>> компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля Ну так то да, килобайты ныне "мало". :) > На самом деле тут еще желательно знать, что там линкуется статистически, а > что динамически, т.к. тот же HelloWorld на Си при "gcc -static > -s" запросто может выдать бинарник на 500КБ c гаком, а для > плюсов и на все полтора, но те кто обсуждают, скорее всего > более-менее в курсе или же могут посмотреть. > Однако, одно дело "стандартный" бинарник с использованием стандартной библиотеки/рантайма > и совершенно другое -- "минимальный бинарник", с вставками ASM и прямыми > сискол-вызовами ядра. С++ с использованием std::cout -- 24.5 Kb. В зависимостях лишь обёртка над сисколами (ntdll). https://code.google.com/archive/p/ontl/wikis/HelloWorld.wiki Полагаю, ничего не мешает портировать и в Linux. > Оно конечно прикольно, но вот желающих писать реальный софт таким макаром почему-то > особо не видно и практическая ценность таких замеров примерно на том > же уровне, что и замер кое-чего другого ;) А если отправить в рассылку ядра какой-нибудь драйвер, скажем, на Rust. Линус выступит, покажет палец, тут впишется кто-то из этих, простите... ну, Вы поняли (надо же их наличие конвертировать в пользу для общества). Люди начнут об этом говорить, а? :)
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору


	5. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	–1 +/–
	Сообщение от Cradle (?), 08-Мрт-19, 12:31
	популярен во франкоязычных странах. Сам по себе вполне не плох, но вот только в остальных странах к сожалению не особо популярен, нужно реально быть в голове французом чтобы предпочесть его плюсам или яве. В том смысле что начиная проект обычно сразу задумываешся с какими людьми будешь его делать вместе и как с ними будешь общаться; французы в этом плане довольно замкнуты.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	11. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Vkni (ok), 08-Мрт-19, 15:34
	Зависит от задачи. Вычислительный код писать, например, очень неудобно, если не переопределить операторы. Многопоточности пока нет.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	23. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от KonstantinB (ok), 09-Мрт-19, 00:41
	Ну почему же? В фейсбуке используют (см. reasonml). Docker for Mac тоже на нем написан.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	10. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	–1 +/–
	Сообщение от Vkni (ok), 08-Мрт-19, 15:34
	И то, и другое. Ocaml - это в девичестве Caml Light, который был создан Ксавье Леруа и компанией в качестве высокопроизводительного компилятора функционального языка. И это у них осталось в культуре: одно из основных требований - это быстрота программ. Это требование, например, заставило их делать все вычисления "справа налево", сломав традиционное для ML слева направо.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	13. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Vkni (ok), 08-Мрт-19, 15:37
	Упомянутая выше dune, кстати, тоже отрабатывает мгновенно за счёт умного кеширования. В Jane Street недавно был доклад на эту тему.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	28. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (25), 09-Мрт-19, 14:18
	MLton для оптимизации выполняет unboxing, в аналогичных местах OCaml будет проверять младший бит, что бы различить значения и указатели. А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	34. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+1 +/–
	Сообщение от Vkni (ok), 09-Мрт-19, 21:05
	> А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении? Чтобы выражение (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. Они ребята последовательные, поэтому это вычисление справа налево у них везде - я проверял. Делается структура, массив, кортеж, что угодно - везде справа налево. Ну кроме блока последовательных процедур, конечно.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	41. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Аноним (25), 10-Мрт-19, 14:12
	Благодарю. Однако, там же сказано (со ссылкой на Драгонбук), что преимущество может дать неопределённый порядок вычисления аргументов, принятый в 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....
	Ответить \| Правка \| ^ к родителю #34 \| Наверх \| Cообщить модератору


	43. "Выпуск MirageOS 3.5, платформы для запуска приложений поверх..."	+/–
	Сообщение от Vkni (ok), 10-Мрт-19, 14:47
	Ну там лажа написана - надо поменять. Простейшая проверка показывает, что 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.
	Ответить \| Правка \| ^ к родителю #41 \| Наверх \| Cообщить модератору