help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identifying sources of allocations in a toy Mandelbrot package


From: Tomas Hlavaty
Subject: Re: Identifying sources of allocations in a toy Mandelbrot package
Date: Sat, 20 Jan 2024 10:09:21 +0100

On Sat 20 Jan 2024 at 12:14, Psionic K <psionik@positron.solutions> wrote:
> I had presumed at a minimum that the compiler can re-use heap locations
> when it decides there's no risk.

garbage collector does this

> While the values will be in the heap, is
> there a way to destructively re-use heap locations so that we are not
> burning through all of the heap during iteration?  Do function calls re-use
> any heap space?  Does anything besides GC?   As it is, I can guess that
> every call to even + or * is creating a unique float that now exists on the
> heap until GC'd.

every lisp system represents data differently.
if a value is not immediate, it has to be consed.
maybe floating point numbers in emacs are not immediate.
it looks like emacs uses libgmp
and there are no special cases for IEEE representation.

for comparison, you could try your code on sbcl
and see how much better it gets just by using very sophisticated compiler

> Should I consider further modifications?

now it looks much nicer, well done

> (d 256) (dd 256.0)

this is fine, but it's used in single place,
could as well put the values directly in the code
without this let indirection

>                       (v 0) (not-escaped t))
>                   (while (and not-escaped
>                               (< v d))
>                     (if (> (+ (expt zr 2.0) (expt zi 2.0)) 4)
>                          (setq not-escaped nil)

not-escaped is not needed

                   (while (and (< v d)
                               (<= (+ (expt zr 2.0) (expt zi 2.0)) 4))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]