Олег, Вы бы хоть не позорились и переименовали README.txt в README.md. У вас файл в формате Markdown, но из-за его расширения гитхаб его убого отрисовывает, а может отрисовывать красивые заголовки. Благодарностей не надо.
Во всяком случае, слов "работать без кучи" и "подсчёт ссылок" я в описании Ofront+ не вижу. В описании Вашего компилятора я не вижу ничего подобного следующему абзацу:
Цитата:
So the default memory management is done using reference counting. Unlike other lisp implementations, Ferret supports various memory management schemes,
* malloc/free - Allocations are handled by the system implementation. (Default memory management.)
* Memory Pooling - On memory constraint systems such as microcontrollers Ferret can use a memory pool to avoid heap fragmentation and calling malloc/free. Effectively running with no heap, allocating all memory at compile time on the stack.
* Third party allocators (i.e tcmalloc)
* Third party garbage collectors (i.e The Boehm-Demers-Weiser conservative garbage collector.) - All memory is managed by a third party GC disables reference counting.
Похоже на то, что в вопросах управления памятью ferret-lang кроет Ofront+ (равно как и большинство других оберонов) аки бык овцу. Другое дело, что Boehm GC - это скорее игрушка, но кто связался с транспиляцией через C/C++, тот будет страдать в любом случае, ввиду того, что Си не позволяет получить доступ к стеку и поэтому крайне проблематично сделать нормальный сборщик мусора. Думаю, что и в Вашем Обероне сборка мусора составляет проблему. Впрочем, Вы неприятный собеседник, и не потому, что Вы правы и знаете больше меня, а по другим причинам. Я с Вами разговор закончил и какое-то время буду воздерживаться от чтения Ваших сообщений. Однако этот вопрос всё же стоит 10 минут.
Пришлось самому скачать Ваш проект. Нельзя сказать, что я понял, что вот тут написано:
Код:
PROCEDURE MarkStack0* (sp: ADDRESS); (* exported in order to prevent inlining by C optimizers *)
VAR
nofcand: INTEGER; inc, p, stack0: ADDRESS;
align: RECORD ch: SHORTCHAR; p: S.PTR END;
cand: ARRAY 10000 OF ADDRESS;
BEGIN
nofcand := 0; stack0 := SystemMainStackFrame();
(* check for minimum alignment of pointers *)
inc := S.ADR(align.p) - S.ADR(align);
IF uLT(stack0, sp) THEN inc := -inc END;
WHILE sp # stack0 DO
S.GET(sp, p);
IF uLE(heapMin, p) & uLT(p, heapMax) THEN
IF nofcand = LEN(cand) THEN HeapSort(nofcand, cand); MarkCandidates(nofcand, cand); nofcand := 0 END;
cand[nofcand] := p; INC(nofcand)
END;
INC(sp, inc)
END;
IF nofcand > 0 THEN HeapSort(nofcand, cand); MarkCandidates(nofcand, cand) END
END MarkStack0;
Но похоже на то, что всё же это консервативный на стеке сборщик мусора. Если было бы не лень, можно было бы написать нечто подобное тому, что я в своё время сделал для BlackBox и показать, как это может привести к краху программы. Но в BB эта проблема решается ЕМНИП дроблением задачи на мелкие подзадачи в событийно-ориентированном подходе, т.е. стек регулярно опустошается, что сильно смягчает (или полностью устраняет) проблему, хотя стоимость решения я бы не назвал малой. Возможно, что если программы на Ofront+ писать так же, а на ferret - иначе, то Ofront+ даже будет работать лучше, чем ferret и меньше будет подвержен этим граблям. Однако надо понимать, что GC непредсказуемо по задержкам (кто-то же там выступал на тему приложений реального времени), а тот же подсчёт ссылок уже предсказуем, если мы понимаем структуру данных в программе, и его можно попытаться ещё вручную так разбить на мелкие слоёчки, либо создавать очередь на удаление, чтобы контролировать паузы на GC.
Неплохо было бы сравнить и быстродействие, но конечно, мне лень. Я в общем-то и не утверждал, что лисп быстрее Оберона, а утверждал ровно обратное. В лиспе все данные тегированы, за исключением каких-то особо извращённых случаев жёсткой оптимизации, а в Обероне есть нетегированные типы данных. Поэтому Оберон должен быть быстрее. Другое дело, что можно написать диалект лиспа со статической типизацией, но это уже всё же будет не совсем идейно чистый лисп. Если бы было иначе, меня бы не было на этом форуме вообще.
При всём при этом, Олег, спасибо! ferret - интересный проект, я включу его в область своих интересов. Иногда в спорах рождается истина (хотя редко).
Вход
FAQ
Поиск
