Re: Identifying sources of allocations in a toy Mandelbrot package

[Tomas Hlavaty]

On Sat 20 Jan 2024 at 19:03, Psionic K <psionik@positron.solutions> wrote:
> I was mainly hoping to start identifying forms that can do okay even
> in spite of the Elisp runtime, especially for these kind of iteration
> problems that could - but should not - generate lots of garbage.  The
> first rows go by in the blink of an eye because of the cache locality.
> Elisp is almost something.  The memory pathologies are likely
> affecting every other perceived lack of responsiveness.

I was curious about:
- How does native compilation improve things?
- How does fixed point arithmetic improve things?

Run:
(benchmark-run 1 (mandelbrot))

with the attached mandelbrot1.el (floating point):
after emacs-lisp-native-compile-and-load:
=> (120.40541861 1947 93.45048212499998)
after emacs-lisp-byte-compile-and-load:
=> (128.362728323 1942 93.44881820700004)

with the attached mandelbrot.el (fixed point):
after emacs-lisp-native-compile-and-load:
(32.898215598 2 0.09366582000001245)
after emacs-lisp-byte-compile-and-load:
(51.629763289 2 0.09165389300000015)

For comparison, the attached forth version test.fs takes about 6sec.

I find it interesting that:
- native compilation improves so little compared to byte compilation.
- floating point calculations are very slow.
- emacs-lisp is very slow

mandelbrot1.el
Description: application/emacs-lisp

mandelbrot.el
Description: application/emacs-lisp

test.fs
Description: Text document