forum.opennet.ru

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

Оглавление

Выпуск MirageOS 3.5, платформы для запуска приложений поверх..., opennews (ok), 08-Мрт-19, (0) [смотреть все]

Интересно, причина в OCaml или в прямых руках разработчиков , proninyaroslav (ok), 11:24 , 08-Мрт-19, (1) –1 //

Развитая система типов плюс статическая типизация позволяют создавать API, котор, Ordu (ok), 11:58 , 08-Мрт-19, (3) +9 //

В Хаскелях не хватает скорости , Vkni (ok), 15:35 , 08-Мрт-19, (12) –2
Вообще-то стэк OCaml-а аллоцирован в куче , Аноним (25), 13:59 , 09-Мрт-19, (25) //

Какая разница где он аллоцирован, если аллокация со стека сводится к одной арифм, Ordu (ok), 14:14 , 09-Мрт-19, (27) +1

Во-первых, говоря о стеке процессора, ты забыл про пересылку данных Во-вторых, д, Аноним (25), 14:24 , 09-Мрт-19, (29) +1

стеке процессора Что за странное словосочетание Ты хочешь сказать, что ocaml, Ordu (ok), 15:35 , 09-Мрт-19, (30)

Хотя я так подумал про ocaml пишут, что у него generational gc, а выделение п, Ordu (ok), 15:41 , 09-Мрт-19, (31)
Обычное название для стека, который адресуется регистром процессора RSP в случа, Аноним (25), 18:11 , 09-Мрт-19, (32) +1

На оба стека , Ordu (ok), 18:49 , 09-Мрт-19, (33)

Контролем стека процессора занимается ОС см man limits conf , ставит сторожеву, Аноним (25), 13:22 , 10-Мрт-19, (39)

Только за счёт того, что компиляция программ занимает минуты или даже десятки ми, Vkni (ok), 21:11 , 09-Мрт-19, (35)

Почему В Clean, например, 3 стека - ABC atomic boxed control по типу того, что, Vkni (ok), 21:14 , 09-Мрт-19, (36)

Потому что cache-locality Стек хорош в этом функции работают преимущественно с, Ordu (ok), 12:15 , 10-Мрт-19, (37)

Я думаю, что раза в полтора - всё-таки, рабочая глубина этих стеков будет меньше, Vkni (ok), 13:11 , 10-Мрт-19, (38)

Тут сложно навскидку рассуждать, но если с каждого из тех стеков надо всего одну, Ordu (ok), 14:06 , 10-Мрт-19, (40)

142 многовато, вот 128 CODE cat hello asm fasm demonstration of writing simp, Аноним (25), 14:23 , 10-Мрт-19, (42)

ЖЫрнота, особенно по зависимостям code cat real_hello_world asmBASE equ 07c00, Аноним84701 (ok), 22:05 , 10-Мрт-19, (46)
Это же MBR размером 512 байт на некотором железе не запустится , а было Smalle, Аноним (47), 16:05 , 11-Мрт-19, (47)
Неа, см Специально считерил, срезав см последние три строчки - в интел-с, Аноним84701 (ok), 17:07 , 11-Мрт-19, (48)
Сами по себе эти 56 байт разве запустятся Всё одно, требуется некий аналог exe, Аноним (47), 06:51 , 12-Мрт-19, (49)

популярен во франкоязычных странах Сам по себе вполне не плох, но вот только в , Cradle (?), 12:31 , 08-Мрт-19, (5) –1 //

Зависит от задачи Вычислительный код писать, например, очень неудобно, если не , Vkni (ok), 15:34 , 08-Мрт-19, (11)
Ну почему же В фейсбуке используют см reasonml Docker for Mac тоже на нем н, KonstantinB (ok), 00:41 , 09-Мрт-19, (23)

И то, и другое Ocaml - это в девичестве Caml Light, который был создан Ксавье Л, Vkni (ok), 15:34 , 08-Мрт-19, (10) –1 //

Упомянутая выше dune, кстати, тоже отрабатывает мгновенно за счёт умного кеширов, Vkni (ok), 15:37 , 08-Мрт-19, (13)
MLton для оптимизации выполняет unboxing, в аналогичных местах OCaml будет прове, Аноним (25), 14:18 , 09-Мрт-19, (28) //

Чтобы выражение f a b c d , которое обязано быть равным f a b c d , можн, Vkni (ok), 21:05 , 09-Мрт-19, (34) +1

Благодарю Однако, там же сказано со ссылкой на Драгонбук , что преимущество мо, Аноним (25), 14:12 , 10-Мрт-19, (41)

Ну там лажа написана - надо поменять Простейшая проверка показывает, что right , Vkni (ok), 14:47 , 10-Мрт-19, (43)

Если там перепутали порядок вычисления аргументов в существующих имплементациях,, Аноним (25), 16:23 , 10-Мрт-19, (44)

Ну я бы не стал рассчитывать на такие тонкости, с учётом тех серьёзных изменений, Vkni (ok), 19:26 , 10-Мрт-19, (45)

print_endline Hello World компилируется в 355944 байт ocamlopt либо в 17793, Аноним (25), 14:08 , 09-Мрт-19, (26)

TL DR чуваки написали ядро ОС без поддержки userspace-процессов , Твоя мама (?), 11:52 , 08-Мрт-19, (2) +4 //

да, это для эмбедовки, Cradle (?), 12:46 , 08-Мрт-19, (6) //

MirageOS в первую очередь применяется в докере , Аноним (8), 14:16 , 08-Мрт-19, (8) –2 //

ок, спасибо, не знал Сам на нее смотрел пару лет назад как на альтернативу free, Cradle (?), 14:56 , 08-Мрт-19, (9)

Это ОС в виде библиотеки статически линкуемой, разумеется В эмбедовке такой п, KonstantinB (ok), 00:45 , 09-Мрт-19, (24) +1

Гайс, обоснуйте в ней можно будет полноценно установить запустить например брайз, Аноним (4), 12:17 , 08-Мрт-19, (4) //

ne, Аноним (7), 13:19 , 08-Мрт-19, (7) +1
Тебе как минимум для гуя нужно взаимодействие с системой , Аноним (14), 16:27 , 08-Мрт-19, (14)
Это для краснoглазиков любящих сервера и консоли, гуй не нужен , Аноним (15), 16:56 , 08-Мрт-19, (15)
Это хромопроблемы В файрфокс метрики нет от слова вообще , его хоть из-под рут, Аноним (19), 18:43 , 08-Мрт-19, (19)

О mirage-kv написано совершенно не верно Это не библиотека, а набор сигнатур OC, erthink (ok), 17:21 , 08-Мрт-19, (18) +1 //

Вижу что уже поправили Теперь норм , erthink (ok), 22:39 , 08-Мрт-19, (22)

Это для тех, кто скучает по DOSу , Аноним (20), 21:51 , 08-Мрт-19, (20) –1 //

да, кстати, сам только сейчас понял что действительно скучаю по такой юнности в , Cradle (?), 22:34 , 08-Мрт-19, (21) +4

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | 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-а аллоцирован в куче.
Какая разница где он аллоцирован, если аллокация со стека сводится к одной арифметической инструкции процессора?

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | 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

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

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

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

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

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

Ответить | Правка | Наверх | 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. По-моему я даже читал об этом что-то когда-то.

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

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

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

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

Ответить | Правка | Наверх | 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 килобайт или мегабайтов Хаскеля определяются вовсе не количеством стеков. Хаскель скорее всего тащит статически вкомпонованные библиотеки, поэтому и бинари такие огромные.

Ответить | Правка | Наверх | 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!

Ответить | Правка | Наверх | 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

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

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

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

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

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

Ответить | Правка | Наверх | 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

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

Ответить | Правка | Наверх | 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 недавно был доклад на эту тему.

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

Ответить | Правка | Наверх | 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....

Ответить | Правка | Наверх | 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Партнёры:

Хостинг:

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

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

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


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


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


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


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


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


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


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


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